Was macht Design Quality v2?

Ein vollzyklischer Skill für die Erstellung und Bewertung von Schnittstellendesigns. Für bestehende Oberflächen führt er eine Prüfung und Bewertung durch. Für neue definiert er eine Richtung und stellt die handwerkliche Qualität sicher. Für defekte wendet er Korrekturen Schritt für Schritt an.

Diese Version verwendet spezialisierte Sub-Agenten für den Review- und Fix-Modus – parallel, wo möglich, und automatisch vertiefend, wenn eine Dimension ≤ 5 Punkte erhält.

Gate 0: Eingabetyp ermitteln

Bevor eine Analyse oder Erstellung beginnt, identifizieren, was geteilt wurde. Dies ändert alles Weitere.

Was geteilt wurde	Was zu tun ist
Screenshot / Bild	Visuell analysieren; notieren, welches CSS nicht bestätigt werden kann
HTML / CSS-Quelltext	Styles lesen; vollständige Prüfung möglich
Projektordner	Zuerst nach den wichtigsten CSS-/Komponentendateien suchen; vor der Bewertung lesen
URL / Live-Seite	DOM lesen; Styles über DevTools inspizieren, falls Browser verfügbar
Artefakt-Link	Artefakt lesen; wie HTML-Quelltext behandeln
Nur Textbeschreibung	Vor der Bewertung mindestens eine der obigen Angaben anfordern; beschreiben, was fehlt

Auch den Kontexttyp erkennen – dies beeinflusst die anzuwendenden Heuristiken:

App-Bildschirm (Tool, Dashboard, SaaS-Produkt): Dichte bestimmt; Kopfzeile ist klein; Aktion IST der Inhalt
Seite (Landingpage, Marketing, Redaktionell): mehr kreative Freiheit; Hero-Bereich zählt; Abschnitte und Rhythmus

Bei Unsicherheit die Annahme benennen und fortfahren.

Modusauswahl

Aus der Anfrage erkennen – bei Unsicherheit mit Review beginnen:

Art der Anfrage	Modus
„review", „critique", „audit", „sieht das KI-generiert aus?"	review
„build", „create", „diese Seite gestalten"	create
„fix", „improve", „unslop", „redesign"	fix (review → anwenden)
„polish", „fühlt sich leicht falsch an", „fast da"	polish

Wenn im Projektstamm eine Datei PROJECT_DESIGN.md existiert, diese zuerst lesen. Sie enthält die genehmigte Richtung, Palette und Signatur – ohne Nachfrage nicht überschreiben.

Agentenarchitektur

Für den Review- und Fix-Modus spezialisierte Sub-Agenten einsetzen, anstatt alles seriell zu erledigen. Dies ermöglicht eine tiefere Analyse in kürzerer Zeit.

Wann Agenten verwendet werden

Review-Modus bei einer echten UI-Eingabe → immer 3 parallele Review-Agenten einsetzen
Jede Dimension mit ≤ 5 Punkten → nach der Bewertung automatisch den passenden Deep-Dive-Agenten starten
Fix-Modus → pro Pass einen dedizierten Fix-Agenten einsetzen (Pass 3 und 4 parallel)
Create-Modus Gate 1 → optional einen Recherche-Agenten für die Richtung einsetzen, wenn Produkt-URL oder Kategorie bekannt sind

Fork vs. frisch

subagent_type: "fork" – für Review- und Fix-Agenten, die den vollständigen Gesprächskontext benötigen (UI-Eingabe, Screenshots, Code)
Standard (frisch) – für Recherche-Agenten zur Richtung, die den Gesprächsverlauf nicht benötigen

Agenten-Prompt-Dateien

Vollständige Prompt-Vorlagen befinden sich in references/agents/. Diese beim Einsatz referenzieren – jede Datei enthält die Anweisungen und das Ausgabeformat für diesen Agenten.

Review-Modus

