Les 12 principes agiles du point de vue de l’UX

Toutes les méthodes agiles reposent sur les 12 principes énoncés dans le manifeste Agile. A travers cet article nous vous proposons de découvrir une interprétation de ces principes selon le point de vue UX.

Cet article est inspiré du livre Agile Experience Design, A Practitioner’s guide to making it work par Diana DeMarco Brown, édition Morgan Kaufmann, 2013

Principe 1 : Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Du point de vue de l’UX ce principe coule sous le sens. A la petite différence que dans notre domaine UX nous n’abordons pas forcément la fréquence des livraisons.
Cela se traduit plus précisément par :

  • une amélioration continue du produit pour satisfaire les besoins changeants des utilisateurs au fur et à mesure qu’ils utilisent le produit ;
  • la collecte de feedback régulier pour identifier les adaptations du produit qui sont nécessaires ;
  • la définition de priorités dans les changements en fonction de l’importance des besoins (satisfaire d’abord les besoins primaires et couvrir au fur et a mesure les besoins secondaires).

Principe 2 : Accueillez positivement les changements de besoins, même tard dans le projet.

Pour un expert UX la considération des changements sur un produit coule de source et ce peu importe le moment auquel ces changements sont exprimés. Au sein d’une équipe projet c’est plus difficile à gérer car cela demande une grande capacité d’adaptation. Les nouveaux besoins exprimés doivent être considérés comme des opportunités d’avoir un retour des utilisateurs avant la fin du projet et non comme des mauvaises nouvelles.

Principe 3 : Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

La livraison fréquente de produit opérationnel nécessite une optimisation du processus de conception en privilégiant les tâches à plus-value – c’est-à-dire celles qui conduisent à la production d’une fonctionnalité. Par exemple un expert UX devra privilégier la production de prototypes interactifs qu’il pourra présenter aux utilisateurs finaux plutôt que des écrans statiques plus difficilement testables. Ainsi il économise un cycle de conception permettant à l’équipe de livrer plus rapidement un produit testable.

Principe 4 : Les utilisateurs (ou leurs représentants) et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

C’est une bonne nouvelle ! Quoi de plus évident pour un expert UX !
Les utilisateurs doivent être omniprésents dans l’équipe. Il peuvent notamment l’être par le biais de personas affichés avec les user stories ou par l’implication des membres de l’équipe avec les experts UX lors de rencontre utilisateurs ;
Là ou dans les projets classiques seuls les managers rencontrent les personnes du métier, dans une équipe agile l’équipe métier est omniprésente.

Attention de ne pas faire blocage en tant qu’UX : impliquez des membres de l’équipe lors de rencontres utilisateur

Principe 5 : Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

L’équipe doit être motivée à fournir une bonne expérience aux utilisateurs du produit qu’elle délivre. L’omniprésence et la collecte du feedbacks des utilisateurs peut aider à motiver l’équipe dans ce sens. C’est également pour faciliter cela qu’il est nécessaire de communiquer la cible avant de débuter le projet.

Ensuite au sein du projet, pour maintenir un bon niveau de motivation, une idée assez efficace est de laisser la possibilité aux membres de l’équipe de changer d’activité. Cela est valable pour les experts UX. Assurez-vous d’avoir des personnes « interchangeables » au sein de l’équipe des compétences multiples au sein des personnes !

Principe 6 : La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Les échanges physiques peuvent parfois être perçus comme une perte de temps. Ainsi on va avoir tendance à communiquer par mail et ne pas s’assurer de la compréhension de l’interlocuteur ; Par exemple lorsque des maquettes fonctionnelles sont établies il est risqué de les communiquer par mail sans explication. Le storytelling est indispensable pour limiter les risques d’incompréhension et aider votre interlocuteur à se projeter dans le système conçu. Ce storytelling ne peut se faire qu’en contact face-to-face.

Principe 7 : Un logiciel opérationnel est la principale mesure d’avancement.

