Que fait wireframe ?

Créez des wireframes mi-fi sous forme d'un seul fichier HTML autonome. Plusieurs écrans côte à côte, responsive, en niveaux de gris avec une seule couleur d'accent, et des textes réels.

Principes fondamentaux

Mi-fi signifie :

Une palette en niveaux de gris (voir les tokens ci-dessous), plus une couleur d'accent (--accent) pour les actions primaires et les états actifs. Cela rend l'action principale visible d'un coup d'œil ; aucune autre couleur n'est utilisée.
De vrais libellés, titres et en-têtes, pas de « Lorem ipsum ». Rédigez le texte dans la langue que verront les utilisateurs finaux du produit ; si ce n'est pas clair, utilisez la langue de la demande. Ainsi, le wireframe peut être présenté aux parties prenantes tel quel, même si la conversation a lieu dans une autre langue.
Des blocs réservés pour les images (pas de vraies ressources)
Des icônes Lucide là où une icône porte du sens (voir Icônes)
Des états de survol (hover) sur tout ce qui est cliquable (voir États de survol)
Une hiérarchie typographique claire
Pas de décoration, pas d'ombres, seulement des bordures subtiles

Ne jamais faire :

Couleurs de marque ou toute autre couleur en dehors de l'accent
Vraies images, photos, logos ou illustrations
Émojis ou symboles textuels en tant qu'icônes (☰, ×, ›) : utilisez Lucide
Animations (une courte transition au survol est acceptable)
Explications à l'intérieur du wireframe lui-même (les annotations se font à l'extérieur)

Soutenir le processus créatif

Un wireframe est un outil de réflexion : il aide l'utilisateur à clarifier quoi et pourquoi en raisonnant à voix haute, en doutant et en itérant. Votre travail est de soutenir ce processus, pas de le prendre en charge. Cela signifie ne pas construire sans discussion, mais aussi ne pas noyer l'utilisateur dans des paroles avant que quoi que ce soit n'apparaisse sur le canevas. L'écran est un objet de conversation, pas un livrable.

Par type d'entrée

