Wann braucht Ihr Produkt ein Designsystem? Und was gehört in die erste Version?

Die meisten Produkte starten ohne Designsystem, und das ist richtig so. In den ersten Wochen geht es darum herauszufinden, ob das Produkt für irgendjemanden funktioniert. Aber es kommt ein Punkt, an dem das Fehlen eines Systems echte Zeit und echtes Geld kostet, meist lange bevor es jemand ausspricht.

Dieser Artikel erklärt, was ein Designsystem eigentlich ist, woran Sie merken, dass Ihr Produkt eines braucht, wann es noch zu früh ist und was eine sinnvolle erste Version enthält.

Was ein Designsystem eigentlich ist

Ein Designsystem ist das gemeinsame Regelwerk und der Baukasten, aus dem ein Produkt entsteht. Es hat drei Ebenen:

• Grundlagen, oft Design Tokens genannt: Farben, Typografie, Abstände, Eckenradien, Schatten und Motion, jeweils mit einem Namen und einem eindeutig festgelegten Wert.
• Komponenten: Buttons, Eingabefelder, Tabellen, Dialoge, Navigation und die übrigen Bausteine, inklusive aller Zustände, die sie haben können.
• Guidelines: wann welche Komponente zum Einsatz kommt, wie Beschriftungen und Fehlermeldungen formuliert werden und welche Barrierefreiheitsregeln jeder Screen erfüllen muss.

Tokens sind inzwischen ein eigener Standard. Die W3C Design Tokens Community Group hat im Oktober 2025 die erste stabile Version ihrer Design-Tokens-Spezifikation veröffentlicht, ein gemeinsames Format, das Design- und Entwicklungstools lesen können. Das ist wichtig, denn ein Designsystem nützt nur, wenn Design und Code dieselben Werte verwenden.

Woran Sie merken, dass Ihr Produkt jetzt eines braucht

• Die Oberfläche driftet auseinander. Drei leicht unterschiedliche Grautöne, vier Button-Stile, Formulare, die Fehler jeweils anders behandeln. Niemand hat das entschieden; es ist Feature für Feature entstanden.
• Jedes Feature beginnt damit, die Grundlagen neu zu zeichnen. Design und Entwicklung bauen Tabellen, Filter und Dialoge immer wieder neu, statt am eigentlichen Problem zu arbeiten.
• Mehr Leute arbeiten am Produkt. Ein zweiter Entwickler, eine neue Designerin oder ein externes Team füllen Lücken jeweils mit eigenen Entscheidungen.
• Eine zweite Oberfläche kommt dazu. Eine Web-App neben einer mobilen App oder eine Marketing-Website, die wie das Produkt aussehen soll, braucht gemeinsame Grundlagen, damit alles wie eine Marke wirkt.
• Sie erzeugen Screens oder Inhalte mit KI. Ohne Regeln sieht jedes Ergebnis etwas anders aus. Ein Markenfundament und ein kleines Designsystem geben generierter Arbeit etwas, dem sie folgen kann. Genau deshalb liefert unsere Deck Engine für Caya Folien, die maßgeschneidert wirken.
• Eine produktweite Änderung steht an. Dark Mode, ein Rebranding, White-Label-Versionen oder Barrierefreiheit werden zu einer Änderung an den Tokens statt zu einer Suche durch Hunderte Screens.

Wann es noch zu früh ist

Wenn Sie gerade testen, ob eine Idee überhaupt funktioniert, lenkt ein vollständiges Designsystem ab. Eine Bibliothek mit fünfzig ausgefeilten Komponenten für ein Produkt, das im nächsten Monat vielleicht die Richtung wechselt, ist Geld für die falsche Frage.

Eine Gewohnheit lohnt sich aber vom ersten Tag an: Farben, Schriften und Abstände im Code als benannte Werte definieren, statt sie in jede Komponente zu kopieren. Das kostet fast nichts und entscheidet darüber, ob Sie Dark Mode oder eine neue Markenfarbe an einem Nachmittag ergänzen oder später die Oberfläche neu schreiben.

Was eine sinnvolle erste Version enthält

Ein erstes Designsystem muss nicht groß sein. Es muss abdecken, was Ihr Produkt heute tatsächlich nutzt, und das gründlich:

• Tokens für Farbe, Typografie, Abstände, Radien und Ebenen, mit Namen, die den Zweck beschreiben (etwa text-muted oder surface-raised) statt des Werts.
• Die Komponenten, die Ihre Screens heute verwenden, jeweils mit allen Zuständen: Standard, Hover, Fokus, deaktiviert, Laden, Fehler und leer.
• Die Muster, die sich im Produkt wiederholen, etwa Formulare, Tabellen mit Filtern sowie Leer- und Fehlerseiten.
• Grundlagen der Barrierefreiheit von Anfang an: ausreichender Kontrast, sichtbare Fokuszustände, Touch-Flächen, die groß genug für echte Finger sind.
• Kurze Nutzungshinweise, damit die nächste Person weiß, welche Komponente sie wählen sollte und warum.

Figma-Bibliothek oder Code? Beides, aus einer Quelle

Der häufigste Fehler, den wir sehen, ist eine schöne Figma-Bibliothek, an die sich der Code nicht hält. Die Designs sagen das eine, das Produkt tut etwas anderes, und nach ein paar Monaten vertraut niemand mehr beidem.

Deshalb werden in unserer App-Entwicklung Farben, Schriften und Komponenten einmal definiert und in Figma wie im Code verwendet. So wirken neue Funktionen, als wären sie schon immer da gewesen. Bei neuen Produkten wächst das System aus Komponenten, die es im Code schon gibt, wie wir in unsere Produktarbeit beginnt im Code beschreiben. Es bleibt synchron mit dem, was live geht, weil es aus dem besteht, was live geht.

Wie das in der Praxis aussieht

Für Ankaadia haben wir eine Relocation-Plattform über mehr als 150 Screens neu gestaltet und ein Designsystem von Grund auf für das Entwicklungsteam aufgebaut. Es umfasst Grundlagen wie Tokens, Styles und Accessibility-Guidelines sowie eine Komponentenbibliothek, die jedes Interface-Muster der App abdeckt. So geht die Umsetzung schneller, und die Oberfläche bleibt konsistent, während das Produkt wächst.

Nicht jedes System muss so groß sein. Für Elea haben wir Farben, Typografie, Grafik, Motion und Komponenten der Website dokumentiert und dem Team so einen praktischen Leitfaden für die weitere Arbeit am Webauftritt gegeben.

Fragen, bevor Sie ein Designsystem beauftragen

• Wird das System im Code existieren oder nur als Figma-Datei?
• Entsteht es aus unseren echten Screens und Anwendungsfällen oder aus einem generischen Kit?
• Deckt es Zustände, Fehler und Barrierefreiheit ab oder nur den Idealfall?
• Wer pflegt es nach der Übergabe, und wie kommen neue Komponenten dazu?
• Können unsere eigenen Entwickler es ohne Sie nutzen?

Ein Designsystem ist kein Ergebnis, das irgendwann fertig ist. Es ist der Teil des Produkts, der jede spätere Änderung günstiger macht. Wenn Sie eine Plattform planen oder Ordnung in eine gewachsene bringen möchten, zeigt unsere Seite zu Webanwendungen, wie wir Produktdesign und Entwicklung gemeinsam angehen.