Ein lebendes Design System.
Wie dokumentiert man ein System, das sich ständig verändert? Arc ist das vollständige Design System für das fiktive Softwareunternehmen Meridian – konzipiert von Grund auf, mit besonderem Fokus auf die schwierigste Frage: Was passiert mit einer Komponentenseite, wenn sich die Komponente ändert?
Ausgangsfrage
Design Systems sind keine Bücher
Die meisten Dokumentationssysteme denken in Snapshots: eine Seite beschreibt eine Komponente, wie sie heute ist. Aber Designsysteme leben. Komponenten werden geändert, erweitert, manchmal zurückgebaut. Was passiert dann mit der Dokumentationsseite?
„Eine Komponentenseite ist kein Artikel. Sie ist ein Vertrag – und Verträge haben Versionen.“
Diese Frage war der Ausgangspunkt für Arc: Wie konzipiert man ein System, das Veränderung nicht als Ausnahme, sondern als Normalzustand behandelt?
Schwierigste Entscheidung
Versionierung auf Komponentenebene
Die größte konzeptionelle Herausforderung war die Struktur einer einzelnen Komponentenseite – nicht das Design, sondern die Informationsarchitektur dahinter.
Wie viel Historie zeigt man? Wer darf was sehen? Wie werden Breaking Changes von Fixes unterschieden? Und wie verhält sich die Seite, wenn eine Komponente als deprecated markiert wird?
onRowClick → onRowSelectDas Versionierungsmodell unterscheidet vier Change-Typen – Breaking, Feature, Fix, Deprecated – die direkt die Sichtbarkeit und Dringlichkeit in der Dokumentation steuern. Breaking Changes lösen automatisch eine Review-Pflicht aus.
Review-System
Änderungen brauchen Kontext
Neben der Versionierung war das Review-System die zweite große konzeptionelle Aufgabe: Wie können Designer und Entwickler Änderungen an Komponenten geordnet diskutieren und freigeben – ohne dass dieses Prozess die Arbeit verlangsamt?
Die Antwort: ein eigenständiger Review-Bereich, der nur für angemeldete Nutzer sichtbar ist. Er zeigt den Status jeder offenen Änderung, wer zuständig ist, und wie das Voting steht.
Warum ein eigener Review-Bereich statt Kommentare auf Komponentenseiten?
Kommentare auf Inhaltsseiten vermischen Dokumentation und Prozess. Der Review-Bereich trennt das: Komponentenseiten zeigen, was ist – der Review-Bereich zeigt, was sich ändert und was dazu zu sagen ist.
Wer darf reviewen?
Nur angemeldete Nutzer – das ist bewusst. Ein öffentliches Voting würde den Review-Prozess in eine Popularity-Contest verwandeln. Wer im System arbeitet, hat eine Stimme.
Web-Ansicht
So sieht Arc im Browser aus
Das Design System wurde als vollständige Web-Dokumentation umgesetzt: übersichtliche Navigation, kategorisierte Komponenten und klare Struktur für Designer und Entwickler.
KI-Interface
Die Ressourcen-Seite als Einstiegspunkt
Im Ressourcen-Bereich von Arc ist ein konversationales Interface eingebaut, das Nutzerinnen hilft, die richtigen Komponenten für ihr Projekt zu finden – ohne die gesamte Dokumentation durchsuchen zu müssen.
Das Interface ist kein Chatbot, der alle Fragen beantwortet. Es ist ein Navigations-Werkzeug: Es versteht Anfragen wie „Ich brauche eine Tabelle mit Inline-Editing" und antwortet mit einer Auswahl konkreter Komponenten und Muster – mit direktem Link in die Dokumentation. Der Kontext bleibt im System.
Diese Entscheidung – KI als Navigationshilfe, nicht als Antwortmaschine – ist eine bewusste Abgrenzung: Nutzerinnen sollen die Dokumentation besser kennenlernen, nicht von ihr entkoppelt werden.
Systemumfang
Was Arc umfasst
Reflexion
Was ich mitgenommen habe
- GelerntEin Designsystem zu konzipieren bedeutet, zuerst zu entscheiden, was es nicht sein soll. Die Entscheidung gegen Freitext-Kommentare auf Komponentenseiten war genauso wichtig wie alle positiven Designentscheidungen.
- BestätigtInformationsarchitektur ist Designarbeit. Die schwierigsten Stunden bei Arc waren keine UI-Fragen, sondern Strukturfragen: Was ist eine Komponente, was ist ein Muster, was ist ein Layout?
- TransferierbarDie Versionierungslogik und das Review-System lassen sich direkt auf reale B2B-Produktteams übertragen – sie lösen ein Problem, das jedes Unternehmen mit einem gewachsenen Designsystem kennt.
- OffenWie skaliert das Review-System mit wachsender Teamgröße? Ab einer bestimmten Anzahl Reviewer wird Voting allein nicht mehr ausreichen – Rollen und Rechte wären der nächste Schritt.