In den eigenen Worten des Skills
Eine handwerklich orientierte Disziplin für den Aufbau von Produkt-UI — Dashboards, Admin-Panels, SaaS-Apps, Tools, Einstellungsseiten, Datenoberflächen — mit den Entscheidungen, die ein Top-Design-Team treffen würde. Sie erzwingt ein funktionierendes Briefing vor dem Code: Wer ist der Mensch, welches eine Verb hat ihn hergeführt, und wie sollte sich die Oberfläche in Worten anfühlen, die etwas bedeuten.
Von dort aus schreibt es die Domain-Exploration vor (Domain, Farbwelt, Signature, verworfene Standards, Richtung), eine Typenskala auf Basis eines Verhältnisses, bei der Gewicht und Farbe die Hierarchiearbeit übernehmen, eine einzige verbindliche Tiefen-Strategie, semantische Tokens statt hartcodierter Literale sowie die Feinschliff- und Motion-Grundlagen — tabellarische Ziffern, konzentrischer Radius, Dauern unter 300 ms, keine Animation bei häufig ausgeführten Aktionen. Ausdrücklich nicht für Landing-Pages, Marketing-Websites, Kampagnen oder reine Markenarbeit.
Was er erzeugt
- Ein Suggest + Ask-Vorschlag, der Domain, Farbwelt, Signature, Verwerfen und Richtung benennt.
- Inline gerenderte Muster — Farbpaletten-Kacheln, die Typenskala in der echten Schrift, gestapelte Elevation-Karten, die Signature als reale Komponente — wenn ein Render-Tool vorhanden ist; die eigentliche Umsetzung landet trotzdem im Codebase.
- Eine gespeicherte .interface-design/system.md mit Richtung, Tiefen-Strategie, Hierarchie-Entscheidungen und wiederkehrenden Komponentenmustern, die erst geschrieben wird, wenn der Nutzer zustimmt.
So funktioniert es
- 01Das Working Briefing schreiben
Beantworten Sie vor jedem Code, wer der Mensch ist, welche Handlung er ausführen muss und wie sich die Oberfläche anfühlen soll — kompakt gehalten, außer die Richtung muss bestätigt werden.
- 02Die Produktdomäne erkunden
Erzeugen Sie vier Ergebnisse, bevor Sie eine Richtung vorschlagen: mindestens 5 Domain-Konzepte, 5+ Farben aus der physischen Welt des Produkts, ein Signature-Element und 3 offensichtliche Standards, die verworfen werden.
- 03Die Richtung vorschlagen und bestätigen
Beginnen Sie mit einem Suggest + Ask-Block, der Domain, Farbwelt, Signature, Verwerfen und Richtung benennt, und prüfen Sie dann, ob sich die Richtung richtig anfühlt, bevor Sie bauen.
- 04Muster rendern, wo möglich
Wenn die Sitzung ein inline-visuelles Render-Tool hat, zeigen Sie die Palette, die Typenskala, die Elevation-Stufen und die Signature als reale Komponenten, statt sie zu beschreiben; andernfalls greifen Sie auf Code zurück.
- 05Gegen den Bestand bauen, dann verifizieren
Untersuchen Sie die App, Tokens, Komponentenmuster und die system.md, patchen Sie die Implementierung, führen Sie Build, Typecheck oder Tests aus, sofern verfügbar, und verifizieren Sie dann visuell bei Desktop- und Mobile-Breiten.
- 06Anbieten, die Muster zu speichern
Bieten Sie nach einer Aufgabe an, Richtung, Tiefen-Strategie, Hierarchie-Entscheidungen und wiederkehrende Komponentenmuster festzuhalten, damit spätere Sitzungen konsistent bleiben.