Cela est également valable pour l ‘équipe UX. Celle-ci ne sera pas évaluée sur les concepts d’utilisation établis ou sur les techniques UX utilisées mais bien sur le produit livré tout comme le reste de l’équipe de production. Qu’est-ce que cela implique ? Tout d’abord cela incite à réaliser des prototypes qui peuvent être implémentés par les équipes de développement (et donc trouver des compromis efficaces) tout en s’assurant de la bonne expérience fournie aux utilisateurs finaux.

Principe 8 : Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Une de grande difficulté des projets Agile est de créer un rythme de développement durable. Les équipes projets étant souvent en sous-effectif, cela est rendu encore plus difficile. Pour y parvenir le moyen le plus aisé est de décomposer le projet en tâche suffisamment petite pour permettre de conserver un rythme de développement régulier ;
Pour les UX, la tâche est également difficile l’analyse centrée utilisateur et la définition d’un concept sous-jacent nécessite d’avoir une vue holistique, ce qui va à l’encontre d’une décomposition en petite tâche. C’est le vrai challenge des UX.

Principe 9 : Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.

L’excellence technique implique d’une part une performance technique mais également une performance fonctionnelle permettant aux utilisateurs de satisfaire leurs besoins actuels et l’usage futur qu’ils feront du produit. Cela implique qu’au moment de la conception les équipes ne doivent pas seulement se contenter de considérer l’usage qui sera fait du système à sa livraison mais devront aussi se projeter pour anticiper les usages qui pourront en être faits à l’avenir. Le système devra permettre les évolutions identifiées lors de la collecte de feedback et les observations faites de l’utilisation du produit.

Principe 10 : La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Probablement ce qui parle le plus aux équipe UX. Produisez des concepts simples pour faciliter leur utilisation mais aussi pour faciliter les développements. Cela n’est pas une difficulté pour les experts UX.

Principe 11 : Les meilleures architectures, spécifications et conceptions émergent d’équipes auto organisées.

Toutes les personnes de l’équipe, quel que soit leur background, peuvent apporter de bonnes idées pour réaliser un produit de qualité.
Les experts UX sont en quelque sorte responsable de la qualité du produit livré (en tant que représentant du product owner). Ainsi ils doivent encourager les autres membres de l’équipe à être force de proposition et à s’approprier le produit.

Principe 12 : À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie ses comportements en conséquence.

Il s’agit là de la clé de l’efficacité mais la plus difficile à réaliser. Régulièrement les membres de l’équipe se réunissent pour réaliser une rétrospective (un bilan) et identifier les point d’amélioration. Il s’agit d’augmenter l’expérience de l’équipe (et non pas les expériences individuelles).

Les experts UX issus de la psychologie cognitive peuvent être des facilitateurs lors de ces rencontres. De part leur background métier ils ont les capacités d’écoute, de reformulation et de synthèse.

Concevoir un site en une journée c’est possible ?

Des méthodes simples peuvent vous aider à concevoir un site web à moindre coût tout en satisfaisant les attentes de vos utilisateurs. Cette approche est inspirée des démarches « Agile UX » que nous avons décrites plus en détails dans notre article UX et Agilité : le duo gagnant pour des produits efficaces.

Ici, nous vous proposons une approche en 5 temps que vous pouvez mettre en œuvre chez vos clients.

1. La vision

Commencez par décrire en quelques mots clés la vision de votre produit. Identifiez les arguments qui vont toucher votre cible, la convaincre à utiliser votre produit. Les éléments qui ressortent de la vision vous aideront à orienter votre message et définir les éléments d’incitation qui devront être mis en œuvre.

Une des techniques pour définir la vision d’un produit est la technique de la product box vision que J.-C. Grosjean décrit sur son blog.

2. La cible

Quelle est la cible visée par votre produit ? Quelles sont ses caractéristiques ? Ses attentes ? Vous devez ajuster votre vision aux caractéristiques de la cible visée. Pour ce faire, vous pouvez simplement vous servir d’un tableau sur lequel vous indiquez les principaux objectifs de votre cible d’un côté et de l’autre les moyens que vous allez lui offrir pour les atteindre.
Pour décrire votre cible vous pouvez par exemple utiliser la technique des personas.

