Concevoir uniquement dans Figma ne suffit plus

Ce que Figma fait bien

Figma reste notre outil de discussion. On y aligne un parcours, on y tranche un libellé, on y montre une intention à un client. Pour KLEMI comme pour AYILE, les premiers écrans sont nés là.

Le problème commence quand on prend ces écrans pour le produit.

Ce qu’une planche ne montre pas

Une planche ne dit pas ce qui se passe si le réseau est lent, si le QR code est mal imprimé, ou si l’infirmier a les mains occupées. Sur Performance Teambuilding, le parcours participant tient en quelques écrans. Le vrai sujet, c’était le scan en extérieur, sans compte, sans application, avec une session déjà commencée.

Tant qu’on n’a pas un prototype cliquable, puis un build, ces cas restent des hypothèses. On les découvre trop tard, souvent en recette, parfois en live.

Ce que nous livrons à la place

Nous ne demandons pas à chaque designer d’écrire le code de production. Nous demandons que l’artefact montre le comportement :

• états de chargement, d’erreur et de vide
• ce qui change après une action, pas seulement le « happy path »
• le parcours sur téléphone, pas uniquement le frame desktop

Sur FlexTransfert, afficher frais, taux et délai avant validation n’est pas un détail visuel. C’est le contrat avec l’utilisateur. Ça se conçoit dans Figma. Ça se vérifie dans l’app.

Une habitude simple

Prototypez un flux critique de bout en bout avant de peaufiner les vingt autres écrans. Montrez-le à quelqu’un qui fera le métier, pas seulement à l’équipe projet. Ensuite seulement, on fige les pixels.

Figma reste central. Il n’est plus le livrable. Le livrable, c’est un usage qui tient une fois le produit allumé.