Archives de l’auteur : Eric

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]

Qualité web : les bonnes pratiques pour améliorer vos sites

Auteurs : Elie Sloïm, Laurent Denis, Muriel de Dona, Fabrice Bonny
Editeur : Temesis
Date de publication : 2012

photo_livre_elie_sloimVoici un ouvrage qui synthétise le résultat de nombreuses années d’expérience dans le monde de la qualité du web. Les 4 auteurs, experts reconnus, partagent 217 bonnes pratiques de qualité web (initiées dans le référentiel Opquast) gravitant autour de nombreux thèmes (référencement, accessibilité, performance, ergonomie…).

Chaque bonne pratique est construite en une fiche efficace : description de l’objectif, moyens pour la mettre en oeuvre, outils pour la mesurer et la contrôler. Les auteurs enrichissent le tout d’une section « Avis de l’expert », bonus non négligeable pour comprendre et utiliser les recommandations émises.

En parallèle, vous pourrez dévorer un bref aperçu du processus de qualité Web et plus précisément comment intégrer la qualité dans un projet de création ou de refonte de site web, comment mesurer la qualité d’un parc de sites web, etc.

Cela fait nul doute, les professionnels du Web en auront pour leur argent en acquérant ce livre.

Table des matières

  1. Les bonnes pratiques de la qualité web
  2. Gestion de la qualité web (gérer la qualité dans un projet, évaluer la qualité d’un parc, etc.)
  3. Trousse à outils, check-lists et annexe

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

[/learn_more]

UX et Agilité : le duo gagnant pour des produits efficaces

Cela fait quelque temps que nous nous intéressons aux complémentarités des approches UX (User Experience ou Expérience Utilisateur) et Agile. Après deux entretiens très riches, le premier avec la référence en matière d’Agile UX en France Jean Claude Grosjean, le second avec le maître incontesté de Scrum dans l’hexagone Claude Aubry, nous dressons ici une vue synthétique de la complémentarité entre les deux disciplines.

[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]

Vous allez vite vous rendre compte que vous avez tout intérêt à associer ces pratiques.

Des projets en péril avant même de commencer

Rappelons tout d’abord deux constats fréquents dans les projets :

  • les premières causes d’échec dans les projets sont fortement liées à une mauvaise interprétation des besoins des utilisateurs ou de leurs priorités et une considération souvent sommaire de la logique des utilisateurs ;
  • les démarrage de projet sont souvent aberrants : on vous mandate pour réaliser un produit, généralement vous ne disposez pas des budgets appropriés, des ressources humaines (compétences) nécessaires à la bonne réalisation des travaux, vous n’avez pas accès aux utilisateurs finaux et pour couronner le tout votre manager (ou votre client) arrive telle une tornade pour que vous respectiez des délais utopistes (« la date de livraison était prévue pour hier »).

tornades-2

Votre manager ou votre client arrive telle une tornade (photo issue du blog Pen’s à Cola)

L’ensemble de ces contraintes fait que livrer un produit efficace devient aussi complexe que comprendre l’essence même d’une phrase de Jean Claude Van Damme. Fusionner l’UX et l’Agilité vous donne des solutions.

Qu’est-ce que l’UX ?

Quoi ? Pourquoi ? Comment ?
Donner la parole à l’utilisateurGérer la relation à l’utilisateur

Comprendre l’expérience de l’utilisateur

Analyser et traduire en éléments d’interface

Favoriser l’acceptation

Limiter les rejets

Kit d’analyse comportementale et cognitive :

#1 User centered design

#2 Toolbox UX

#3 Approche expérimentale

Qu’est-ce que l’Agilité ?

Quoi ? Pourquoi ? Comment ?
Capacité d’une organisation à créer de la valeur tout en s’adaptant à temps aux changements dans son environnementS’adapter aux imprévus

Réduire l’écart entre « Cycle d’évolution d’un produit » et « Processus d’une organisation »

Livrer au plus vite des livrables qui ont de la valeur

Garantir un produit à la fin

Fournir un produit répondant aux attentes

Itérations courtes

Polyvalence des membres de l’équipe

Définition très claire du rôle des acteurs

Implication forte du client

[box type= »shadow »]Vous souhaitez aller un peu plus loin dans la réflexion Agile ? Trois ressources sur la question :

[/box]

Idées reçues sur l’Agilité

L’Agilité ne veut pas dire « Moins de gestion de projet »

dilbert26667000711261

En implémentant une approche Agile, vous serez confronté à de nombreuses remarques croustillantes, par exemple : « On n’a pas le temps, je propose que l’on soit plus agile : on a qu’à s’envoyer un mail ».

L’agilité ne veut pas dire pas de gestion de projet et pas de documentation. Agilité veut dire documenter différemment, de manière évolutive et plus flexible. L’Agilité est efficace car elle vient flexibiliser les méthodologies de gestion de projet. Mais elle ne les supprime pas.

L’Agilité ne veut pas dire « Tout remettre en question »