3. La concurrence

Observez les produits concurrents. Enrichissez votre vision en fonction des moyens intéressants qu’ils offrent pour attirer leur public. Vous devrez être meilleurs qu’eux.

A l’issu de ces 3 premières étapes vous disposez d’une vision décrivant votre produit, ses avantages, son positionnement par rapport à la concurrence et les caractéristiques de vos principales cibles.

Vous pouvez débuter la conception.

4. L’architecture de l’information

Votre produit existe déjà ? Commencez par lister ce que vous proposez à vos clients en identifiant les éléments à conserver et ceux à améliorer. Pour cela vous aurez probablement besoin de support. Les feed-backs utilisateurs que vous aurez collectés et les statistiques d’utilisation sont des éléments précieux qui vous aideront lors de cette analyse.
La technique du card-sorting peut vous aider à définir une architecture de contenu.

5. Les écrans

Les contenus et les fonctionnalités sont identifiés, il ne vous reste plus qu’à mettre tout cela en musique. La maquette papier crayon reste un outil puissant et efficace pour agencer les fonctionnalités dans votre produit (découvrez nos astuces pour faire des maquettes efficaces). Pour chaque fonctionnalité, que vous concevez, posez-vous la question de savoir si votre utilisateur sera convaincu par ce que vous lui proposez ? Va t-il s’identifier et s’approprier les contenus et services proposés ?

N’hésitez pas un donner un petit coup de pouce pour guider ses choix avec les techniques du persuasive design.

Voilà comment en 1 journée vous pouvez concevoir un produit simple avec votre client. Cette approche est très adaptée aux petits budgets mais il n’en reste pas moins utile de l’enrichir avec des techniques issues de l’approche de développement centrée sur l’utilisateur. Ainsi, en fonction de vos contraintes, vous pouvez impliquer les utilisateurs dès la définition de la vision ou collecter leur feed-back sur le produit conçu.

[learn_more caption= »Les petits plus ! » state= »open »]

[/learn_more]

Améliorer l’UX en identifiant les vrais problèmes

Si vous développez une envie obsédante de vous améliorer, que ce soit d’un point de vue purement personnel ou professionnel, il est essentiel d’apprendre de ses erreurs afin de ne pas les reproduire.

Les bilans de projet sont le bon moment pour définir les améliorations car c’est le moment où vous pourrez réaliser une rétrospective objective du déroulement du projet.

A travers cet article nous vous présentons la technique des “5 pourquoi” qui vous permettra d’identifier la cause première (profonde) d’un problème identifié afin de le résoudre durablement. Si vous êtes expert UX, cette technique va vous en rappeler de nombreuses, notamment la technique de l’arbre des causes.

La question que vous vous posez

Comment définir des actions efficaces pour améliorer le déroulement des projets ?

Notre proposition : appliquez la technique des « 5 pourquoi »

Erreurs habituelles

Lorsque l’on détecte un problème, il est fréquent de le résoudre par des mesures qui ne l’éradiquent pas durablement car l’on n’identifie pas la cause première. La technique des “5 pourquoi” vous permet de cibler la cause d’origine de votre problème et ainsi de définir des actions qui permettront de le supprimer de manière durable.

Lors d’une session de “5 pourquoi” vous allez mettre sur la touche un à un les symptômes, et vous intéresser aux causes racines.

Généralement, si la session est bien menée, vous parviendrez à trouver la cause à l’origine du problème en 5 questions.

Nous vous conseillons de faire cet exercice avec toutes les personnes impliquées dans le projet. Veillez malgré tout à bien maîtriser les biais classiques d’une session en groupe (vous pouvez consulter notre article : Réussissez vos évaluations utilisateur ! sur Gargarismes Ergonomiques).

Avant la session

