mickzijdel/design-process

Designprozess

Modelle sind zu erstaunlicher Kreativität fähig, aber diese wird durch ihre Trainingsweise erstickt. Ein Modell baut ein Design Token für Token auf, und immer wenn es eine Designentscheidung treffen muss – welche Farben verwendet werden, wie Elemente angeordnet werden – füllt es die Token ein, von denen es glaubt, dass sie allen am besten gefallen. Das Ergebnis ist ein sich wiederholendes, fades Design: der ultimative Fall von Design-by-Committee. Großartiges Design beginnt mit einem Gefühl und zielt darauf ab, eine emotionale Reaktion hervorzurufen. Es beugt die Regeln und erfreut Nutzer mit einprägsamen, unerwarteten Entscheidungen – genau das Gegenteil davon, bei jedem Schritt die vorhersagbarste Wahl zu treffen.

Dieser Skill ist ein für KI-Agenten neu gedachter Designprozess, lose inspiriert vom Double Diamond: Entdecken Sie neue Ideen jenseits des Durchschnitts, indem Sie verschiedene Richtungen erkunden und mutige Design-Briefings schreiben; Definieren Sie eine individuelle Design-Identität, indem Sie über vertraute Muster hinausgehen und Modelle miteinander verketten; Liefern Sie ein atemberaubendes Endergebnis, indem Sie die schlampigen, groben Kanten wegpolieren. (Adaptiert von Anshu Chimalas „How to turn your AI into a world-class designer“, mit den wiederkehrenden Regeln der am besten bewerteten öffentlichen Design-Skills in references/anti-slop.md.)

Zwei Regeln stehen über jedem Schritt:

• Das Briefing gewinnt. Wo der Nutzer eine Richtung, eine Schriftart, eine Palette, eine Ära festgelegt hat – folge ihr genau, selbst wenn sie auf einer „niemals standardmäßig“-Liste steht. Ein klares Briefing in Richtung des eigenen Geschmacks umzuleiten, ist ein Fehler. Die Listen gelten nur dort, wo das Briefing eine Achse freilässt.
• Ein Tell ist ein Standard, der ohne Grund erreicht wird, nicht ein Muster, das auftaucht. Beurteile nach der Absicht. Wenn du unsicher bist, ob etwas ein Tell oder eine Entscheidung ist, behandle es als Entscheidung.

Die Schritte

1. Gate: Was ist das, und für wen ist es? Jeweils eine Zeile: das Produkt, die Zielgruppe, die eine Aktion, für die die Seite existiert, die Plattform und etwaige Markenauflagen. Wenn der Nutzer nichts davon angegeben hat, frage einmal (AskUserQuestion) – ein Briefing, das du dir ausdenkst, ist das durchschnittliche Briefing. Die Branche des Themas, Materialien und die Fachsprache sind die Quellen für unverwechselbare Entscheidungen. Kläre in derselben Nachricht die Bildsprache: Prüfe auf einen Generierungsweg (einen Schlüssel in .env.agents oder fnox, einen fal/replicate MCP-Server, die Codex CLI, integrierte Bildwerkzeuge; siehe define.md). Nichts gefunden → frage nach einem oder nach echten Assets (Produkt-Screenshots, Fotos). Halte die Antwort im Briefing fest; eine rein typografische Seite ist eine Entscheidung des Nutzers, kein Standard, in den der Agent verfällt.

2. Entdecken — breit werden, bevor es tief geht. Hol dir Variation außerhalb des Modells. Entweder säe die Richtung aus einem zufälligen String (String Seed of Thought) oder hole dir eine spezifische und wilde Inspiration, die der Nutzer mitbringt; wenn er keine hat, generiere eine breite Liste von Designsprachen und lass ihn reagieren. Wenn Komposition und Hierarchie wichtiger sind als die gesäte Inspiration selbst, skizziere den Bildschirm zuerst mit einem Bildmodell und baue darauf auf, anstatt nur einem textbasierten Briefing. Schreibe die gewählte Richtung als Design-Briefing, bevor irgendein Code geschrieben wird. Mehrere Richtungen gewünscht → mehrere Briefings, mehrere Wegwerf-Varianten, jede isoliert. → references/discover.md

