Modèle de Wireframe Sketch
Wireframes basse fidélité dessinés à la main qui paraissent explicitement provisoires — pour inviter des retours sur la mise en page, signaler « non livrable » ou documenter l'IA sans s'engager dans un design visuel.
⚠️ Choisissez le squelette D'ABORD
Le plus grand échec de ce skill : le modèle hérite des traits de pinceau (wobble, tirets, écriture manuscrite) mais écrit la mauvaise structure de document — par exemple, produire 3 écrans d'application isolés alors qu'un document de flux multi-écrans était nécessaire, ou fourrer un sitemap avec des figures éditoriales.
Avant d'écrire une seule ligne, déclarez dans votre réponse quel squelette vous utilisez et pourquoi. Faites correspondre les mots de l'utilisateur à l'un des cas suivants :
| L'utilisateur dit | Squelette | Pourquoi |
|---|---|---|
| journal / magazine / landing / site officiel / brochure / une page / one-pager / éditorial | A. Page éditoriale unique | Une longue page, sections empilées, dense en contenu |
| application / mobile / téléphone / app desktop / flux SaaS / parcours utilisateur / flux d'inscription / flux de paiement / multi-écrans / multi-page / inscription / connexion / onboarding / paramètres / onglet / flux de formulaire | B. Flux multi-écrans d'application | Plusieurs écrans, navigation, états, déclencheurs |
| architecture de l'information / IA / sitemap / plan de site / organigramme / graphe de relations / graphe de données / flux de données / machine à états / matrice de permissions | C. Diagramme IA / Sitemap | Nœuds + arêtes, pas d'écrans réels |
| pas clair / l'utilisateur n'a pas dit / les deux fonctionnent | demander à l'utilisateur avant de choisir — ne pas prendre de valeur par défaut | — |
Si l'utilisateur a donné un sujet mais pas d'indice de squelette, demandez lequel. Choisir le mauvais = faire le travail deux fois.
Squelette A — Page éditoriale unique
foolscap-wireframe.html est la référence pour ce squelette. À utiliser lorsque l'artefact est une seule page scrollable (journal, spread de magazine, wireframe de landing page, brochure, illustration de PRD en une page).
Sections requises (dans l'ordre, on peut en supprimer 1 à 2 mais garder le rythme) :
- En-tête / bannière — titre, numéro/version, date
- Élément vedette — un grand bloc principal avec titre + intro + emplacement d'illustration dessinée à la main
- 3 à 5 sections de contenu — chacune avec son propre h2, mélange de figures textuelles et d'illustrations esquissées
- Barre latérale / bloc de liste — éléments courts, texte dense, casse le rythme
- Appel à l'action / inscription / pied de page
Densité : viser la densité de contenu par pouce carré de la référence foolscap — des wireframes d'une seule page trop clairsemés donnent l'impression d'une ébauche, pas d'un brouillon.
Squelette B — Flux multi-écrans d'application ⛔ MINIMUMS STRICTS
foolscap-wireframe.html n'est pas la référence pour ce squelette — empruntez uniquement ses filtres SVG, sa pile de polices et son esthétique de cellules en tirets. La structure du document doit être assemblée à partir de la liste de vérification ci-dessous.
Sections requises (TOUTES doivent être présentes — la page est incomplète sinon)
- Couverture — nom de l'application + version + rôle/persona + périmètre en une ligne (« MVP / beta / v0.3 / suivi des dépenses uniquement, pas d'investissement »)
- Sitemap / diagramme de navigation — arbre visuel ou grille montrant tous les écrans et leurs relations. Pas une liste — un véritable diagramme avec des boîtes + des lignes.
- 6 à 8+ écrans principaux sous forme de blocs
figure. Pour une application de suivi des dépenses, cela inclut au minimum : lancement/bienvenue → accueil (vue d'ensemble) → ajouter une entrée (montant → catégorie → note → enregistrer) → détail d'une facture → statistiques mensuelles → gestion des catégories → paramètres budgétaires → profil/paramètres. 3 écrans ne constituent pas un document de wireframe, mais un échantillon de croquis. - Au moins 1 diagramme de flux avec flèches montrant le parcours utilisateur entre les écrans (ex. « accueil → appuyer sur '+' → ajouter une entrée → enregistrer → toast → retour à l'accueil »). Ne mettez pas simplement une seule
↓entre les écrans — écrivez le déclencheur sur la flèche. - Au moins 1 variante d'état pour chaque écran qui en a : vide / chargement / erreur / succès. Choisissez les écrans où c'est pertinent (page de liste → état vide ; formulaire → état d'erreur).
- Partie finale — questions ouvertes / liste à déterminer / journal des versions / décisions à prendre
Exigences par écran
Chaque bloc d'écran doit avoir :
- Numéro de figure —
Fig. 02(utilisez la forme localisée pour le chinois), séquentiel, référencé depuis les diagrammes de flux - Responsabilité en une ligne — « ajouter une entrée · atteint depuis le bouton '+' sur l'accueil ; affiche un toast lors de l'enregistrement et retourne à l'accueil »
- Annotations de déclencheurs — quels points d'entrée mènent ici, quelles sorties vont où
- Marginalia — au moins 1 note manuscrite par écran non trivial (contrainte, cas particulier, « à déterminer », question ouverte)
Mise en page
- Pile verticale d'écrans avec flèche explicite + étiquette de déclencheur entre chaque (pas une
↓passive) - Ou bande de flux horizontale avec écrans dans l'ordre de gauche à droite — fonctionne bien pour les flux linéaires comme l'onboarding ou le paiement
- Ne mettez pas les écrans dans une grille sans indication de flux — c'est une galerie d'écrans, pas un document de flux
Seuils de densité de contenu
- < 5 écrans → refusez-vous, demandez à l'utilisateur plus de flux ou réduisez honnêtement le périmètre
- Pas de sitemap → refusez-vous, le document est illisible sans
- Pas de variantes d'état → marquez au moins les emplacements vides/erreur même si vous ne les dessinez pas (« état vide : voir Fig. 04a / à déterminer »)
- Aucune marginalia nulle part → vous avez copié le pinceau mais pas le langage ; revenez en arrière et annotez
Squelette C — Diagramme IA / Sitemap
Document purement structurel — pas d'écrans réels, seulement des diagrammes nœud-arête de l'architecture de l'information, de la navigation, des flux de données ou des machines à états.
Sections requises :
- Titre + légende — ce que signifient les boîtes, ce que signifient les types de lignes (trait plein = navigation directe, pointillé = conditionnel, double = liaison de données)
- Diagramme principal — l'arbre/graphe lui-même, central, grand
- Mini-spécification par nœud — pour les nœuds non évidents, 1 à 3 lignes sur ce qui s'y trouve
- Matrice de permissions / rôles si applicable
- Questions ouvertes en bas
Le wobble et l'écriture manuscrite s'appliquent toujours. Disposition boîtes-et-lignes, beaucoup d'espace blanc, une seule couleur d'accent pour la mise en évidence du « chemin actuel » / « défaut ».
Langage des marginalia (squelettes B et C doivent utiliser ; A facultatif)
Les marginalia sont ce qui distingue un vrai wireframe basse fidélité d'un « brouillon haute fidélité qui se fait passer pour basse fidélité ». Utilisez ces techniques :
| Marque | Quand | Comment |
|---|---|---|
| Note latérale | Contrainte ou justification | `<aside class= |