Du wireframe au prototype

Avant de brancher quoi que ce soit, il faut nommer précisément ce qu'on produit, car les trois mots — wireframe, mockup, prototype — désignent trois intentions différentes et sont trop souvent employés l'un pour l'autre. Le wireframe pose la structure et la hiérarchie en gris, sans style : il répond à « où va quoi ». Le mockup est une maquette statique haute fidélité, avec couleurs, typo et composants finaux : il répond à « à quoi ça ressemble ». Le prototype, enfin, est une maquette cliquable : il répond à « comment ça se comporte ».

Ce qui distingue vraiment le prototype des deux autres, c'est qu'il ajoute la dimension temporelle : la navigation d'un écran à l'autre, les états successifs, les transitions, le retour visuel après une action. C'est précisément cette dimension qui permet de tester un parcours avant de l'avoir codé. Un mockup montre une photo ; un prototype fait vivre un film. Et c'est en regardant quelqu'un « jouer » ce film qu'on découvre les frictions qu'aucune image figée ne révèle.

D'où une règle pratique qui t'évitera beaucoup de temps perdu : on ne prototype que ce qu'on va tester ou démontrer. Rendre cliquable chaque écran d'une application « au cas où » représente un travail énorme, vite périmé au premier changement. Si tu n'as pas prévu de test utilisateur ni de démo pour un écran donné, un mockup bien annoté suffit. Le prototype est un outil de validation, pas une fin en soi — garde ton énergie pour les parcours à enjeu.

• Wireframe : structure et hiérarchie en gris, zéro style
• Mockup : maquette statique haute fidélité (couleurs, typo, composants finaux)
• Prototype : maquette cliquable qui simule le comportement

Le prototype ajoute la dimension temporelle : navigation, états, transitions, feedback utilisateur. C'est ce qui te permet de tester un parcours avant de coder.

La question la plus mal posée en prototypage est « quel niveau de détail dois-je viser ? » — parce qu'on y répond souvent par « le plus joli possible ». La bonne question est : quelle décision est-ce que je veux prendre grâce à ce prototype ? La fidélité doit servir cette décision, pas ton envie de faire beau. Valider un parcours global n'a pas besoin de couleurs ; valider le ressenti final d'un écran en a besoin. Chaque niveau a son usage.

Concrètement, trois paliers. Le low-fi (papier, Excalidraw) sert à valider un parcours et à itérer très vite, quitte à jeter. Le mid-fi (Figma en niveaux de gris) précise la structure et la logique d'interaction. Le high-fi (Figma, Penpot, Framer) montre les composants finaux avec des données réalistes. Et il est utile de comprendre que la fidélité se règle sur trois axes indépendants : le visuel (du noir et blanc aux couleurs), le contenu (du Lorem ipsum au vrai texte) et le comportement (du statique à l'animation complète). Tu peux très bien avoir un écran visuellement abouti mais au comportement encore basique, ou l'inverse.

Le principe qui doit guider tes choix, c'est le coût de la modification : plus la fidélité est élevée, plus changer quelque chose coûte cher. Déplacer un bloc gris est trivial ; refaire un écran entièrement stylé avec ses composants et ses vraies données prend des heures. La stratégie gagnante consiste donc à travailler l'essentiel en mid-fi, et à ne monter en haute fidélité que sur les écrans que tu vas réellement tester ou livrer. Investir du détail visuel sur un parcours que tu n'as pas encore validé, c'est risquer de tout refaire au premier retour.

• Low-fi (papier, Balsamiq, Excalidraw) : valider un parcours global, itérer vite
• Mid-fi (Figma en gris) : structure et logique d'interaction
• High-fi (Figma, Penpot, Framer) : composants finaux et données réalistes

Les 3 axes de fidélité

• Visuel : du noir et blanc aux couleurs finales
• Contenu : Lorem ipsum vs vrai contenu réaliste
• Comportement : statique vs navigation vs animations complètes

