Unslop Design

Was macht Unslop Design?

Drei Teile: was zu beheben ist (checklist.md, jede Behebung mit ihrer Begründung), wie es orchestriert wird (process.md, Runden mit Reviewern und Entwicklern parallel) und Fälle und Quellen (references.md: die fünf Vorher/Nachher-Studien, die diese Skill ins Leben gerufen haben, und eine Karte von Refactoring UI). Die Spezifikationskarte, die jeder Reviewer ausfüllt, befindet sich in spec-card.md. Plattformspezifische Hinweise (SwiftUI, Compose, Web, Widgets, Watch, Car) sind in platforms.md. Lies nur die, die du brauchst, nicht alle.

Prinzipien (nicht verhandelbar)

1. Eine Korrektur ist eine Regel, kein Feintuning. Jede Änderung wird als Token oder Komponente ausgeliefert (Abstand, Schriftgröße, -stärke, Farbrolle, Radius, Schatten, Button), niemals als Literal in der View. Fehlt der Token, wird er in derselben Änderung erstellt. Werte werden per Elimination innerhalb der Skala gewählt (versuche den Wert und seine beiden Nachbarn; der mittlere gewinnt oder du wiederholst den Vorgang), niemals Pixel für Pixel.
2. Hierarchie vor Farbe. Der Bildschirm muss in Graustufen funktionieren: Abstände, Größe, Stärke und Kontrast leisten die Arbeit; Farbe kommt erst danach und nur, um etwas zu bedeuten. Wenn in Grau nicht klar ist, was wichtig ist, wird Farbe es nicht beheben.
3. Das Erste, was du liest, ist die Antwort. Eine Held-Zahl pro Bildschirm (der Kontostand, der Preis, der heutige Fortschritt); alles andere tritt zurück. Betone durch Entbetonung der Konkurrenz, nicht durch Aufblähen der Held-Zahl. Maximal eine dunkle/Held-Oberfläche pro Bildschirm und keine in Sheets oder Modals.
4. Farbe sagt eine Sache. Eine Marken-Akzentfarbe für die Aktion oder die Held-Zahl; alles andere ist eine Rolle mit Bedeutung (Geld/Erfolg, hoch/Gefahr, Status, Belohnung) und Grau für das, was nur navigiert. Dekorative Farbe = Geschmiere. Farbe arbeitet nie allein: Form oder ein Wort begleiten sie.
5. Gemessener Kontrast, nicht angenommen. WCAG AA (4,5:1 Text, 3:1 großer Text und Symbole) berechnet aus den tatsächlichen Hex-Werten auf den tatsächlichen Hintergründen, hell und dunkel. Weiß auf einer grünen/gelben Markenfarbe besteht fast nie; grauer Text auf farbigem Hintergrund auch nicht (wähle einen Farbton desselben Farbtons).
6. Nichts, was der Bildschirm nicht liefern kann. Keine erfundenen Zahlen, keine als Daten präsentierte Projektion, keine implizierte Funktion, die nicht existiert, kein leerer Zustand, der lügt. Gestalte die kleinste Version, die du tatsächlich ausliefern kannst.
7. Eine signifikante Geste, entnommen aus der Domäne. Ein Markendetail, das aus dem entsteht, was die App zeigt (ein Preis aus einer Preisliste mit einer kleineren letzten Ziffer, Punkt-Matrix-Zahlen in einer Lauf-App), keine neue Schriftart oder kein neuer Effekt; und sie degradiert anmutig, wo sie nicht zutrifft. Alles andere ist nativ: bekämpfe nicht die Tab-Leiste, Schalter oder System-Sheets.
8. Plattformen werden gemeinsam ausgeliefert. Wenn das Projekt iOS und Android (oder App und Web) umfasst, geht die Änderung in beide im selben PR, in jeder Sprache.
9. Überprüfe, was der Benutzer sieht. Screenshots in hell und dunkel, größte Textgröße, eine nicht standardmäßige Währung/Sprache, echte Daten (lange Namen, leer, 2.000 Elemente). Was in deiner Umgebung nicht kompiliert werden kann, wird durch Lesen auditiert, und der PR weist darauf hin.

Beliebiger Agent (Claude Code, Codex, Cursor, Copilot, Gemini …)

Die Regeln sind überall gleich. Wo „Agenten“ steht, verwende, was dein Tool hat: Unteragenten, falls vorhanden (Claude Code, Codex …), jeweils mit einem Git-Worktree für Entwickler. Ohne Unteragenten führe die Reviewer nacheinander aus, jeder mit seiner eigenen Aufgabenbeschreibung, und behalte ihre Ausgaben vor dem Jury-Schritt getrennt. Wo „veröffentlichen“ steht, veröffentlicht Claude Code ein Artefakt; andere Agenten schreiben eine HTML-Datei, die der Benutzer öffnet. In einer Chat-App ohne Codebasis halte nach dem Vorher/Nachher-Vorschlag an.

Arbeitsvereinbarung (Standards)

• Reviewer = leitende Produktdesigner und Entwickler = leitende Entwickler, als Agenten (verwende das vom Benutzer angeforderte Modell). Der Orchestrator erstellt die Bereiche nicht: Er leistet die gemeinsame Arbeit, integriert und auditiert.
• Jede Entscheidung kommt mit einer expliziten, umsetzbaren Empfehlung.
• Vor der Implementierung veröffentliche das Vorher/Nachher und warte auf das „Ja“ des Benutzers.
• Jede Runde überprüft auch, was frühere Runden ausgeliefert haben, und alle erhaltenen Videos/Screenshots, nicht nur die neuesten.
• Wenn das Mergen erlaubt ist, sobald CI grün ist: schließe mit einer Liste dessen, was beim Kompilieren zu überprüfen ist (konkrete Risiken) und, falls es keinen Mac/Simulator gibt, einem eigenständigen Prompt für eine lokale Sitzung.
• Bei „Ist alles erledigt?“: erledigt (mit PRs) · wartet auf dich · absichtlich ausgelassen.
• Nach der letzten Runde aktualisiere das Designsystem des Projekts.

Kurzer Ablauf

1. Bestandsaufnahme: Einzelbilder aus den Videos (process.md § 1), Bildschirme und Zustände, und jeder Bildschirm im Code lokalisiert.
2. System: Überprüfe (oder erstelle) die Skalen für Abstände, Typografie, Farben und Höhen (checklist.md § System). Ohne Skalen bewerten Reviewer nach Augenmaß.
3. Graustufendurchlauf + parallele Reviewer (3-4, einer pro Bereich) gegen checklist.md, wobei Korrekturen einzeln angewendet werden.
4. Gewinnervorschlag: eine HTML-Seite mit Vorher/Nachher, der Spezifikationskarte und der Liste der Entscheidungen; der Benutzer wählt.
5. Entwickler pro Bereich in isolierten Worktrees mit einer geschlossenen Aufgabenbeschreibung; integrieren, kompilieren, auditieren, PR, Review-Bots beantworten, mergen, wenn grün.
6. Schließlich: aktualisiere das Designsystem des Projekts (Dokumentation + Tokens + eigene Skill) mit dem, was neu ist.

Wenn das Projekt bereits eine eigene Design-Skill hat

Verwende sie für konkrete Tokens und Komponenten; diese Skill bringt die Methode und die allgemeine Checkliste. Wenn eine Regel hier mit einer schriftlichen Projektentscheidung kollidiert, gewinnt das Projekt, und der Vorschlag weist darauf hin.