← Zurück zum Journal
Design SystemsUIProcess

Erst das Regelbuch, dann der nächste Screen

Warum ich mitten im Bau der meetre-Mac-App angehalten und ein Design-Regelbuch geschrieben habe, was drinsteht (ein Rot, sieben Abstände, sechs Prinzipien) und warum danach jeder Screen schneller ging.

Erst das Regelbuch, dann der nächste Screen

In meetre gibt es genau ein Rot. #E5484D im hellen Modus, #FF6369 im dunklen, und es darf an genau drei Stellen auftauchen: am Aufnahmeknopf, am kleinen roten Punkt und am Timer, solange aufgenommen wird. Sonst nirgends. Nicht am Löschen-Button, nicht im Fehlerbanner, nicht auf irgendeinem „Neu"-Badge. Dieser eine Satz steht in einer Datei namens DESIGN.md, und er hat mir diesen Monat mehr Diskussionen mit mir selbst erspart als alles andere.

Geschrieben habe ich die Datei mitten im Bau der nativen Mac-App. Menüleisten-Popover, Bibliotheksfenster, Live-Overlays, Einstellungen, Onboarding. Irgendwo bei der dritten Oberfläche ist mir aufgefallen, dass ich dieselben Entscheidungen immer wieder treffe, jedes Mal ein bisschen anders. Hier 12 pt Abstand, da 14. Ein Eckenradius, den ich um 23 Uhr ausgesucht hab, weil er gerade gut aussah. Also hab ich aufgehört, Screens zu bauen, und erst mal die Regeln aufgeschrieben.

Sechs Prinzipien, der Rest folgt

Ganz oben stehen sechs Prinzipien, so kurz, dass ich sie im Kopf habe, ohne die Datei aufzumachen:

  1. Leise, bis es gebraucht wird. meetre sitzt neben dem Meeting, nicht mittendrin. Nichts blinkt, nichts will Aufmerksamkeit, außer du musst wirklich was tun.
  2. Inhalt vor Rahmen. Was entschieden wurde und wer was macht, das ist die Oberfläche. Toolbars und Rahmen so leicht wie möglich.
  3. Lokal und ehrlich. Nie so tun, als liefe was in der Cloud. Keine Fake-Spinner. Klar sagen, wenn was kaputt ist.
  4. Eine offensichtliche Aktion pro Oberfläche. Menüleiste: aufnehmen oder stoppen. Meeting: Zusammenfassung lesen. Einstellungen: eine Sache ändern.
  5. Nativ zuerst. SwiftUI, Systemsteuerelemente, SF Symbols, Liquid Glass. Selbst gezeichnet wird nur, wo macOS nichts anbietet.
  6. Fühlt sich sofort an. Jede Interaktion antwortet innerhalb von 100 ms, auch wenn die eigentliche Arbeit Minuten dauert.

Diese sechs entscheiden das meiste. Als ich unsicher war, ob im Popover eine Liste mit Modelloptionen stehen soll, hat Prinzip vier geantwortet: nein, das gehört in ein Menü. Als ich unbedingt eine animierte Waveform ins Bibliotheksfenster bauen wollte, hat Prinzip eins gesagt: die gehört ins HUD während der Aufnahme. Und sonst nirgends.

Ein Regelbuch ist eine Liste von Diskussionen, die du schon geführt hast. Damit du sie um 23 Uhr nicht noch mal führen musst.

Weniger Werte, als du denkst

Die Abstands-Skala ist 2, 4, 8, 12, 16, 24, 32. In der Datei steht wörtlich: „Nothing else." Für Eckenradien gibt's vier Werte: 6 für Chips und kleine Buttons, 10 für Karten und Textfelder, 14 für HUD-Panels und Popover-Karten, 20 für große Hero-Karten. Das Popover ist 360 pt breit. Die HUDs sind 440 pt breit, sitzen 14 pt von der rechten oberen Ecke entfernt, und das Live-Transkript ist 300 pt hoch, minimiert 46.