Demandez au préalable aux différentes personnes impliquées de décrire le problème rencontré. Les personnes interrogées devront décrire précisément le problème en répondant notamment aux questions “qui ?”, “quoi ?”, “quand ?” et “où ?”. Si le problème n’est pas suffisamment précis il sera difficile de l’analyser.

Pendant la session

Exposez aux participants la liste des problèmes identifiés et demandez-leur de définir ensemble le problème qui sera analysé durant la session. Gardez en tête que si vous voulez des résultats efficaces, vous ne pourrez quoi qu’il arrive traiter qu’un seul problème par session. On peut avoir tendance à vouloir résoudre tous les problèmes mais ne vous détrompez pas, si vous parvenez à en résoudre déjà un c’est positif !

L’idée est de trouver un problème suffisamment conséquent pour qu’il concerne toutes les personnes impliquées dans le projet. Par exemple : “Lors de la mise en ligne de notre site web, la page de connexion n’était pas disponible”.

Une fois le problème commun sélectionné, l’approche est la suivante :

  1. chaque personne reprend le problème identifié et note sur un post-it pourquoi, selon elle, ce problème est apparu ;
  2. chaque personne va ensuite individuellement au tableau et présente sa réflexion aux autres membres du groupe ;
  3. une fois que chaque personne est passée au tableau, le modérateur fait le tri (il rassemble les réponses similaires) ;
  4. et ainsi de suite 5 fois.

Vous allez ainsi obtenir un arbre logique plus ou moins élaboré. Le rôle du modérateur va être de mettre de l’ordre et idéalement de trouver un consensus sur les causes profondes.

Les 5 pourquoi

A la fin de la session, faites une rétrospective des causes identifiées afin de vous assurer que le raisonnement est complet. Pour cela parcourez le schéma en sens inverse et posez la question : « si la cause trouvée n’était pas intervenue y aurait-il eu d’autres causes qui auraient pu intervenir ? » Ainsi vous vous assurerez que votre raisonnement est complet et que toutes les causes ont été identifiées.

A l’issue du meeting, l’idéal est d’avoir une représentation du problème complète et partagée par toute l’équipe. Pour illustrer les réflexions, vous pouvez utiliser toute une série de diagramme de cause à effet, comme celui d’Ishikawa. Cependant, nous vous conseillons d’éviter de faire compliqué, un simple schéma suffit.

Quelques pièges à appréhender par le modérateur :

  • Pour chaque cause identifiée, veillez à ce qu’elle soit basée sur des faits réels (par exemple, ici « Le module de connexion était incompatible avec les changements réalisés” est un fait avéré, démontré, communément admis par toute l’équipe). Ne vous basez pas sur des éléments subjectifs. Pour chaque cause identifiée par une personne, demandez au groupe s’il s’agit effectivement d’un fait réel où d’un élément subjectif ;
  • Veillez à ce que chaque réponse au problème identifié soit unique (par exemple, on ne pourrait pas donner une réponse de type « Manque de budget et de compétence « . A chaque pourquoi, demandez de faire une seule phrase avec 1 sujet, 1 verbe, 1 complément) ;
  • C’est humain, les participants vont essayer de trouver des causes externes à l’équipe. Il faut absolument que les réponses au problème soit du ressort de l’équipe (il existe forcément des petites actions à faire par l’équipe pour aider à corriger le problème) ;
  • Veillez à ce que votre session ne tourne pas en règlement de compte car il arrive vite en réunissant toute l’équipe que des « coupables » soient désignés – or ces séances doivent se focaliser sur les causes et non pas sur les responsabilités, en partant toujours du principe que si un membre de l’équipe n’a pas réalisé une action attendue par d’autres personnes c’est qu’il y a une raison valable.

Après le meeting

Nous n’avons pas encore évoqué les solutions. C’est la prochaine étape. Suite à la réunion, le modérateur transmet le consensus, et chaque membre de l’équipe, à son niveau, va identifier des solutions simples (« quickwins ») à mettre en place.