3. Baue die erste Version gegen das Briefing. Verpflichte dich hart zur Richtung: echte Typografie (für dieses Thema ausgewählt, geladen und verifiziert), eine selten verwendete Akzentfarbe, eine seitenfüllende Form, die nicht Hero → drei Features → CTA → Footer ist, ein Signatur-Element, an das sich ein Besucher erinnern würde, jeder Zustand entworfen. Überprüfe die Entscheidungen während der Arbeit an der Tabelle „niemals standardmäßig“ in references/anti-slop.md, nicht danach, und führe deren sechsachsigen Selbstcheck vor dem ersten Screenshot durch.

4. Definieren — der Kritiker-Loop. Mache einen Screenshot der Seite (Desktop und Telefon, als Dateien). Beauftrage einen Designkritiker-Subagenten auf dem stärksten verfügbaren Modell, in einem frischen Kontext, mit nur den Screenshots und der beabsichtigten Ästhetik (niemals der Code, niemals die Zielpunktzahl). Er benennt die Lücken zu einem Studio-Niveau – oder besser noch, gegen echte Referenz-Designs, blind – und bewertet /10. Behebe die größte Lücke, mache einen neuen Screenshot, wiederhole mit dem gleichen Prompt. Der Loop ist begrenzt: standardmäßig zwei Runden, dann stoppen beim ersten Eintreten von Ziel erreicht / Runde ohne Veränderung / Budget aufgebraucht, und dem Nutzer zeigen. Ein reiner Schwellenwert ist kein Ausstieg; kein veröffentlichter Loop ist jemals mit einem solchen beendet worden. → references/define.md, Prompt in references/critic-prompt.md

5. Definieren — echte Assets. Jede Seite, die ein Bild trägt – ein Hero, Feature-Artwork, eine Textur, eine Illustration – bekommt standardmäßig generierte oder echte Bildsprache, keine Verläufe, Formen oder CSS-Muster; Agenten überspringen diesen Schritt, wenn man es ihnen nicht sagt, und Code-gezeichnete Dekoration ist das Verräterische. Wo Bewegung es verdient, Video (Chromakey-Loops, keyframe-interpolierte Übergänge). Schlüssel liegen in einer gitignorierten Env-Datei oder fnox, niemals im Quellcode. Kein Weg wurde am Gate gefunden und der Nutzer hat sich für reinen Text entschieden → sag dies in der Übergabe als bekannte Lücke und gestalte so, dass der Hero allein auf Typografie und Komposition trägt. → references/define.md

6. Ausliefern — subtrahieren, dann verifizieren. Gehe jedes Element durch und frage, was kaputtgeht, wenn es wegfällt; entferne Glühen, Verläufe, redundante Labels, Fülltexte, benutzerdefinierte Bedienelemente, die schlechter sind als native, Abschnitte, die eine Vorlage platziert hat. Dann responsiv, hell/dunkel, accessibility-Audit, Performance und ein echter Browser-Screenshot bei jedem Breakpoint. → references/deliver.md

7. Ausliefern — Voice-Pass. Führe den Skill writing:voice-profile über jeden benutzersichtbaren String aus (Überschriften, Teasers, Buttons, Leer- und Fehlerzustände), sodass der Text im Register des Nutzers gelesen wird, nicht im Standard des Modells; ohne Profil gelten trotzdem dessen Basisregeln plus writing:humanizer. → references/deliver.md

flowchart LR
    G[Gate: Produkt, Zielgruppe,
eine Aktion] --> D1[Entdecken:
Seed oder wilder Prompt]
    D1 --> B[Design-Briefing]
    B --> V[Baue v1 gegen Briefing]
    V --> S[Screenshot]
    S --> C{Kritiker /10
frischer Kontext}
    C -- "Lücken" --> F[Behebe größte Lücke]
    F --> S
    C -- "9+ oder blockiert" --> A[Echte Bilder / Video
wo Persönlichkeit dünn ist]
    A --> P[Ausliefern: subtrahieren,
dann verifizieren]
    P --> W[Voice-Pass
über allen Text]

