Ein Designsystem in ein bestehendes Produkt einführen

Mit einem ehrlichen Blick beginnen

Der erste Schritt ist immer, genau hinzusehen, was das Produkt bereits verwendet. Ich sammle jeden Button, jede Farbe, jeden Abstandswert und jedes Muster, das auf echten Screens vorkommt, nicht in den Designdateien, wo alles meist aufgeräumter aussieht, als es ist. Das Ergebnis ist meist ernüchternd: elf Grautöne, vier Versionen derselben Karte und ein Modal, das sich auf jeder Seite anders verhält.

Diese Bestandsaufnahme ist keine Anklage. Sie ist eine Landkarte. Sie zeigt, wo das Produkt ohne Absicht konsistent war, wo es abgedriftet ist und welche Entscheidungen immer wieder getroffen werden. Genau um diese wiederkehrenden Entscheidungen sollte sich ein System kümmern.

Manchmal zeigt die Bestandsaufnahme, dass es überhaupt kein System gibt. Manchmal, dass es eines geben sollte und es vor allem dem Namen nach existiert. Beides ist völlig normal, und beides lässt sich lösen. Das Zweite braucht nur etwas mehr Diplomatie.

Kontext kommt vor Komponenten

Bevor ich einen einzigen Token benenne, möchte ich das Produkt um die Oberfläche herum verstehen: welche Art von Produkt es ist, in welchem Markt es konkurriert, wer es wie oft nutzt und wohin es sich in den nächsten Jahren entwickelt. Ein System für ein öffentliches Portal, das jedem Bürger dienen muss, wird anders gebaut als eines für ein Handelswerkzeug, das zwanzig Spezialisten den ganzen Tag nutzen. Liegt man hier falsch, entsteht ein technisch elegantes System, das zu niemandes Realität passt.

Erst die Entscheidungen benennen, dann die Teile

Wenn die Landkarte klar ist, gebe ich den wiederkehrenden Entscheidungen Namen. Farben werden zu Tokens mit einem Zweck, etwa Fläche, Rand oder Warnung, statt eines Hexwerts, den jemand einmal mochte. Abstände werden zu einer Skala. Schrift wird zu einem kleinen Satz von Rollen. Benennung nach Zweck ist wichtig, weil das Produkt so später sein Aussehen ändern kann, ohne dass jemand Hunderte Screens durchsuchen muss.

Dann kommen die Komponenten, beginnend mit den Teilen, die sich am häufigsten wiederholen. In einem bestehenden Produkt sind das meist Buttons, Formularfelder, Tabellen und Karten. Eine Handvoll gut gemachter gemeinsamer Komponenten ersetzt Dutzende lokale Varianten, und die Wirkung ist innerhalb weniger Wochen sichtbar.

Schrittweise ersetzen, parallel zur Arbeit

Die neuen Teile kommen nicht in einem großen Release. Sie ersetzen die alten nach und nach, Screen für Screen, parallel zur ohnehin geplanten Entwicklung. Ein Team, das eine Seite für ein neues Feature anfasst, nimmt die gemeinsamen Komponenten mit. Niemand hält an; das Produkt wird einfach mit jedem Sprint konsistenter.

Dieser Rhythmus hält auch alle an Bord. Entwickler sehen, dass das System ihre Arbeit beschleunigt, statt eine Schicht Regeln hinzuzufügen. Product Owner sehen die Konsistenz wachsen, ohne Stillstand. Und das System verdient sich seinen Platz, indem es nützlich ist, und nur so verdient sich ein System ihn wirklich.

Wo es endet

Nach einigen Monaten teilen Design und Code eine einzige Quelle der Wahrheit. Neue Screens entstehen schneller als die letzten, weil das meiste, was sie brauchen, schon existiert. Die alten Varianten verblassen, statt herausgerissen zu werden. Und das Produkt, das ein paar Monate zuvor wie die Arbeit mehrerer Firmen aussah, sieht endlich aus wie es selbst.

Die Lektion, die ich immer wieder lerne: Ein Designsystem braucht keinen Neuanfang. Es braucht Geduld, eine klare Landkarte und die Bereitschaft, etwas zu verbessern, auf das sich Menschen schon verlassen, ohne sie je zum Anhalten zu bitten.