La session de « 5 pourquoi » doit aboutir à l’identification d’actions à réaliser et à la désignation de personnes pour réaliser ces actions.

Limite de la technique

Attention, l’apparente simplicité de la technique est un leurre. Le modérateur devra faire preuve d’expertise pour conduire la session en groupe et avoir des éléments de réponse concrets à la fin.

Plus vous pratiquerez, plus vous maîtriserez les pièges classiques :

  • risque de ne pas aller assez en profondeur et de s’arrêter à un symptôme de surface ;
  • risque que les personnes se limitent à leur représentation du problème et à la connaissance qu’ils en ont (parfois erronée) ;
  • ne pas réussir à se poser les bonnes questions ;
  • tendance à associer une seule cause au problème alors qu’il y en a plusieurs.

Même si les résultats sont difficiles à reproduire d’une séance à une autre, ce n’est pas grave. Gardez à l’esprit que cette pratique rentre dans une logique itérative à long terme : plus vous réalisez ces rétrospectives, plus vous identifiez les vrais causes des problèmes et les « quickwins » salvateurs à mettre en place.

[learn_more caption= »Les petits plus ! » state= »open »]

[/learn_more]

Capter et prioriser les besoins de façon ludique avec les focus groups Agile UX

La technique du focus group consiste à réunir un groupe d’utilisateurs pour collecter leurs besoins, évaluer leurs perceptions d’un produit ou animer une réflexion sur un thème particulier. Elle est très souvent employée en marketing pour comprendre les attitudes des gens à l’égard d’une offre. Elle peut autant être employée pour recenser un besoin existant que pour en créer de nouveaux. C’est ce second cas de figure que nous ciblons dans le cadre de cet article. Nous parlons de focus group « Agile UX » car nous sommes convaincus que coupler les principes d’Agilité et d’UX (expérience utilisateur) est très efficace et bénéfique pour la réalisation de cette technique. Pour plus d’informations concernant la complémentarité des 2 approches, vous pouvez consulter notre précédent article « UX et Agile : Duo gagnant pour livrer des produits efficaces« .

[box type= »shadow »]

Prenez le train

Nous avons eu le grand plaisir de rédiger la 1ère version de cet article pour le magazine « Le train de 13h37 ». Merci pour leur confiance !

[/box]

En mode Agile, nous utilisons principalement cette technique pour alimenter le backlog (liste des thèmes à développer) fourni aux équipes en charge de l’implémentation. Cela permet d’obtenir un ensemble de user stories (thèmes utilisateurs) classés par priorité.

Ainsi plutôt que de démarrer d’une feuille blanche et de nombreuses hypothèses non vérifiées, cette technique va vous permettre de mieux cerner les attentes réelles des utilisateurs avec une première roadmap des scénarios à développer. Evidemment cette roadmap n’est qu’une première vue des besoins utilisateurs et aura besoin d’être complétée. L’expert UX, en intervenant tout au long du projet, va la façonner et l’enrichir. Elle sera également améliorée par l’équipe technique en charge de la réalisation du produit, en ajoutant les contraintes liées à la technologie.

Les bases de la technique

Votre objectif va être de collecter des données très précises auprès des utilisateurs finaux. Pour cela, vous allez devoir guider vos participants à travers une réflexion qui leur permettra de comprendre le but de votre produit et créer une atmosphère propice à l’idéation (émergence d’idées créatives).

Pour une mise en immersion efficace, nous utilisons les techniques issues de l’animation de groupe par le jeu.

Comme dans toutes les techniques d’idéation, le focus group « Agile UX » s’organise en 3 grandes phases :

  1. une phase « Ice Breaker » ;
  2. une phase de développement ;
  3. une phase de synthèse.

1ère phase : « Ice Breaker »

L’objectif de l’Ice Breaker est de mettre les participants en condition et d’instaurer une atmosphère propice à la génération d’idées. Cette phase doit vous permettre d’établir un lien entre toutes les personnes présentes pour qu’elles forment un groupe soudé.

