Dans une petite équipe, chaque décision de navigation qui tourne mal coûte deux fois : une fois à construire, une fois à refaire. Et refaire un flux de navigation une fois qu'il est déjà en production est l'une des choses les plus coûteuses qu'une application puisse demander, car cela change l'architecture, le code et l'esprit de l'utilisateur qui a déjà appris à l'ancienne.
Le flux de navigation est précisément le type de problème qu’il est préférable de résoudre avant qu’une ligne de code n’existe. La mauvaise nouvelle est que les petites équipes sautent souvent cette étape en pensant qu'elles "s'en rendront compte au fur et à mesure de leur construction". Ils ne le découvrent presque jamais. Ils accumulent des écrans qui ne se parlent pas.
Ce texte s'adresse à ceux qui ont peu de mains et souhaitent utiliser les bons outils pour obtenir le bon flux du premier coup, ou du moins commettre une erreur peu coûteuse, sur le papier, avant de commettre une erreur coûteuse, dans le code.
Pourquoi le flux compte plus que le joli écran
Il est tentant d'ouvrir Figma et de commencer à dessiner de belles toiles. Mais screen est un nom et flow est un verbe. L'utilisateur n'utilise pas d'écrans isolés ; il traverse un chemin pour accomplir une tâche. Si le chemin est déroutant, aucun bel écran n'est sauvegardé.
Pour une petite équipe, cela a une implication pratique directe : le temps passé à concevoir le flux de navigation rapporte plus que le temps passé à peaufiner les pixels. Un flux clair réduit les retouches, réduit le support et réduit les abandons. Il s’agit de l’investissement à effet de levier le plus élevé qu’une équipe Lean puisse réaliser en UX.
Les outils adaptés à une équipe Lean
Choisir un outil pour une petite équipe a avant tout un critère : il doit correspondre à ce que vous avez déjà. Un outil puissant qui nécessite un spécialiste dédié est un luxe qu’une petite équipe ne peut se permettre.
Pour cartographier le flux
Avant la conception visuelle vient la carte. FigJam, Miro et Whimsical résolvent bien l'étape de cartographie des chemins utilisateur avec des cases et des flèches. Ils sont bon marché, collaboratifs et ne nécessitent aucune formation. Pour une équipe de deux ou trois personnes, commencer ici et dessiner le flux sous forme de diagramme avant tout écran permet de gagner des semaines.
Le véritable avantage de ces outils est qu’ils rendent le flux discutable. Un schéma sur le mur force la conversation « attendez, comment l'utilisateur revient-il de cet écran ? se produire avant le code, c'est exactement là que cela coûte moins cher.
Pour le prototypage et les tests
Figma est le standard de facto, et pour cause : prototypes cliquables, composants réutilisables et collaboration en temps réel dans un plan adapté au budget de démarrage. Pour une petite équipe, la possibilité de transformer un wireframe en un prototype navigable sans écrire de code est ce qui vous permet de tester le flux avec de vrais utilisateurs avant de vous engager dans l'ingénierie.
La fonction prototype de Maze et Figma vous permet d'exécuter des tests d'utilisabilité à distance à moindre coût. Vous n'avez pas besoin d'un laboratoire, vous avez besoin de cinq utilisateurs et d'un lien.
Pour valider avec les données après le lancement
Une fois l'application en ligne, des outils tels que Firebase Analytics ou Mixpanel montrent où l'utilisateur est bloqué dans le flux réel. Pour une petite équipe, le niveau gratuit de ces outils suffit généralement pendant longtemps. L’important est d’instrumenter les points de décision de flux dès le début, et non après l’apparition du problème.
Comment séquencer cela en pratique
Cartographiez d’abord, dessinez ensuite, validez toujours. Commencez par l’organigramme dans Whimsical ou FigJam. Ce n'est que lorsque le chemin est clair que vous accédez au prototype dans Figma. Testez avec cinq vrais utilisateurs. Ajuster. Alors seulement, construisez.
Cet enchaînement semble évident, mais c'est exactement ce que les petites équipes sautent sous la pression de « livrer bientôt ». L’ironie est que sauter l’étape de flux n’accélère pas la livraison, mais la retarde, car la retouche arrive plus tard et est plus importante.
L'erreur la plus courante dans une petite équipe
L’erreur classique est de confondre mouvement et progrès. Les écrans dessinés donnent une impression de progrès. Mais si le flux sous-jacent est erroné, chaque nouvel écran est une dette. J'ai vu de petites équipes construire vingt magnifiques écrans liés à un flux de navigation qui obligeait l'utilisateur à appuyer sept fois pour faire ce qui aurait dû en prendre deux.
Une autre erreur consiste à adopter trop d’outils. Les petites équipes n'ont pas besoin de FigJam, Figma, Maze, Mixpanel et trois autres. Il vous en faut un pour cartographier, un pour prototyper et un pour mesurer. Trop d’outils deviennent trop de licences, trop de contexte et personne ne les maîtrise réellement.
Modèles de navigation : ne réinventez pas ce qui fonctionne déjà
Une petite équipe n’a ni le temps ni les utilisateurs pour inventer de nouvelles façons de naviguer. Et cette restriction, loin d'être un problème, est un avantage : les modèles de navigation consolidés existent parce qu'ils fonctionnent et parce que l'utilisateur les connaît déjà.
Onglets en bas pour les zones principales, geste arrière cohérent, hiérarchie claire entre les écrans parents et enfants. Des systèmes tels que Material Design d'Android et Human Interface Guidelines d'Apple documentent abondamment ces normes. Pour une petite équipe, le respect de ces directives permet d'économiser des dizaines de décisions de conception et de fournir une application que l'utilisateur comprend sans apprentissage.
La créativité d'une équipe Lean doit aller là où votre produit est unique, la proposition de valeur, la fonctionnalité de base, et non réinventer la façon dont l'utilisateur navigue entre les écrans. La navigation inventée est un coût d'apprentissage jeté sur les genoux de l'utilisateur et les utilisateurs confus désinstallent.
Une bonne utilisation des outils consiste ici à tirer parti des kits de composants prêts à l'emploi proposés par Figma pour ces systèmes de conception. Au lieu de concevoir chaque élément de navigation à partir de zéro, l'équipe part de blocs testés et concentre l'effort sur ce qui différencie le produit. Pour ceux qui ont peu de mains, c’est un multiplicateur de productivité.
La réflexion qui divise les équipes
Aucun outil ne peut concevoir un bon flux pour vous. Cela rend simplement le flux visible plus tôt, alors que le réparer est encore bon marché. La différence dans une petite équipe qui réussit n'est pas d'avoir l'outil le plus cher, c'est d'avoir l'habitude de réfléchir au parcours de l'utilisateur avant de le construire.
Pour une équipe avec peu de bras, cette habitude constitue un véritable avantage concurrentiel. Pendant que votre concurrent refait les flux de production, vous avez déjà validé les vôtres sur papier.
Si vous dirigez une petite équipe et concevez maintenant le flux de navigation de votre application, cela vaut la peine de discuter de la manière de structurer ce processus sans surcharger l'équipe. Il existe d'autres articles sur le blog sur le prototypage, l'UX mobile et la validation de produits qui abordent directement ce sujet.
A lire aussi
-Backend pour les applications : bonnes pratiques pour les petites équipes qui ne peuvent pas faire d'erreurs -Meilleures pratiques UX pour les formulaires complexes avec React Hook Form