Terminologie: prompts tot outputs

Waarom woorden opeens design-werk worden

Je zit in een websiteproject en iemand zegt: “Kun je Claude even vragen om een premium homepage?” Vijf minuten later heb je een tekst die best oké klinkt, maar niemand weet wat je ermee moet. De developer vindt het te vaag (“wat moet ik bouwen?”), de marketeer vindt het niet scherp genoeg (“wat is de belofte?”), en jij voelt dat het niet klopt met de hiërarchie die je voor ogen hebt. Het probleem is zelden Claude zelf—het probleem is dat het team niet dezelfde taal gebruikt voor wat er in- en uitgaat.

In webdesign is taal niet alleen “copy”; taal is ook specificatie. Een prompt is in feite een mini-briefing. En een output is geen eindproduct, maar een voorstel dat je moet toetsen op merk, funnel, structuur, toegankelijkheid en technische haalbaarheid. Als je de terminologie scherp hebt, ga je sneller van “leuke tekst” naar bruikbare ontwerpbeslissingen.

In deze les leer je de kernwoorden rondom Claude Design zo precies dat je ze in reviews, briefings en handovers kunt gebruiken zonder ruis: van prompt en context tot constraints, iteraties en verschillende soorten outputs.

De basis: wat bedoelen we met prompt, context en output?

Een goede manier om Claude Design te begrijpen is als een gesprek met een extreem snelle collega. Die collega kan veel voorstellen doen, maar heeft niet automatisch jouw projectdetails in het hoofd. De terminologie helpt je om dat gesprek te sturen, én om naar je team uit te leggen wat je precies doet.

Hier zijn de belangrijkste begrippen:

• AI-model: het systeem dat tekst kan begrijpen en genereren op basis van patronen uit veel voorbeelden. Het “denkt” niet zoals een mens; het voorspelt plausibele vervolgstappen in taal.

• Prompt: jouw opdracht aan het model. In webdesign is dit vaak een combinatie van doel, doelgroep, pagina, tone of voice en randvoorwaarden.

• Output: het antwoord van het model. In Claude Design is output meestal een tussenresultaat (ideeën, structuren, varianten, onderbouwingen), geen af ontwerp.

• Context: alle informatie die je meegeeft zodat het model niet hoeft te gokken. Denk aan product, doelgroep, merkstem, pagina-doel, beperkingen en bestaande content.

• Iteratie: de cyclus prompt → output → bijsturen. Je gebruikt iteratie om van generiek naar specifiek te gaan, en om keuzes explicieter te maken.

De onderliggende principe uit de vorige les blijft leidend: specificiteit wint. Als je prompt te algemeen is (“maak het moderner”), is de output bijna altijd generiek. Als je prompt testbaar is (“geef 10 concrete designregels voor ‘premium’ op een SaaS pricing page, inclusief wat te vermijden”), dan kun je output wél gebruiken om beslissingen te nemen en te onderbouwen.

Belangrijk detail: context is niet hetzelfde als “veel tekst plakken”. Context is relevante informatie die direct invloed heeft op de keuze die je vraagt. Als je geen constraints noemt (bijvoorbeeld “max 6 woorden per CTA” of “geen uitroeptekens”), dan kan Claude prima opties geven die inhoudelijk kloppen, maar praktisch onbruikbaar zijn in jouw componenten.

Van simpele prompt naar bruikbaar resultaat: de onderdelen die het verschil maken

Een prompt bestaat meestal uit bouwstenen. Als je die bouwstenen herkent en benoemt, kun je sneller debuggen waarom output niet werkt. In webdesign is de reden vaak niet “Claude is slecht”, maar “de prompt bevatte te weinig richting” of “de vraag vroeg om een eindantwoord zonder beoordelingskader”.

1) Doel en taak: wat moet er gebeuren?

De eerste bouwsteen is het doel (waarom) en de taak (wat). Dit lijkt triviaal, maar het is waar veel prompts misgaan. “Schrijf een hero” is een taak, maar zonder doel wordt het gokken: wil je leads, purchases, demo’s, of vertrouwen opbouwen? Een website is een keten van overtuigingsstappen; de output moet passen bij de stap die je ontwerpt.