Une autre idée reçue revient fréquemment : « Avec l’Agilité, ce qui est bien, c’est que si on se trompe, même après deux ans de travail, on peut tout remettre en cause du jour au lendemain ».

Ce n’est pas vrai non plus. N’oubliez pas qu’Agilité signifie livrer au plus vite de la valeur. Ainsi, favoriser le changement ne veut pas dire faire n’importe quoi et changer sans arrêt d’orientation.

Pourquoi l’UX et l’Agilité sont complémentaires ?

Les principaux inconvénients de l’UX sont palliés grâce aux avantages procurés par l’Agilité et inversement.

Avantages Inconvénients
UX Conversion utilisateurGère scientifiquement le lien à l’utilisateur

Acceptation utilisateur

Trop ancré modèle en cascadeLong à livrer malgré sa vocation première (« Itération » et « Solution intermédiaire de conception »)
Agilité Crée de la valeur, livre et s’adapte aux imprévusFlexibilise la démarche projet (i.e. guerilla testing)

Délivre rapidement pour tester

Forte implication du client

Polyvalence du rôle des membres de l’équipe

Présente l’illusion que c’est facileLaisse croire qu’il ne faut pas documenter ou que cela fonctionne sans gestionRythme de production soutenu

Gestion pas assez profonde de la relation utilisateur

Les lacunes de l’UX comblées par l’Agilité

Nous identifions encore régulièrement les lacunes suivantes dans les activités UX :

  • l’approche UX est trop fortement conditionnée par le modèle de gestion « en cascade » qui impose de terminer une phase avant de débuter la suivante. Il faut notamment disposer d’une analyse complète avant de commencer à implémenter. L’Agilité flexibilise cette démarche en permettant d’avancer sur plusieurs micro-chantiers en même temps et de délivrer rapidement – ainsi collecter du feed-back utilisateur plus rapidement ;
  • l’UX prône généralement une seule suite logique d’activités, avec une seule façon de faire. L’Agilité flexibilise et enrichit la réflexion tout en imposant un rythme. Elle favorise la communication entre les acteurs et vise une autogestion des équipes ;
  • même si l’UX préconise une approche itérative et des solutions intermédiaires de conception (i.e. faire du maquettage papier), l’Agilité l’opérationnalise de manière nettement plus efficace et ce notamment à l’aide de cérémonials imposant des règles strictes et une rigueur ;
  • l’UX prône la pluridisciplinarité mais est souvent incapable de communiquer avec d’autres corps de métier, a du mal à s’intégrer au sein des équipes et accepter les compromis ;
  • l’Agilité met le focus sur le client, l’éternel oublié des UX (« on représente l’utilisateur final, pas le client »).

Les apports de l’UX à l’Agilité

D’un autre côté, le gros désavantage de l’Agilité est qu’elle présente l’illusion que tout est facile. Qui plus est, elle laisse de côté les éléments relevant de l’ingénierie des exigences, l’ergonomie et l’expérience utilisateur. C’est une faiblesse incontestable tant ces dimensions sont cruciales pour assurer une bonne acceptation des produits par les utilisateurs finaux. L’UX apporte de nombreuses solutions à cet égard. 

L’approche UX permet ainsi de :

  • favoriser l’acceptation des produits et réduire les rejets d’utilisation ;
  • améliorer la satisfaction des utilisateurs ;
  • mettre en place des protocoles rigoureux de conception / évaluation avec les utilisateurs ;
  • observer les comportements de manière scientifique et systématique ;
  • identifier et comprendre les mécanismes cognitifs sous-jacents lors de l’utilisation du produit ;
  • traduire l’analyse des comportements en éléments d’interface ;
  • prioriser le point de vue de l’utilisateur dans une roadmap projet.

prhdr3002.id168452.tricky_tv_490x276
L’Agilité présente l’illusion que c’est facile (crédit photo M6)

[box type= »shadow »]

Le grand avantage de l’UX est son approche scientifique de l’utilisateur final. Deux ressources sur la question :

[/box]

L’UX met le focus sur l’utilisateur et l’acceptation d’un produit, l’Agilité travaille sur la prise en compte du besoin client et comment délivrer une valeur business au plus vite tout en s’adaptant aux imprévus.

[box type= »shadow »]

Les spécialistes de l’UX pensent encore trop souvent que la valeur d’un produit résulte uniquement de la prise en compte de l’utilisateur final. Créer de la valeur c’est fournir un produit orienté utilisateur (UX), qui satisfasse l’équipe métier (l’équipe projet qui le réalise) et le client (approche politique, stratégique, légale et business).

[/box]

La place de l’UX dans un projet mené en mode Agile

Il est évident qu’il existe des synergies naturelles entre UX et Agile, ce tout au long d’un projet.

Pour être efficace, les activités UX doivent être réalisées tout au long du projet (par petite dose ou de manière plus conséquente) en fonction des besoins et des budgets disponibles.

