Croquis HTML jetables

Croquis

Utilisez cette compétence lorsque l'utilisateur souhaite voir une direction de design avant de s'engager — en explorant une idée UI/UX sous forme de maquettes HTML jetables. L'objectif est de générer 2-3 variantes interactives pour comparer côte à côte les directions visuelles, et non de produire du code livrable.

Chargez cette compétence quand l'utilisateur dit des choses comme « esquisse cet écran », « montre-moi ce à quoi X pourrait ressembler », « compare la mise en page A vs B », « donne-moi 2-3 propositions pour cette UI », « laisse-moi voir quelques variantes », « maquette ça avant de construire ».

Quand NE PAS utiliser cette compétence

• L'utilisateur veut un composant de production — utilisez claude-design ou construisez-le correctement
• L'utilisateur veut un artefact HTML soigné unique (page d'accueil, présentation) — claude-design
• L'utilisateur veut un diagramme — excalidraw, architecture-diagram
• Le design est déjà figé — construisez-le simplement

Si l'utilisateur a le système GSD complet installé

Si gsd-sketch apparaît comme une compétence sœur (installée via npx get-shit-done-cc --hermes), préférez gsd-sketch pour le workflow complet : des dossiers .planning/sketches/ persistants avec MANIFEST, une analyse en mode frontière, des audits de cohérence entre les esquisses passées, et l'intégration avec le reste de GSD. Cette compétence est la version autonome allégée — des esquisses ponctuelles sans mécanisme d'état.

Méthode principale

réception  →  variantes  →  face-à-face  →  choisir le gagnant (ou itérer)

1. Réception (ignorer si l'utilisateur a déjà donné assez d'informations)

Avant de générer les variantes, obtenez trois éléments — une question à la fois, pas toutes en même temps :

1. Sensation. « Quelle sensation cela devrait-il donner ? Adjectifs, émotions, une ambiance. » — « calme, éditorial, comme Linear » en dit plus que « minimaliste ».
2. Références. « Quelles applications, sites ou produits capturent la sensation que vous imaginez ? » — des références concrètes valent mieux que des descriptions abstraites.
3. Action principale. « Quelle est la chose la plus importante qu'un utilisateur fait sur cet écran ? » — les variantes doivent toutes bien servir cette action ; sinon, ce ne sont que de la décoration.

Réfléchissez brièvement à chaque réponse avant la question suivante. Si l'utilisateur vous a déjà donné les trois éléments d'emblée, passez directement aux variantes.

2. Variantes (2-3, jamais 1, rarement 4+)

Produisez 2-3 variantes en une seule fois. Chaque variante est un fichier HTML complet et autonome. Ne décrivez pas les variantes — construisez-les. Le but est la comparaison.

Chaque variante doit adopter une posture de design différente, pas des valeurs de pixels différentes. Trois bons axes de variantes :

• Densité : compact / aéré / ultra-dense (choisissez deux pôles contrastés)
• Accent : contenu d'abord / action d'abord / outil d'abord
• Esthétique : éditorial / utilitaire / ludique
• Mise en page : colonne unique / barre latérale / écran partagé
• Ancrage : basé sur des cartes / contenu nu / style document

Choisissez un axe et écartez-vous-en. Deux variantes qui ne diffèrent que par la couleur d'accent sont un effort gaspillé — l'utilisateur ne peut pas les distinguer.

Nommage des variantes : décrivez la posture, pas le numéro.

esquisses/
├── 001-calme-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitaire-dense/
│   ├── index.html
│   └── README.md
└── 001-ludique-partage/
    ├── index.html
    └── README.md

3. Rendez-les en HTML réel

Chaque variante est un fichier HTML unique et autonome :

• <style> en ligne — pas d'étape de build, pas de CSS externe
• Polices système ou une police Google via <link>
• Tailwind via CDN (<script src="https://cdn.tailwindcss.com"></script>) est acceptable
• Contenu factice réaliste — des phrases réelles, des vrais noms, pas de « Lorem ipsum »
• Interactif : liens cliquables, survols réels, au moins une transition d'état (ouvrir/fermer, filtrer, basculer). Une image statique figée est un moins bon aperçu qu'une animation brouillonne.

Ouvrez-le dans un navigateur. S'il a l'air cassé, corrigez-le avant de le montrer à l'utilisateur.

Vérifiez les variantes visuellement — utilisez les outils navigateur d'Hermes. Ne vous contentez pas d'écrire du HTML en espérant qu'il s'affiche correctement ; chargez chaque variante et regardez-la :

browser_navigate(url="file:///chemin/absolu/vers/esquisses/001-calme-editorial/index.html")
browser_vision(question="Cette mise en page a-t-elle l'air propre et lisible ? Y a-t-il des bugs visibles (texte qui se chevauche, éléments non stylés, images cassées) ?")

