Ein Design-System mit den Menschen verbinden, die es bauen würden

Fielmann, Europas größter Optikeinzelhändler, kam mit einem Design-System zu uns, das auf der einen Seite bereits reif war und auf der anderen kaum nutzbar. Das Design-Team hatte jahrelang an einer kohärenten visuellen Sprache gearbeitet: jedes Muster, jedes Token, jede Komponente existierte in ihren Tools. Sobald das Engineering irgendetwas davon nutzen wollte, brach das System am Übergabepunkt auseinander. Nichts war als Code ausgeliefert, nichts war versioniert, und es gab kein geteiltes Modell dafür, wie ein neues Muster vom Designer:innenscreen in eine Produktionsoberfläche kam.

Die Versuchung war, das als Tooling-Problem zu behandeln: ein Component-Framework wählen, eine Registry aufsetzen, eine Library ausliefern, fertig. Wir haben dem widerstanden, aus einem bestimmten Grund. Die Lücke zwischen Fielmanns Design und Engineering war nicht wirklich technisch, sondern organisatorisch. Jede Seite hatte ihr eigenes Vokabular, ihre eigene Definition davon, was „eine Komponente“ ist, und ihre eigenen impliziten Standards dafür, was als fertig galt. Eine Library, die ohne diese Klärungen ausgeliefert wird, würde von niemandem angenommen.

Wir haben die Arbeit als Design-Systems-Team geführt, und „Team“ war eine bewusste Entscheidung, weil die Struktur länger halten musste als jede einzelne Zusammenarbeit. Die technische Arbeit war real (React-Komponenten, Styleguidist-Dokumentation, eine CircleCI-Pipeline, Semantic Versioning über NPM, Granularitätsentscheidungen darüber, was Komponente, was Token, was Muster ist), aber die Arbeit, die am meisten Zeit brauchte, war weniger greifbar: sich zu verständigen, was „fertig“ heißt, wer neue Komponenten anfragen darf, wie sich Breaking Changes kommunizieren lassen, und welche Rituale Design und Engineering dazu bringen, sich gegenseitig die Arbeit anzuschauen.

Der einzelne Schritt, der die Adoption am stärksten verschoben hat, war das Wiederbeleben einer schlafenden Frontend Community of Practice. Sie existierte auf dem Papier, aber niemand hatte sie geführt. Wir haben sie als ständiges Forum aufgegriffen: ein Ort, an dem Komponentenentscheidungen offen diskutiert werden konnten, Muster zwischen Teams reisen konnten, bevor sie in die Library gingen, und kleine alltägliche Reibungen früh benannt wurden, statt sich anzuhäufen. Das Wissen darüber, was das System anbietet, musste das Design-Systems-Team nicht mehr von außen hineindrücken. Es wurde etwas, das die Frontend-Entwickler:innen selbst zwischen den Teams weitertrugen, in einem Raum, den sie selbst besaßen.