Claude gebruiken als ontwerper: briefs, copy, feedback en overdrachtsdocumenten

Claude kan een afbeelding accepteren, dus je kunt een screenshot van een Figma-frame, een wireframe of een gelanceerd scherm erin zetten en er direct vragen over stellen: klopt deze hiërarchie, is de primaire actie duidelijk, komt dit overeen met het patroon dat op het vorige scherm is gebruikt.

Het leest pixels zoals iemand een screenshot zou doorbladeren, niet door de laagstructuur of componenteigenschappen van je Figma-bestand te parsen. Het kent je design tokens, je componentbibliotheek of welk frame de 'echte' is niet, tenzij je het dat vertelt. Zie het als een snelle tweede blik, niet als een reviewer die je designsysteem kent.

De meest nuttige versie hiervan is smal: één scherm, één specifieke vraag. 'Is de foutstatus hier duidelijk' levert een scherper antwoord op dan 'beoordeel deze hele flow', net zoals een teamgenoot een beter antwoord geeft wanneer je iets specifieks vraagt in plaats van het hele bestand te overhandigen.

Stel dat een project begint zoals de meeste: een Slack-thread met een productmanager, een half vergeten gesprek op de gang, en een paar regels in een ticket die niet helemaal met elkaar overeenkomen. In plaats van naar een leeg briefsjabloon te staren, plak je alles als ruw materiaal in Claude en vraag je het om het signaal van de ruis te scheiden.

Vraag direct om de onderdelen die een brief nodig heeft: wat is het eigenlijke probleem dat wordt opgelost, welke randvoorwaarden zijn al genoemd (een deadline, een platformbeperking, een merkregel), wat zou als succes gelden, en wat is nog onopgelost. Claude haalt vaak een tegenstrijdigheid naar boven die je gemist hebt, zoals een randvoorwaarde die vroeg in de thread één keer werd genoemd en later wegviel.

De output is niet definitief. Het is een eerste concept dat al georganiseerd is in plaats van een leeg vel, wat betekent dat het redigeren dat je daarna doet bestaande inhoud aanscherpt in plaats van structuur vanaf nul te verzinnen. Dat is de echte tijdsbesparing: niet het schrijven zelf, maar het overslaan van de lege-pagina-fase.

Lezen over deze workflows en ze daadwerkelijk toepassen zijn verschillende vaardigheden. Het startpad hieronder is gebouwd om dat gat te dichten in drie korte lessen, in deze volgorde.

Begin met "De Drie Manieren om Claude te Gebruiken" uit de cursus De Drie Modi, een les van vijf minuten die het verschil behandelt tussen een snel gesprek, een langere heen-en-weer co-worksessie, en Claude Code. Het meeste ontwerpwerk, of dat nu een feedbackvraag, een copyronde of een brief is, speelt zich af in de eerste twee modi, dus deze les helpt je de juiste te kiezen in plaats van standaard het tabblad te gebruiken dat toevallig openstaat.

Ga daarna verder met "Context Is Alles" uit Strategisch Prompten, ook vijf minuten. Dit is de les die een generieke brief verandert in een die je echte project weerspiegelt: hij behandelt wat je erin moet plakken (je echte notities, je brand voice, het specifieke scherm) zodat Claude niet gokt naar context die het nooit heeft gekregen.

Sluit af met "De Iteratielus" uit Beheers de Basis, een les van zes minuten over het behandelen van Claude's eerste antwoord als concept in plaats van eindoordeel. Voor een ontwerper is dit het verschil tussen het eerste setje UI-copyopties accepteren en acht opties daadwerkelijk terugbrengen tot twee via een paar rondes feedback.

Het verschil tussen een generiek antwoord en een bruikbaar antwoord zit vrijwel altijd in de context die je gaf. Voor ontwerpwerk betekent dat specifiek: plak de dingen die in je hoofd of je bestanden zitten maar nooit in een korte prompt terechtkomen: de echte vergadernotities in plaats van je herinnering daaraan, je brand voice-richtlijnen als je die hebt opgeschreven, en de specifieke screenshot in plaats van een beschrijving van een scherm.

Het betekent ook specifiek zijn over de scope. "Beoordeel deze flow" nodigt uit tot een vaag, verspreid antwoord. "Kijk naar het bevestigingsscherm en vertel me of de secundaire actie concurreert met de primaire" nodigt uit tot een bruikbaar antwoord. Hoe nauwer de vraag, hoe meer het loont om hem te stellen.

Als je vaak hetzelfde type vraag gaat stellen, zoals dezelfde toegankelijkheidscheck op elk nieuw scherm of dezelfde toonrichtlijn voor elk stukje UI-copy, is het de moeite waard om die context één keer op te schrijven en te herbruiken, in plaats van je brand voice in elk gesprek opnieuw uit te leggen.

Claude genereert geen productieklare UI, manipuleert je Figma-bestand niet, en heeft je merkrichtlijnen niet onthouden tenzij je ze erin plakt. Het kan ook geen visuele afwerking valideren zoals een geoefend oog dat kan; het redeneert over structuur, hiërarchie en duidelijkheid op basis van wat zichtbaar in de afbeelding staat, niet over of iets op pixelniveau goed aanvoelt.

Behandel de toegankelijkheidschecks als een eerste ronde, niet als goedkeuring. Echt toegankelijkheidswerk vraagt om contrasttools, tests met een screenreader, en vaak een beoordeling door een specialist, zeker voor alles dat naar een breed publiek gaat. Vertel een stakeholder of compliance-beoordelaar niet dat een ontwerp op toegankelijkheid is gecheckt omdat Claude naar een screenshot heeft gekeken.

Dezelfde voorzichtigheid geldt voordat iets naar een klant, een opdrachtgever of een teamgenoot gaat: lees wat Claude heeft gemaakt voordat je het verstuurt. Een overdrachtsdocument met een overtuigend onjuiste interactienotitie is erger dan geen document, omdat een engineer ermee gaat bouwen.

Het is ook maar zo goed als wat je erin stopt. Een brief geschreven vanuit een prompt van twee regels leest generiek; een brief geschreven vanuit een echt gesprekstranscript of een echte set notities zal het project echt weerspiegelen.