Figma sépare deux modes : le mode Design, où tu dessines tes écrans, et le mode Prototype, où tu les relies entre eux pour les rendre navigables. Passer de l'un à l'autre ne change rien à tes maquettes ; ça superpose simplement une couche d'interactions par-dessus. Le principe de base est très visuel : tu sélectionnes un élément déclencheur (un bouton), tu tires une poignée vers l'écran de destination, et tu choisis ce qui déclenche la navigation et quelle action elle produit. En quelques minutes, un fichier de maquettes statiques devient un parcours cliquable.

Deux notions structurent toute interaction : le trigger (ce qui la déclenche) et l'action (ce qu'elle fait). Côté triggers, le plus courant est On click (clic ou tap), mais tu as aussi While hovering (tant que la souris survole, utile pour un tooltip), On drag (interactions glissées) ou After delay (transitions automatiques, parfait pour simuler un chargement). Côté actions : Navigate to pour changer d'écran, Open overlay pour afficher une modale par-dessus, Swap with pour remplacer le contenu d'un composant, ou Set variable pour modifier un état logique.

Le vrai gain de temps vient des composants avec variantes. Plutôt que de dupliquer un bouton pour chacun de ses états (normal, survol, focus, chargement, erreur), tu crées un seul composant qui contient toutes ses variantes. Tu le réutilises partout, et dans le mode Prototype tu le fais passer d'un état à l'autre avec Swap with. Ce réflexe rapproche ton fichier de la logique du code — un composant, des états, des props — et c'est aussi ce qui rendra le hand-off au développement bien plus fluide, comme tu le verras au dernier chapitre.

Les étapes

1. Sélectionne l'onglet Prototype dans le panneau de droite
2. Sélectionne l'élément déclencheur (un bouton, un lien)
3. Tire la poignée bleue ronde vers l'écran cible
4. Choisis le trigger et l'action
5. Définis un Starting frame, puis lance Present

Les triggers utiles

• On click : déclic à la souris ou au tap
• While hovering : tant que la souris reste sur l'élément
• On drag : pour les interactions glissées (carrousels, switches)
• After delay : utile pour les transitions automatiques
• Mouse enter / Mouse leave : pour gérer un tooltip

Les actions principales

• Navigate to : aller à un autre écran
• Open overlay : ouvrir une modale par-dessus
• Swap with : remplacer le contenu d'un composant
• Set variable : modifier une variable Figma (logué / non logué)
• Back / Close overlay : retour ou fermeture

Une transition n'est pas une décoration : elle raconte la relation entre deux écrans. Un panneau qui glisse depuis la droite dit « tu avances dans une pile » ; un fondu dit « le contenu se remplace » ; une modale qui apparaît par-dessus dit « tu es toujours au même endroit, on te demande juste quelque chose ». Bien choisies, les transitions aident l'utilisateur·ice à se repérer et donnent une impression de qualité. Mal dosées, elles ralentissent et agacent. La règle générale : rester sobre.

L'outil central dans Figma est Smart Animate : il détecte automatiquement les propriétés communes entre deux écrans (position, taille, opacité) et interpole entre les deux, ce qui donne des transitions fluides sans avoir à tout animer à la main. À côté, tu disposes de transitions prêtes à l'emploi — Instant (aucune), Dissolve (fondu), Move in/out, Push, Slide — qu'on choisit selon le sens qu'on veut donner au changement d'écran. Pour la durée et le rythme, vise 150 à 300 ms : plus court, on perçoit un saut ; au-delà de 500 ms, ça traîne. Un easing comme Ease in and out ou Spring rend le mouvement plus naturel qu'une vitesse constante.

Au-delà des transitions entre écrans, un bon prototype prévoit les micro-interactions qui répondent à l'utilisateur·ice : un état de chargement (skeleton ou spinner) pendant un appel, un retour de succès (toast, coche verte) après une action, un message d'erreur clair avec possibilité de réessayer, un état vide qui suggère quoi faire quand il n'y a pas encore de contenu, et bien sûr les retours au survol et au focus. Ce sont ces détails qui font la différence entre un prototype « joli mais mort » et un prototype qui donne vraiment la sensation du produit fini. Pense aussi, pour le produit réel, à respecter la préférence système reduced motion des personnes sensibles au mouvement.

Smart Animate

Figma détecte automatiquement les propriétés communes entre deux frames (position, taille, opacité) et interpole entre les deux. Indispensable pour les transitions élégantes sans tout animer à la main.