Prüfen, bewerten und priorisieren. Keine Code-Änderungen ohne vorherige Rückfrage.

Schritt 0: 3 Parallele Review-Agenten Einsetzen

Bevor du selbst eine Analyse durchführst, setze alle drei Agenten in einer Nachricht mit dem Agent-Tool ein. Alle drei sind Forks – sie erben den vollständigen Gesprächskontext einschließlich der UI-Eingabe.

Agent 1 – Slop Auditor Prompt-Vorlage: references/agents/review-slop.md Aufgabe: Slop-Prüfung, Vorlagencheck, Barrierefreiheit, mobil/Touch, Performance-Schnellchecks.

Agent 2 – Scorecard Scorer Prompt-Vorlage: references/agents/review-scorecard.md Aufgabe: Bewertung aller 8 Dimensionen auf einer Skala von 1–10 mit Begründung pro Punktzahl.

Agent 3 – Emotion Analyst Prompt-Vorlage: references/agents/review-emotion.md Aufgabe: Gefühlszustands-Prüfung über alle wichtigen Zustände hinweg + Peak-End-Regel-Mapping.

Warte, bis alle 3 abgeschlossen sind, und fahre dann mit Schritt 1 fort.

Schritt 1: Synthese

Die Ergebnisse der drei Agenten in das Standard-Ausgabeformat zusammenführen. Doppelte Befunde aus mehreren Agenten entfernen. Wenn Agenten bei einer Punktzahl abweichen, den niedrigeren Wert verwenden und die Abweichung notieren.

## Slop Audit
[von Agent 1 – jeder Befund mit Ort und Schweregrad]

## Template Check
[von Agent 1]

## Scorecard
Produktfit:    X/10   [von Agent 2 – einzeilige Notiz]
Hierarchie:      X/10
Klarheit:        X/10
Geschmack:          X/10
Zurückhaltung:      X/10
Dichte:        X/10
Handwerk:          X/10
Responsivität: X/10
Gesamt:        X/10

## Emotionales Design
[von Agent 3 – Gefühlszustand + Peak-End-Befunde]

