Designinfrastrukturen die ein Team skalierbar machen
Der Werksmonitor ist ein internes B2B-Tool für Asphaltmischwerke. Disponenten, Wääger und Mischmeister treffen damit täglich operative Entscheidungen — bei laufender Produktion, LKW-Stau, kurzfristigen Planungsänderungen. Fehler haben direkte operative Konsequenzen.
Das Problem
Der Werksmonitor bedient fünf verschiedene Nutzerrollen mit den unterschiedlichsten Bedürfnissen. Dazu wird das Design System von mehreren Produkten geteilt (Werksmonitor, Baumonitor, Kundenportal, 360 Grad Kunde). Jede Entscheidung muss über Rollen, Werke und Organisationsstrukturen hinweg konsistent funktionieren.
Diese Struktur forcierte Wissens-Probleme. Entscheidungen wurden anfangs getroffen, aber nicht festgehalten, sodass sie ein paar Wochen oder Monate später nochmal hinterfragt wurden und erneute Recherche und Evaluierung zur Folge hatten. In der Zusammenarbeit mit den Entwicklern ging Kontext verloren. Als verantwortliche Designerin für den Werksmonitor und das Design System habe ich mir dieses Problem geschnappt. Denn wenn ich das jetzt nicht aufbaue, macht das erstmal niemand.
Mein AI-gestützter Prozess
Design-Problem strukturieren
Problem, Nutzerrollen, Constraints und Ziel im strukturierten Gespräch mit Claude klären.
Claude als SparringspartnerOptionen generieren & evaluieren
Mehrere Lösungsoptionen entwickeln, gegen ADRs und Nutzerrollen prüfen, Entscheidung treffen.
Claude + /evaluate-solutionFigma + iterativer Review
Screens und States in Figma bauen. Claude reviewt als visuelles Widget — States, Edge Cases, Zonenlogik.
Claude in Chrome / SVG-WidgetsDEV-Brief + ADR generieren
Claude erstellt strukturierten DEV-Brief aus Design-Input. Entscheidungen werden als ADR dokumentiert.
Claude als Dokumentations-ToolEntscheidungen bleiben erhalten
Jede Designentscheidung ist begründet und nachlesbar — für Entwickler, neue Teammitglieder und die nächste Version.
→ ADR-System · 18 EinträgeHandoff ohne Informationsverlust
DEV-Briefs enthalten Kontext, alle States und Edge Cases. Entwickler können asynchron arbeiten.
→ DEV-Brief-Format · FigmaAI beschleunigt, nicht ersetzt
Claude erzwingt strukturiertes Denken — Kontext, Konsequenzen, Alternativen. Bessere Entscheidungen, schneller.
→ Cursor + Figma MCP · PrototypingWas ich gebaut habe
ADR-System für Designentscheidungen
Ich habe ein Architecture Decision Record System eingeführt — ein Format das aus der Softwareentwicklung kommt und Entscheidungen mit Kontext, Begründung und Konsequenzen dokumentiert. Übertragen auf Design.
18 ADRs decken heute Themen wie Filter-Interaktionslogik, Modal-Patterns, Skeleton vs. Spinner, Error Handling, Mobile Drawer-Verhalten und komplexe Gruppenlogik bei verknüpften Lieferabrufen. Und werden stetig erweitert.
“Wenn ein Entwickler fragt warum der „Fertig“-Button nicht „Übernehmen“ heißt — gibt es eine Antwort die nicht von mir kommen muss.”
| Nr. | Entscheidung | Scope | Datum |
|---|---|---|---|
| Shared · 001 | Klarheit vor Effizienz | Shared | 2025 |
| Shared · 002 | Aktionen nur mit Berechtigung | Shared | 2025 |
| Shared · 003 | Neue Komponenten: Schwellenwert | Shared | 2025 |
| Shared · 004 | Organisationsagnostisches Design | Shared | 2025 |
| Shared · 005 | Kritisches Löschen: Bestätigungsdialog | Shared | 2026-04 |
| Shared · 006 | Mobile: Bottom Drawer statt Dropdown | Shared | 2026-04 |
| Shared · 007 | Pflichtfeld-Fehlerverhalten | Shared | 2026-04 |
| Shared · 008 | Filter: Live-Apply | Shared | 2026-04 |
| Shared · 009 | Empty States sind immer hilfreich | Shared | 2026-04 |
| Shared · 010 | Loading States: Skeleton vs. Spinner | Shared | 2026-04 |
| Shared · 011 | Kein Modal in Modal | Shared | 2026-04 |
| Shared · 012 | Status-Wording darf divergieren | Shared | 2026-04 |
| Rocks · 001 | Kein Offline-Modus | Basaltrocks | 2025-Q1 |
| Rocks · 002 | Prio-1-Fehler: kein Silent Fail | Basaltrocks | 2025 |
| Rocks · 003 | Navigation: Baumonitor separat | Basaltrocks | 2026-04 |
| Rocks · 004 | Tabellenverhalten: view-spezifisch | Basaltrocks | 2026-04 |
| Rocks · 005 | Abrufe verknüpfen: Gruppenlogik | Basaltrocks | 2026-04 |
| Portal · 001 | Pagination statt Infinite Scroll | Portal | 2026-04 |
DEV-Brief als skalierbarer Handoff-Prozess
Ich habe einen standardisierten DEV-Brief-Prozess etabliert, der Designentscheidungen und Feature/Flowrequests so aufbereitet, dass Entwickler ohne viele Rückfragen nach dem Refinement, selbständig coden können. Dies habe ich durch das erstellen diverser Skills geschafft und mit dem Design Team geteilt. Die Rework-Zyklen haben sich merklich reduziert.
Jeder DEV-Brief enthält: Kontext und Nutzerrolle, alle relevanten States (Default, Loading, Error, Empty), Interaktionslogik mit Begründung, Randbedingungen und explizit benannte offene Fragen.
AI als strukturierter Prozess-Baustein
Claude ist in meinem Workflow kein Convenience-Tool — es ist ein fester Bestandteil meines Designprozesses mit klaren Einsatzbereichen.
Als Konzept-Partner strukturiere ich damit UX-Probleme, generiere Alternativen und evaluiere Optionen gegen Nutzerrollen und Constraints — bevor ich in Figma gehe. Als DEV-Brief-Generator füttere ich konkreten Design-Input ein und erhalte sofort strukturierten Handoff-Content. Als Dokumentations-System entsteht jeder ADR in einem strukturierten Gespräch, wird geprüft und dann als festes Dokument ins Projekt übernommen.
Figma MCP + Cursor
Prototypen direkt aus dem Designtool heraus bauen. Kein Kontext-Switch.
Claude als Denkpartner
Designprobleme strukturieren, Alternativen generieren, gegen Constraints prüfen — bevor Figma geöffnet wird.
NotebookLM Onboarding
Aus ADRs und Prozessdokumenten automatisch Lernmaterial für neue Teammitglieder generieren.
So entsteht ein ADR — konkret
ADR-008 dokumentiert eine Entscheidung die klein klingt und groß ist: Sollen Filter sofort angewendet werden, oder erst nach einem „Übernehmen“-Button?
Das Problem
Im Werksmonitor-Filter-Drawer wurde diskutiert: Live-Apply oder explizites Bestätigen? Dazu kommt eine Besonderheit: Verknüpfte Abrufe sind Gruppen die als Einheit gefiltert werden müssen — kein Standard-Behavior.
Die Entscheidung
Ich habe beide Optionen gegen die Nutzerrollen geprüft. Das Ergebnis → Live Apply gibt sofortiges Feedback ohne Reibung. Der Button heißt „Fertig“ — nicht „Übernehmen“ — weil er schließt, nicht anwendet. Klare Semantik.
Das ADR-Dokument
# ADR-008: Filter werden sofort angewendet
Status: Accepted · Datum: 2026-04 · Scope: Shared
## Entscheidung
Filter werden sofort angewendet sobald sie gesetzt werden.
„Fertig" schließt das Panel — bedeutet nicht „jetzt anwenden".
Ausnahme: Verknüpfte Abrufe bleiben als Gruppe sichtbar wenn
mindestens ein Mitglied den Filter matcht. Opacity ~0.45 für
nicht-matchende Mitglieder.
## Konsequenzen
+ Schnelles Filtern, sofortiges Feedback
+ Gruppen bleiben als Einheit erkennbar
- Gruppen-Filterlogik erhöht Implementierungsaufwand
- Debouncing nötig bei schnellen Filter-ÄnderungenWas dieses System leistet
Ein guter Designprozess macht drei Dinge: Er erzeugt bessere Entscheidungen. Er macht Entscheidungen übertragbar. Und er reduziert den Aufwand für die nächste ähnliche Entscheidung.
Das ADR-System, der DEV-Brief-Prozess und die AI-Integration sind keine separaten Werkzeuge — sie sind Teile desselben Systems. Designwissen wird erzeugt, begründet, dokumentiert und übergeben. Nicht als Einmalleistung, sondern als wiederholbarer Prozess.
Drei Dinge die ich dabei gelernt habe
Dokumentation ist kein Overhead — sie ist das Produkt.
Ein Designsystem ohne Entscheidungsdokumentation ist ein System das die nächste Person von vorne aufbauen muss.
AI macht Prozesse besser wenn man weiß was man will.
Der Hebel entsteht nicht durch das Tool — er entsteht durch den strukturierten Einsatz. Wer AI ohne klaren Prozess nutzt, produziert schneller mittelmäßige Ergebnisse.
Ich baue Strukturen bevor jemand danach fragt.
Kein Ticket, kein Auftrag. Ich finde es schlicht befriedigender Strukturen zu schaffen die für alle funktionieren — als Probleme immer wieder einzeln zu lösen. Das ADR-System war so eine Entscheidung. Einmal richtig gemacht, für alle nutzbar.