Design

Les 7 pièges à éviter quand on fait du lean & agile UX

Le lean & agile UX puise ses sources dans les principes lean. Cette pratique a pour objectif de diminuer le gâchis et permettre de créer des produits de manière plus rapide et efficace en favorisant les moments collaboratifs en équipe interdisciplinaire et en étant le plus possible au contact des utilisateurs.

Screen_Shot_2016-09-19_at_18.59.13.png


En théorie ces objectifs sont atteints en travaillant sur l'expérience utilisateur du produit en parallèle des développements. En pratique, il est facile de tomber dans des pièges qui viennent compromettre l'efficacité de cette méthode ! Voilà donc les 7 pièges les plus fréquents à éviter :


Piège #1 : Impliquer le UX Designer trop tôt ou seulement au début des développements

Si on commence à designer le produit 4 semaines avant le début des développements on risque d'avoir tout le design d'un produit complet sans l'avoir mis dans les mains des utilisateurs et ainsi d'oublier l'objectif du produit. On est alors tiré par les fonctionnalités du produit plutôt que le problème utilisateur à résoudre. On n'est donc plus agile du tout.


Si on commence les développements sans prendre le temps de rencontrer ses utilisateurs et de challenger avec eux nos succès, on prend le risque se lancer dans des fonctionnalités inutiles. De plus, commencer les développements au même moment que le design ne permet pas d'avoir les éléments graphiques suffisants. Des fonctionnalités sont donc ajoutées sans intégration et cela ne permet pas d'avoir un produit pouvant être mis en production tous les soirs. On n'est donc plus agile non plus.


Screen_Shot_2016-09-19_at_18.58.01.png


Solution :

Une bonne pratique que vous pouvez mettre en place est de toujours avoir le design avec une semaine d'avance sur les développements. Le UX Designer va donc commencer à travailler 1 sprint avant le début des développements et les éléments designés lors d'un sprint seront intégrés par les développeurs lors du prochain sprint.


Piège #2 : Ne pas donner de la visibilité au Product Owner (PO) et aux Stakeholders (SH) sur les jours où le UX Designer travaille

Dans la méthode agile, le PO et le SH doivent transmettre la direction du projet et les fonctionnalitées à développer à l'équipe. Une des façons de leur faciliter ce travail est de leur donner de la visibilité sur le travail réalisé et à venir. Cela permet au PO de se rendre disponible pour la validation ainsi que de s'assurer d'avoir le design nécessaire au bon moment pour pouvoir avancer et donc de ne pas perdre de temps.

 

Une bonne pratique est que l'équipe ait toujours au moins 3 semaines de visibilité sur le travail à venir, ce qui est compromis si le PO et les stakeholders ne peuvent pas se projeter dans la construction du produit avec le UX Designer.

Solutions :

  • Vous pouvez afficher un planning des jours travaillés visible par tous les membres de l'équipe projet
  • Vous pouvez également rappeler tous les matins où le UX designer travaille sur les sujets sur lesquels il va avancer


Piège #3 : Minimiser le brief

Commencer à produire des écrans trop rapidement, sans prendre le temps suffisant pour faire un benchmark ni de récupérer un bon brief du Product Owner (PO), peut mener à de nombreux allers-retours qui ralentissent la chaîne de production.

Solution :

Avant d'attaquer la réalisation des maquettes, prenez un moment en équipe pour étudier les concurrents et vous aligner sur l'image et le style du produit (Atelier UI).


Piège #4 : Ne faire valider qu'une fois par jour

Même avec un bon brief on peut taper à côté ! Une fois absorbé dans la production des écrans, il arrive d'oublier d'échanger à étape intermédiaire avec le PO et de se rendre compte de l'écart entre le design produit et le design recherché après beaucoup de travail fourni !

Solutions :

  • Une première solution est de vous fixer un objectif d'échange pour valider le travail en cours, par exemple un échange par heure. Quitte à faire valider les éléments graphiques un à un.
  • Si malgré cette première solution il y a encore trop de retours, vous pouvez réaliser des sessions d'une heure où le designer va travailler avec le PO à côté de lui pour itérer plus rapidement sur les différentes propositions.
  •  D'une manière générale si vous réalisez bien des ateliers UX, ateliers durant lesquels l'équipe au complet créer les parcours utilisateurs et wireframes des écrans associés, avant la réalisation des maquettes il y aura moins d'échange et incertitudes quand à la validation à l'étape des maquettes

Piège #5 : Faire des ateliers UX et UI sans développeurs

Un manque d'implication des membres de l'équipe technique dans la UX peut créer des désalignements quand à la vision du produit qu'ont les développeurs, le Product Owner, et le UX designer.

Solution :

Une solution est de systématiquement inclure des membres de l'équipe technique en atelier de design collaboratif, en atelier UI ou lors des tests ou interviews utilisateurs.


Les avantages sont nombreux ! Cela permet :

  • Moins de redite en revue de sprint et en atelier ;
  • D'avoir davantage de retours sur la faisabilité et la complexité d'une fonctionnalité, ce qui permet au PO de prendre les décisions nécessaires lors de la création du produit et pas seulement lors du planning du sprint ;
  • Et surtout, d'avoir des idées plus riches.


Piège #6 : Ne faire valider que par le PO et montrer le produit au stakeholder qu'une fois par semaine

Une fois le stakeholder impliqué au lancement du projet et en cérémonie, on peut oublier de l'impliquer dans les moments clés du design de l'interface. C'est pourtant la partie la plus visible du produit et qui est susceptible de plus attirer l'attention des SH et autres personnes en dehors de l'équipe de production ! D'autant que ces-derniers peuvent se révéler être une source d'idées intéressantes.

Solution :

Le manque de disponibilité des SH peut paraître contraignant au premier abord mais vous pouvez résoudre cela en prévoyant par exemple 15 minutes en fin d'atelier pour partager les avancées et décisions prises avant d'attaquer la production des maquettes.  


Piège #7 : Mettre le UX Designer dans un bureau différent de celui des développeurs

L'accompagnement des développeurs lorsqu'ils intègrent le design est souvent négligé alors que la valeur ajoutée de cette démarche est énorme pour familiariser et engager les développeurs dans la démarche Lean UX et le challenge du design du produit.

Solutions :

  • Une solution que vous pouvez mettre en place est de faire en sorte que le UX designer travaille dans le même open space, et même, sur le même bureau que les développeurs de son équipe, de telle sorte que même s'il travaille sur d'autres sujets, il puisse intervenir et les aider.
  • Un standard que vous pouvez vous fixer est de toujours faire challenger les maquettes par les développeurs avant qu'elles soient soumises à validation pour le PO. Ce qui est plus facile s'il suffit de tourner son écran pour que les développeurs y jettent un oeil !


En évitant ces 7 pièges vous augmenterez votre vitesse de développement et éviterez le gâchis sur le design ou les fonctionnalités développées.

 

Pour en savoir plus sur le lean & agile UX et comment BAM l'applique : 6 étapes pour améliorer votre lean UX

Designer UX/UI ?

Rejoins nos équipes