Eine Design-Sprache, die 30 Entwicklungsteams überdauert hat

Xing, das deutsche soziale Netzwerk für das Berufsleben, hatte ein deutlich sichtbares Konsistenzproblem: Dutzende Produkt-Teams lieferten Interfaces aus, die schneller auseinanderdrifteten, als ein einzelner Designer das je korrigieren könnte. Die naheliegende Diagnose war eine fehlende Komponenten-Library. Die naheliegende Antwort war, eine zu bauen.

Wir haben die Situation anders behandelt. Eine Komponenten-Library ist ein technisches Artefakt. Sie liegt in einem Repository, und Entwickler:innen greifen entweder darauf zu oder eben nicht. Was Xing tatsächlich fehlte, war eine geteilte Sprache: ein Vokabular, mit dem Design, Product Management und Engineering dasselbe meinen, wenn sie „Card“, „Primary Action“ oder „Empty State“ sagen. Ohne das wäre jede Library Code, für den sich niemand verantwortlich fühlt.

Unsere Arbeit teilte sich in zwei Stränge, die parallel liefen.

Der erste war der sichtbare: React-Komponenten bauen, das Tooling aufsetzen (Flow, Jest, PostCSS), Semantic Versioning und einen Release-Rhythmus etablieren. Der zweite war weniger sichtbar und schwerer: das Vokabular in die Art einzubetten, wie die Teams über UI reden. Das hieß, in Design-Reviews sitzen, Dinge öffentlich benennen, Dokumentation schreiben, die warum ein Muster existiert, bevor sie zeigt, wie man es nutzt, und zu akzeptieren, dass Adoption Team für Team passieren würde, nicht per Anordnung.

Der zweite Strang ist das, was den ersten hat halten lassen.