Wanneer “maak een homepage” misgaat

Je hebt een websiteproject: een nieuwe landingspagina voor een SaaS-tool, een portfolio voor een freelancer, of een webshopcategoriepagina die conversie moet verhogen. Je opent Claude en typt iets als: “Maak een mooi webdesign.” Het resultaat klinkt overtuigend, maar is vaak te algemeen, mist je merk, negeert je doelgroep, en levert onderdelen die niet op elkaar aansluiten (tone of voice, layout, content, componenten).

Dat is frustrerend, maar niet vreemd: Claude kan alleen scherp ontwerpen “in woorden” als jij helder ontwerpt in prompts. In webdesign is vaagheid duur: het kost iteraties, veroorzaakt misalignment met stakeholders, en leidt tot inconsistentie in UI-onderdelen. Heldere prompts zijn daarom geen “AI-trucje”, maar een manier om requirements, context en kwaliteitscriteria concreet te maken.

In deze les leer je hoe je prompts formuleert die Claude sturen naar webdesign-uitkomsten die bruikbaar zijn: duidelijk, toetsbaar en consistent met je doel.

Wat een goede prompt is (en wat Claude ermee doet)

Een prompt is de set instructies en context waarmee je Claude vraagt om een output te genereren. Voor webdesign is een goede prompt niet alleen “wat wil ik?”, maar ook: voor wie, waarom, binnen welke kaders, en hoe ziet succes eruit. Denk aan een prompt als een mini-briefing die je ook aan een collega-ontwerper zou geven—maar dan extra expliciet, omdat Claude geen impliciete voorkennis van jouw project heeft.

Belangrijke termen:

  • Doel (goal): het gewenste effect, zoals “meer demo-aanvragen” of “sneller begrip van propositie”.

  • Doelgroep (audience): wie leest/klikt; inclusief context (B2B, mobiel, taalniveau).

  • Deliverable: wat je precies wilt ontvangen, zoals “hero-sectie + features + CTA-varianten”.

  • Constraints: beperkingen of vaste eisen (merktoon, lengte, structuur, toegankelijkheid).

  • Acceptatiecriteria: waar je output aan moet voldoen om “goed” te zijn (bijv. 3 CTA-varianten, max 12 woorden in hero-kop).

Een nuttige analogie: een goede prompt is als een Figma-frame met constraints. Als je auto-layout, spacing-rules en componenten definieert, wordt het resultaat consistent. In tekst werkt het hetzelfde: hoe beter je structuur en regels benoemt, hoe minder Claude “vrij improviseert” op plekken waar jij juist zekerheid wilt.

Van vaag naar verifieerbaar: 3 bouwstenen van sterke webdesign-prompts

1) Context + doel: stuur op het waarom, niet alleen op het wat

De grootste kwaliteitsprong komt meestal van het toevoegen van context en intentie. “Schrijf een hero” geeft Claude te veel vrijheid: hero’s verschillen enorm per product, funnel-fase en doelgroep. Geef je wél context—zoals markt, doelgroep, onzekerheden en conversiedoel—dan kan Claude keuzes onderbouwen: welk voordeel eerst, welke bezwaren adresseren, wat voor CTA past, en hoe je de boodschap rangschikt.

Een sterke manier om context te geven is om drie dingen expliciet te maken: situatie, taak, succesmaatstaf. Bijvoorbeeld: “Bezoekers komen via LinkedIn ads en haken af als het te technisch wordt” is waardevoller dan “doelgroep: marketeers”. Claude gebruikt dit om taalniveau, argumentatie en scannability te kiezen. Als jouw doel “demo-aanvragen” is, dan zullen CTA’s, microcopy en social proof anders zijn dan bij “newsletter signup”.

Veelvoorkomende misvatting: “Als ik te veel context geef, wordt de output lang en rommelig.” In de praktijk gebeurt het omgekeerde: meer context kan leiden tot beknoptere output, omdat Claude minder hoeft te gokken en minder zijpaden neemt. Je kunt bovendien scheiden tussen context (achtergrond) en deliverable (wat je wilt zien), zodat de output compact blijft.

Veelgemaakte valkuilen:

  • Doel verwarren met output: “Maak een homepage” is output; “verhoog trial-signups” is doel.

  • Geen bron van verkeer noemen: ads, SEO, referral beïnvloeden structuur en boodschap.

  • Geen besliscriteria: zonder “waarom” kan Claude niet prioriteren tussen features, benefits en trust.

