HTML-mockupschetser

Sketch

Gebruik deze vaardigheid wanneer de gebruiker een ontwerprichting wil zien voordat hij zich vastlegt — een UI/UX-idee verkent als wegwerp HTML-mockups. Het doel is om 2-3 interactieve varianten te genereren, zodat de gebruiker visuele richtingen naast elkaar kan vergelijken, niet om kant-en-klare code te produceren.

Laad dit wanneer de gebruiker dingen zegt als "schets dit scherm", "laat me zien hoe X eruit zou kunnen zien", "vergelijk layout A vs B", "geef me 2-3 interpretaties van deze UI", "laat me wat varianten zien", "maak hier een mockup van voordat ik het bouw".

Wanneer NIET te gebruiken

• De gebruiker wil een productiecomponent — gebruik claude-design of bouw het correct
• De gebruiker wil een gepolijst eenmalig HTML-artefact (landingspagina, presentatie) — claude-design
• De gebruiker wil een diagram — excalidraw, architecture-diagram
• Het ontwerp staat al vast — bouw het gewoon

Als de gebruiker het volledige GSD-systeem heeft geïnstalleerd

Als gsd-sketch verschijnt als een zuster-vaardigheid (geïnstalleerd via npx get-shit-done-cc --hermes), geef dan de voorkeur aan gsd-sketch voor de volledige workflow: persistente .planning/sketches/ met MANIFEST, frontier mode-analyse, consistentiecontroles over eerdere schetsen, en integratie met de rest van GSD. Deze vaardigheid is de lichtgewicht standalone versie — eenmalig schetsen zonder de statusmachine.

Kernmethode

inname  →  varianten  →  rechtstreekse vergelijking  →  kies winnaar (of herhaal)

1. Inname (sla over als de gebruiker al voldoende informatie gaf)

Voordat je varianten genereert, krijg drie dingen helder — één vraag tegelijk, niet allemaal tegelijk:

1. Gevoel. "Hoe moet dit aanvoelen? Bijvoeglijke naamwoorden, emoties, een sfeer." — "rustig, redactioneel, zoals Linear" zegt meer dan "minimaal".
2. Referenties. "Welke apps, sites of producten vangen het gevoel dat je je voorstelt?" — echte referenties overtreffen abstracte beschrijvingen.
3. Kernactie. "Wat is het allerbelangrijkste dat een gebruiker op dit scherm doet?" — de varianten moeten dit allemaal goed ondersteunen; zo niet, dan zijn het alleen maar versieringen.

Reflecteer kort op elk antwoord voordat je de volgende vraag stelt. Als de gebruiker alledrie al vooraf gaf, ga dan direct door naar varianten.

2. Varianten (2-3, nooit 1, zelden 4+)

Produceer 2-3 varianten in één keer. Elke variant is een compleet, op zichzelf staand HTML-bestand. Beschrijf varianten niet — bouw ze. Het punt is vergelijking.

Elke variant moet een andere ontwerphouding aannemen, niet verschillende pixelwaarden. Drie goede variant-assen:

• Dichtheid: compact / luchtig / ultra-dicht (kies twee contrasterende polen)
• Nadruk: inhoud-eerst / actie-eerst / tool-eerst
• Esthetiek: redactioneel / utilitair / speels
• Layout: éénkoloms / zijbalk / gesplitst paneel
• Onderbouwing: kaartgebaseerd / kale inhoud / documentstijl

Kies één as en differencieer van daaruit. Twee varianten die alleen in accentkleur verschillen, zijn verspilde moeite — de gebruiker kan ze niet onderscheiden.

Naamgeving van varianten: beschrijf de houding, niet het nummer.

sketches/
├── 001-rustig-redactioneel/
│   ├── index.html
│   └── README.md
├── 001-utilitair-compact/
│   ├── index.html
│   └── README.md
└── 001-speels-gesplitst/
    ├── index.html
    └── README.md

3. Maak ze echt HTML

Elke variant is een enkel op zichzelf staand HTML-bestand:

• Inline <style> — geen build-stap, geen externe CSS
• Systeemlettertypen of één Google Font via <link>
• Tailwind via CDN (<script src="https://cdn.tailwindcss.com"></script>) is prima
• Realistische nepinhoud — echte zinnen, echte namen, niet "Lorem ipsum"
• Interactief: klikbare links, echte hover-effecten, minstens één statusovergang (open/dicht, filter, toggle). Een bevroren statisch beeld is een slechtere spike dan een slordige geanimeerde.

Open het in een browser. Als het er kapot uitziet, repareer het voordat je het aan de gebruiker laat zien.

Verifieer varianten visueel — gebruik de browsertools van Hermes. Schrijf niet alleen HTML en hoop dat het rendert; laad elke variant en bekijk hem:

browser_navigate(url="file:///absoluut/pad/naar/sketches/001-rustig-redactioneel/index.html")
browser_vision(question="Ziet deze layout er schoon en leesbaar uit? Zijn er zichtbare bugs (overlappende tekst, niet-gestileerde elementen, kapotte afbeeldingen)?")

