imagile-dev/design

Was macht design?

Erstelle Oberflächen, die sich wie gewählt und nicht wie generiert anfühlen. Jeder Standardwert ist eine Entscheidung, die jemand übersprungen hat. Diese Fähigkeit trifft jede Entscheidung bewusst: zuerst ein Briefing, dann ein Aufbau bis zu einer Qualitätsschwelle, dann eine Kritik an echten Screenshots.

Zwei Fehlermodi, wobei der erste schlimmer ist:

1. Generisch. Die Seite könnte zu jedem Produkt in ihrer Kategorie gehören. Sie trägt die aktuellen KI-Standards oder ist so schlicht, dass sich niemand daran erinnert.
2. Überladen. Jedes Element performt. Motion, Verläufe und Ornamente konkurrieren, und nichts hat Priorität.

Das Gegenmittel für beide ist eine starke Idee, an einem Ort, in einem disziplinierten System. Zurückhaltung ist nicht das Ziel. Absicht ist das Ziel.

1. Wähle den Modus

Modus	Verwende ihn, wenn	Mache
Erstellen	Eine neue Seite, neuer Bildschirm, neue Komponente, neue Präsentation oder neues Bilderset	Abschnitte 2 bis 5
Verfeinern	„Mach es kräftiger, ruhiger, einfacher, farbenfroher, lebendiger“	Abschnitt 6
Kritisieren	„Überprüfe dies“, „sieht das richtig aus“, eine Bewertung	references/critique.md
Polieren	Bevor du etwas Visuelles auslieferst	Abschnitt 7

Verfeinern gestaltet nicht neu. Es behält die Identität, den Text und alles außerhalb der Anfrage bei. Wenn die Anfrage ein Redesign benötigt, sage dies und stoppe. Gehe niemals einen Kompromiss zwischen beiden ein.

2. Lade zuerst den Kontext

1. Lies DESIGN.md im Repository-Stammverzeichnis, das CLAUDE.md des Repos, die vorhandenen Tokens (global.css, tailwind.config.*, Theme-Dateien) und .claude/image-generation/style.md.
2. Das Briefing hat Vorrang. Wenn DESIGN.md oder der Benutzer einen Look vorgibt, folge ihm genau, auch wenn der Look auf der Liste der Erkennungsmerkmale (Tells) steht. Die folgenden Regeln gelten nur für die Entscheidungen, die noch niemand getroffen hat.
3. Ohne DESIGN.md durchsuche das Repository, stelle dann höchstens drei Fragen zu dauerhaften Fakten: Wer nutzt es, was muss es erreichen und welche Beweise gibt es. Frage niemals jemanden, abstrakt eine Ästhetik zu wählen. Zeige stattdessen zwei oder drei Optionen.
4. Schreibe das Gelernte in DESIGN.md nach der Vorlage aus references/design-md.md. Die nächste Sitzung sollte nicht erneut fragen müssen.
5. Eine Korrektur ist eine dauerhafte Regel. Wenn der Benutzer eine visuelle Entscheidung korrigiert, füge in derselben Aktion eine Zeile unter „Dauerhafte Regeln“ in DESIGN.md hinzu.
6. Verwende nur die vorhandenen Belege. Erfinde niemals Testimonials, Kundenlogos, Nutzerzahlen, Metriken oder Zitate. Markiere Platzhalterdaten und liste sie zur Bestätigung durch den Benutzer auf.

3. Schreibe das Briefing (Erstellen-Modus)

Poste ein kurzes Briefing im Chat, bevor du Code schreibst. Das dauert eine Minute und verhindert das generische Ergebnis.

1. Design-Read. Ein Satz: „Das lese ich als [Oberfläche] für [Zielgruppe], im [Modus]-Modus, tendierend zu [Richtung].“

2. Oberflächenmodus. Wähle einen pro Oberfläche, nicht pro Produkt. Die Landingpage eines Entwickler-Tools ist dennoch Überzeugen.

   Modus	Oberflächen	Ausdruck	Variation / Motion / Dichte
   Überzeugen	Landing, Pricing, Launch, Portfolio-Startseite	Eine große Idee, echte Bilder, ein Farbfeld	7 / 6 / 3
   Bedienen	App, Dashboard, Einstellungen, Admin	Das System ist das Design. Keine Show	3 / 2 / 7
   Lesen	Docs, Artikel, Lektionen	Die Schrift trägt die Seite	3 / 2 / 5
   Erleben	Spiele, spielerisches Lernen, Kinder, Events	Charaktere, Umgebungsbewegung, Humor	8 / 8 / 4

   Die drei Regler gehen von 1 bis 10. Variation ist Symmetrie bis kräftige Asymmetrie. Motion ist statisch bis filmisch. Dichte ist Galerie bis Cockpit. Lies Stimmungsbeschreibungen hinein: „minimal“ senkt Variation und Dichte, „auffällig“ oder „lebendig“ erhöht Motion, „dicht“ oder „pro“ erhöht Dichte. Notiere die Regler in DESIGN.md.