Le principe du Ice Breaker est en soit très simple : il consiste à introduire l’objet de l’atelier et à demander à chaque personne de se présenter au reste du groupe. Pour créer une relation entre les membres du groupe il faut qu’il y ait contact.

Généralement nous procédons de la sorte :

  • nous demandons à tous les participants de se mettre ensemble autour d’une table ;
  • nous leur proposons de se décrire brièvement par écrit en répondant à 3 points (« Qui suis-je ? », « Quelle est ma fonction ? », « Quelles sont mes attentes de la séance ? ») ;
  • ensuite nous invitons chaque participant à transmettre leur description à leur voisin de droite ;
  • chaque participant découvre en silence la fiche de son voisin et l’annote d’une question ;
  • enfin chaque participant reprend sa fiche, se présente au reste du groupe et répond à la question posée.

Cette procédure très simple permet littéralement de briser la glace et de créer un climat de confiance et d’échange propice à l’idéation.

2ème phase : « Le développement d’idées »

La phase de développement consiste à faire émerger des idées. Pour cela vous devrez diriger votre séance en plusieurs étapes qui guideront vos participants vers la construction d’idées structurées.

Présentez votre vision

Tout d’abord, vous devez exposer le sujet d’étude aux participants du focus group. Nous vous conseillons de le faire sous forme de vision.

vision

La vision est un moyen de présenter votre produit de manière précise et structurée afin que les participants disposent des éléments nécessaires pour commencer la réflexion (à qui s’adresse le produit, comment il s’appelle, quels sont ses objectifs, les bénéfices qu’il procure par rapport à des produits concurrents, etc.). La vision peut se présenter de différentes manières, par exemple sous la forme d’un poster, d’un slide etc. Veillez à ce que la vision soit consultable par les participants tout au long du focus group, c’est essentiel pour le bon déroulement de la séance.

Une fois la vision exposée, nous vous conseillons de procéder en 2 étapes : tout d’abord le World Café (brainstorming amélioré), puis la rédaction de user stories.

Organisez un Word café – Brainstorming itératif

Plus vous allez faire des sessions en groupe, plus vous allez vous rendre compte que certains participants vont s’imposer et monopoliser le temps de parole. C’est un biais fréquent. L’étape précédente du Ice Breaker va entre autres vous permettre d’observer les comportements et de déceler les personnalités de vos participants. Un des moyens pour mieux maîtriser l’influence de certaines personnes est d’organiser le brainstorming sous la forme d’un World Café. Cela consiste à réunir les participants en petits groupes (essayez de faire des groupes homogènes en termes de personnalités), chacun autour d’une table, et de nommer un secrétaire par groupe pour formaliser les réflexions.

Après un temps imparti, demandez à chaque groupe, sauf au secrétaire, de rejoindre une autre table et de continuer la réflexion avec le secrétaire de la table qu’il a rejoint. Chaque secrétaire fait un debrief des réflexions menées par sa table, et l’on permet aux gens d’enrichir les réflexions.

Une fois que les groupes ont rencontré tous les secrétaires de table, ces derniers établissent un premier bilan des réflexions réalisées. Ces présentations n’ont pas besoin d’être trop formalisées, elles servent à poser les 1ères briques pour une réflexion plus structurée (user stories).

Rédaction des user stories

A ce stade de la séance, chaque participant est fortement imprégné de la vision du produit établie par vos soins et des nombreuses idées échangées en groupe. Il est temps désormais que chaque participant s’approprie les idées les plus importantes selon lui et les documente sous la forme de user stories.

story

Chaque participant va décrire sous forme d’histoire (c’est pour cela que l’on parle de user stories) 5 idées qu’il juge importantes selon le formalisme suivant : « En tant que…, je souhaite que le produit permette de… car cela apporterait l’avantage de… ».