In Claude Design werkt het goed om taak en doel expliciet te scheiden. Bijvoorbeeld: “Taak: genereer 3 hero-varianten. Doel: meer offerteaanvragen van particulieren, met focus op vertrouwen en responstijd.” Daarmee stuur je niet alleen op tekst, maar op het designargument erachter: waarom staat dit bovenaan, welke frictie neem je weg, welke belofte test je?

Best practice is om output te vragen in een vorm die je kunt beoordelen. Dus niet alleen “schrijf copy”, maar “schrijf copy + motiveer per variant welke gebruikerbehoefte je adresseert.” Dat voorkomt dat je later alsnog zelf moet raden wat een variant “bedoelt”. Het sluit ook aan op het idee uit de vorige les dat Claude nuttig is als clarifier: het maakt impliciete keuzes expliciet.

Veelgemaakte pitfall: één prompt die tegelijk structuur, tone of voice, visuele stijl en technische implementatie wil oplossen. Dan krijg je een lange output die nergens echt scherp wordt. Een typische misvatting is: “Als ik alles in één keer vraag, bespaar ik tijd.” Meestal verlies je tijd, omdat je niet weet welk deel je moet bijsturen. In plaats daarvan werkt het beter om één primaire taak per iteratie te nemen: eerst doel/variabelen helder, dan structuur, dan varianten.

2) Context en constraints: de rails waarbinnen Claude rijdt

Context is de brandstof, maar constraints zijn de rails. In webdesign zijn constraints vaak concreter dan je denkt: maximale lengte (headings, CTA’s), component-structuur (input + helper text + error state), juridische grenzen (claims), tone of voice (formeel/inclusief), en content die al vaststaat (bestaande secties, productnamen).

Een sterke Claude Design prompt bevat daarom context in twee lagen. Laag één is “wat is dit?”: producttype, doelgroep, pagina-doel. Laag twee is “wat mag wel/niet?”: woorden om te vermijden, merkregels, toegankelijkheids- en UX-richtlijnen (bijv. duidelijke foutmeldingen, geen schuldige toon). Juist die tweede laag voorkomt dat output “AI-achtig” wordt: glad, algemeen en net niet consistent.

Hier werkt ook de waarschuwing uit de vorige les: laat Claude niet raden naar context. Als jij geen doelgroep noemt, krijg je copy die voor iedereen is, en dus voor niemand. Als je techniek/flow niet noemt (bijvoorbeeld dat je formulier een budgetvraag bevat die frictie geeft), mist output de kern. Claude kan prima helpen, maar alleen in de wereld die jij schetst. Dat maakt Claude Design minder “magisch”, maar veel betrouwbaarder.

Typische misconceptie: “Meer context is altijd beter.” In werkelijkheid kan te veel irrelevante info juist ruis geven. Een handige check is: “Als ik dit detail weglaat, verandert dan de juiste keuze?” Zo niet, dan is het waarschijnlijk geen nuttige context voor deze prompt. Bewaak scherp: context die de beslissing beïnvloedt, niet context die alleen achtergrond is.

3) Output-vorm: hoe je antwoord ‘bruikbaar’ maakt

De derde bouwsteen is de vorm waarin je output wilt ontvangen. In webdesign is “long-form tekst” vaak niet de beste output, omdat je in componenten werkt en omdat scanbaarheid belangrijk is. Als je niet specificeert wat je wilt, geeft Claude iets wat linguïstisch logisch is, maar niet altijd direct inzetbaar in je workflow.

Vraag daarom om outputs die passen bij je ontwerppraktijk: lijsten met labels, een tabel met varianten, een outline met sectierollen, of microcopy per state (default/hover/error/success). Dit sluit aan bij hoe je later met developers en design systems praat: je wil gedrag en content per component kunnen aanwijzen.

Het helpt ook om te vragen om “keuzehulp” in de output. Denk aan: “Geef 3 opties en zet erbij: wanneer kies je welke?” Daarmee maak je output minder een eindantwoord en meer een set ontwerpbeslissingen. Dit past bij het principe dat Claude Design jouw werk niet vervangt, maar versnelt doordat argumenten sneller expliciet worden.