3. Szenensatz. Wer verwendet es, wo und in welchem Licht. „Eine Nachtschwester, die auf einem Telefon in einem dunklen Aufenthaltsraum einen Dienstplan prüft“ entscheidet über dunkel oder hell. Ein Kategorielabel wie „Dev-Tool bedeutet dunkel“ tut das nicht.

4. Ideensatz. „[Etwas, das nur dieses Thema hat] wird zu [einem visuellen Mittel].“ Führe dann den Wettbewerbstest durch: Setze den Namen eines Wettbewerbers ein. Wenn der Satz immer noch funktioniert, ist die Idee generisch. Schreibe sie um.

5. Tokens. Vier bis sechs benannte Farben und eine Farbstrategie (references/color.md). Schriftfamilien und ihre Rollen (references/typography.md). Ein Layoutkonzept als Satz plus ASCII-Drahtgitter. Das Motion-Niveau.

6. Argument (nur Überzeugen). Eine Behauptung pro Abschnitt, jede mit ihrem Beweis. Lösche jeden Abschnitt ohne Behauptung. Gehe nicht standardmäßig zu Held, Logo-Strip, drei Funktionen, CTA.

7. Prüfe es gegen die Erkennungsmerkmale. Für jede Achse, die das Briefing freilässt, lies references/tells.md. Frage, ob das Thema allein anhand der Kategorie erraten werden kann, dann, ob der Look anhand der Kategorie plus „nicht der übliche Look“ erraten werden kann. Wenn eine Antwort „Ja“ lautet, überarbeite diesen Teil und sage, was sich geändert hat.

4. Baue bis zur Schwelle

Setze Kühnheit an einer Stelle ein. Lass ein Element das einprägsame sein, halte alles andere darum herum ruhig und entferne Dekoration, die der Idee nicht dient. Wenn du ein Erkennungsmerkmal entfernst, fülle den Raum mit etwas Realem: Größe, Bildmaterial, Inhalt oder einem Farbfeld. Alleinige Entfernung hinterlässt eine dünne, leere Seite.

Die Schwelle gilt für jede Oberfläche, ohne angekündigt zu werden:

• Tokens, keine Literale. Farben, Schriftart, Abstand, Radius und Bewegung leben als Tokens in :root. Hell und Dunkel kommen von prefers-color-scheme, überschreibbar mit data-theme. Ein Umschalter, wenn vorhanden, gewinnt.
• Kontrast. 4,5:1 für Text, 3:1 für großen Text, Symbole, Steuerelemente und Fokusringe. Niemals grauer Text auf farbigem Grund.
• Schrift. Höchstens zwei Familien. Fünf oder weniger Größen. Textkörper 16px oder größer bei 45 bis 75 Zeichen pro Zeile. Überschriften passen in zwei Zeilen bei jeder Breite.
• Mobile zuerst. Funktioniert ab 320px mit einem 16px Rand und keinem seitlichen Scrollen. Zielbereiche sind 44px. Eingaben sind 16px, damit iOS nicht zoomt. Deaktiviere niemals Zoom.
• Zustände. Jedes Steuerelement hat Standard, Hover, Fokus-sichtbar, Aktiv, Deaktiviert, Laden, Fehler und Erfolg. Jeder asynchrone Bereich hat Laden, Leer und Fehler.
• Stabilität. Keine Layoutverschiebung. Animierte oder asynchrone Panels behalten eine feste Höhe. Karten in einem Raster teilen sich eine Höhe mit fixiertem Footer.
• Neige niemals etwas Anklickbares. Neigung ist nur für dekorative Stempel und Aufkleber.
• Bewegung. Zweckmäßig, unterbrechbar, nur transform und opacity, und sanfter bei prefers-reduced-motion. Inhalt ist ohne JavaScript sichtbar.
• Bildmaterial. Echte oder generierte Kunst in einem einheitlichen Stil. Charakter- und dekorative Kunst wird als transparenter Ausschnitt ausgeliefert, niemals als dunkle Box. Kein in Bilder eingebackener Text.
• Text. Kurz, spezifisch und aus Benutzersicht geschrieben. Visuelles schlägt Absätze.

Details leben in den Referenzen. Lies nur, was die Aufgabe benötigt:

Datei	Abgedeckt
references/typography.md	Schriftgesichter auswählen, die Skalierung, das Maß, Display-Schrift, Laden
references/color.md	Farbstrategie, OKLCH-Tokens, Dunkelmodus, Kontrast
references/layout.md	Abstand, Rahmen, Raster, Hierarchie, responsive und Touch
references/motion.md	Ob animiert werden soll, Easing, Dauern, Performance, reduzierte Bewegung
references/interaction.md	Zustände, Formulare, Worst-Case-Daten, wahrgenommene Geschwindigkeit
references/copy.md	UX-Text, Fehler, Leerzustände, ehrlicher Inhalt
references/imagery.md	Art Direction, generierte Kunst, Fotos, Symbole
references/decks.md	Folienpräsentationen und Vorträge
references/tells.md	Die veraltete Liste generierter Design-Standards

5. Sieh es an

Code-Review ist kein Design-Review. Rendere es und sieh es an.