2) Deliverable + formaat: zeg wat je precies wilt ontvangen

Claude kan van alles produceren: concepten, wireframe-achtige beschrijvingen, copy, componentlists, user flows. Als je niet specificeert welke vorm je wil, krijg je vaak een mix die moeilijk te gebruiken is. Heldere prompts noemen daarom expliciet het deliverable en het formaat: “geef 3 hero-varianten met kop, subkop, CTA en microcopy” of “maak een section-by-section outline met headings en bulletpoints”.

Dit werkt omdat Claude goed is in patroonvolgend genereren: als jij een format voorschrijft, zal Claude die structuur vullen. Dat maakt de output scanbaar, vergelijkbaar en sneller te beoordelen. Zeker in designwerk wil je opties naast elkaar kunnen leggen: varianten, tone-of-voice alternatieven, of verschillende hiërarchieën.

Let ook op “granulariteit”: vraag je om een volledige pagina, of om één sectie? Beginners vragen vaak te breed (“hele website”), waardoor je oppervlakkige output krijgt. Een betere strategie is om een deliverable te kiezen dat binnen één iteratie diep kan: bijvoorbeeld alleen hero + value props + CTA’s, of alleen navigatie + IA. Claude presteert beter wanneer het probleem afgebakend is en wanneer jij aangeeft hoe diep het moet: “per sectie: doel, kernboodschap, 2 bullets, en één UX-notitie”.

Typische misvatting: “Als ik om wireframes vraag, moet Claude visueel tekenen.” Je krijgt geen echte Figma-wireframes, maar wél een structurele beschrijving: grid-logica, contentblokken, prioriteit, componenten. Dat is precies wat je nodig hebt om sneller in Figma te werken of om met stakeholders af te stemmen.

Hier zie je hoe verschillende prompt-vormen andere output opleveren:

Dimensie Vage prompt Heldere prompt (deliverable + formaat)
Wat je krijgt Algemeen “mooi design” advies, vaak generiek Een concrete set secties/varianten die je kunt selecteren en uitwerken
Beoordeelbaarheid Moeilijk: er zijn geen criteria of grenzen Makkelijk: je kunt afvinken of alles aanwezig is en past bij doel
Iteratie-snelheid Traag: je moet eerst duidelijkheid creëren Snel: je stuurt op gerichte verbeterpunten (“variant 2, maar korter”)
Risico Inconsistentie in tone, structuur en claims Consistentie door vaste outputstructuur en gevraagde elementen

3) Constraints + kwaliteit: beperk vrijheid waar het moet

Zodra je doel en deliverable helder zijn, is de volgende stap: aangeven waar Claude níet creatief moet zijn. Constraints zijn geen beperking van kwaliteit; ze zijn een manier om kwaliteit te borgen. In webdesign zijn constraints overal: merkstem, toegankelijkheid, legal claims, componentbibliotheek, SEO-richtlijnen, of eenvoudigweg “past boven de fold op mobiel”.

Goede constraints zijn specifiek en toetsbaar. “Maak het kort” is vaag; “hero-kop max 8 woorden, subkop max 18 woorden” is bruikbaar. “Gebruik duidelijke taal” is vaag; “schrijf op B1-niveau, vermijd jargon behalve ‘API’ en ‘dashboard’” is duidelijk. Claude kan zich dan aanpassen: kortere zinnen, minder vaktermen, meer concrete werkwoorden en minder marketingclichés.

Kwaliteitscriteria werken het best als je ze koppelt aan het deliverable. Voor hero-varianten kun je zeggen: “Elke variant bevat: 1 belofte, 1 bewijs (metric of social proof placeholder), 1 CTA, en 1 microcopy-regel die frictie wegneemt.” Claude gaat dan automatisch de ontbrekende elementen invullen. Dit voorkomt een veelvoorkomend probleem: hero’s die wel lekker klinken, maar geen bewijs of frictieverlaging hebben (zoals “Geen creditcard nodig”, “Setup in 10 min”).

Veelgemaakte valkuilen:

  • Te veel constraints tegelijk: dan voelt output geforceerd. Kies 3–6 constraints die echt belangrijk zijn.

  • Constraints als wensenlijst: “modern, strak, premium, speels” kan botsen. Kies 1–2 dominante stijlattributen.

  • Geen grenzen aan claims: Claude kan te stellige claims doen. Voeg toe: “geen onbewezen superlatieven; formuleer controleerbaar.”

