Design Systems, die Designer, Entwickler und KI-Tools gleichermaßen befolgen

Bei Sygnum gab es neun verschiedene Design-Stile in separaten CSS-Repositories. Bei Workwise hatten frühe Entscheidungen aufgehört zu skalieren. Bei Aerospike standen mehrere Teams kurz davor, ohne eine gemeinsame Grundlage zu bauen.

Das Muster war jedes Mal dasselbe: inkonsistente UI über Teams hinweg, mehrere Versionen derselben Komponente, lokale Entscheidungen ohne gemeinsame Standards, neue Personen, die nicht wussten, wie gut aussieht. Es fehlten nicht die Komponenten. Es fehlte die Einigung darüber.

In allen drei Projekten verantwortete ich das Design System von der Definition bis zur Adoption. Bei Sygnum und Aerospike war ich der erste eingestellte Designer und definierte Standards von Grund auf, in direkter Zusammenarbeit mit Frontend-Engineers. Bei Workwise stabilisierte und entwickelte ich ein System weiter, das organisch gewachsen war.

In allen Fällen definierte ich die Systemarchitektur mit Engineering-Input, verantwortete Designentscheidungen und Contribution-Regeln und arbeitete täglich eng mit Frontend-Engineers zusammen.

Bei Sygnum war die größte Herausforderung, Engineering-Teams davon zu überzeugen, Zeit für die Migration weg von ihren eigenen hardgecodeten Komponenten in das Monorepo zu investieren. Jedes Team hatte seine eigenen Lösungen gebaut und betrachtete diese als funktionierend. Sie davon zu überzeugen, dass die Konsolidierung die Unterbrechung wert war, erforderte es, immer wieder den Fall zu machen, nicht nur einmal.

Bei Workwise war der Widerstand passiver. Niemand war gegen das Design System. Man hielt es nur nicht für wichtig genug, um mir Frontend-Zeit für Updates zu geben. Dieses Muster wiederholte sich in allen drei Unternehmen in verschiedenen Formen: Die technische Arbeit an einem Design System ist der handhabbare Teil. Menschen dazu zu bringen, es als echte Arbeit zu behandeln statt als Nebenprojekt des Design-Teams, ist die eigentliche Aufgabe.

Komponenten zu bauen war der einfache Teil. Der schwierigere Teil war die Angleichung von Designabsichten in Figma mit der Produktionsrealität im Code und herauszufinden, wie Entscheidungen tatsächlich über Menschen und Prozesse hinweg getroffen werden.

Bei Aerospike gab es eine vierte Herausforderung, mit der keiner von uns zuvor zu tun hatte: KI-Tools generierten UI und Prototypen neben dem Team. Ein für Menschen konzipiertes System war für Maschinen nicht lesbar. Das musste sich auch ändern.

Bei Sygnum und Aerospike basierte ich das System auf Material UI: ein bewusster Kompromiss für Barrierefreiheits-Standards, bewährte Interaktionsmuster und schnellere Ausrichtung mit Engineering. Wir passten die visuelle Ebene an das Produkt an, anstatt alles von Grund auf neu aufzubauen.

Ich konzentrierte mich auf die Teile, die die meiste Reibung zwischen Teams erzeugten: Tokens als Grundlage (Farbe, Typografie, Abstände, Layout – einmal definiert, zwischen Design und Code gemappt), Komponenten mit klaren Zuständen und Verhaltensweisen, die von Anfang an mit Barrierefreiheit entwickelt wurden, Contribution-Regeln, die klar machten, wie das System sich weiterentwickelte, und Dokumentation, die Entscheidungen erklärte – nicht nur was zu verwenden ist, sondern warum es existiert und wann.

Bei Aerospike erweiterte ich die Dokumentation zu einer strukturierten Markdown-Ebene, die Tokens und ihren Zweck, Komponentennutzung und -einschränkungen, Designprinzipien mit Begründungen und Contribution-Logik definiert. Dies wurde zu einer gemeinsamen Instruktionsebene, die Claude, Cursor und Codex nutzen können, um systemkonforme Ausgaben zu erzeugen.

Das System entwickelte sich von einem Satz von Assets zu einem Loop: Figma erfasst Designabsichten → Code enthält Produktionskomponenten → die Markdown-Ebene definiert Systemlogik und Anleitungen → KI-Tools generieren UI nach diesen Regeln.

Entscheidungen werden einmal kodiert und über jede Ebene hinweg wiederverwendet. Das beschleunigt die Dinge, bedeutet aber auch, dass Inkonsistenz schnell skaliert, wenn Regeln nicht klar sind. Das ist es, was die Contribution-Regeln und der Review-Prozess verwalten.

In allen drei Systemen wurden Komponenten konsistent wiederverwendet, Design- und Engineering-Nacharbeit ging zurück, und die Systeme blieben auch nach meiner Beteiligung bestehen. Stakeholder gewannen Vertrauen in UI-Entscheidungen und die Lieferung wurde vorhersehbarer.

Keines dieser Systeme war perfekt. Sie waren gut genug, dass Teams sie weiter nutzten und darauf aufbauten, ohne neu anfangen zu müssen. Das war mein Ziel.

Design Systems brauchen Pflege, Gespräch und Weiterentwicklung. Die Arbeit hört beim Launch nicht auf. Sie wird nur zu einer anderen Art von Arbeit.

Was mich jetzt interessiert, ist, dass sich die Oberfläche verändert. Systeme sind nicht mehr nur Komponentenbibliotheken. Sie werden zur gemeinsamen Sprache zwischen Design, Engineering und den KI-Tools, die neben dem Team bauen. Das über alle drei hinweg konsistent zu halten ist eine schwierigere und interessantere Version desselben Problems. Das ist die Arbeit, die mich am meisten interessiert.

Der schwierigste Teil jedes Systems, das ich gebaut habe, waren nicht die Komponenten, die Architektur oder die Dokumentation. Es war, Menschen davon zu überzeugen, dass die Arbeit real ist. Engineers haben Features zu liefern. Hardgecodete Komponenten in eine gemeinsame Bibliothek zu migrieren fühlt sich nicht dringend an, bis es das tut. Man macht den Fall kontinuierlich, nicht einmal.

Die Systeme, auf die ich am stolzesten bin, sind die, bei denen ich Engineers überzeugt habe, die den Wert anfangs nicht sahen. Das bedeutete, die Arbeit in Begriffen zu zeigen, die ihnen wichtig waren, und die Vorteile in ihrem Alltag sichtbar zu machen, nicht nur in Design-Reviews. Sobald sie es verstanden, fingen sie an, den Fall gegenüber ihren eigenen Teamkollegen zu machen. Diese Gespräche verbreiteten sich weiter als jede Dokumentation, die ich geschrieben habe.

Dieses Argument hat jetzt ein neues Publikum. KI-Tools konsumieren Design Systems genauso wie Engineers. Wenn die Menschen im Team das System nicht befolgen, werden es die Tools auch nicht. Es ist dasselbe Argument, in einem größeren Raum.