On vous a envoyé une série d'écrans gris : des rectangles barrés d'une croix à la place des images, des traits à la place du texte, aucun logo. Le prestataire appelle ça un wireframe et vous demande de le valider avant de passer aux maquettes. La tentation est de survoler, en se disant que le vrai travail commencera quand il y aura des couleurs. C'est pourtant là que se trouve l'occasion la moins chère de corriger un site ou une application.
J'ai conçu Moonworkers, mon logiciel de paie pour les petites entreprises britanniques (il figure dans mon portfolio de missions), en partant des utilisateurs : des personas d'abord, puis des wireframes, puis un design system dans Figma. Ce qui suit vient de ce travail et de quelques missions : ce qu'est un wireframe et ce qui le distingue d'une maquette, ma méthode pour en faire un qui sert, une grille pour le relire, et les cas où je saute l'étape.
01Un wireframe montre la structure, pas l'apparence
Nielsen Norman Group le résume dans une courte vidéo sur la différence entre wireframes et prototypes : un wireframe est une représentation simplifiée d'un site ou d'une application, faite de lignes et de texte. Il montre quels éléments sont présents et lesquels passent en premier. Le design visuel et la couleur n'y figurent pas, qu'il soit dessiné à la main ou dans un logiciel.
Le mot vient de l'anglais : wire, le fil de fer, et frame, le cadre. En français, on parle de maquette fil de fer, de maquette fonctionnelle, ou de zoning quand on reste au niveau des grandes zones d'une page. Figma, dans son guide sur le wireframing, le décrit comme le squelette de l'interface : des niveaux de gris, des boîtes à la place des images, et un plan qui aide l'équipe à s'accorder sur les exigences.
Ce que je demande à un wireframe tient en peu de questions. Qu'est-ce qu'il y a sur cet écran ? Dans quel ordre l'œil le rencontre-t-il ? Que peut faire la personne ici, et où va-t-elle ensuite ? Si le document y répond clairement, il a fait son travail, même s'il est laid.
02Wireframe, maquette, prototype : trois étapes, trois questions
Les trois mots circulent souvent l'un pour l'autre, et beaucoup de réunions confuses viennent de là. Je les distingue par la question à laquelle chacun répond :
- le wireframe répond à « quoi et où » : le contenu de chaque écran, sa hiérarchie, les chemins d'un écran à l'autre ;
- la maquette répond à « à quoi ça ressemble » : couleurs, typographies, images, marque, sur des écrans statiques ;
- le prototype répond à « est-ce que ça marche quand on s'en sert » : on clique, on enchaîne les écrans, on observe.
La frontière n'est pas étanche. Dans la même vidéo, Nielsen Norman Group précise que tout wireframe est un prototype de basse fidélité, mais que l'inverse n'est pas vrai. J'ai détaillé la suite du parcours dans mon article sur le prototype cliquable avant le développement.
Pourquoi ne pas sauter directement à la maquette ? Parce que le coût d'un changement monte à chaque étape. Nielsen Norman Group le dit sans détour dans son article sur la fidélité des prototypes : jeter du code coûte très cher, jeter un prototype beaucoup moins, surtout s'il tient sur une feuille de papier. Le même article relève un effet que j'ai souvent vu en réunion. Devant un rendu très soigné, un décideur est tenté de dire « c'est bien, mettons-le en ligne ». Devant un croquis, tout le monde s'attend encore à des changements.
03Faire un wireframe utile en cinq étapes
Voici la méthode que je suis, que le wireframe soit dessiné sur papier ou dans Figma.
1. Partir des personnes et de ce qu'elles viennent faire
Avant de tracer un rectangle, j'écris pour chaque écran qui arrive là et ce qu'il veut accomplir. Sur Moonworkers, les wireframes sont venus après les personas, et cet ordre a du sens : un écran sans destinataire ne se juge pas. Si vous n'avez pas encore de personas, j'explique comment en faire qui servent à décider.
2. Lister les écrans et les chemins
D'abord une liste des écrans, puis des flèches entre eux. Pour un site : la page d'accueil, une page de service, un article, le contact. Pour une application : l'inscription, le tableau de bord, la tâche principale. Les chemins comptent autant que les écrans, parce que c'est souvent entre deux pages qu'un parcours se casse.
3. Écrire avec le vrai contenu
Le faux texte cache les problèmes. Un vrai titre de quinze mots ne tient pas dans la place prévue pour quatre, et un menu numéroté de 1 à 4 ne dit rien de l'organisation des contenus. Le guide de Figma donne la même règle : dès qu'on organise l'information, mieux vaut utiliser le contenu réel que du lorem ipsum. Je mets au moins les vrais titres, les vrais boutons et les vrais libellés de formulaire.
4. Rester en gris, et dessiner plusieurs pistes
Pas de couleur, une seule police, des boîtes pour les images. Et plutôt qu'une seule proposition, deux ou trois. Pour le design parallèle, Nielsen Norman Group recommande de créer au moins trois alternatives et au plus cinq, sur quelques pages clés, affinées seulement jusqu'au niveau de wireframes grossiers, puis de fusionner les meilleures idées. En mission, j'ai vu une décision se débloquer quand plusieurs directions étaient montrées au même niveau de finition. Personne ne peut alors préférer une piste parce qu'elle est mieux habillée.
5. Annoter ce qui ne se voit pas
Un wireframe statique ne dit pas ce qui se passe quand on clique, quand un champ est mal rempli ou quand une liste est vide. J'ajoute des notes dans la marge : règles d'affichage, messages d'erreur, contenus qui viennent d'un autre système. Ces notes nourrissent ensuite le cahier des charges du site et évitent que le développeur devine.
04Relire un wireframe sans parler de couleurs
Si c'est vous qui validez, c'est ici que vous avez le plus à gagner. Un wireframe se relit avec une grille, pas au ressenti. Voici celle que j'utilise :
- sur chaque écran, je retrouve ce que la personne vient y faire, et l'action principale se voit sans chercher ;
- l'ordre des blocs suit l'ordre des questions que se pose le visiteur ;
- chaque bouton mène quelque part, et je sais où ;
- les cas difficiles sont prévus : liste vide, erreur, chargement, accès refusé ;
- rien n'est là seulement parce que les autres sites le font.
Le piège le plus courant consiste à commenter l'esthétique : « ce gris est triste », « le logo devrait être plus grand ». Le guide de Figma donne un conseil que j'applique : si les personnes qui relisent s'attardent sur des détails esthétiques plutôt que sur les besoins des utilisateurs, il faut baisser la fidélité du wireframe et retirer ce qui est trop soigné, jusqu'à obtenir les retours dont on a besoin. Je préfère prévenir avant la réunion : aujourd'hui, on ne parle ni couleur ni police, on parle de ce qui est sur la page et dans quel ordre.
Sur ce blog, je fais la même chose avec du texte. Chaque article suit une structure écrite avant la rédaction (une introduction courte, des intertitres, une partie pratique, une FAQ, les sources), et un outil vérifie que l'article la respecte avant de le publier. C'est un wireframe en texte : l'ordre et la place de chaque bloc sont décidés avant le style, et la relecture porte d'abord sur la structure.
05Quand sauter l'étape du wireframe
Le wireframe n'est pas un rite. Il y a des cas où je m'en passe, ou presque.
Quand un design system existe déjà et que l'écran ressemble à ce qui a été fait avant, dessiner en gris puis tout redessiner en couleur fait perdre du temps. Le guide de Figma le reconnaît : dans ce cas, explorer directement en haute fidélité peut être aussi rapide et aussi efficace. C'est l'un des intérêts d'un design system bien tenu.
Quand il faut tester un vrai comportement avec des utilisateurs, un wireframe ne suffit pas. Le manuel de service du gouvernement britannique, dans sa page sur les prototypes, distingue les deux usages : les croquis servent à explorer et discuter des idées entre collègues, les prototypes en code sont plus réalistes pour la recherche utilisateur. Il rappelle aussi qu'on ne copie pas le code d'un prototype tel quel en production.
Et quand la page est simple et connue, comme des mentions légales ou un formulaire de contact, un croquis de cinq minutes sur papier suffit. Ce qui compte, c'est que quelqu'un ait décidé de la structure avant de l'habiller.
Le wireframe a aussi ses limites. Il ne dit rien de la lisibilité réelle, du ton, ni de la sensation d'un écran sous le pouce. Et une équipe peut valider un wireframe sans l'avoir compris, simplement parce qu'il n'y avait rien d'accrocheur à contester. C'est pour cela que je fais commenter chaque écran à voix haute plutôt que d'attendre un « ok » par message.
06Par où commencer cette semaine
Si vous avez un site ou une application en préparation, prenez l'écran le plus important, celui où se jouent l'inscription, la demande de contact ou l'achat. Dessinez-le en gris, avec les vrais textes, sur une feuille ou dans Figma. Faites-en deux versions. Montrez-les à deux personnes qui ne connaissent pas le projet, et demandez-leur ce qu'elles feraient en premier.
Vous saurez vite si la structure tient. Si vous voulez être accompagné sur cette étape, du wireframe jusqu'au design system, cela fait partie de ce que je fais en mission, et on peut en parler.