Qonto a construit un process de spécification visuel et fonctionnel pour cartographier l'expérience utilisateur à l'échelle. Cette Masterclass couvre la création de la librairie, les rôles définis, la production d'écrans et les métriques de succès. Le tout dans Figma, avec une collaboration transversale Product, Design, Brand et Tech.
1. 4 axes couverts dans cette Masterclass
Créer et maintenir une librairie de spécifications en équipe. Structure des fichiers, conventions de nommage, ownership partagé.
Les process mis en place. Définition des rôles, circuit de production des écrans, revues d'équipe.
Les difficultés rencontrées. Définition des success metrics, tracking des résultats, conformité à la production.
Les bénéfices retirés. Visibilité accrue, alignement design-tech, réduction des delta entre specs et production.
2. Comment Qonto organise ses Visual Specs
Pas d'UX Research dédié
Choix du CPO : Product Managers et Product Designers vont directement discuter avec les utilisateurs. Ils ne sont pas que des concepteurs techniques de fonctionnalités.
Design System décentralisé
Un seul Design System Designer guide les Product Designers. Quand un designer a besoin d'ajouter un composant, il se rapproche de l'équipe Design System. Le designer est challengé, accompagné jusqu'à la livraison et la documentation.
Teamwork à tous les niveaux
Le PM écrit directement les specs sur Figma. La livraison d'une feature est une responsabilité d'équipe, pas seulement du designer pour les écrans ou du PM pour les specs fonctionnelles.
Les développeurs sont principalement en mode "View" sur Figma. Les commentaires suffisent pour les échanges.
3. Circuit de production des spécifications
Intégration du branding
Le branding est intégré dès que la solution est validée en faisabilité technique et que la phase de spécifications démarre. Étapes : demande d'assets à l'équipe Brand, spécifications terminées avec illustrations, revue d'équipe avec le brand designer, update de la librairie de Visual Specs.
Gestion des variants
Pour les écrans différents selon les pays, des variants sont créés sous l'écran principal avec les règles fonctionnelles liées à chaque variation.
Phases d'itération
Les grosses fonctionnalités sont découpées en sous-parties. Sur les petites fonctionnalités, les success metrics sont traquées et les prochaines actions priorisées en conséquence.
4. Pourquoi Figma et pas Notion
"Les Visual Specs sont d'abord visuelles. Figma a été retenu pour la collaboration : Product Designers, Product Managers, Brand Designers, Copywriters et Développeurs sur un même fichier. Notion reste utilisé pour le suivi de"
FigJam uniquement pour les ateliers d'idéation. Figma pour tout le reste.
Estimation du temps de dev et analyse technique restent sur Notion dans la carte liée au projet.
Ticketing centralisé dans Notion (fusion de tous les outils de ticketing).
Temps passé sur les specs mesuré par tracking de la carte en phase de spec dans le kanban Notion.
5. Collaboration entre designers et développeurs
La conformité à la production est la plus grosse source de friction remontée par l'équipe Tech. Le teamwork quotidien permet de corriger les deltas pas à pas.
Implication tech dans la conception
Les développeurs sont intégrés dès la "Value Engineering", juste après la validation du cadre projet ("Value Analysis").
Pas de QA dédié
Les équipes sont responsables de ce qu'elles produisent, de la conception à la mise en production.
6. Les défis restants
Deux chantiers identifiés : scaler l'usage des Visual Specs à toute l'équipe de manière cohérente et fluide. Former les nouveaux arrivants au process et à la librairie.
L'adoption n'a pas nécessité de réécriture complète. Qonto a commencé par un premier projet pilote, analysé les success metrics, documenté la méthode et ouvert aux autres équipes. Les spécifications sont réécrites projet par projet.