/grill-design — UI/UX-Sokratisches Design

/grill-design

Ziel: Festlegen, wie die Anwendung für den Endbenutzer aussehen und sich verhalten soll – gestützt auf etablierte Patterns und reale Produkte – und dies dauerhaft dokumentieren.

Vorbereitung (still)

1. Lies wiki/index.md, wiki/overview.md, zugehörige Spezifikationen in wiki/ui-specs/ und schema/design-system.md (falls vorhanden).
2. Untersuche die vorhandene UI im Code (Komponentenbibliothek, Tokens, Tailwind-Konfiguration, ähnliche Bildschirme).
3. Lies den Patterns-Katalog.
4. Wenn die Funktion noch kein /grill durchlaufen hat und die Geschäftsregeln unsicher sind, schlage vor, zuerst /grill auszuführen.

Leitregeln

1. Eine Frage pro Schritt, mit begründeter Empfehlung.

2. Jede Designfrage wird mit konkreten Vorschlägen im folgenden Format präsentiert:

   **Frage:** Wie soll der Benutzer durch die 2.000 Bestellungen navigieren?
   
   | Option | Pattern | Referenzen (was kopieren) | Vorteile | Nachteile |
   |---|---|---|---|---|
   | A ⭐ | Datentabelle + facettierte Filter + gespeicherte Ansichten | **Stripe-Dashboard** (Filter-Chips über der Tabelle), **Linear** (gespeicherte Ansichten in der Sidebar) | Skalierung, Power-User | Schlechter auf Mobilgeräten |
   | B | Master-Detail | **Gmail** (Liste + Lesefenster nebeneinander) | Kontext bleibt erhalten | Erfordert breiten Bildschirm |
   | C | Kartenraster | **Airbnb** (Karten mit Foto) | Optisch ansprechend | Schwerer vergleichbar |
   
   **Ich empfehle A**, da das Publikum operativ arbeitet, Desktop bevorzugt und Status/Werte vergleichen muss.
   

3. Referenzen sollten reale und dem Projekt fachlich verwandte Apps sein (Fintech → Nubank, Stripe, Mercury; Produktivität → Linear, Notion; Marketplace → Airbnb, Mercado Livre usw.). Gib an, was genau kopiert werden soll (ein spezifisches Detail), nicht nur den Namen.

4. Wenn der Agent über Websuche verfügt, kann er Beispiele recherchieren (Mobbin, Page Flows, Dribbble), um die Vorschläge anzureichern.

5. Zeige nach Möglichkeit ein ASCII-Wireframe der empfohlenen Option.

6. Respektiere das bestehende Designsystem; schlage Änderungen daran nur explizit vor.

Dimensionen (durchlaufe die relevanten in dieser Reihenfolge)

#	Dimension	Typische Fragen	Übliche vorzuschlagende Patterns
1	Zielgruppe und Kontext	Wer ist sie? Nutzungshäufigkeit? Desktop/Mobil? Technisches Niveau?	— (bestimmt den Rest)
2	User Journey / Flow	Woher kommt sie, welches Ziel, wohin geht sie? Schritte?	Wizard, Hub-and-Spoke, linearer Flow
3	Informationsarchitektur	Welche Bildschirme? Hierarchie? Navigation?	Sidebar, Tabs, Bottom-Bar, ⌘K, Breadcrumbs
4	Layout und visuelle Hierarchie	Fokuspunkt? Dichte? Raster? Responsivität?	Master-Detail, KPI-Dashboard, Split View
5	Datenanzeige	Liste, Tabelle, Karten, Diagramm? Suche/Filter/Sortierung?	Datentabelle, Kanban, Facetten, gespeicherte Ansichten
6	Erstellung und Bearbeitung	Wie wird erstellt/bearbeitet? Validierung? Speichern?	Modal, Drawer, Inline-Bearbeitung, Autosave, Stepper
7	Zustände	Laden, leer, Fehler, Erfolg, teilweise, keine Berechtigung, offline	Skeleton, lehrreicher Empty State, Undo-Toast, optimistische UI
8	Feedback und Mikrointeraktionen	Bestätigungen, Übergänge, Hover, Tastenkürzel	Toast, Inline-Validierung, Tastaturkürzel
9	Designsystem und Tokens	Bibliothek (shadcn, Radix, MUI …)? Semantische Farben, Typografie, Abstände, Dark Mode	Semantische Tokens, 4/8px-Skala
10	Barrierefreiheit	Tastatur, Fokus, Kontrast AA, Screenreader, prefers-reduced-motion	Skip Links, Focus Ring, ARIA-Patterns
11	Inhalt und Ton	Microcopy, Sprache, Tonfall, Fehlermeldungen	—
12	Onboarding und Aktivierung	Erste Nutzung? Beispieldaten?	Checkliste, Vorlagengalerie, Beispieldaten

Synthese

Präsentiere die Spezifikation, indem du die Vorlage ui-ux-spec.md ausfüllst, einschließlich:

• Tabelle Übernommene Patterns (Pattern → wo → Referenz → Grund);
• Tabelle Referenzen (App → was kopieren → was vermeiden);
• ASCII-Wireframes der Hauptbildschirme;
• Zustandsmatrix pro Komponente;
• Neue Tokens/Regeln, die für das Designsystem vorgeschlagen werden.

Und die Speichertabelle:

Ziel	Datei	Aktion
wiki	wiki/ui-specs/<bildschirm-oder-flow>.md	/wiki:add
wiki	wiki/concepts/<feature>.md (Link zur Spezifikation)	/wiki:increment
schema	schema/design-system.md	/schema:add (1. Mal) oder /schema:increment

UI-Implementierungsplan (Tasks / Tickets)

Task	Vertikale	Abhängig von	Priorität	Aktion
wiki/tasks/<slug-der-komponente>.md	ui	-	medium	/ticket:new (wiki + issue)

Explizite Zustimmung (Gate)

„Bestätigst du die UI/UX-Spezifikation, die Einträge im Designsystem und die Erstellung der Tasks (+ Issues auf GitHub)? (ja / anpassen)“ – ohne eindeutige Zustimmung wird nichts gespeichert.

Formalisierung (nach Zustimmung)

1. /wiki:add → wiki/ui-specs/<slug>.md (type: ui-spec).
2. /wiki:increment in den zugehörigen Feature-/Entitätsseiten.
3. /schema:add oder /schema:increment → schema/design-system.md (Vorlage design-system-rules.md).
4. Führe /ticket:new für jede geplante UI-Aufgabe aus (Komponenten, Bildschirme, Interaktionen), mit den Labels vertical:ui (oder der Vertikalen der Funktion) und status:planned.
5. Füge in wiki/log.md den Eintrag hinzu: ## [JJJJ-MM-TT] grill-design | <bildschirm/flow> mit den erstellten Seiten und Tasks.
6. Schlage nächste Schritte vor: /implement <ui-task>, Prototyp, benachbarte Bildschirme ohne Spezifikation.