De l'idée au wireframe : comment je structure un projet UX avant de toucher à Figma

Temps de lecture : 6 min

Quand j'ai débuté, le wireframe était pour moi une formalité un peu ennuyeuse qu'on faisait avant les "vraies" maquettes. Je le bâclais pour passer le plus vite possible à la phase où ça devenait joli.

C'était une erreur qui m'a coûté beaucoup de temps et d'allers-retours inutiles. Aujourd'hui, le wireframe est l'étape que je défends le plus farouchement dans mes projets. Voici pourquoi — et comment je l'aborde.

Le wireframe n'est pas une maquette dégradée

C'est le premier malentendu à lever. Un wireframe n'est pas une maquette à laquelle il manque les couleurs et les vraies images. C'est un outil de pensée structurelle — il sert à répondre à des questions précises avant de s'engager dans la production visuelle.

Ces questions sont : Quelle information doit apparaître sur cet écran ? Dans quel ordre ? Quelle est la hiérarchie visuelle ? Quel est le parcours entre les écrans ? Quelles actions sont disponibles à quel moment ?

Tant que ces questions ne sont pas résolues, travailler sur la couleur des boutons ou le choix de la typographie est une perte de temps. Le wireframe force à répondre à l'essentiel avant de s'occuper du superflu.

Étape 0 : avant même le wireframe, le flow

Avant de dessiner quoi que ce soit, je commence par cartographier le parcours utilisateur. Quelles sont les étapes que l'utilisateur va traverser pour accomplir son objectif ? Quels sont les points d'entrée ? Les bifurcations ? Les cas d'erreur ?

Je fais ça sur papier ou sur FigJam, avec des rectangles et des flèches. Ça ne prend pas longtemps et ça change tout : ça révèle les écrans manquants, les parcours trop longs, les boucles qui n'ont pas de sortie.

Beaucoup de problèmes de design que je rencontre dans des projets mal cadrés viennent d'un parcours qui n'a jamais été formalisé. On a designé des écrans sans savoir comment les utilisateurs y arrivent ou en repartent.

Étape 1 : le wireframe basse fidélité, sur papier

Oui, sur papier. Ou sur tableau blanc. L'outil importe peu — ce qui compte, c'est la vitesse et la liberté.

Je dessine des rectangles pour les blocs de contenu, des zigzags pour les images, des lignes pour le texte. En cinq minutes, j'ai une première idée de la structure d'un écran. En vingt minutes, j'ai une version grossière de tout le flow.

L'avantage du papier, c'est que personne ne va commenter la typographie ou la couleur des boutons. Les retours portent sur ce qui compte : est-ce que la logique est claire ? Est-ce que l'utilisateur a accès aux informations dont il a besoin au bon moment ?

Étape 2 : le wireframe moyenne fidélité sur Figma

Une fois la logique validée sur papier, je passe sur Figma pour une version un peu plus structurée — toujours en niveaux de gris, toujours sans vraies photos ni typographies définitives.

À cette étape, je commence à réfléchir aux composants. Quels éléments vont se répéter ? Y a-t-il des patterns cohérents entre les écrans ? Est-ce que la navigation est accessible partout où elle doit l'être ?

Je travaille aussi les états : l'état vide (quand il n'y a pas encore de données), l'état d'erreur, l'état de chargement. Ce sont souvent les grands oubliés du wireframe — et des sources de bugs et d'expériences dégradées en production.

Étape 3 : la présentation et la validation

Avant de passer aux maquettes haute fidélité, je présente le wireframe au client ou à l'équipe produit.

Cette présentation a une règle d'or : montrer en contexte, pas en statique. Un wireframe présenté écran par écran sans expliquer le parcours est difficile à évaluer. Je présente toujours en racontant l'histoire de l'utilisateur — "il arrive ici, il voit ça, il fait ça, il arrive là."

Les retours à cette étape sont précieux parce qu'ils sont encore peu coûteux à intégrer. Changer la position d'un bloc dans un wireframe prend deux minutes. Le même changement dans une maquette haute fidélité avec composants et variantes peut prendre une heure.

Ce que le wireframe révèle sur un produit

En travaillant beaucoup sur des wireframes, j'ai réalisé qu'ils fonctionnent comme un détecteur de problèmes. Quand un écran est difficile à wireframer — quand on n'arrive pas à trouver une structure claire — c'est presque toujours parce que le problème qu'il est censé résoudre n'est pas clairement défini.

Le wireframe met en évidence les ambiguïtés du brief. Il force à prendre des décisions qu'on repoussait. Il rend visible ce qui restait flou dans les discussions.

C'est pour ça que je considère le wireframe non pas comme une étape préliminaire, mais comme un outil de réflexion à part entière — au même titre que la recherche utilisateur ou les personas.

Un conseil pour les designers qui débutent

Si tu as tendance à sauter le wireframe pour aller directement aux maquettes, je t'encourage à faire l'expérience inverse sur ton prochain projet : passe deux fois plus de temps en wireframe que tu ne le ferais habituellement.

Tu verras probablement que tes maquettes avancent ensuite deux fois plus vite, avec deux fois moins de retours. Et que le résultat final est plus cohérent, plus logique, plus solide.

Le wireframe est l'investissement qui se rentabilise le mieux dans un projet de design. Je n'ai jamais regretté d'en avoir fait trop. J'ai souvent regretté d'en avoir fait trop peu.

Dans mes case studies, je documente les phases de wireframe de mes projets — avec les itérations, les choix abandonnés et les problèmes que ça m'a permis d'éviter.