Claude als Designer nutzen: Briefings, Texte, Kritik und Handoff-Dokumente

Claude kann ein Bild entgegennehmen, also könnt ihr einen Screenshot eines Figma-Frames, eines Wireframes oder eines bereits ausgelieferten Screens hineinwerfen und direkt Fragen dazu stellen: Macht diese Hierarchie Sinn, ist die primäre Aktion offensichtlich, passt das zum Muster des vorherigen Screens.

Es liest Pixel so, wie ein Mensch einen Screenshot überfliegen würde, nicht die Layer-Struktur oder Komponenteneigenschaften eurer Figma-Datei. Es kennt eure Design-Tokens, eure Komponentenbibliothek oder welcher Frame der 'echte' ist nicht, es sei denn, ihr sagt es ihm. Behandelt es als schnellen zweiten Blick, nicht als Reviewer, der euer Design-System kennt.

Am nützlichsten ist es, wenn die Frage eng gefasst ist: ein Screen, eine konkrete Frage. 'Ist der Fehlerzustand hier klar' bringt eine schärfere Antwort als 'diesen ganzen Flow überprüfen', genauso wie ein Teammitglied eine bessere Antwort gibt, wenn ihr etwas Konkretes fragt, statt ihm die ganze Datei in die Hand zu drücken.

Nehmen wir an, ein Projekt startet so wie die meisten: ein Slack-Thread mit einem Product Manager, ein halb erinnertes Flurgespräch und ein paar Zeilen in einem Ticket, die nicht ganz zueinander passen. Statt auf eine leere Briefing-Vorlage zu starren, fügt alles als Rohmaterial in Claude ein und bittet es, das Signal vom Rauschen zu trennen.

Fragt direkt nach den Teilen, die ein Briefing braucht: Was ist das eigentliche Problem, das gelöst werden soll, welche Rahmenbedingungen wurden schon genannt (eine Deadline, eine Plattform-Einschränkung, eine Markenregel), was würde als Erfolg zählen, und was ist noch ungeklärt. Claude bringt dabei oft einen Widerspruch zutage, den ihr übersehen habt, etwa eine Rahmenbedingung, die früh im Thread einmal genannt und später fallen gelassen wurde.

Die Ausgabe ist nicht final. Es ist ein erster Entwurf, der bereits organisiert ist statt einer leeren Seite, was bedeutet, dass die Überarbeitung danach echten Inhalt schärft, statt Struktur von Grund auf zu erfinden. Das ist die eigentliche Zeitersparnis: nicht das Schreiben selbst, sondern das Überspringen der Phase der leeren Seite.

Über diese Workflows zu lesen und sie tatsächlich anzuwenden sind unterschiedliche Fähigkeiten. Der folgende Einstiegspfad schließt diese Lücke in drei kurzen Lektionen, in dieser Reihenfolge.

Beginnt mit "Die drei Arten, Claude zu nutzen" aus dem Kurs Die drei Modi, einer fünfminütigen Lektion über den Unterschied zwischen einem schnellen Chat, einer längeren Co-Work-Session im Hin und Her und Claude Code. Die meiste Design-Arbeit, ob Kritik-Frage, Text-Durchgang oder Briefing, findet in den ersten beiden Modi statt, deshalb hilft diese Lektion, den richtigen auszuwählen, statt einfach den Tab zu nehmen, der gerade offen ist.

Dann geht es weiter mit "Kontext ist alles" aus Strategisches Prompting, ebenfalls fünf Minuten. Diese Lektion macht aus einem generischen Briefing eines, das euer echtes Projekt widerspiegelt: Sie behandelt, was ihr einfügen solltet (eure echten Notizen, eure Brand Voice, den konkreten Screen), damit Claude nicht Kontext erraten muss, den es nie bekommen hat.

Schließt ab mit "Die Iterationsschleife" aus Die Grundlagen meistern, einer sechsminütigen Lektion darüber, Claudes erste Antwort als Entwurf statt als endgültiges Urteil zu behandeln. Für Designerinnen und Designer ist das der Unterschied zwischen der ersten Auswahl an UI-Textoptionen zu akzeptieren und acht Optionen durch ein paar Runden Nachfragen tatsächlich auf zwei einzugrenzen.

Der Unterschied zwischen einer generischen und einer nützlichen Antwort ist fast immer der Kontext, den ihr gegeben habt. Für Design-Arbeit heißt das konkret: die Dinge einzufügen, die in eurem Kopf oder euren Dateien stecken, aber nie in einen kurzen Prompt kommen, die tatsächlichen Meeting-Notizen statt eurer Erinnerung daran, eure Brand-Voice-Richtlinien, falls ihr sie schriftlich habt, und den konkreten Screenshot statt einer Beschreibung eines Screens.

Es bedeutet außerdem, beim Umfang konkret zu sein. "Überprüfe diesen Flow" lädt zu einer vagen, verstreuten Antwort ein. "Schau dir den Bestätigungsscreen an und sag mir, ob die sekundäre Aktion mit der primären konkurriert" lädt zu einer nützlichen ein. Je enger die Frage, desto mehr lohnt es sich, sie zu stellen.

Wenn ihr dieselbe Art von Frage immer wieder stellt, etwa denselben Accessibility-Check bei jedem neuen Screen oder dieselbe Ton-Vorgabe für jeden UI-Text, lohnt es sich, diesen Kontext einmal aufzuschreiben und wiederzuverwenden, statt eure Brand Voice in jedem Gespräch neu zu erklären.

Claude erzeugt keine produktionsreife UI, manipuliert nicht eure Figma-Datei und hat eure Markenrichtlinien nicht im Kopf, es sei denn, ihr fügt sie ein. Es kann visuellen Feinschliff auch nicht so beurteilen wie ein geschultes Auge; es denkt über Struktur, Hierarchie und Klarheit anhand dessen nach, was im Bild sichtbar ist, nicht darüber, ob sich etwas auf Pixel-Ebene richtig anfühlt.

Bei Accessibility solltet ihr die Checks als ersten Durchgang behandeln, nicht als Freigabe. Echte Accessibility-Arbeit braucht Kontrast-Prüftools, Screenreader-Tests und oft eine Fachprüfung, besonders bei allem, was an ein breites Publikum geht. Erzählt keinem Stakeholder oder Compliance-Prüfer, ein Design sei auf Accessibility geprüft worden, nur weil Claude einen Screenshot angesehen hat.

Dieselbe Vorsicht gilt, bevor etwas an einen Kunden, eine Kundin oder ein Teammitglied geht: Lest, was Claude produziert hat, bevor ihr es verschickt. Ein Handoff-Dokument mit einem selbstbewusst falschen Interaktionshinweis ist schlimmer als gar kein Dokument, weil ein Entwickler danach baut.

Es ist außerdem nur so gut wie das, was ihr ihm gebt. Ein Briefing aus einem Zwei-Zeilen-Prompt liest sich generisch; ein Briefing aus einem echten Gesprächsprotokoll oder echten Notizen spiegelt das Projekt tatsächlich wider.