Veelgemaakte pitfall: output kopiëren zonder consistentiecheck. In de vorige les kwam dit terug bij “variant generator”: losse AI-zinnen over meerdere plekken verspreid geven een site die net niet één stem heeft. Een goede term om hier te onthouden is consistentie als ontwerpkeuze: jij bewaakt hergebruik van termen, ritme, aanspreekvorm en hiërarchie. Output-vorm helpt, maar jouw review blijft essentieel.

Prompt-bouwstenen in één overzicht

Bouwsteen	Wat het is	Waarom het in webdesign telt	Veelgemaakte fout
Doel	Het beoogde effect (bijv. meer aanvragen, minder afhakers).	Zonder doel kan Claude niet prioriteren tussen “mooi” en “effectief”. Je mist hiërarchie en funnel-logica.	Doel vervangen door vage woorden als “moderner” of “impactvoller”.
Taak	Wat je precies wilt (outline, CTA-varianten, foutmeldingen).	Houdt output concreet en goed te evalueren in je workflow.	Te veel taken in één prompt, waardoor niets scherp wordt.
Context	Relevante projectinfo (doelgroep, product, pagina, tone).	Voorkomt generieke output en laat Claude aansluiten op echte bezwaren/vragen.	Context weglaten zodat Claude moet gokken.
Constraints	Grenzen en regels (lengte, woorden vermijden, component-structuur).	Maakt output direct inzetbaar in componenten en consistent met merk en UX.	Alleen “wees creatief” zeggen en vervolgens output afkeuren op details.
Output-vorm	Het gewenste format (tabel, bullets, per variant label/motivatie).	Bespaart tijd: je krijgt iets dat je kunt plakken in je design/hand-off.	Output-vorm niet aangeven, waardoor je onbruikbare lange tekst krijgt.

[[flowchart-placeholder]]

Begrippen die je helpen om Claude-output te beoordelen (zonder smaakdiscussie)

Als je terminologie alleen gebruikt om “betere prompts” te maken, mis je de helft. De andere helft is: hoe praat je over output, zodat je sneller reviewt en iteraties stuurt. In Claude Design zijn drie begrippen extra handig: kwaliteit, bruikbaarheid, en risico.

Kwaliteit gaat over inhoudelijke juistheid en passendheid. Klopt de claim? Past de tone of voice? Sluit de structuur aan op de vragen van de gebruiker in die fase? Claude kan overtuigend klinken terwijl het iets suggereert dat jouw business niet kan waarmaken. Daarom is “klinkt goed” geen kwaliteitscriterium; “is waar en past bij ons” wel.

Bruikbaarheid gaat over of je het direct kunt inzetten in je designproces. Een output kan inhoudelijk slim zijn, maar onbruikbaar als het niet past in je componenten (te lang, te vaag, geen states). Daarom is output-vorm zo’n groot deel van prompt-writing: je ontwerpt niet alleen de tekst, je ontwerpt het pakket waarin je het ontvangt.

Risico gaat over waar Claude sneller de mist in kan gaan: generieke adviezen, inconsistentie, of “schijnzekerheid” (alsof iets bewezen is zonder data). In de vorige les kwam dit terug: Claude ziet je analytics niet, kent je juridische grenzen niet, en voelt je productmarges niet aan. Terminologie helpt omdat je expliciet kunt zeggen: “Dit is een hypothese-output” versus “Dit is een consistente set guidelines.” Zo voorkom je dat stakeholders output behandelen als waarheid.

Een typische misconception is: “Als Claude het overtuigend formuleert, zal het wel kloppen.” In webdesign is overtuiging juist gevaarlijk als het niet gegrond is in echte constraints. Werk daarom met taal die status aangeeft: concept, voorstel, variant, hypothese, guideline. Dat klinkt misschien administratief, maar het is precies wat teams nodig hebben om snelheid en kwaliteit tegelijk te houden.

Twee webdesignvoorbeelden: van terminologie naar concrete prompts en outputs

Voorbeeld 1: homepage herstructureren voor een installatiebedrijf (segmentatie zonder chaos)

Stel je ontwerpt een homepage voor een lokaal installatiebedrijf (warmtepompen/airco). De eigenaar wil “meer aanvragen”, maar bezoekers zijn gemengd: particulieren, VvE’s en zakelijke pandbeheerders. Als je Claude alleen vraagt om “een homepage-structuur”, krijg je waarschijnlijk de standaardvolgorde met algemene secties. De terminologie helpt je om het probleem scherp te zetten: doel, context, constraints en output-vorm.

