falconair/wireframes

Maquettes Fil-de-Fer (Wireframes)

Aperçu

Une proposition d'interface utilisateur est une image, pas une page de prose. Dessinez chaque modification sous forme de maquette fil-de-fer bon marché : le Maintenant à côté du Proposé, des barres grises pour tout ce qui reste identique, des libellés réels uniquement sur les éléments discutés, et une phrase expliquant le pourquoi. Cela ne reproduit pas l'apparence réelle de l'application : pas de couleurs de marque, pas de polices réelles, pas de fidélité pixel. L'utilisateur voit le changement en un coup d'œil, et le dessin coûte peu de tokens.

Quand ne pas l'utiliser : le changement est purement stylistique visuel (couleur, contraste, polices, espacements) : décrivez-le ou montrez le CSS réel. Ou l'utilisateur a déjà décidé et vous a demandé de le coder : codez-le. Ou rien ne change dans la disposition, les contrôles ou le flux.

Le résultat

Un fichier HTML autonome, construit comme suit :

1. Chemin : docs/mockups/YYYY-MM-DD-<sujet>.html dans le projet, de sorte que les maquettes soient conservées avec le code et puissent être commitées. Si le projet stocke déjà les maquettes dans un autre dossier mockups/, utilisez celui-ci à la place.
2. En-tête : copiez tout depuis <!doctype html> jusqu'à </style></head><body> dans kit.html textuellement. Changez uniquement <title>. Utilisez uniquement les classes du kit. Le style en ligne est réservé à la taille et à l'espacement (width, height, margin, la position d'un .menu), jamais pour la couleur.
3. <h1> et une phrase d'accroche d'une ligne .lede.
4. Une section par changement : <h2>N · résultat exprimé avec les mots de l'utilisateur</h2>, puis une disposition :

Situation	Disposition	Libellés
Quelque chose existe et doit changer	.pair : Maintenant, puis Proposé	.lbl.b "Maintenant : ce qui ne va pas" · .lbl.g "Proposé : ce qui change"
La correction n'est pas décidée	.opts : 2-3 options, avec un petit .solo Maintenant au-dessus quand la chose existe	.lbl.o "A · nom (recommandé)" ; .why "+ gain · − coût"
Rien n'existe encore	.solo : Proposé uniquement	.lbl.g ; annotations .n numérotées expliquées dans .why
Un élément selon différents états ou largeurs	.strip : une image par état	.lbl "Vide", "Chargement", "Erreur", "Téléphone"… ; au plus une .why sous la bande

5. Chaque côté d'une .pair, et chaque option, reçoit un libellé (10 mots maximum), son image ou ses images, et une phrase .why. Utilisez deux images d'un côté quand le changement est une séquence (menu, puis le toast qui suit).

Lisez kit.html une fois : sous le CSS, il contient un exemple travaillé de chaque disposition et un index de toutes les classes.

Règles de dessin

• Texte réel uniquement là où se trouve la décision : le contrôle modifié, ses voisins immédiats, et le nom de l'application ou le fil d'Ariane pour l'orientation. Tout le reste est .box (ligne de texte, définir width), .img (image ou graphique) ou une .row de barres grises.
• Marquez le seul contrôle qui change : .bad (tireté rouge) sur le problème dans Maintenant, .good (vert plein) sur le changement dans Proposé et sur ce qui distingue chaque option. Ne marquez rien dans une .strip. Encadrez le contrôle, jamais une barre pleine largeur ni une image entière, car les images coupent les contours à leurs bords.
• Quelque chose manque : dessinez un emplacement vide en tireté à l'endroit où il devrait se trouver (<span class="in bad">pas de recherche ici</span>), pas un contour sur un élément voisin.
• Taille d'environ 800px : chaque colonne .pair fait environ 380px, donc limitez une .bar à environ 5 éléments.
• Type d'application : web ou bureau → .f ; écrans étroits ou mobile natif → .phone ; interface terminal → .f.mono.pad avec des lignes de texte réelles et des barres grises pour la sortie inchangée.
• Questions ouvertes dans le .why de ce côté, formulées comme une question.
• Budget : au maximum environ 15 Ko par fichier. Une section de plus d'environ 1,5 Ko dessine un contenu sur lequel personne ne décide, remplacez donc ce contenu par des barres grises.

Vérifiez avant de montrer

Si un outil navigateur capable de faire une capture d'écran est disponible, ouvrez le fichier et regardez. Dans l'application de bureau Claude, cela signifie mcp__Claude_Browser__preview_start avec url: file://<chemin absolu>, puis mcp__Claude_Browser__computer avec l'action screenshot. Si le navigateur refuse le fichier local, considérez la page comme non visualisée (voir ci-dessous). Vérifiez que chaque contour se trouve sur l'élément prévu, que rien n'est coupé ou renvoyé à la ligne, et que les superpositions ne cachent pas ce qu'elles expliquent. Corrigez, puis regardez à nouveau.

Sans outil de capture d'écran (CLI, headless, sous-agent), relisez le balisage en fonction de ces vérifications et dites dans la passation que la page n'a pas été visualisée.

Passez-la

Dans le chat, écrivez uniquement :

• le fichier sous forme de lien markdown relatif à la racine du projet ;
• une ligne par section : numéro, titre, et état ("prêt", "choisir A/B/C", ou la question ouverte) ;
• les décisions dont vous avez besoin : une phrase chacune, votre choix et la raison principale.

Les dessins et leurs lignes .why contiennent les détails et les compromis, donc ne les décrivez pas à nouveau. Attendez les choix de l'utilisateur avant de coder. Sans utilisateur à qui demander (sous-agent, headless), revenez avec les mêmes trois éléments et arrêtez-vous.

Erreurs fréquentes

Erreur	Plutôt
Étiqueter chaque élément	Étiquetez uniquement ce qui concerne la décision
Restyler pour correspondre à l'application	CSS du kit textuellement ; barres grises
Un paragraphe par dessin dans le chat	Lien, une ligne par section, décisions