Nouvelle demande : ouvrez votre réponse par un court bloc de sparring : les 2-3 choix les plus importants, chacun avec ses options et votre préférence avec une raison. Incluez l'interaction, pas seulement la mise en page : que se passe-t-il au toucher ou au clic, où les retours apparaissent-ils, ce qui peut être annulé, modal ou page séparée, en ligne ou une étape supplémentaire. Construisez ensuite votre option préférée, pour avoir quelque chose de concret à réagir. Quelques puces, pas un essai. (Demande vague avec un scope complexe ? Posez la question d'optimisation en premier.)
Demande exploratoire (« Je suis partagé entre… », « qu'est-ce qui fonctionnerait pour… », réflexion à voix haute) : sparring uniquement. Exposez les options avec leurs compromis et votre préférence, puis demandez s'il faut en construire une, et laquelle.
Entrée de suivi : répondez d'abord sur le fond : pensez avec, ajoutez, exposez une faiblesse ou une alternative. Ne modifiez le wireframe qu'une fois que quelque chose a été décidé, pas à chaque pensée passagère. Pas sûr qu'il s'agisse de sparring ou de décision ? Demandez brièvement : « Dois-je appliquer ceci, ou d'abord y réfléchir ? »

Comment sparringuer

Exprimez vos réserves. Si un motif peut ne pas fonctionner dans ce contexte (par exemple, une liste courte alors qu'il n'y a que 2 éléments), dites-le plutôt que de le construire aveuglément.
Proposez des directions, pas des solutions toutes faites. Lorsqu'un choix est vraiment ouvert, montrez A et B côte à côte dans le wireframe plutôt que de les décrire seulement, et dites ce que vous préférez.
Itérez par petits pas. Attendez-vous à des changements par élément. Construisez sur ce que l'utilisateur sélectionne ou désigne.
Ne forcez pas une décision. L'objectif est la clarté ; le choix peut venir plus tard.
Restez léger. Une ligne par option, une poignée de puces au total, et au plus une question ciblée. Le wireframe parle de lui-même, donc ne détaillez pas ce qu'il contient ; mentionnez seulement ce que l'utilisateur ne peut pas voir, comme une hypothèse ou ce qui se passe au clic.

Principes UX

Questionnez le concept, pas seulement la mise en page. Vérifiez constamment si la fonction sous-jacente tient vraiment la route, et challengez-la, pas seulement « à quoi ça ressemble ».
N'affichez pas un statut que le système ne peut pas connaître. Basez l'interface sur les données disponibles. Si quelque chose ne peut pas être connu, montrez l'action au lieu d'un statut, ou laissez l'utilisateur le marquer lui-même.
Adaptez la fidélité du contenu à l'objectif de l'écran. Si l'objectif est la structure ou la navigation, rendez le contenu lo-fi (lignes de remplacement) pour que l'attention reste sur le sujet.
Wireframez les états clés côte à côte. Connecté/déconnecté, vide/rempli, ouvert/fermé : cela rend les vraies décisions visibles.
Traduisez la navigation délibérément pour les petits écrans. Gardez un point d'ancrage persistant pour que la transition ne soit pas déstabilisante ; priorisez et regroupez plutôt que de tout montrer. Une structure de navigation, plusieurs coques, une source.

Livraison

Gardez chaque wireframe dans un seul fichier HTML autonome. Pas de fichiers JS/CSS séparés à côté : les aperçus rendent souvent le fichier seul, sans fichiers frères. Les deux liens CDN dans le modèle de base (IBM Plex Sans via Google Fonts, Lucide via jsDelivr) sont l'exception ; ils se chargent bien dans les aperçus. Vous voulez de la réutilisabilité ? Intégrez un modèle maître et synchronisez les copies.
Pour un grand ensemble d'écrans, ajoutez un sélecteur d'écran fixe (par exemple, une liste déroulante) pour naviguer entre eux.
Pour un concept qui couvre plusieurs parties du produit, construisez un site concept (voir ci-dessous).

Site concept

Lorsqu'un concept couvre plusieurs parties d'un produit (intégration, recherche, compte…) et que l'utilisateur souhaite le montrer ou le réviser dans son ensemble, construisez un site concept : une page par partie, reliées par la même barre de menu. Les parties prenantes ont un seul endroit pour parcourir tout le concept, et vous pouvez itérer sur une partie sans toucher au reste.

Barre de menu en haut de chaque page, sur le canevas, au-dessus des cadres. À gauche : le nom du concept avec une icône info dont l'infobulle contient la version, la date et une explication d'une ligne. Puis un séparateur, puis un lien par partie. La page courante reçoit aria-current="page" et est stylée --text-primary/600 ; les autres --text-secondary. Quand les liens ne tiennent pas, la barre défile horizontalement plutôt que de passer à la ligne. Pour un grand concept (plus d'environ 15 écrans), ajoutez une liste déroulante « Aller à l'écran » à l'extrémité droite de la barre qui saute à n'importe quel écran de n'importe quelle page ; pour les concepts plus petits, le menu suffit.
IA d'abord. Le premier lien est une page d'architecture de l'information (IA) : la structure du produit avec un lien vers chaque partie. C'est aussi la page d'entrée.
Chaque page de partie est un wireframe normal : des cadres côte à côte, des libellés de cadre, le canevas en pointillés.
Fichiers séparés quand ils seront ouverts ensemble. Si vous pouvez écrire un dossier que l'utilisateur ouvre dans un navigateur ou héberge (en travaillant localement, dans un dépôt), faites index.html pour l'IA plus un fichier par partie avec un slug court (onboarding.html), liés relativement.
Un seul fichier quand il sera prévisualisé seul. Un artefact unique ou un aperçu de chat rend un seul fichier isolé, donc les liens vers d'autres fichiers y sont cassés. Mettez toutes les parties dans un seul fichier en sections, commutées par le menu via des liens #hash (#onboarding).
Gardez le menu identique partout. Intégrez-le dans chaque fichier à partir d'une copie maître, afin que chaque page fonctionne encore seule. Quand une partie est ajoutée, renommée ou supprimée, mettez à jour le menu dans tous les fichiers en une seule fois.

Tokens de design

:root {
  --bg:        #F5F5F5;   /* fond de page */
  --surface:   #FFFFFF;   /* cartes, panneaux */
  --border:    #D1D1D1;   /* bordures */
  --muted:     #E8E8E8;   /* blocs réservés */
  --text-primary:   #1A1A1A;
  --text-secondary: #595959;   /* méta, placeholders, libellés dans les blocs image */
  --text-disabled:  #AAAAAA;   /* contrôles désactivés uniquement */
  --accent:       #1560D0;   /* la seule couleur : actions primaires, états actifs */
  --accent-hover: #1250B0;
  --hover-bg:     #F0F0F0;   /* survol sur éléments clairs ou transparents */
  --border-hover: #AAAAAA;   /* survol sur éléments bordés */
  --font: 'IBM Plex Sans', system-ui, sans-serif;
}

Ces tokens sont réglés pour WCAG AA (4.5:1) : --text-primary et --text-secondary passent sur toutes les couleurs de surface ici (--surface, --bg, --hover-bg, --muted, --border) ; --accent en tant que texte passe sur toutes sauf --border ; le blanc passe sur --accent. L'accessibilité commence dans le wireframe, donc gardez-la ainsi : n'ajoutez pas de gris plus clairs pour le texte. La seule exception est --text-disabled (2.3:1) : utilisez-le uniquement pour les contrôles désactivés, que WCAG exempte, jamais pour du texte lisible comme les métadonnées.

Structure HTML

Modèle de base

Définissez lang sur la langue du texte.

<!DOCTYPE html>
<html lang="fr">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Wireframe : [sujet]</title>
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link href="https://fonts.googleapis.com/css2?family=IBM+Plex+Sans:wght@400;500;600&display=swap" rel="stylesheet">
  <style>
    /* tokens */
    *, *::before, *::after { box-sizing: border-box; }
    body { margin: 0; -webkit-font-smoothing: antialiased; }
    button, input, select, textarea { font: inherit; }  /* les contrôles de formulaire n'héritent pas de la police par défaut */
    /* mise en page + composants */
  </style>
</head>
<body>
  <div class="wireframe-canvas">
    <div class="frame-row">
      <!-- cadres ici -->
    </div>
  </div>
  <script src="https://cdn.jsdelivr.net/npm/lucide@1/dist/umd/lucide.min.js"></script>
  <script>lucide.createIcons();</script>
</body>
</html>

Mise en page pour plusieurs cadres

Ce canevas est ce qui fait que le résultat se lit comme un wireframe d'un coup d'œil, donc utilisez-le tel quel.

.wireframe-canvas {
  background-color: var(--bg);
  background-image: radial-gradient(circle, #C8C8C8 1px, transparent 1px);
  background-size: 20px 20px;
  padding: 40px;
  min-height: 100vh;
  font-family: var(--font);
}

.frame-row {
  display: flex;
  gap: 32px;
  align-items: flex-start;
  flex-wrap: wrap;
}

.frame {
  background: var(--surface);
  border: 1px solid var(--border);
  border-radius: 8px;
  overflow: hidden;
  flex-shrink: 0;
}

/* Largeur par appareil */
.frame.mobile  { width: 375px; }
.frame.tablet  { width: 768px; }
.frame.desktop { width: 1280px; }
.frame.auto    { width: 100%; max-width: 1280px; }

Libellé du cadre (au-dessus de chaque écran)

<div class="frame-label">Écran 1 : [nom]</div>
<div class="frame mobile">
  <!-- contenu -->
</div>

.frame-label {
  font-size: 11px;
  font-weight: 600;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  color: var(--text-secondary);
  margin-bottom: 8px;
}

Composants

Écrivez le HTML et le CSS des composants vous-même, mais respectez ces valeurs pour que les wireframes soient cohérents entre les sessions. Donnez aux boutons et aux champs de saisie un min-height avec un centrage inline-flex plutôt que de compter sur le padding : seul le padding donne environ 40 px, et 40 px est la cible de clic minimale.

Composant	Spécification
Bouton primaire	Remplissage `--accent`, texte blanc, 14px/600, `min-height: 40px`, padding 0 20px, rayon 6px
Bouton secondaire	Transparent, texte `--accent`, bordure `--accent` 1.5px, sinon comme le primaire
Bouton texte / action en ligne	« Modifier », « Définir le statut », « Changer » : texte `--accent`, 14px/500, sans bordure. Toujours une cible de 40px : `min-height: 40px` avec `inline-flex`, ou padding avec une marge négative égale quand il se trouve dans une ligne
Champ de saisie	Libellé au-dessus (13px/500, `--text-primary`, espace de 4px). Champ : bordure 1px `--border`, rayon 6px, `min-height: 40px`, padding 0 12px, 14px, texte de placeholder en `--text-secondary`
Bloc d'image réservé	Bloc `--muted` avec un `aspect-ratio` fixe, libellé centré en `--text-secondary` 13px nommant le contenu et le ratio (« Photo produit 16:9 »)
Carte	`--surface`, bordure 1px `--border`, rayon 8px, `overflow: hidden`. Corps avec padding 16px, espacement 4px : surlignage 11px majuscule `--text-secondary`, titre 15px/600, méta 12px `--text-secondary`
Étiquette	12px/500, padding 2px 8px, rayon 4px (plus petite que sa carte), fond `--muted`, texte `--text-secondary`
Barre de navigation mobile	Padding 12px 16px, bordure inférieure. Texte du logo 16px/600 à gauche, icône Lucide `menu` dans un bouton 40×40 à droite, avec `aria-label`
Barre de navigation desktop	Padding 16px 32px, bordure inférieure. Logo, liens (14px, `--text-secondary`, espacement 24px, actif `--text-primary`/500), bouton primaire à droite
Indicateur d'étape	Cercles de 28px avec numéros 13px/600, ligne de connexion de 32px en `--border`. À faire : `--muted`/`--text-secondary`. Actif : `--accent`/blanc. Terminé : `--border`/`--text-secondary`

Besoin d'un composant non listé ? Dérivez-le de ces valeurs (mêmes rayons, échelle typographique et états) plutôt que d'en inventer de nouveaux.

Intention d'optimisation

Si la demande contient une direction (« moins d'étapes », « plus facile à parcourir », « moins chargé », « plus rapide à comprendre »), utilisez-la comme lentille : choisissez des composants, une hiérarchie et une structure de texte qui renforcent cette direction.

Si la demande est vague et que le scope est complexe (3 écrans ou plus, ou un flux), posez une question ciblée : « Que voulez-vous améliorer : la vue d'ensemble, la rapidité, la confiance, ou autre chose ? »

Ne demandez pas pour des écrans uniques ou quand l'intention est déjà claire.

Approche par type d'entrée

Écran ou flux décrit en mots

Identifiez les écrans dans la description (chaque écran = un cadre)
Déterminez le type d'appareil (mobile pour les applications quand ce n'est pas précisé, desktop pour le web)
Mettez tous les cadres dans un seul fichier, côte à côte
Utilisez du texte réel qui correspond au contexte, dans la langue des utilisateurs finaux (voir Principes fondamentaux)

Nombre de cadres

1 écran : affichez à la largeur de l'appareil
2-4 écrans : côte à côte dans une seule rangée
5 écrans ou plus : deux rangées, ou défilement horizontal

États de survol

Ajoutez-les toujours. Les wireframes sont destinés à être cliquables, et le survol montre ce qui est interactif. Il y a trois modèles. Appliquez-les aux classes que vous créez dans ce wireframe, pas à une liste fixe :

/* 1. Remplissage accent : bouton primaire, puce ou onglet actif, FAB */
.btn-primary:hover   { background: var(--accent-hover); cursor: pointer; }

/* 2. Clair ou transparent : bouton secondaire, bouton icône, élément de liste */
.btn-secondary:hover,
.nav-menu:hover      { background: var(--hover-bg); cursor: pointer; }

/* 3. Bordé : carte cliquable, puce, option de choix */
.card:hover          { border-color: var(--border-hover); cursor: pointer; }

Chaque élément interactif reçoit cursor: pointer. Les éléments non interactifs (texte, libellés, blocs réservés, cartes qui ne sont pas des cibles de clic) n'ont pas de survol.

Icônes

Utilisez toujours Lucide. Importez via CDN (voir le modèle de base) ; lucide.createIcons() les crée après le chargement.
data-lucide="icon-name" sur un élément <i> vide, ou <i data-lucide="icon-name"></i>.
Taille par défaut : 20px (la valeur par défaut de Lucide). Pour les icônes seules dans un bouton 40×40, utilisez 20px. Si l'icône est à côté d'un texte de 14px, utilisez 16px.
Choisissez toujours l'icône la plus proche du sens : menu, arrow-left, search, plus, etc. Ne composez pas des icônes non standards.
Quand il n'y a clairement pas d'icône Lucide pour le contexte, n'en utilisez pas.

États

Visez le réalisme de l'état dans le wireframe quand l'état est clair. Les écrans vides montrent des états vides ; les listes montrent une charge de données réaliste. Quand l'utilisateur décrit une situation (« après l'inscription », « avant de soumettre »), montrez cet état.

Exemple

<div class="frame-label">Profil : vide</div>
<div class="frame mobile">
  <div style="padding: 16px;">
    <div style="font-size: 14px; font-weight: 500; color: var(--text-primary); margin-bottom: 4px;">Photo de profil</div>
    <div style="background: var(--muted); aspect-ratio: 1/1; border-radius: 8px; display: flex; align-items: center; justify-content: center; color: var(--text-secondary); font-size: 13px;">Image 1:1</div>
  </div>
</div>

Notes d'implémentation

Ne me dis pas ce qu'il y a dans le wireframe. Utilise l'espace pour mettre en avant ce que je ne peux pas voir depuis le wireframe : une hypothèse, une faiblesse structurelle, une alternative, ou un piège d'interaction. (Par exemple : « J'ai remplacé l'étape modale par un panneau latéral parce que l'utilisateur doit voir le tableau pendant qu'il filtre. »)
Respecte les tokens de design. Les couleurs des tokens définies ici (pas de couleurs Bootstrap ou Material héritées d'ailleurs).
N'ajoute pas de commentaires dans le HTML – le wireframe lui-même est l'interface.
Gère les cas limites : quand un champ de saisie ou un sélecteur est logique, tu le construis toi-même en HTML/CSS ; n'utilise pas de JavaScript pour un rendu de contenu simulé.
Les liens dans le wireframe : utilise # ou, dans un site concept qui sera ouvert en tant que fichier unique, #hash. N'utilise pas javascript:void(0).

floorvanriet/wireframe

Qu'est-ce que wireframe ?

Demander à votre IA préférée

Documentation