## Urteil
Bester Teil:
Schlechtester Teil:
Erforderliche Korrektur (P0): [falls vorhanden – ansonsten „keine"]
Schnelle Erfolge (P1): [höchstens 3]

Nach der Ausgabe fragen, ob Korrekturen angewendet werden sollen.

Schritt 2: Automatische Vertiefung

Nachdem die Bewertungskarte angezeigt wurde, jede Dimension überprüfen. Für jede, die ≤ 5 Punkte erhalten hat, automatisch den passenden Deep-Dive-Agenten starten, ohne abzuwarten, ob gefragt wird.

Siehe references/agents/deepdive-dispatch.md für die Einsatztabelle und Prompt-Vorlagen.

Vor dem Start ankündigen: „Hierarchie hat 4 Punkte erhalten – eine fokussierte visuelle Hierarchie-Kritik wird gestartet."

Deep-Dive-Zuordnung:

Dimension / Befund	Zu startender Skill
Hierarchie ≤ 5	Skill `critique-visual-hierarchy`
Klarheit ≤ 5 (Affordanzen)	Skill `critique-affordance`
Klarheit ≤ 5 (Dichte)	Skill `critique-information-density`
Handwerk ≤ 5 (Typografie)	Skill `critique-typography`
Handwerk ≤ 5 (Farbe)	Skill `critique-color`
Handwerk ≤ 5 (Layout)	Skill `critique-composition`
Geschmack ≤ 5 (wirkt flach)	Skill `interfaces-that-feel`
Dichte ≤ 5	Skill `critique-information-density`
Probleme im emotionalen Bogen	Skill `peak-end-rule`

Create-Modus

Bevor UI-Code geschrieben wird, diese Reihenfolge einhalten. Jeder Schritt ist ein Gate – stoppen und bestätigen, bevor es weitergeht.

Gate 0: Kontexttyp

Angeben, welcher zutrifft, bevor fortgefahren wird:

App-Bildschirm – Tool, Dashboard, Datenprodukt. Dichte, Aktionen und Zustände bestimmen.
Seite – Landingpage, redaktionell, Marketing. Komposition, Rhythmus und Abschnitte bestimmen.

Gate 1: Produkt-Recherche-Agent (optional, aber empfohlen)

Wenn das Produkt eine URL, einen Namen hat oder zu einer bekannten Kategorie gehört, einen Recherche-Agenten einsetzen, bevor der Nutzer nach dem Produktverständnis gefragt wird. Dies spart eine Hin- und Rückrunde und deckt domänenspezifische Konventionen auf, an die der Nutzer vielleicht nicht denkt.

Prompt-Vorlage: references/agents/direction-research.md

Wenn keine URL oder Kategorie bekannt ist, diesen Schritt überspringen und den Nutzer direkt fragen.

Prüfen, ob im Projektstamm bereits eine PROJECT_DESIGN.md existiert. Wenn ja, lesen – die Richtung ist bereits festgelegt; direkt zu Gate 3 (Bauen) springen und die aufgezeichnete Richtung anwenden.

Wenn nicht, erfragen oder fragen nach: Was das Produkt tut, für wen es ist, was die Hauptaufgabe ist, welche Inhalte existieren, der Technologie-Stack, vorhandene Markenfarben, Schriftarten, Komponenten.

Fragen: „Ist mein Verständnis korrekt, bevor ich die Designrichtung festlege?" Anhalten. Warten.

Gate 2: Richtung + Design-Dials

Fünf Linien aus dem Produkt ableiten – niemals aus Trends, Portfolios oder dem, was cool aussieht:

Produkt: Was es tut und für wen, in einem einfachen Satz.
Charakter: 2–3 konkrete Wörter. ruhig, genau, ein bisschen warm oder schnell, technisch, verspielt. „Sauber, modern, elegant, minimalistisch, erstklassig" sind verboten – sie beschreiben jede Vorlage.
Welt: Das Material oder der Ort, zu dem das Produkt natürlicherweise gehört. Eine Notiz-App: Papier und Tinte. Ein Überwachungstool: Instrumente und Nachtschichten. Eine Reise-App: Karten und Fensterlicht. Dies färbt die Neutraltöne, den Akzent und die visuellen Momente.
Momente: 1–2 Stellen auf dem Bildschirm, an denen das Design reich und spezifisch wird. Alles andere bleibt ruhig, damit diese sofort lesbar sind.
Signatur: Ein kleines Detail, das nur dieses Produkt hätte, konsequent wiederholt.

1–3 Richtungen präsentieren. Für jede drei Design-Dials zeigen:

Varianz  ░░░░░░░░░░  1–10   (1 = minimal/zentriert, 10 = gewagt/asymmetrisch)
Bewegung    ░░░░░░░░░░  1–10   (1 = statisch, 10 = animiert)
Dichte   ░░░░░░░░░░  1–10   (1 = großzügig/redaktionell, 10 = Dashboard/dicht)

Fragen: „Welche Richtung? Und stimmen die Dials, oder sollte ich welche anpassen?" Anhalten. Warten.

Nachdem die Richtung bestätigt wurde, vorschlagen, eine PROJECT_DESIGN.md im Projektstamm zu erstellen:

# PROJECT_DESIGN.md

## Richtung: [Name]
Produkt: [ein Satz]
Charakter: [2–3 Wörter]
Welt: [Material / Ort]
Momente: [1–2 bestimmte Stellen]
Signatur: [ein Detail]

## Dials
Varianz: X/10
Bewegung: X/10
Dichte: X/10

## Palette
Grundfläche: [Token + Hex]
Akzent: [Token + Hex]
Text primär: [Token + Hex]
Text dezent: [Token + Hex]

## Typografie
Auszeichnung: [Schriftartname + Stärke]
Fließtext: [Schriftartname + Stärke]
Mono: [Schriftartname] (falls zutreffend)

## Eckenradius: [Wert]px

Designprinzipien

Wenn die Richtung bestätigt ist, in dieser Reihenfolge anwenden (frühere Pässe beeinflussen spätere):

Abstände – zuerst festlegen

8px-Raster. Alle Ränder, Abstände, Lücken: Vielfache von 4 oder 8. (mt-[13px] → korrigieren.)
Gleiches Element = gleiche Größe. Alle Listenzeilen teilen eine Höhe und einen Abstand.
Abstand zeigt Gruppierung: innen < außen. Eine Abschnittsbeschriftung sitzt näher an ihren eigenen Elementen als an der darüber.
Navigation ist am dichtesten: Zeilen 32–36px, 2–4px dazwischen.

Farbe

Eine neutrale Abstufung, getönt in Richtung der Welt. Hintergründe, Oberflächen, Rahmen, Text alle aus dieser Abstufung.
Ein Akzent, selten verwendet: primäre Aktion, Auswahl oder die eine Zahl, die zählt.
Drei Textrollen: primär, sekundär, dezent. Niemals zehn leicht unterschiedliche Grautöne.
Verboten: Farbverläufe auf Oberflächen, Farbverlaufstext, farbige Glüheffekte, farbige Schatten, radiale Kleckse, Neonrahmen.
Akzent mit Text darauf: ≥ 4,5:1 Kontrast.
Für neue Farb-Token OKLCH bevorzugen: oklch(L% C H).

Typografie

Eine unverwechselbare Auszeichnungsschriftart mit einer sauberen Fließtextschriftart kombinieren. Den Gewichtskontrast maximieren.
text-wrap: balance auf allen Überschriften (h1–h3). text-wrap: pretty auf Fließtext und Listentext.
-webkit-font-smoothing: antialiased auf :root oder html.
Mindestens 14px Fließtext (16px bevorzugt). Eine h1 pro Seite.

Komponenten

Buttons: Verb-zuerst-Labels. Ein primärer Button pro Abschnitt.
Keine Emojis als Icons. Eine Icon-Bibliothek, eine Strichstärke, nur currentColor.
Karten: Schatten ODER Rahmen, nicht beides.
Leere Zustände: Illustration + Überschrift + CTA. Niemals nur leer.
Laden: Skelett-Bildschirme (keine Spinner) nach 300ms Verzögerung.
Modals: X, Abbrechen und Esc. Fokus einfangen. Fokus beim Schließen zurückgeben.
overscroll-behavior: contain auf allen Modals, Drawern und Dropdowns.
Alle Icon-Buttons benötigen aria-label. Alle Formulareingaben benötigen ein zugehöriges <label>.

Regel des einen hellen Elements

Jeder Bildschirm erhält ein poliertes, reichhaltiges Element. Alles drumherum bleibt ruhig.

Anti-Generisch-Schutz

Wenn das Design in einem Portfolio-Screenshot beeindruckend aussehen würde, aber das Produkt weniger klar macht, ablehnen.

Nach dem Bauen

Den Review-Modus (mit Agenten) ausführen. Fertig, wenn: keine P0-Befunde, Gesamtbewertung ≥ 7/10, Produktfit ≥ 7/10.

Fix-Modus

Zunächst den Review-Modus ausführen, um die Bewertungskarte zu erhalten. Dann die Fix-Agenten in der Pass-Reihenfolge einsetzen.

Ausführungsreihenfolge:

Pass 1, 2 → sequenziell (zuerst Abstände, dann Farbe)
Pass 3 + Pass 4 → parallel (Icons und Text sind unabhängig)
Pässe 5–10 → sequenziell

Siehe references/agents/fix-passes.md für die Prompt-Vorlage jedes Passes.

Für jeden Pass ankündigen, was der Agent tut, und pro Pass berichten: was geändert wurde und was noch Aufmerksamkeit benötigt.

Pass-Reihenfolge:

Abstände – 8px-Raster-Ausrichtung, Rhythmus, Gruppierung
Farbe – Schludrigkeit entfernen, aus neutraler Abstufung aufbauen
Icons – eine Serie, eine Größe, eine Strichstärke, currentColor (parallel mit Text)
Text – Emoji-Labels entfernen, das Geschrei beruhigen, produktspezifisch machen (parallel mit Icons)
Typografie – Hierarchie, Gewichte, text-wrap: balance, text-wrap: pretty, Antialiasing, tabular-nums
Layout – Ausrichtung, Dichte
Details – Konzentrische Radien, Schatten, Rahmen
Barrierefreiheit & Touch – Fokus-Zustände, aria-label, touch-action: manipulation, 44px Ziele, overscroll-behavior
Visuals – Illustrationen für leere Zustände, Icon-Konsistenz, Bild-Seitenverhältnisse. Siehe references/passes-visuals.md
Bewegung – letzter Pass, nur wo es Bedeutung hinzufügt. Siehe references/passes-motion.md

Nach allen Pässen: die Review-Modus-Agenten erneut ausführen, um zu überprüfen. Delta zur ursprünglichen Bewertungskarte melden.

Polishing-Modus

Für Oberflächen, die größtenteils gut gestaltet sind, sich aber leicht falsch anfühlen.

Technik: Die Oberfläche in den Browser-DevTools (Bereich Animationen) auf 10% Geschwindigkeit verlangsamen und jeden Zustand durchgehen: hover, focus, active, loading, empty. Was sich bei 10% falsch anfühlt, ist bei voller Geschwindigkeit subtil falsch.

Siehe references/micro-polish.md für spezifische Werte.

Schnell-Checkliste:

Checkliste vor der Auslieferung

Bevor eine UI als erledigt markiert wird:

Keine Emojis als Icons (SVG verwenden: Heroicons/Lucide/Phosphor/Radix)
cursor-pointer auf allen klickbaren Elementen
Textkontrast ≥ 4.5:1 (WCAG AA)
Fokus-Zustände für Tastaturnavigation sichtbar (focus-visible, nicht outline entfernt)
aria-label auf jedem Icon-Button
<label> mit jedem <input> oder <select> assoziiert
role-Attribut auf modalen Dialogen, aria-modal="true", aria-labelledby auf den Titel
aria-hidden="true" auf dekorativen Icons und Illustrationen
alt-Text auf allen <img> (dekorativ → alt="")

Kurzreferenz der Befehle

„Überprüfe dieses Design" → Review-Modus, 3 Agenten starten
„Baut mir einen Dashboard-Bildschirm" → Create-Modus
„Das sieht KI-generiert aus“ → Review-Modus spezifisch
„Korrigiere die Schleife“ → Fix-Modus, Pässe ausführen
„Fühlt sich fast richtig an“ → Polish-Modus, 10% Geschwindigkeit-Zustände
„Gibt es eine `PROJECT_DESIGN.md`?” → Richtung prüfen, nicht überschreiben

Anhänge

references/agents/review-slop.md – Slop-Prüfungs-Prompt
references/agents/review-scorecard.md – Bewertungskarten-Prompt
references/agents/review-emotion.md – Emotionsanalyse-Prompt
references/agents/direction-research.md – Recherche-Prompt für die Richtung
references/agents/deepdive-dispatch.md – Dispatch-Tabelle & Vorlagen
references/agents/fix-passes.md – Fix-Agent pro Pass
references/micro-polish.md – Polishing-Werte & Referenz
references/passes-visuals.md – Visuelle Details für Pass 9
references/passes-motion.md – Bewegungshinweise für Pass 10

Design Quality v2

Was ist Design Quality v2?

In Ihrer bevorzugten KI fragen

Dokumentation