Designsystem statt Pixel-Pingpong

Das eigentliche Problem sind nicht die Pixel

Viele digitale Teams verlieren Zeit in kleinen Wiederholungen: Welcher Abstand gilt hier? Ist dieser Button noch derselbe? Wie verhält sich die Karte auf dem Handy? Was passiert bei einem Fehler? Design liefert eine Variante, Entwicklung interpretiert sie, später entsteht eine zweite — und irgendwann gibt es sechs fast gleiche Lösungen.

Das wird oft als Abstimmungsproblem behandelt. Tatsächlich fehlt meist ein gemeinsames Produktvokabular.

Ein Designsystem schafft dieses Vokabular. Es verbindet visuelle Regeln, wiederverwendbare Komponenten, Inhaltsprinzipien und dokumentiertes Verhalten. Entscheidend ist nicht, wie umfangreich die Bibliothek aussieht, sondern ob Design und Code dieselbe Entscheidung wiederverwenden können.

Mit den häufigsten Entscheidungen beginnen

Ein Designsystem muss nicht mit hundert Komponenten starten. Für viele Produkte reichen zunächst wenige belastbare Grundlagen:

• Farben mit klarer Funktion statt bloßer Farbnamen
• Typografie mit definierten Hierarchien
• Abstände und Raster
• Buttons, Eingaben, Karten und Navigation
• Zustände wie Laden, Fehler, leer, aktiv und deaktiviert
• Regeln für responsive Verhalten

Der Wert entsteht, wenn diese Grundlagen tatsächlich in Figma und Code übereinstimmen. Ein perfekt dokumentierter Button, der im Produkt anders implementiert ist, ist keine Wahrheit — nur eine weitere Datei.

Komponenten brauchen Grenzen

Wiederverwendbarkeit bedeutet nicht, jede denkbare Variante in eine Mega-Komponente zu packen. Gute Komponenten lösen eine wiederkehrende Aufgabe und machen erlaubte Unterschiede sichtbar.

Ein Button kann beispielsweise Größe, Gewichtung, Icon und Ladezustand variieren. Er sollte aber nicht gleichzeitig Navigation, Modal, Download und Formularlogik verstecken. Je klarer Verantwortung und Schnittstelle sind, desto leichter lassen sich Komponenten testen, kombinieren und später verändern.

Dasselbe gilt für Inhalte. Wenn eine Karte nur mit einer exakt zweizeiligen Überschrift funktioniert, ist das keine robuste Komponente. Ein System muss mit echten Textlängen, fehlenden Bildern, langen Sprachen und kleinen Bildschirmen umgehen können.

Dokumentation gehört in die Arbeit

Dokumentation scheitert, wenn sie als Extra-Projekt nach dem Launch geplant wird. Besser ist eine kurze Definition direkt bei der Komponente: Wofür ist sie gedacht? Welche Varianten gibt es? Welche Kombinationen sind nicht erlaubt? Wie reagiert sie auf unterschiedliche Bildschirmgrößen und Eingabemethoden?

Screenshots allein reichen nicht. Gute Dokumentation zeigt Verhalten. Dazu gehören Tastaturbedienung, Fokus, Touch-Flächen, Ladezeiten, Fehlermeldungen und reduzierte Bewegung.

Wann sich ein Designsystem lohnt

Ein einmaliger Onepager braucht selten eine große Bibliothek. Ein wachsendes Produkt, mehrere Markenflächen oder ein Team mit wiederkehrenden Releases dagegen fast immer.

Ein guter Zeitpunkt ist erreicht, wenn dieselben Entscheidungen mehrfach diskutiert werden, ähnliche Elemente auseinanderlaufen oder kleine Änderungen an vielen Stellen manuell nachgezogen werden müssen. Dann kostet das fehlende System bereits mehr als sein Aufbau.

Ein System ist ein Produkt

Designsysteme bleiben nur wertvoll, wenn jemand ihre Qualität verantwortet. Veraltete Komponenten müssen entfernt, neue Muster geprüft und Änderungen verständlich kommuniziert werden.

Das Ziel ist nicht maximale Einheitlichkeit. Das Ziel ist, Routineentscheidungen zuverlässig zu lösen, damit das Team seine Energie auf die besonderen Probleme des Produkts richten kann.