browser_vision renvoie une description IA de ce qui est réellement sur la page ainsi que le chemin d'une capture d'écran — cela détecte les bugs de mise en page qu'une simple inspection du code source manque (par exemple, une importation de police qui a échoué silencieusement, un conteneur flex qui s'est effondré). Corrigez et naviguez à nouveau jusqu'à ce que chaque variante ait l'air correcte.

Réinitialisation CSS par défaut + pile de polices système pour des démarrages rapides :

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. README de la variante

Le README.md de chaque variante répond à :

## Variante : {nom de la posture}

### Posture de design
Une phrase sur le principe qui motive cette variante.

### Choix clés
- Mise en page : ...
- Typographie : ...
- Couleur : ...
- Interaction : ...

### Compromis
- Forte en : ...
- Faible en : ...

### Meilleur pour
- Le type d'utilisateur ou de cas d'usage que cette variante sert réellement

5. Face-à-face

Après avoir construit toutes les variantes, présentez-les sous forme de comparaison. Ne vous contentez pas d'énumérer — donnez un avis tranché :

## Trois propositions pour l'écran d'accueil

| Dimension | Calme éditorial | Utilitaire dense | Ludique partagé |
|-----------|----------------|-------------------|-----------------|
| Densité   | Faible         | Élevée            | Moyenne         |
| Visibilité de l'action principale | Faible | Élevée | Moyenne |
| Scannabilité | Élevée | Moyenne | Faible |
| Sensation | Calme, fiable | Tranchant, outil | Invitant, énergique |

**Mon avis :** Utilitaire dense pour les utilisateurs expérimentés, calme éditorial pour les audiences axées contenu. Ludique partagé est le plus faible — il essaie de faire les deux et ne s'engage dans aucun.

Laissez l'utilisateur choisir un gagnant, ou combiner deux en un hybride, ou demander un autre tour.

Thématisation (quand le projet a une identité visuelle)

Si l'utilisateur a un thème existant (couleurs, polices, tokens), placez les tokens partagés dans esquisses/themes/tokens.css et @import-les dans chaque variante. Gardez les tokens minimalistes :

/* esquisses/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

Ne sur-tokenisez pas une esquisse jetable — trois couleurs et une police suffisent généralement.

Barre d'interactivité

Une esquisse est suffisamment interactive quand l'utilisateur peut :

1. Cliquer sur une action principale et quelque chose de visible se produit (changement d'état, modale, toast, feinte de navigation)
2. Voir une transition d'état significative (filtrer une liste, basculer un mode, ouvrir/fermer un panneau)
3. Survoler des affordances reconnaissables (boutons, lignes, onglets)

Plus que cela, c'est du sur-engineering pour un jetable. Moins que cela, c'est une capture d'écran.

Mode frontière (choisir quoi esquisser ensuite)

Si des esquisses existent déjà et que l'utilisateur dit « que devrais-je esquisser ensuite ? » :

• Écarts de cohérence — deux variantes gagnantes d'esquisses différentes ont fait des choix indépendants qui n'ont pas encore été composés ensemble
• Écrans non esquissés — référencés mais jamais explorés
• Couverture des états — le chemin heureux est esquissé, mais pas les états vides / chargement / erreur / 1000 éléments
• Lacunes de réactivité — validé sur une seule fenêtre ; est-ce que ça tient sur mobile / écran ultra-large ?
• Patrons d'interaction — des mises en page statiques existent ; les transitions, le glisser, le comportement de défilement n'existent pas

Proposez 2-4 candidats nommés. Laissez l'utilisateur choisir.

Sortie

• Créez esquisses/ (ou .planning/esquisses/ si l'utilisateur utilise les conventions GSD) à la racine du dépôt
• Un sous-dossier par variante : NNN-nom-de-la-posture/index.html + README.md
• Dites à l'utilisateur comment les ouvrir : open sketches/001-calm-editorial/index.html sur macOS, xdg-open sur Linux, start sur Windows
• Gardez les variantes jetables — une esquisse que vous avez ressenti le besoin de conserver doit être promue en code de projet réel, pas conservée comme un actif

Séquence d'outils typique pour une variante :

terminal("mkdir -p esquisses/001-calme-editorial")
write_file("esquisses/001-calme-editorial/index.html", "<!doctype html>...")
write_file("esquisses/001-calme-editorial/README.md", "## Variante : Calme éditorial\n...")
browser_navigate(url="file://$(pwd)/esquisses/001-calme-editorial/index.html")
browser_vision(question="À quoi ça ressemble ? Y a-t-il des problèmes de mise en page évidents ?")

Répétez pour chaque variante, puis présentez le tableau de comparaison.

Attribution

Adapté du workflow /gsd-sketch du projet GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Le système GSD complet fournit un état d'esquisse persistant, des références de motifs de thème/variante, et des workflows d'audit de cohérence ; installez avec npx get-shit-done-cc --hermes --global.