Aufgeschrieben wirkt das kleinlich. In der Praxis ist es das Gegenteil von einengend. Wenn du nur sieben Abstände hast, grübelst du nicht mehr, ob da 13 oder 14 hingehört. Du nimmst 12 oder 16 und machst weiter, und das Ergebnis wirkt ruhiger, weil alles im selben Raster einrastet. Darüber hab ich schon mal in Designsysteme, die wirklich funktionieren geschrieben: Die Einschränkung ist genau das, was dich schnell macht.

Das meetre-Popover in der Menüleiste während einer Aufnahme: roter Stopp-Button, roter Timer bei 00:03, eine Live-Untertitelzeile und darunter die drei letzten Meetings
Das einzige Rot in der ganzen App. Timer, Stopp-Button, Aufnahmepunkt. Fertig.

Bei Farben läuft es genauso. Text nutzt .primary, .secondary, .tertiary und sonst nichts Eigenes. Selbst ausgesucht sind nur ein paar Tokens mit hellem und dunklem Wert: ein Indigo als accent, das record-Rot, ein Grün für live, ein Amber für warn und eine Farbe pro Verarbeitungsschritt. Sprecher bekommen die Systempalette in der Reihenfolge, in der sie zum ersten Mal reden. „Ich" ist immer neutrales Grau. Dich selbst erkennst du auch ohne Farbe.

Eine Regel mag ich besonders: Zustand nie nur über Farbe zeigen. Alles Farbige kommt mit Symbol oder Wort. „● Recording", „✓ Done", „⚠ Needs permission". Wenn du farbenblind bist oder einfach von der anderen Seite des Raums auf die Menüleiste schielst, liest es sich trotzdem.

Die Zeile, die das Ganze ehrlich hält

Die meisten Design-Dokus sterben, weil sie keiner pflegt. Die Screens wandern weiter, das Dokument bleibt stehen, und nach einem halben Jahr beschreibt es eine App, die es so nicht mehr gibt. Deshalb ist der letzte Abschnitt in meetres Buch eine Liste von Engineering-Regeln, und eine davon lautet sinngemäß: Jede neue Farbe, jeder Radius, jeder Abstand kommt aus den Tokens in Theme.swift. Wer einen neuen festen Wert einbaut, schreibt ihn zuerst ins Buch.

Das ist der ganze Mechanismus. Neue Werte sind erlaubt. Du musst sie nur da hinschreiben, wo alle sie sehen, und damit wird aus „ich brauchte hier halt 18" eine Entscheidung statt eines Unfalls. Meistens merkst du beim Aufschreiben, dass du die 18 gar nicht brauchst.

Nebenbei ein ziemlich guter Prompt

Was ich nicht geplant hatte: Einen guten Teil von meetre hab ich mit einem KI-Coding-Agent neben mir geschrieben, und so ein Regelbuch ist genau das, woran sich diese Agents gut halten. „Mach das Fehlerbanner passend zum Designbuch" bringt ein besseres Ergebnis als jede lange Beschreibung. Der Agent rät kein Rot, weil im Buch steht, dass destruktive Aktionen das System-.red nutzen und niemals record. Das Buch macht niemanden zum Designer. Aber es macht Geschmack wiederholbar, und genau der geht als Erstes verloren, wenn's schnell gehen muss.

Früher schreiben, als es sich vernünftig anfühlt

Der ehrliche Haken: Das Buch hat mich Zeit gekostet, in der ich auch Screens hätte bauen können. Nach zwei Oberflächen fühlte es sich verfrüht an. Bei Oberfläche fünf (dem Onboarding, mit eigenen Regeln für Sound, Tempo und die einzige Stelle, an der runde Display-Schrift erlaubt ist) hab ich mich geärgert, dass ich's nicht am ersten Tag gemacht hab.

TaskAlarm, die kleine To-do-App, die ich direkt danach gebaut hab, hatte eine BRAND.md, bevor sie eine zweite Ansicht hatte. Statusfarben nur für Status. Der Smiley schaut dich bei normalen Sachen nie böse an. Buttons geben beim Drücken auf etwa 94 % nach. War schnell geschrieben, und die App sieht aus, als hätte sie eine einzige Person gemacht. Was, zugegeben, auch stimmt.

Ich brech meine eigenen Regeln immer noch ab und zu. Nur muss ich jetzt dafür eine Datei aufmachen und es zugeben.