Des besoins aux parcours cibles
La V2 ne partait pas d'une page blanche : la V1 avait ses usages installés et ses irritants connus. Le point de départ : le brief transmis par la PM — besoins et pain points clients, traduits en features, parcours et améliorations à couvrir. Restait à situer ce brief : ce que faisait déjà la V1, et ce que faisait le marché. J'ai donc mené deux relevés complémentaires : un audit de l'existant en production, pour repérer ce qui devait changer, et un benchmark de 3 solutions concurrentes pour situer la V2 face aux standards du marché.
Le prototype face aux pairs
Le task panel — le détail d'une tâche — concentre l'essentiel de la valeur de l'app : c'était l'écran à dérisquer en premier. Le regard des pairs offrait le meilleur ratio : une heure de critique structurée pour détecter les problèmes de fond avant de mobiliser des clients. J'ai animé un atelier design critique d'1h à distance (FigJam) avec les 6 autres designers du chapter UX : 4 types de feedback (positif, à préciser, négatif, améliorations), 3 minutes de production en solo par type, un tri par cartes entre chaque pour regrouper les signaux. Le format a séparé ce qui tenait — hiérarchie du contenu, UI des commentaires — de ce qui méritait arbitrage : 3 notions restaient floues (abonnement, tâche bloquée, statut de l'espace de discussion) et la densité du panel posait la question du plein écran. Ces points ont réorienté les maquettes avant toute exposition aux clients.
Le prototype entre les mains des clients
Le prototype corrigé restait à confronter aux utilisateurs payants. Le format collectif faisait plus que résoudre les agendas : recueillir les besoins en une seule session, les confronter et les prioriser à chaud pour aligner les principaux clients sur les dernières modifications avant le développement. J'ai animé un atelier hybride focus group / test d'usabilité de 2h avec 7 clients, à distance sur prototype partagé : 6 parcours testés en autonomie, chacun suivi d'une auto-évaluation de difficulté de 1 à 10 et d'un débriefing collectif. La grille consolidée écran par écran a fait ressortir l'essentiel plutôt qu'un inventaire de détails : les frictions restantes tenaient encore aux notions du produit, mais à d'autres — fichiers attendus, circuit de validation — des angles morts que le regard interne n'avait pas vus et que seuls des clients en situation ont révélés. Chaque friction est repartie avec sa correction, intégrée aux maquettes.
Capitaliser dans le design system
Chaque arbitrage rendu sur Tâches valait au-delà de l'application : la squad partage ses composants avec les autres apps de la suite. Il fallait fixer les décisions au fil de l'eau plutôt qu'en fin de projet. J'ai tenu à jour les guidelines du design system en parallèle des maquettes : comportement de l'affichage des résultats de recherche (suggestions, raccourcis, états de la dropdown) et flow type des pages List — création, édition, suppression, actions bulk — le parcours de référence de toute page de liste.