Types de transitions

• Instant : pas de transition, switch direct
• Dissolve : fondu
• Move in / out : glisse depuis un côté
• Push : pousse l'ancien écran vers le côté
• Slide in / out : glisse par-dessus

Durée et easing

• Durée typique : 150 à 300 ms
• Au-delà de 500 ms, ça paraît lent
• Easing recommandé : Ease in and out, Spring pour un rendu plus naturel
• Toujours offrir une option de reduced motion dans le produit final (préférence OS)

Micro-interactions à prévoir

• Loading : skeleton ou spinner pendant un appel API
• Succès : feedback visuel après une action (toast, check vert)
• Erreur : message clair, possibilité de réessayer
• État vide : pas de résultat, suggestion d'action
• Hover et focus : feedback sur les interactifs

Le piège le plus répandu du prototypage, c'est de ne montrer que le happy path : le scénario idéal où tout se passe bien, où l'utilisateur·ice saisit les bonnes données et clique au bon endroit. Un tel prototype fait une belle démo mais ment : dans la vraie vie, les gens laissent des champs vides, se trompent de mot de passe, perdent leur connexion. Si ces situations n'existent pas dans ton prototype, tu ne les as pas conçues — et le développement les improvisera, souvent mal.

Un parcours sérieux couvre donc trois niveaux. Le happy path (le scénario nominal, de bout en bout). Les chemins d'erreur (champ vide, identifiant inconnu, erreur réseau, délai dépassé). Et les états système que traverse une même page : chargement, vide, partiel, succès, échec. Pour t'y retrouver quand les écrans se multiplient, adopte une convention de nommage : un préfixe numérique pour l'ordre et un suffixe sémantique pour l'état, comme 01-login-default, 02-login-error, 03-dashboard-empty. Ça paraît anodin, mais sur un flow de vingt écrans c'est ce qui te sauve.

Comment éviter de dupliquer des écrans presque identiques pour gérer, par exemple, un état connecté et non connecté ? Avec les variables Figma. Tu crées une variable booléenne isLoggedIn, et tu adaptes le contenu des écrans en fonction de sa valeur via des actions conditionnelles. Tu gardes ainsi un seul jeu d'écrans, piloté par un état logique, comme le ferait du vrai code. Un dernier repère pour juger ton prototype : s'il ne fonctionne que sur l'unique clic prévu et que tout le reste est inerte, tu as une démo, pas un prototype testable. Couvre au minimum le tap à côté de la cible — c'est exactement ce que feront tes testeur·euses.

Les 3 niveaux à couvrir

• Happy path : le scénario nominal, du début à la fin sans friction
• Chemins d'erreur : champ vide, identifiant inconnu, erreur réseau, timeout
• États système : loading, vide, partiel, succès, échec

Convention de nommage

Nomme tes écrans pour t'y retrouver : 01-login-default, 02-login-error, 03-dashboard-empty. Un préfixe numérique te donne l'ordre. Un suffixe sémantique précise l'état.

Variables Figma pour les états logiques

Tu veux gérer un état logué / non logué sans dupliquer tous les écrans ? Crée une variable booléenne Figma isLoggedIn. Les écrans s'adaptent via des Conditional Set Variable en réponse aux actions.

Le test utilisateur est le moment où ton prototype prend tout son sens : c'est là qu'on découvre l'écart entre ce qu'on croyait évident et ce que les gens comprennent réellement. Bonne nouvelle contre-intuitive, popularisée par Jakob Nielsen : tu n'as pas besoin d'une grande étude. Cinq personnes révèlent environ 85 % des problèmes d'usabilité ; au-delà, tu vois surtout les mêmes soucis se répéter. Mieux vaut donc faire trois séries de cinq tests, en corrigeant entre chaque, qu'un seul test massif sur une version qui ne bougera plus.

La préparation fait la moitié du travail. Recrute cinq profils proches de ta cible réelle — surtout pas tes collègues, qui connaissent déjà le produit et le vocabulaire. Écris un court script de trois à cinq tâches, et formule-les en objectif et non en action : dis « retrouve ta dernière commande », jamais « clique sur l'onglet Historique ». Si tu dictes les clics, tu testes la mémoire de tes consignes, pas ton interface. En donnant un but, tu observes le chemin que la personne emprunte spontanément — et c'est précisément là qu'apparaissent les frictions.