La qualité première d’un spécialiste UX est d’identifier les risques liés à l’utilisation du produit tout en suggérant des solutions tenant compte des contraintes et autres composantes du projet. Ce dernier est responsable du bon compromis entre « acceptation / utilité / facilité d’usage » et coût de mise en place.

scrum-ux-lifecycle

Exemple d’intégration d’activités UX au sein d’un processus SCRUM

Pour les plus aguerris en matière d’Agilité, voilà ce que nous proposons :

1. Intégration de l’UX dans le backlog du produit

La démarche UX repose sur une analyse orientée utilisateur solide :

  • identification des profils utilisateurs ;
  • identification des tâches ;
  • analyse du contexte d’utilisation.

L’analyse orientée utilisation va par la suite conditionner tous les choix de conception. Le spécialiste UX doit travailler en étroite collaboration avec le Product Owner (personne qui est responsable du produit livré) pour définir le backlog du produit et faciliter sa définition.

Grâce à sa connaissance précise des objectifs et des besoins des utilisateurs (qu’il acquiert à leur contact), le spécialiste UX garantit une concordance entre les User stories et les attentes de ces derniers. Un des outils utilisé par le spécialiste UX est notamment le maquettage papier, essentiel pour dégrossir les interfaces avant le premier sprint et orienter les choix du Product Owner concernant le backlog.

Par la suite, les spécialistes UX interviennent de façon itérative, à chaque sprint et en avance de phase par rapport au reste de l’équipe afin d’identifier au plus vite les difficultés d’utilisation. Ainsi, l’équipe en charge de la réalisation disposera d’éléments précis pour la réalisation de chaque User story.

2. L’UX donne le cap « Utilisateur »

Dans une approche UX, il est très important de s’assurer que la conception soit holistique. En mode Agile (i.e. Scrum), une fois l’analyse des besoins utilisateur réalisée (constitution du backlog du produit) on identifie des Features, puis on plonge directement dans les User stories. Etant donné que l’on va très rapidement au niveau de la User story, on risque d’une part de perdre la vue d’ensemble et d’autre part de faire des choix de conception lors d’un sprint qui auront un impact négatif à d’autres endroits lors d’autres sprints.

La collaboration étroite menée lors de la définition du backlog du produit donne au spécialiste UX une vue globale de l’ensemble du produit et de ses usages. Ainsi grâce au concept qu’il établit lors des premiers sprints, le spécialiste UX dispose des moyens permettant d’assurer une cohérence globale dans la définition des User stories. Son rôle est de partager cette visibilité avec le reste de l’équipe.

3. L’UX assure des checks réguliers

En tant que « conseiller utilisateur » du Product Owner, le spécialiste UX à la responsabilité de tester et vérifier les résultats de chaque sprint sur base des feed-backs utilisateur. Souvent plus facile à solliciter que le Product Owner lui-même, le spécialiste UX intervient avec le reste de l’équipe en cours de sprint. Ainsi il fait partie intégrante de l’équipe et participe à chaque cérémonial.

Ses interventions constantes dans le projet permettent de réduire les risques de rejet et garantissent une prise en compte de la vision utilisateur tout au long du projet. Lorsqu’un élément impacte la qualité pour l’utilisateur, il doit se positionner : l’utilité de cette fonction est-elle importante ? Est-il possible de reporter son développement ? etc. En répondant à ces questions le spécialiste UX s’assure que l’équipe garde le focus sur des fonctionnalités à forte plus-value pour l’utilisateur.

4. L’UX organise les rencontres utilisateur

L’apport principal du spécialiste UX est sa capacité à gérer la relation avec l’utilisateur (choix des utilisateurs, représentativité des scénarios proposés aux utilisateurs, méthodologie d’évaluation, technique UX employée, etc.). Il est là pour proposer les techniques et activités UX appropriées aux contraintes du projet, celles qui offrent le meilleur retour sur investissement.

Pour conclure

L’approche UX est souvent vendue comme un package complet, avec un ordre pré-établi à respecter et une seule façon de faire. Nous vous encourageons à développer une approche modulaire et plus flexible. Bien sûr de nombreuses personnes vous diront « Ce n’est pas comme cela qu’il faut faire, il y a tel biais, tel biais… ». Nous partons du principe qu’il faut évidemment limiter les biais mais surtout accepter que l’on ne peut pas tout maîtriser et tout figer avant de commencer. L’important c’est d’être conscient des biais éventuels, d’en tenir compte et d’avancer en connaissance de cause.

Parfois même, le spécialiste UX ne sera pas d’accord avec les choix de l’équipe et/ou du client. Peu importe, il est là pour prévenir des risques, poser les nouvelles hypothèses et vérifier si elle sont confirmées.

De toute façon, si l’équipe part sur des mauvais besoins utilisateurs, l’approche UX Agile va permettre de s’en rendre compte très rapidement. Et puis n’oubliez pas que les hypothèses UX vont évoluer au gré des changements organisationnels et de l’avancement du projet.

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

[/learn_more]