Wie Entwickler das Designsystem wirklich nutzen

Warum es anfangs schwer ist

Entwickler sind keine schwierigen Menschen. Sie sind beschäftigte Menschen, die sich schon die Finger verbrannt haben. Die meisten haben schöne Designs bekommen, die ignorierten, wie das Produkt wirklich funktioniert, Komponenten, die nur in Figma existierten, und Regeln, die sich alle zwei Wochen änderten. Wenn also eine Designerin mit einem neuen System kommt, ist Misstrauen die natürliche Reaktion: Ist das noch eine Schicht Arbeit, noch etwas, das uns bremst?

Dieses Misstrauen ist berechtigt, und dagegen zu argumentieren hilft nicht. Was hilft, ist so schnell wie möglich zu zeigen, dass das System Arbeit wegnimmt, statt welche hinzuzufügen.

Autorität, sorgsam eingesetzt

Jemand muss das System verantworten, und in meinen Teams bin das ich. Das heißt, bei visuellen und Interaktionsentscheidungen das letzte Wort zu haben: welche Komponenten es gibt, wie sie sich verhalten und wann eine Ausnahme akzeptabel ist. Ohne diese Autorität löst sich ein System langsam in eine Sammlung lokaler Varianten auf, jede für sich völlig vernünftig.

Aber Autorität funktioniert nur, wenn man ihr vertraut. Das verdiene ich mir, indem ich konsistent bin, die Gründe hinter den Regeln erkläre und offen umdenke, wenn mir ein Entwickler etwas zeigt, das ich übersehen habe. Meine Regel für mich selbst ist einfach: Ich darf nur auf einer Entscheidung bestehen, die ich erklären kann. Kann ich es nicht, ist es noch keine Regel.

Kreativität im Vorgehen

Autorität setzt die Grenzen; Kreativität bringt Menschen darüber. Mit den Jahren habe ich aufgehört, Systeme zu präsentieren, und angefangen, Entwickler dort abzuholen, wo sie sind. Ich spreche ihre Sprache: Tokens sind Variablen, Komponenten haben Eigenschaften und Zustände, und das Register liest sich wie Dokumentation statt wie ein Moodboard. Ich sorge dafür, dass das System im Code existiert, nicht nur in Designdateien, damit seine Nutzung der Weg des geringsten Widerstands ist.

Ich suche auch den ersten kleinen Erfolg. Ein Entwickler, der an einem Nachmittag ein komplexes Formular baut, weil Felder, Validierungszustände und Abstände schon da sind, wird zum besten Fürsprecher des Systems, viel überzeugender als alles, was ich sagen könnte. Und neben der Bibliothek pflege ich einen Lernbereich mit kurzen Notizen dazu, warum die Dinge so sind, wie sie sind, damit mich niemand zweimal dasselbe fragen muss.

Wenn sie einmal anfangen

Der Wandel, wenn er kommt, ist beeindruckend. Dieselben Entwickler, die am System zweifelten, verteidigen es. Sie weisen auf Inkonsistenzen hin, bevor ich es tue, schlagen neue Komponenten mit sauberen Zuständen und Namen vor und widersprechen jedem, der eine Farbe fest codieren will. Die Gespräche zwischen Design und Entwicklung werden kürzer und ruhiger, weil beide Seiten dieselbe Sprache sprechen.

Dieser Respekt ist jedes schwierige Gespräch am Anfang wert. Ein Designsystem, das Entwickler wirklich nutzen, kann eine Designerin nicht verordnen. Es ist etwas, das das ganze Team wählt, sobald es selbst gesehen hat, wie viel leichter es die Arbeit macht. Meine Aufgabe ist, sie mit genug Festigkeit bis dorthin zu führen, um die Linie zu halten, und mit genug Fantasie, damit sich das Halten lohnt.