La lean UX est une technique extrêmement utile lorsque vous travaillez sur des projets utilisant la méthode de développement agile. Les techniques UX traditionnelles ne fonctionnent souvent pas lorsque le développement est effectué en rafales rapides – il n’y a pas assez de temps pour fournir des UX de la même manière. Fondamentalement, la lean UX et d’autres formes de UX ont tous le même objectif en tête ; offrir une excellente expérience utilisateur signifie que la façon dont vous travaillez sur un projet est légèrement différente. Alors, regardons comment cela pourrait fonctionner.

Lean UX – Qu’est-ce que c’est ?

La lean UX se concentre sur l’expérience sous-jacente et se concentre moins sur les livrables que les UX traditionnelles. Cela nécessite un plus grand niveau de collaboration avec toute l’équipe. L’objectif principal est de se concentrer sur l’obtention d’avis le plus tôt possible afin de pouvoir prendre des décisions rapides. La nature du développement agile est de fonctionner en cycles itératifs rapides et La lean UX imite ces cycles pour garantir que les données générées peuvent être utilisées dans chaque itération.

Le besoin de suppositions en Lean UX

Dans les UX traditionnelles, le projet repose sur la circonscription des exigences et les livrables. L’objectif est de s’assurer que les livrables sont aussi détaillés que possible et répondent de manière adéquate aux exigences définies au début du projet.

La lean UX est légèrement différente. Vous n’êtes pas concentré sur les livrables détaillés. Vous cherchez à apporter des changements qui améliorent le produit ici et maintenant, essentiellement pour améliorer les résultats.

Cela fonctionne en pratique en abandonnant les « exigences » et en utilisant une « déclaration de problème – problem statement » qui devrait conduire à un ensemble de suppositions pouvant être utilisées pour créer des hypothèses.

Qu’est-ce qu’une supposition ? Une supposition est essentiellement une déclaration de quelque chose que nous pensons être vraie. Elles sont conçues pour générer une compréhension commune autour d’une idée qui permet à chacun de se lancer. Il est bien entendu que les hypothèses peuvent ne pas être correctes et 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 suppositions sont normalement générées en atelier. Vous rassemblez l’équipe et énoncez le problème, puis permettez à l’équipe de réfléchir à leurs idées pour résoudre le problème. Dans le processus, vous générez des réponses à certaines questions qui constituent vos suppositions.

Les questions typiques peuvent inclure :

• Qui sont nos utilisateurs ?
• À 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 un plus grand nombre d’hypothèses qu’il pourrait être pratique de traiter. Si tel est le cas, l’équipe peut hiérarchiser rapidement ses hypothèses après leur génération. En général, vous accorderiez la priorité à vos hypothèses en fonction du risque qu’elles représentent (quelles sont les conséquences d’une telle erreur ? Plus la conséquence est grave, plus la priorité est élevée) et le niveau de compréhension du problème (moins vous en savez, plus la priorité est élevée).

Créer une hypothèse en Lean UX

Les hypothèses créées en lean UX sont conçues pour tester 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 que permettre aux utilisateurs de sauvegarder leurs progrès à tout moment est essentiel pour les utilisateurs de smartphones. Cela permettra d’atteindre un niveau plus élevé de complétions d’inscription. Nous l’aurons démontré lorsque nous pouvons mesurer une amélioration du taux d’achèvement actuel de 20%.

Nous exprimons la conviction et pourquoi c’est important et pour qui c’est important. Ensuite, nous suivons cela avec ce que nous espérons réaliser. Enfin, nous déterminons quelles preuves nous devrions collecter pour prouver que notre croyance était vraie.

Si nous trouvons qu’il n’existe aucun moyen de prouver notre hypothèse, nous risquons d’aller dans la mauvaise direction parce que nos résultats ne sont pas clairement définis.

Un des grands avantages de travailler de cette façon est de supprimer une grande partie des « je ne pense pas que ce soit une bonne idée » et des querelles politiques du processus de design UX. Chaque idée va être testée et les critères de preuve clairement déterminés. Aucune preuve ? Il est alors temps de laisser tomber l’idée et d’essayer autre chose.

Si tout le monde peut comprendre une hypothèse et ses attentes, ils ont tendance à se réjouir de voir si cela est vrai plutôt que de débattre passionnément de leur propre point de vue subjectif.

Le produit minimum viable et la Lean UX

Le produit minimum viable (MVP) est un concept de base en Lean UX. L’idée est de construire la version la plus élémentaire possible du concept, de la tester et de ne pas l’abandonner s’il n’y a pas de résultat valable. Les MVP qui sont prometteurs peuvent ensuite être incorporés à d’autres cycles de design et de développement sans trop de problèmes.

C’est un excellent moyen de maximiser vos ressources et l’une des raisons pour lesquelles cela fonctionne si bien avec le développement agile – cela permet beaucoup d’expérimentation sans « vaches sacrées ».

Recherche et test utilisateurs en Lean UX

La recherche et les tests effectués sur les utilisateurs, de par la nature même du lean UX, reposent sur les mêmes principes que ceux utilisés dans les environnements UX traditionnels. Cependant, l’approche a tendance à être « rapide et sale » – les résultats doivent être livrés avant le début du prochain sprint agile ; il y a donc beaucoup moins d’attention sur les extrants lourds, documentant méticuleusement et davantage sur les données brutes.

Les responsabilités en matière de recherche ont également tendance à être réparties plus largement sur l’ensemble de l’équipe, de sorte qu’aucun « goulot d’étranglement » n’est créé en ayant une seule ressource de design UX essayant de faire tout le travail dans des délais serrés. Cela permet souvent de disposer de ressources de développement pour effectuer un travail UX « pratique » et augmente également le niveau de compréhension et de prise en charge du travail UX au sein de l’équipe de développement.

Résumé

Il s’agit d’une vue d’ensemble de très haut niveau de la lean UX et, bien sûr, il y a beaucoup plus que ce que vous pouvez couvrir dans un court article. Cependant, ces concepts de base devraient vous permettre de vous orienter vers la mise en œuvre de la lean UX dans votre environnement agile.