Une fois les users stories rédigées, chaque participant les présente au reste de l’assemblée et les affiche sur un tableau commun. Puis les user stories identiques ou similaires sont regroupées. A ce stade, vous devrez vous assurer que les users stories exprimées sont comprises par tous mais également par l’équipe qui sera en charge de leur réalisation. En tant qu’animateur du groupe, vous êtes responsable de la clarté des user stories.

A l’issue de cette phase, vous êtes en possession des prémisses d’un backlog initial avec des groupements de user stories. Vous pouvez alors passer à la phase de synthèse.

3ème phase : « La synthèse »

De très nombreuses idées ont été avancées, il est difficile d’y voir clair. L’objectif désormais est d’essayer de réduire le nombre d’éléments, de les fédérer et de les regrouper en thèmes communs.

Regroupement des user stories en thèmes

group

Pour réduire le nombre d’éléments, vous allez demander aux participants de regrouper les user stories en thèmes. A ce stade, vous pouvez aisément employer la technique du card sorting. Même si vous ne respectez pas tous les pré requis, vous pouvez largement vous en inspirer. Pour entretenir la dynamique du groupe, il est préférable que les participants réalisent ce regroupement ensemble.

Ici, c’est l’animateur qui impacte les regroupements au tableau. Il s’assure que tous les participants interprètent correctement les user stories et les regroupements de thèmes réalisés.

Ca y est, vous disposez désormais de la liste des thèmes qui constituent votre roadmap. Il ne vous reste plus qu’à solliciter vos utilisateurs pour déterminer une priorité de réalisation.

Classer des thèmes en fonction de leur priorité

Pour définir un degré de priorité, vous pouvez utiliser la technique du MOSCOW planning.

MoSCoW

Pour réaliser cette technique, vous pouvez utiliser un tableau en 4 colonnes sur lequel les participants placent les thèmes : la première colonne représente le Must have (M), la deuxième colonne le Should have (So), la troisième le Could have (Co) et la dernière le Won’t have (W).

Chaque participant place les thèmes identifiés sur les colonnes de son choix, tour à tour, sur le même tableau. Chaque participant suivant se base sur le classement du participant précédent. Bien évidemment, il y a un effet d’ordre qui risque de biaiser les résultats, c’est pourquoi, à chaque passage, le changement proposé par un participant doit être argumenté et nécessite l’approbation du groupe entier. C’est l’exercice le plus complexe.

Ainsi, lorsque le dernier participant passe au tableau, on disposera d’une priorisation qui aura vécue plusieurs cycles de changements issus d’une réflexion collective. Attention ! Si vous décidez de faire terminer ce classement par une forte tête vous risquez d’obtenir une roadmap qui n’a pas l’accord du groupe. Le rôle de l’animateur est très important à ce niveau.

A la fin du MOSCOW planning vous obtiendrez probablement beaucoup d’éléments dans la colonne Must have (M) et peu voire aucun dans la colonne Won’t have (W) (à vrai dire c’est normal car les user stories sont créées par vos participants, ils vont les défendre becs et ongles). Vous devez donc aller encore plus en profondeur pour définir la séquence de réalisation des thèmes pour l’équipe de la réalisation : c’est là qu’intervient la technique du vote par point.

Distribution des points

Permettez aux participants de distribuer autant de points qu’il y a de thèmes. Tous les participants se rendent en même temps au tableau et répartissent leurs points comme bon leur semble sur l’ensemble des thèmes affichés. Ils peuvent répartir ces points équitablement ou décider de tous les placer sur un seul thème.

Cette étape est intéressante car elle permet de rééquilibrer les premiers classements faits par les participants dans les 4 colonnes.

Une fois les points administrés, vous pouvez appliquer une pondération (en associant un facteur par colonne).

dot-voting

Faites le compte de points en appliquant le facteur défini pour chaque colonne et ordonnez vos thèmes du plus grand score au plus petit. Votre roadmap utilisateur est définie !

Conclusion

Ca y est, vous disposez d’une roadmap priorisée des thèmes à développer par l’équipe de réalisation.