Pendant le test, ta posture est celle d'une observatrice : reste silencieuse, n'aide pas, demande à la personne de penser à voix haute, et note les hésitations, les phrases prononcées, les endroits cliqués par erreur. Règle d'or à ne jamais oublier : l'utilisateur·ice n'a jamais tort. Si elle bloque, ce n'est pas qu'elle « ne sait pas se servir d'un ordinateur », c'est que ton prototype n'est pas assez clair — note la friction plutôt que de la justifier. Après chaque session, corrige les problèmes les plus graves avant le test suivant : c'est ce cycle observer-corriger-retester qui te fait progresser vite. Le scénario ci-dessous te met justement dans la peau de cette observatrice.

Préparer le test

• Recrute 5 profils proches de la cible (pas tes collègues)
• Prépare un script avec 3 à 5 tâches précises
• Formule les tâches en objectif, pas en action (« retrouve la commande de mars », pas « clique sur l'onglet Historique »)
• Prépare un canal pour la session (Zoom, Meet, ou présentiel)

Pendant le test

• Reste silencieuse, observe, n'aide pas
• Demande de penser à voix haute
• Note les hésitations, les phrases prononcées, les zones cliquées par erreur
• Mesure : succès / échec, temps, nombre d'erreurs, score de satisfaction (SUS)

Itère vite

Après chaque test, corrige les frictions les plus graves avant le test suivant. Tu apprends plus en 5 itérations qu'en 5 tests sur le même proto.

Le hand-off, c'est le passage de relais entre le design et le développement — et c'est souvent là que la qualité se perd. Un prototype magnifique mal transmis donne une implémentation approximative ; un prototype même modeste, bien documenté, donne un résultat fidèle. L'objectif de ce chapitre est simple : faire de ton prototype une véritable spécification exploitable par la personne qui va coder, pas juste une jolie image à imiter au jugé.

Figma propose pour cela le Dev Mode, une vue dédiée au développement : les tokens (couleurs, espacements, typo) y sont exposés, les mesures et le CSS générés automatiquement, et les variables exportables vers CSS, Tailwind, iOS ou Android. C'est précieux, mais insuffisant à lui seul, car le Dev Mode donne le quoi visuel, pas le comment comportemental. Tu dois documenter en clair, à côté de la maquette ou dans le ticket, ce que le code seul ne peut deviner : ce que fait chaque bouton, les conditions de passage d'un état à l'autre, l'ordre de tabulation au clavier, les contrastes vérifiés, et ce que devient chaque bloc en responsive.

Deux réflexes complètent un bon hand-off. D'abord, fige une version de référence (par exemple v1.0-handoff) : quand le design continuera d'évoluer, l'équipe pourra toujours revenir à la maquette qui a servi de spec, ou comparer ce qui a changé. Ensuite, et c'est le plus important : un prototype ne remplace jamais une conversation. Reste joignable, bloque un créneau régulier avec l'équipe, et accueille sereinement un « cet écran est difficile à réaliser » — c'est le signe que le prototype fait son travail : provoquer la discussion technique avant le code plutôt qu'après. Le mieux étant souvent d'ajuster la maquette avec l'alternative proposée plutôt que d'imposer une solution coûteuse.

Dev Mode dans Figma

• Active Dev Mode sur ton fichier
• Tokens (couleurs, espacements, typo) accessibles côté droit
• Mesures et CSS générés automatiquement
• Variables exportables en CSS, Tailwind, iOS, Android

Documenter au-delà du visuel

• États interactifs : que fait chaque bouton, dans quel ordre
• Conditions de transition : quand passer d'un état à l'autre
• Accessibilité : focus visible, ordre de tabulation, contrastes vérifiés
• Responsive : que devient chaque bloc en mobile
• Lien vers le ticket Jira, Linear ou GitHub Issue de la feature

Versionner les livrables

Fige une release v1.0-handoff dans Figma (Branching ou simple duplication). Quand le design évolue, tu peux toujours revenir à la version qui a servi de spec, ou comparer ce qui a bougé.