1. Führe die Seite aus und mache Screenshots bei 375px und 1440px, plus 768px für Layouts, die sich dort ändern. Mache Screenshots hell und dunkel, wenn beide existieren. Verwende playwright-cli, das Browser-Panel oder ein beliebiges Browser-Tool, das die Sitzung hat.
2. Schau dir jeden Screenshot mit zusammengekniffenen Augen an. Das primäre Element, das sekundäre Element und die Gruppen sollten in dieser Reihenfolge noch lesbar sein.
3. Suche nach Kollisionen: Überlappungen, beschnittene Banner, Text, der umbricht, wo er nicht sollte, falsch ausgerichtete Symbole, ungleichmäßige Raster, eine 3+1-Zeile, wo 2x2 hingehört.
4. Kritisiere mit references/critique.md, behebe in der dort angegebenen Reihenfolge und mache erneut Screenshots. Stoppe nach drei Runden und berichte, was übrig bleibt.
5. Für Spiele und interaktive Teile: Spiele sie. Ein Unteragenten-Spieltest auf mobiler Breite findet, was das Lesen des Codes niemals finden wird.
6. Lasse den Dev-Server laufen und gib dem Benutzer die URL. Füge die endgültigen Screenshots in den PR ein: mobil und Desktop, hell und dunkel.

Wenn die Richtung offen ist, wie bei einer Schriftart, einem Logo oder einer Palette, erstelle zwei oder drei kleine Mockups nebeneinander und lasse den Benutzer wählen. Baue dann den Gewinner aus.

6. Verfeinern

Jede Verfeinerung folgt einer Methode: Bewerte den aktuellen Zustand, schreibe eine These in einem Satz, wende sie im Vokabular des bestehenden Systems an, mache Screenshots und poliere dann.

Anfrage	Was zu tun ist
Kräftiger	Erhöhe das Ziel auf das Vertrauensniveau seiner Nachbarn: Größe, Gewicht, Farbverbindlichkeit, Bildmaterial. Mache dann das Umfeld ruhiger
Ruhiger	Entferne ein Accessoire nach dem anderen. Senke den Bewegungsregler. Verschmelze Farben zu weniger Rollen
Einfacher	Schneide Abschnitte, die keine Behauptung aufstellen. Halbiere die Wörter. Verwandle Absätze in ein visuelles Element
Mehr Farbe	Gehe eine Stufe auf der Farbstrategie-Leiter nach oben. Füge niemals zuerst einen zweiten Akzentfarbton hinzu
Typografie	Baue die Skalierung und Paarung aus references/typography.md neu auf
Layout	Korrigiere den Rahmen, die linken Kanten und den Rhythmus aus references/layout.md
Animieren	Bestehe zuerst das Frequenz-Gatter in references/motion.md. Füge dann einen orchestrierten Moment hinzu
Klarerer Text	Wende references/copy.md an
Responsive	Arbeite zuerst für 375px um: Einzelspalte, echte Zielbereiche, nichts beschnitten
Härten	Füge Worst-Case-Daten zu und füge die fehlenden Zustände aus references/interaction.md hinzu

7. Checkliste für die Auslieferung

Führe diese aus, bevor du eine visuelle Arbeit als erledigt bezeichnest:

• DESIGN.md spiegelt die getroffenen Entscheidungen und alle gegebenen Korrekturen wider
• Screenshots bei 375px und Desktop, hell und dunkel, zeigen keine Kollisionen oder Beschnitte
• Nichts aus references/tells.md erscheint, es sei denn, das Briefing hat es festgelegt
• Jedes Steuerelement hat seine Zustände, und jeder asynchrone Bereich hat Laden, Leer und Fehler
• Worst-Case-Daten werden gerendert: lange Namen, null und ein Element, riesige Zahlen
• Die Tastatur erreicht alles, der Fokus ist sichtbar, und reduzierte Bewegung wird beachtet
• Die accessibility-Fähigkeit meldet null schwerwiegende Verstöße bei den Hauptthemen
• Bilder sind einheitlich, ausgeschnitten wo nötig und mit web-optimize optimiert
• Der Text ist auf das reduziert, was der Benutzer braucht, ohne erfundene Beweise
• Der Dev-Server läuft und der PR enthält die Screenshots

Verwandte Fähigkeiten

• accessibility prüft WCAG 2.2 AA mit axe-core über Breiten, Farbschemata und Themen hinweg.
• image-generation erstellt Kunst aus einer palettengebundenen style.md. background-removal schneidet sie aus. web-optimize liefert sie aus.
• architecture enthält die Stack-Standards für Websites in seiner Web-Referenz.

Danksagungen

Diese Fähigkeit paraphrasiert und kombiniert Ideen aus Anthropics frontend-design-Fähigkeit (Apache-2.0), Paul Bakaus' Impeccable (Apache-2.0), Emil Kowalskis Design-Engineering-Fähigkeiten (MIT) und Leonxlnx' taste-skill (MIT). Es wurde kein Text kopiert. Jede Referenzdatei nennt die Quelle ihrer Regeln.