Des Tests Utilisateurs beaucoup plus efficaces et moins monotones !

avec RITE (Rapid Iterative Testing and Evaluation)…

L’idée est simple:
les changements sont effectués dés, qu’un problème est détecté avec certitude et que la solution est claire .
Autrement dit, une modification peut s’opérer suite au passage du 1er participant, et être testée, vérifiée avec les suivants : une valeur réelle et immédiate !

Née chez les équipes de développement Microsoft (Games Studio), la méthode RITE (.doc) innove dans la pratique des Tests Utilisateurs, et répond parfaitement aux exigences et à la réalité des projets d’aujourd’hui… Elle est d’ailleurs trés appropriée dans les contextes Agiles, de type SCRUM, par exemple…

Des Tests Utilisateurs plus efficaces…
Selon moi, l’essentiel des Tests Utilisateurs réside avant tout dans le feedback qu’ils procurent. Et c’est justement sur la restitution du Feedback, mais aussi et surtout sur son traitement et sa vérification que la méthode RITE se distingue des Tests Utilisateurs classiques, avec à la clé une confirmation en temps réel et donc une valeur immédiate.

Des Tests Utilisateurs moins monotones…
Si comme moi, vous avez déjà enchaîné une série de tests avec 8, parfois 12 ou jusqu’à 16 participants, sur une même application, selon un même protocole, vous savez que cela devient vite assez répétitif, voire à la longue carrément lassant. C’est notre boulot, me direz-vous, certes … mais la encore la méthode RITE, en rupture avec ce modèle figé, permet de se sortir d’une routine dans laquelle on peut vite tomber.

Des Tests Utilisateur tout aussi valides…
De la rigueur sur le choix des profils testés, un plan de test bien cadré, des scénarios de test, un protocole verbal (« Penser à voix haute »), un facilitateur… la méthode RITE n’a rien à envier aux Tests Utilisateurs, dits plus « classiques ».

RITE permet donc enfin d’exploiter cette richesse du nombre de participants, et joue sur le feeddback et la réactivité pour enfin VERIFIER immédiatement l’effet d’une solution implémentée sur l’interface. Valeur et réactivitéquand il faut … voilà ce qui m’intéresse vraiment, voilà ce que veulent nos Clients.
Pas de temps à perdre avec la rhétorique! Pour bien cadrer la démarche, les équipes de Microsoft proposent aussi une échelle de décision pour qualifier les problèmes rencontrés, et déterminer s’ils seront fixés et testés immédiatement. Une échelle qui tient la route, et qui est exploitable dans pas mal de contextes:

  • Type 1: Problèmes qui ont à la fois une cause évidente et une solution évidente qui est implémentable très vite => On fait la modification dans la foulée et on teste la nouvelle solution avec le participant suivant
  • Type 2 : Problèmes qui ont une cause évidente et une solution évidente mais qui cette fois n’est pas implémentable tout de suite => On continue avec le problème et on teste dés que c’est prêt
  • Type 3: Problèmes sans cause évidente (et donc sans solution évidente) = > On attend de voir ce qui se passe avec les autres participants
  • Type 4: Problèmes potentiellement liés à d’autres facteurs => là encore, on attend de voir !

Le Rapid Iterative Testing Evaluation (RITE) est vraiment une méthode de tests très très séduisante, mais elle nécessite 4 ingrédients essentiels:

  • de l’experience du Test Utilisateurs et du domaine testé pour l’ergonome qui facilitera les sessions de tests
  • de la disponibilité des équipes de développement ou de ceux chargés de réaliser ce qui est testé
  • de la réactivité et une bonne capacité d’adaptation côté équipe et côté ergonome
  • avant tout un esprit collaboratif … on travaille ensemble pour maximiser la valeur

Bref, voilà une vision plutôt pragmatique ! Qu’en pensez-vous ?

http://download.microsoft.com/download/5/c/c/5cc406a0-0f87-4b94-bf80-dbc707db4fe1/mgsut_MWTRF02.doc.doc

A propos de jc-Qualitystreet (Jean Claude Grosjean) 448 Articles
Jean Claude GROSJEAN - COACH d’Organisation. Coach d'Equipes - Coach Agile. J’accompagne la transformation des organisations et coach les PERSONNES, les EQUIPES dans leur nouveau parcours. La facilitation & la formation font aussi partie de mes activités. Me contacter: 06.20.98.58.40

5 Comments

  1. Je suis assez surpris sur la théorie de la méthode. Imagine que ton testeur n’est pas représentatif de ta cible (malgré ta sélection), tu fais un changement mais les 14 suivants attendaient la version avant changement du testeur 1. Tu auras donc fait un changement inutile. Non ?
    Je suis très curieux de ce process de test en tout cas que tu me fais découvrir, mais aussi prudent 🙂

  2. Bon, en principe ton participant est représentatif … mais bon tu as raison tout peut arriver.
    En tout cas, merci pour ton commentaire, qui me permet d’insister sur deux précautions essentielles :
    – "l’experience du Test Utilisateurs et du domaine testé pour l’ergonome"
    – "l’echelle pour qualifier le pb ergo : type 1, 2, 3, ou 4"

  3. Merci pour cette info qui m’intéresse tout particulièrement et est d’actualité pour moi.
    Pourrais-tu vérifier tes liens vers le .doc, je n’arrive pas à le télécharger, j’ai dû en fait faire la recherche sur le site de download de MS pour me procurer le fichier.
    Merci encore.

  4. Pareil, je suis très sceptique, puisque cela correspond à prendre un ou deux utilisateurs comme représentatifs de toute une cible !

    De plus, dans le cas de tests qualitatifs, l’intérêt sur un panel de 6, 8, 10 voire 12 utilisateurs est de pouvoir comparer les résultats et problèmes rencontrés afin de justifier au client les modifications à apporter ensuite, ou en tous cas de les prioriser.

    En méthodo agile, lorsque le client fait entièrement confiance à l’équipe et qu’il ne demande pas de rapports intermédiaires pourquoi pas…

  5. Je tombe sur cet article, quelques mois en retard mais peu importe 🙂

    Je me demandais si le eye tracking était utilisé dans ce genre de tests ou si cela avait été envisagé? En espérant une réponse de votre part 🙂

3 Trackbacks / Pingbacks

  1. Jean Claude Grosjean
  2. Yolène Louison
  3. Valtech Training

Les commentaires sont fermés.