Ein Designsystem am Leben halten: Verantwortung, Schulden und kleine regelmäßige Korrekturen

Warum Systeme verblassen

Ein Designsystem ist beim Launch leicht zu bewundern. Alles ist neu, dokumentiert und stimmig, und jedes Team übernimmt es gern. Dann beginnt die eigentliche Arbeit. Eine Deadline drängt, eine Komponente ist fast richtig, und Kopieren scheint schneller als eine Änderung anzufragen. Niemand macht etwas falsch, und doch driftet das System ein Stück weiter von den Produkten weg, denen es dienen sollte.

Die Abkürzung selbst ist nicht das Problem; Abkürzungen sind eher ein Beleg dafür, dass geliefert wird. Das Problem ist, dass niemand sieht, wie sie sich anhäufen, und niemand dafür verantwortlich ist, sie zusammenzuführen.

Jemand muss es verantworten

Ein System braucht eine einzige, klar benannte Verantwortung, kein Komitee oder, schlimmer, „alle“. Wer es verantwortet, entscheidet, was in die Bibliothek kommt, was sich ändert und was draußen bleibt, und darf Nein sagen. Das heißt nicht, die ganze Arbeit allein zu machen. Es heißt, dass jede Frage eine Adresse hat und jede Entscheidung einen Namen.

Wenn alle die Verantwortung teilen, gehört sie in der Praxis niemandem, und die Bibliothek wird nach und nach zu einem Lager guter Absichten.

Schulden sind normal, Schweigen nicht

Jedes lebendige System sammelt Schulden an: Overrides, abgelöste Instanzen, fest codierte Werte, Komponenten für das Problem vom letzten Jahr. Ich sehe das nicht als Scheitern. Ich sehe es als Information, als Aufzeichnung darüber, wo das System nicht mehr zur Arbeit passt. Wichtig ist, dass die Schulden sichtbar sind, an einem Ort festgehalten, den alle einsehen können, statt im Gedächtnis von irgendjemandem zu leben.

Kleine Korrekturen, jeden Sprint

Die Gewohnheiten, die ein System am Leben halten, sind unspektakulär, und das ist Absicht. Ein bescheidener Teil jedes Sprints gehört dem System statt neuen Features, und er bleibt dort, auch wenn die Deadline drängt. Jede Änderung kommt mit einem Satz zum Warum ins Changelog, damit die Produkte ihr mit Zuversicht statt mit Angst folgen können.

Die Bibliothek hat auch einen eigenen Ort zum Lernen, mit Beispielen und Regeln, damit jemand Neues nicht auf ein Meeting warten muss, um anzufangen. Und bevor etwas Neues aufgenommen wird, suche ich etwas Altes, das in den Ruhestand kann. Ein schlankeres System lässt sich einfach leichter am Leben halten.

Was sich ändert

Teams hören auf, um das System herumzuarbeiten, weil eine Änderung anzufragen schneller wird als eine Komponente zu kopieren. Updates verlieren ihren Schrecken, weil jedes klein und erklärt ist. Und das System behält seinen Wert lange nach dem Launch, was letztlich der einzige Grund ist, eines zu bauen.

Bei meinem letzten großen Projekt lief die Bibliothek als eigener Lernraum neben den Produkten, und jede Änderung kam mit einer kurzen Begründung ins Changelog. Neue fanden Antworten selbst, und die Produkte konnten der Bibliothek ohne störende Migration folgen.

Wann ein Neubau die richtige Wahl ist

Gelegentlich reichen kleine Korrekturen nicht. Wenn das Fundament selbst fehlerhaft ist, etwa Tokens, die Bedeutung und Wert vermischen, oder Komponenten für ein Produkt, das es nicht mehr gibt, verbreitet Flicken das Problem nur weiter. Dann baue ich einmal neu, sorgfältig, und etabliere die Gewohnheiten, die einen zweiten Neubau überflüssig machen.

Ein Designsystem ist nie fertig. Das klingt vielleicht anstrengend, ist aber eigentlich eine gute Nachricht: Es bedeutet, dass Menschen es noch benutzen.