Le Lean UX est une technique incroyablement utile pour travailler sur des projets où la méthode de développement Agile est utilisée. Les techniques traditionnelles d’UX ne fonctionnent souvent pas lorsque le développement est effectué en rafales rapides. Il n’y a pas assez de temps pour livrer les UX de la même manière. Fondamentalement, les UX Lean et les autres formes d’UX ont tous le même objectif en tête : offrir une expérience utilisateur exceptionnelle. C’est juste que la façon dont vous travaillez sur un projet est légèrement différente. Voyons donc comment cela pourrait fonctionner.
Lean UX – Qu’est-ce que c’est ?
Le Lean UX est axé sur l’expérience en cours de conception et est moins axé sur les produits livrables que les UX traditionnels. Cela exige un niveau de collaboration plus élevé avec l’ensemble de l’équipe. L’objectif principal est de se concentrer sur l’obtention d’une rétroaction le plus tôt possible afin qu’elle puisse être utilisée pour prendre des décisions rapides. La nature du développement Agile est de travailler en cycles rapides et itératifs. Le Lean UX imite ces cycles pour s’assurer que les données générées peuvent être utilisées dans chaque itération.
Nécessité de formuler des hypothèses sur les UX Lean
Dans le cas des UX traditionnelles, le projet est fondé sur la saisie des exigences et les produits livrables. L’objectif est de s’assurer que les livrables sont aussi détaillés que possible et qu’ils répondent adéquatement aux exigences établies au début du projet.
Le Lean UX est légèrement différent. Vous n’êtes pas concentré sur les livrables détaillés. Vous cherchez à produire des changements qui améliorent le produit ici et maintenant – essentiellement pour façonner le résultat pour le mieux.
Dans la pratique, cela fonctionne en abandonnant les « exigences » et en utilisant un « énoncé du problème » qui devrait mener à un ensemble d’hypothèses qui peuvent être utilisées pour créer des hypothèses.
Qu’est-ce qu’une hypothèse ?
Une hypothèse est essentiellement un énoncé de quelque chose que nous pensons être vrai. Les hypothèses sont conçus pour générer une compréhension commune autour d’une idée qui permet à chacun de s’imaginer. Il est bien entendu que les hypothèses peuvent ne pas être correctes et qu’elles peuvent être modifiées au cours du projet au fur et à mesure qu’une meilleure compréhension se développe au sein de l’équipe.
Les hypothèses sont normalement formulées dans le cadre d’un atelier. Vous réunissez l’équipe et énoncez le problème, puis vous permettez à l’équipe de faire un brain storming pour trouver des idées afin de résoudre le problème. Au cours de ce processus, vous générez des réponses à certaines questions qui forment vos hypothèses.
Les questions typiques peuvent inclure :
- Qui sont nos utilisateurs ?
- A quoi sert le produit ?
- Quand est-il utilisé ?
- Dans quelles situations est-il utilisé ?
- Quelle sera la fonctionnalité la plus importante ?
- Quel est le plus grand risque pour la livraison du produit ?
Il peut y avoir plus d’une réponse à chaque question. Cela nous laisse avec un plus grand nombre d’hypothèses qu’il ne serait pratique de le faire. Si tel est le cas, l’équipe peut classer ses hypothèses par ordre de priorité rapidement après leur génération. En général, vous prioriseriez vos hypothèses en fonction du risque qu’elles représentent (quelles sont les conséquences d’une erreur grave ? Plus la conséquence est grave, plus la priorité est élevée) et le niveau de compréhension de la question à l’étude (moins vous en savez, plus la priorité est élevée).
Création d’une hypothèse en Lean UX
Les hypothèses créées dans le cadre du Lean UX sont conçues pour vérifier nos hypothèses. Il existe un format simple que vous pouvez utiliser pour créer vos propres hypothèses, rapidement et facilement.
Un exemple :
Nous pensons qu’il est essentiel pour les utilisateurs de smartphones de permettre aux gens de sauvegarder leurs progrès à tout moment. Cela permettra d’atteindre un niveau plus élevé d’inscriptions complétées. Nous l’aurons démontré lorsque nous pourrons mesurer une amélioration du taux d’achèvement actuel de 20 %.
Nous énonçons la croyance et les raisons pour lesquelles elle est importante et pour qui elle l’est. Ensuite, nous suivons cela avec ce que nous nous attendons à réaliser. Enfin, nous déterminons quels éléments de preuve nous devrions recueillir pour prouver que notre croyance est vraie.
Si nous constatons qu’il n’y a aucun moyen de prouver notre hypothèse, il se peut que nous allions dans la mauvaise direction parce que nos résultats ne sont pas clairement définis.
L’un des grands avantages de travailler de la sorte est qu’il enlève une grande partie du processus de conception des UX et des luttes intestines politiques qui s’y rattachent. Chaque idée sera mise à l’essai et les critères de preuve seront clairement déterminés. Aucune preuve ? Alors il est temps de laisser tomber l’idée et d’essayer autre chose.
Si tout le monde peut comprendre une hypothèse et les attentes qui en découlent, ils ont tendance à être heureux d’attendre de voir si elle est vraie plutôt que de débattre avec passion de leur propre point de vue subjectif.
Le produit viable minimal et les UX maigres
Le produit minimum viable (MVP) est un concept de base du Lean UX. L’idée est de construire la version la plus basique possible du concept, de le tester et s’il n’y a pas de résultats valables, de l’abandonner. Les MVP prometteurs peuvent ensuite être intégrés sans trop de tracas dans d’autres cycles de conception et de développement.
C’est un excellent moyen de maximiser vos ressources et l’une des raisons pour lesquelles il fonctionne si bien avec le développement Agile – il permet beaucoup d’expérimentation.
Recherche et test des utilisateurs dans le cadre du Lean UX
De par leur nature même, la recherche et les tests auprès des utilisateurs sont basés sur les mêmes principes que ceux utilisés dans les environnements UX traditionnels. Cependant, l’approche tend à être » rapide et sale » – les résultats doivent être livrés avant le début de la prochaine Agile Sprint ; il y a donc beaucoup moins d’accent sur les résultats lourds et méticuleusement documentés et plus sur les données brutes.
Les responsabilités en matière de recherche tendent également à être réparties plus largement dans l’ensemble de l’équipe, de sorte qu’il n’y a pas de » goulot d’étranglement » créé par le fait qu’une seule ressource de conception d’UX essaie de faire tout le travail dans des délais serrés. Cela permet souvent aux ressources de développement d’effectuer un travail pratique sur les UX et augmente le niveau de compréhension et de soutien du travail sur les UX au sein de l’équipe de développement également.
Résumé
Il s’agit d’un aperçu de très haut niveau de Lean UX et, bien sûr, il y a beaucoup plus à cela que ce que vous pouvez couvrir dans un court article . Cependant, ces concepts de base devraient vous permettre d’aller dans la bonne direction lorsqu’il s’agit d’implémenter Lean UX dans votre environnement Agile.