Welches Regime

Nicht jeder Design-Job verdient den vollen Loop. Wähle die Behandlung, nicht, ob du designen sollst:

Aufgabe	Tu
Eine Komponente, ein Einstellungs-Panel, eine Dokumentationsseite, ein kleiner Restyle	Schritte 1–3 + ein einzelner Look: vollständig bauen, Desktop und Mobile zusammen scannen, alles, was es zeigt, in einem Durchlauf beheben, einmal bestätigen, stoppen
Eine Landingpage, ein Hero-Bildschirm, alles, was der Nutzer „generisch“ nannte oder das herausstechen soll	Der volle Loop, Schritte 1–6, Kritiker begrenzt wie oben
Der Nutzer möchte eine Auswahl zur Ansicht	Schritt 2 drei oder mehr Mal in isolierten Varianten, je ein Screenshot, den Nutzer wählen lassen, dann ab Schritt 3 mit dem Gewinner fortfahren

Kurzreferenz

Symptom	Maßnahme
Jeder Durchlauf sieht gleich aus (lila Gradient, Hero geteilt)	Seed aus einem zufälligen String oder nenne eine wilde Inspiration — discover.md
„Mach es einzigartig/zufällig“ hat nicht geholfen	Es kann nicht zufällig sein, indem man danach fragt; Variation muss von außerhalb des Modells kommen
Keine Idee, welche Richtung	Liste breit anlegen → Nutzer reagiert → schärfen → Prompt bauen
Layout/Hierarchie fühlt sich falsch an, aber die Richtung stimmt	Skizziere den Bildschirm mit einem Bildmodell und baue darauf auf, neben dem schriftlichen Briefing — discover.md
Der Agent sagt immer wieder „sieht gut aus“ zu seiner eigenen Arbeit	Kritiker-Subagent, frischer Kontext, nur Screenshot, gleicher Prompt jede Runde
Kritiker nie zufrieden, Tokens verbrennen	Begrenzung auf 2 Runden zuerst; stoppen bei stagnierender Punktzahl; das Ziel konkret machen (blinde Auswahl vs. echte Referenzen)
Jede nicht standardmäßige Wahl ist dieselbe nicht standardmäßige (Space Grotesk, Creme + Serife)	Eine Entscheidung zweiter Ordnung ist immer noch ein Standard; rotieren — anti-slop.md
Persönlichkeit kommt von CSS-Verläufen und Blobs	Echte Bilder generieren; Shader/3D nur in Kombination mit Bildmaterial
Kein Bildgenerierungs-Schlüssel zur Hand	Am Gate fragen oder echte Assets vom Nutzer holen; typografisch nur als deren erklärte Wahl ausliefern
Fühlt sich überladen an, „Premium“ fehlt	Subtraktions-Durchgang — deliver.md
Sieht im Code-Review gut aus	Es ist nicht fertig, bis du den Screenshot gesehen hast

Fertig, wenn

• Ein schriftliches Briefing existiert und das ausgelieferte Design immer noch dazu passt.
• Entferne den Produktnamen aus dem Briefing: jemand könnte trotzdem sagen, wofür die Seite ist.
• Der Kritiker hat 9+ bewertet (oder den Blindvergleich gewonnen) in einem frischen Kontext, oder der Loop hat seine Grenze erreicht und der Nutzer hat den Stand akzeptiert.
• Nichts auf der „niemals standardmäßig“-Tabelle überlebt ohne einen im Briefing festgehaltenen Grund.
• Jeder visuelle Slot enthält generierte oder echte Bildsprache, oder das Briefing dokumentiert die rein typografische Entscheidung des Nutzers und die Übergabe benennt sie als Lücke.
• Jedes verbleibende Element hat eine Aufgabe; der Text sagt nur, was das Produkt tut.
• Screenshots bei Telefon- und Desktop-Breiten, hell und dunkel, wurden angesehen und das accessibility-Audit ist sauber.
• Jeder benutzersichtbare String wurde durch den Voice-Pass geschickt; der Text liest sich, als hätte der Nutzer ihn geschrieben, und das Voice-Audit meldet keine verbotenen Wörter.