Bien évidemment, nous sommes tout à fait conscients que le déroulement d’une telle séance est sujette à de nombreux biais (d’ailleurs, nous vous conseillons la lecture de 2 articles pour approfondir les réflexions, le 1er : « Séance utilisateur : individuelle ou en groupe ? » et le 2ième : « Réussissez vos évaluations utilisateurs !« ). Nous sommes également tout à fait convaincus que réaliser un seul focus group de ce type n’est pas suffisant pour dresser une liste exhaustive et fidèle des besoins utilisateurs, et qu’il faut compléter cette démarche avec d’autres études utilisateurs tout au long du projet (par exemple une enquête de satisfaction, des tests utilisateurs, une analyse de l’usage etc.).

En guise de clôture de la séance, nous aimons rappeler aux participants le travail réalisé durant le focus group et insister sur l’objectif atteint. Vous pouvez également revenir sur les différentes phases du focus group et expliquer pourquoi vous avez procédé de la sorte. Ainsi, les participants partent sur une image positive et la sensation justifiée d’avoir travailler sur quelque chose de concret qui donne du sens.

Nous vous conseillons à ce stade d’expliquer la suite du projet, et d’insister sur le fait que l’équipe de réalisation va s’approprier les résultats au risque de faire évoluer la roadmap en fonction de certaines contraintes techniques. Rassurez-les et rappelez que votre rôle est de garantir la prise en compte des besoins utilisateurs et que vous ferez le nécessaire pour défendre leurs intérêts.

Vous pouvez également sonder parmi les utilisateurs qui serait intéressé pour participer de nouveau à une future session utilisateur, par exemple une séance de test utilisateur lors des premières phases de développement.

[learn_more caption= »En savoir plus ! » state= »open »]

[/learn_more]

Comment initier un changement efficace et durable ?

Que vous souhaitiez initier un changement ou pas, la conduite du changement est un processus en perpétuelle évolution qui ne correspond jamais à ce que l’on a pu prévoir.

Pourquoi ?

Les raisons sont simples :

  • le contexte est impacté par de nombreux facteurs variables que l’on ne maîtrise pas et fortement dépendant du système managérial et des systèmes d’influence en place ;
  • l’être humain est complexe. Il peut accepter une solution, la rejeter en force, participer de manière discrétionnaire (appropriation en détournant les objectifs d’origine)…

Le challenge lorsque l’on souhaite initier un changement est de provoquer l’appropriation du projet et la mobilisation générale. Pour favoriser les chances de réussite vous devez vous poser les questions de base avant de commencer vos travaux.

Par où commencer pour réussir son changement ?

Tout d’abord avant d’initier un changement qu’il soit organisationnel ou technique il est conseillé de se faire épauler par un expert neutre et externe, spécialisé en organisation et en approche centrée utilisateur afin de favoriser l’acceptation des mesures proposées.

Voici les points essentiels à appréhender avant d’initier un changement :

  1. identifiez l’objet réel et les objectifs du changement : s’agit-il d’introduire un nouveau système informatique, d’un changement d’organisation suite à une fusion, etc. ;
  2. à quel niveau s’opère ce changement ? Au top level (stratégique), au niveau managérial, au niveau opérationnel avec les équipes en place… les trois ? ;
  3. quels sont les groupes d’acteurs impliqués, les intérêts qu’ils défendent, la dynamique des groupes en place, les alliances, les moyens qu’ils ont de peser sur l’organisation, les comportements et attitudes qu’ils développent face au changement ;
  4. quels sont les mécanismes de prise de décision dans l’entreprise ? ;
  5. comment s’insère le changement dans le temps, notamment vis-à-vis des autres projets en cours ?

Ces différents points pourront être abordés, complétés et outillés par de nombreux modèles, notamment le modèle des 5 forces de Pichault. Ce dernier est tout à fait intéressant car il intègre les principaux grands courants sociologiques tout en proposant une grille concrète pour l’intervention.

[learn_more caption= »À lire sur le web » state= »open »]

[/learn_more]