Adopter l’approche LEAN UX, c’est optimiser son taux de conversion grâce à l’innovation et à l’amélioration continue de l’expérience utilisateur.
Les fondements du Lean UX sont le Design Thinking, le développement Agile et la méthode Lean Startup.
Synthèse du Lean UX
L’ensemble du processus est axé sur la conversion (métrique) plutôt que sur la réalisation (fonction et service).
L’équipe.
Petite équipe pluridisciplinaire constituée de designers, développeurs, experts en marketing, en Web Analytics et tout autre talent qui fait sens. Toutes les mesures doivent être effectuées de manière collaborative.
Objectifs.
- Toute l’équipe doit savoir quel est le problème que nous résolvons.
- Toute l’équipe doit savoir à quoi ressemble le succès.
- Chercher des solutions simples.
- Toujours demander pourquoi, ne pas simplement accepter.
Principes.
- Petite équipe pluridisciplinaire dédiée
- Résultats = l’amélioration, pas la réalisation
- Équipe axée sur le problème (business)
- Nettoyeur (= suppression de tout ce qui ne supporte pas le but ultime)
- Lot de taches de petite taille (= pas d’attente pour de grands livrables de conception)
- Découverte continue
- GOOB (= getting out of the building)
- Vision commune (de l’espace, du produit, des clients)
- Anti-Modèle : Rockstars, Gourous, Ninjas (au lieu : partager, collaborer !)
- Externaliser votre travail (dessinez vos idées sur les murs, impressions, notes, etc. à partager avec l’équipe et les clients)
- Faire de l’analyse un atout (moins de débats, plus de pratique)
- Perfectionnement sur la croissance (développer une idée qui n’est pas prouvée est risqué)
- Le droit à l’échec (un prérequis à l’apprentissage)
Flux Lean UX.
Suppositions.
Suppositions fondées sur la recherche.
- Les rapports Analytics
- Les rapports d’utilisabilité
- Des infos sur les tentatives passées pour résoudre le problème
- Analyse des parties prenantes de l’entreprise
- Analyse de la concurrence
Suppositions basées sur l’Énoncé du problème.
Composé de trois éléments :
- Les objectifs actuels du produit/système
- Les objectifs business des parties prenantes qui n’ont pas été atteints
- Une demande explicite d’amélioration qui ne dicte pas une solution (storie Scrum)
Template.
« Notre [service/produit] a été conçu pour atteindre [ces objectifs]. Nous avons observé que le produit/service n’a pas atteint [cet objectif], qui est à l’origine de cet [effet indésirable] pour notre entreprise. Comment pourrions-nous améliorer le [service/produit] auprès de [ce type d’utilisateurs] sur la base de [ce critère mesurable]. »
Disséquer cet énoncé du problème en suppositions de base.
[Ce type d’utilisateurs] ne réalise pas suffisamment [cet objectif] à travers [ce critère mesurable] parce que [causes possibles].
Prioriser les suppositions.
Risque.
Par exemple, que se passerait-il si nous nous sommes trompés sur ce sujet
Les suppositions les plus risquées doivent être testées en priorité. Tandis que les moins risquées seront traitées plus tard.
Déclaration de l’hypothèse (ou du but).
Hypothèse de test.
Pour tester les suppositions les plus risquées, il faut transformer chaque supposition
dans un format plus facile à tester : la déclaration de l’hypothèse.
- Format de l’hypothèse :
Nous pensons que [cette affirmation est vraie].
Nous validerons que nous soyons dans le [vrai / faux] en actant les [Retour qualitatif] et/ou [Retour quantitatif] et/ou [changement du KPI]. - Format de l’hypothèse renforcée :
Nous pensons que [faire ceci / construire cette fonctionnalité / créer cette expérience] pour [ces personnes/personas] permettra d’atteindre [ce résultat] [parce que]. Nous saurons que cela est vrai dans l’observation des [mesures quantitatives ou qualitatives].
Soyez très précis sur les résultats plutôt que sur la réalisation.
Dresser une liste des résultats (ex. KPI) que vous essayez d’atteindre, une définition des personas vous essayez de cibler, et un ensemble de fonctionnalités que vous croyez utile dans cette situation.
Cibler des Personas.
Personas.
(passer seulement quelques heures max pour la création des principaux personas. Ils s’affineront au fur et à mesure des recherches.)
1. Portrait & Nom
2. Informations démographiques et comportementales
3. Points sensibles et besoins
4. Les solutions potentielles
Conception collaborative / Idéation.
Exemple Méthode : Design Studio (Design Charrette)
- Définition du problème et contraintes (15-45 min)
- Génération d’idée individuelle (10 min), modèle de croquis 3×3 A6
- Présentation et critique (3 min par personne)
- Itérer & Affiner en fonction des commentaires (5-10 min)
- Génération d’idées d’équipe (45 min)
MVP.
Minimun Viable Product est la mise en forme « rapide » d’une hypothèse de test (cette tactique va-t-elle atteindre le résultat souhaité ?). MVP n’est pas forcément un objet codé, un
Test / Itération/ Amélioration.
Validation interne.
Feedback rapide et régulier de l’exécutif et de l’équipe.
Whiteboard, Pineboard, Daily Scrum meeting, Sondage mail, Wiki, Coffee Meeting.
Test externe.
Tester le MVP auprès des clients ou groupes d’utilisateurs cibles.
Test A/B, Test utilisateur, Focus group, Web Analytics, Sondage, Enquête,
Décider quoi faire avec les résultats puis itérer ou sélectionner un nouveau problème.
Si vous êtes intéressé par le sujet, je vous conseille de lire le livre référent de Jeff Gothelf
Lean UX: Applying Lean Principles to Improve User Experience