Een compact schema om deze bouwstenen te onthouden:

[[flowchart-placeholder]]

Twee uitgewerkte voorbeelden uit webdesignpraktijk

Voorbeeld 1: SaaS-landingspagina die demo-aanvragen verhoogt

Stel: je bouwt een B2B SaaS-landingspagina voor een tool die onboarding automatiseert. Je eerste prompt is: “Schrijf een landingspagina voor onboarding software.” Claude komt met algemene tekst (“revolutioneer je workflow”), maar je mist onderscheid en conversie-elementen. Je scherpt de prompt aan met context, deliverable en constraints.

Wat je toevoegt in je briefing-achtige prompt:

  • Context: doelgroep (Product Managers bij mid-market), kanaal (LinkedIn ads), main bezwaar (“we hebben al een helpcentrum”), en gewenste actie (demo).

  • Deliverable: alleen boven-de-fold + 2 secties (features + social proof), in een vaste structuur.

  • Constraints: B1-taal, geen ongeverifieerde superlatieven, CTA-varianten, en microcopy tegen frictie.

Waarom dit in de praktijk werkt: Claude kan nu de hero richten op tijdwinst en adoptie in plaats van “automatisering” als leeg begrip. Ook kan Claude social proof als structuur opnemen (bijv. “Teams bij [industrie] verkorten time-to-value”) zonder te doen alsof het echte klanten zijn, door placeholders te gebruiken. Je krijgt bovendien meerdere CTA’s die passen bij funnel-intentie: “Plan een demo”, “Bekijk 2-min walkthrough”, “Vraag pricing aan”—waarbij je kunt kiezen wat bij je organisatieproces past.

Beperkingen om realistisch te blijven: Claude kent je echte metrics en klanten niet. Daarom is het belangrijk dat je in de prompt vraagt om placeholders en om claims te formuleren als hypothese (“leidt vaak tot…”) tenzij jij cijfers aanlevert. Zo voorkom je dat de pagina overtuigend klinkt maar later juridisch of reputatie-technisch pijn doet.

Voorbeeld 2: Portfolio-website voor een webdesigner met duidelijke positionering

Stel: je ontwerpt je eigen portfolio en je wilt dat bezoekers binnen 10 seconden snappen: voor wie je werkt, wat je maakt, en waarom jij. Een vage prompt (“Maak een portfolio structuur”) levert meestal een standaard template op: about, projects, contact. Dat is niet verkeerd, maar ook niet onderscheidend.

Met heldere prompts kun je Claude laten meedenken over information architecture en copy die positioneert. Je geeft context: je wil opdrachten van startups in de duurzame hoek, je doet vooral Webflow/Framer builds, en je wil minder “uurtje-factuurtje” en meer pakketprijzen. Vervolgens definieer je deliverables: een homepage-outline met secties, per sectie: doel, headline, 2 bullets, en één UX-notitie. Ook voeg je constraints toe: tone of voice (nuchter, direct), taal (NL), en “geen vage claims zoals ‘passie voor design’”.

Claude kan dan de homepage zo structureren dat je niet begint met jezelf (“Ik ben…”) maar met het bezoekerprobleem (“Je site ziet er goed uit, maar verkoopt niet”), gevolgd door bewijs (cases met resultaat-placeholders), en pas later jouw verhaal. Dit is een typische webdesign-impact: je prompt stuurt Claude naar conversatie-hiërarchie in plaats van een cv-achtige volgorde.

Ook hier geldt een beperking: Claude kan geen echte case-resultaten verzinnen zonder risico. Door in je prompt expliciet te vragen “gebruik [Resultaat-placeholder] en noteer welk bewijs ik moet aanleveren”, maak je de output meteen bruikbaar in je workflow. Het wordt een checklist voor contentverzameling én een startpunt voor je design in Figma, omdat elke sectie al een doel en boodschap heeft.

Wat je vooral wilt onthouden

Heldere prompts voor webdesign bestaan uit drie kernonderdelen: context + doel, deliverable + formaat, en constraints + kwaliteit. Als je die expliciet maakt, gaat Claude minder gokken en meer ontwerpen binnen jouw kaders. Je output wordt daardoor consistenter, sneller te beoordelen, en makkelijker te vertalen naar echte pagina’s en componenten.

Dit sets je up perfect voor UI/UX-constraints specificeren [20 minutes].

Last modified: Tuesday, 5 May 2026, 11:21 AM