Je prompt-onderdelen kunnen er conceptueel zo uitzien: Doel = kwalificeren en conversie naar offerteaanvraag. Context = drie segmenten met verschillende bezwaren (particulier: betrouwbaarheid en prijsindicatie; VvE: proces en planning; zakelijk: service-level en responstijd). Constraints = boven de vouw maximaal drie paden, elk met één CTA van max 3 woorden, rustige tone of voice, geen uitroeptekens. Output-vorm = drie alternatieve pagina-outlines, elk met sectierol + voorbeeldheading + bewijsbehoefte.

Met zo’n output kun je als designer iets heel concreets doen: je kiest bijvoorbeeld de “segmentatie-eerst” outline, omdat die direct duidelijk maakt “voor wie is dit?” en de rest van de pagina per pad kan differentiëren. Daarna toets je het op haalbaarheid: is er genoeg content voor drie paden, zijn er aparte landingspagina’s nodig, en kunnen claims onderbouwd worden (keurmerken, reviews, responstijd). De impact is dat het gesprek met stakeholders verschuift van smaak (“mooier”) naar beslissingen (“welk segment eerst, welk bewijs waar”). De beperking blijft dat Claude niet weet welke doelgroep het meest winstgevend is; jij bepaalt de prioriteit op basis van businesskennis.

Voorbeeld 2: microcopy voor een aanvraagformulier (states, frictie en consistentie)

Stel je werkt aan een “Plan een kennismaking”-formulier voor een webbureau. De drop-off is hoog bij budget en telefoonnummer. Hier is terminologie extra belangrijk omdat je niet “copy” ontwerpt, maar componentgedrag: labels, helper text, validatie en foutmeldingen. Als je alleen vraagt “schrijf microcopy”, krijg je losse zinnen zonder systeem.

Een bruikbare aanpak is om de taak te definiëren als: “Schrijf microcopy per component-state.” Je context is: tone of voice vriendelijk maar professioneel, geen sales-gevoel, en altijd uitleggen waarom je iets vraagt. Je constraints zijn bijvoorbeeld: helper text max 80 tekens, foutmeldingen menselijk en actiegericht, en consistente termen (één woord kiezen voor afspraak: “kennismaking” of “gesprek”, niet allebei). Je output-vorm vraag je als een overzicht per veld: Label, Helper, Error, Succes/confirmatie.

Daarna komt jouw designwerk: je integreert de output in je design system of componentbibliotheek, zodat dezelfde patterns herbruikbaar zijn. Vervolgens doe je een consistentiecheck over het hele formulier: spreekt alles in dezelfde persoon (“je/jij” of “u”), zijn de foutmeldingen niet beschuldigend, en sluiten ze aan op toegankelijkheid (duidelijk wat er mis is en hoe je het oplost). De impact is vaak direct: minder onzekerheid (“waarom vragen ze dit?”), wat frictie verlaagt. De beperking blijft dat de echte effectmeting via analytics of tests moet komen; Claude levert hier vooral hypotheses en snelle varianten binnen jouw regels.

De kern in je hoofd (en in je team)

Terminologie in Claude Design is geen theorie-voor-de-vorm; het is de taal waarmee je AI-output omzet in ontwerpbeslissingen. Als je doel, taak, context, constraints en output-vorm expliciet maakt, krijg je minder generieke antwoorden en meer materiaal dat past in componenten, pagina-structuren en stakeholdergesprekken. En als je output beoordeelt op kwaliteit, bruikbaarheid en risico, voorkom je schijnzekerheid en inconsistentie.

Neem dit mee:

• Prompt = mini-briefing: hoe preciezer jouw briefing, hoe meer Claude als denkpartner werkt.

• Context + constraints bepalen bruikbaarheid: zonder rails ontspoort output snel naar “algemeen oké”.

• Output is een startpunt: jij blijft verantwoordelijk voor waarheid, merk, toegankelijkheid en samenhang.

This sets you up perfectly for Verschillen & webdesign-use cases [20 minutes].