browser_vision retourneert een AI-beschrijving van wat er daadwerkelijk op de pagina staat plus een pad naar een screenshot — vangt layout-bugs die pure broninspectie mist (bijv. een lettertype-import die stilletjes faalde, een flex-container die instortte). Repareer en hernavigeer tot elke variant er goed uitziet.

Standaard CSS-reset + systeemlettertype-stack voor snelle starts:

<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. Variant README

Elke variant's README.md beantwoordt:

## Variant: {naam van houding}

### Ontwerphouding
Eén zin over het principe dat deze variant drijft.

### Belangrijkste keuzes
- Layout: ...
- Typografie: ...
- Kleur: ...
- Interactie: ...

### Afwegingen
- Sterk in: ...
- Zwak in: ...

### Best voor
- Het type gebruiker of use case dat deze variant werkelijk dient

5. Rechtstreekse vergelijking

Nadat alle varianten zijn gebouwd, presenteer ze als een vergelijking. Noem niet alleen op — geef een mening:

## Drie interpretaties van het startscherm

| Dimensie | Rustig redactioneel | Utilitair compact | Speels gesplitst |
|-----------|----------------|-------------------|---------------|
| Dichtheid   | Laag            | Hoog              | Gemiddeld        |
| Zichtbaarheid primaire actie | Laag | Hoog | Gemiddeld |
| Scanbaarheid | Hoog | Gemiddeld | Laag |
| Gevoel | Rustig, vertrouwd | Scherp, tool-achtig | Uitnodigend, energiek |

**Mijn mening:** Utilitair compact voor power users, rustig redactioneel voor inhoudgerichte doelgroepen. Speels gesplitst is het zwakst — probeert beide te doen en committeert aan geen van beide.

Laat de gebruiker een winnaar kiezen, of combineer twee tot een hybride, of vraag om een nieuwe ronde.

Themagebruik (wanneer het project een visuele identiteit heeft)

Als de gebruiker een bestaand thema heeft (kleuren, lettertypen, tokens), zet gedeelde tokens in sketches/themes/tokens.css en importeer ze met @import in elke variant. Houd tokens minimaal:

/* sketches/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;
}

Tokeniseer een wegwerpschets niet te veel — drie kleuren en één lettertype is meestal genoeg.

Interactiviteitsdrempel

Een schets is interactief genoeg wanneer de gebruiker:

1. Op een primaire actie klikt en er iets zichtbaars gebeurt (statusverandering, modaal, toast, navigatie-schijnbeweging)
2. Eén betekenisvolle statusovergang ziet (filter een lijst, schakel een modus, open/sluit een paneel)
3. Herkende affordances aanwijst (knoppen, rijen, tabbladen)

Meer dan dat is over-engineeren voor een wegwerpschets. Minder dan dat is een screenshot.

Frontier mode (kiezen wat je vervolgens schetst)

Als er al schetsen bestaan en de gebruiker zegt "wat moet ik hierna schetsen?":

• Consistentiehiaten — twee winnende varianten uit verschillende schetsen hebben onafhankelijke keuzes gemaakt die nog niet zijn samengevoegd
• Ongeschetste schermen — waarnaar verwezen is maar nooit verkend
• Statusdekking — happy path geschetst, maar niet leeg / laden / fout / 1000-items
• Responsieve hiaten — gevalideerd op één viewport; houdt het stand op mobiel / ultrabreed?
• Interactiepatronen — statische layouts bestaan; overgangen, slepen, scrollgedrag niet

Stel 2-4 benoemde kandidaten voor. Laat de gebruiker kiezen.

Uitvoer

• Maak sketches/ (of .planning/sketches/ als de gebruiker GSD-conventies volgt) in de repository-root
• Eén submap per variant: NNN-naam-van-houding/index.html + README.md
• Vertel de gebruiker hoe ze te openen: open sketches/001-rustig-redactioneel/index.html op macOS, xdg-open op Linux, start op Windows
• Houd varianten wegwerpbaar — een schets die je de neiging had te bewaren, moet worden gepromoveerd tot echte projectcode, niet gecureerd als een artefact

Typische toolvolgorde voor één variant:

terminal("mkdir -p sketches/001-rustig-redactioneel")
write_file("sketches/001-rustig-redactioneel/index.html", "<!doctype html>...")
write_file("sketches/001-rustig-redactioneel/README.md", "## Variant: Rustig redactioneel\n...")
browser_navigate(url="file://$(pwd)/sketches/001-rustig-redactioneel/index.html")
browser_vision(question="Hoe ziet dit eruit? Zijn er duidelijke layoutproblemen?")

Herhaal voor elke variant en presenteer dan de vergelijkingstabel.

Naamsvermelding

Aangepast van de GSD (Get Shit Done)-project /gsd-sketch workflow — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Het volledige GSD-systeem levert persistente schetsstatus, thema-/variantpatroonreferenties en workflows voor consistentie-audits; installeer met npx get-shit-done-cc --hermes --global.