Was ist ein Design System? Warum Unternehmenswebsites eines brauchen

Arbeiten drei Teams gleichzeitig an einer Unternehmenswebsite, finden Sie nach ein paar Monaten vier Blautöne, sechs Buttonvarianten und Formulare, die sich überall anders verhalten. Ein Design System stoppt genau diesen Wildwuchs. Ich arbeite seit 2012 an Webprojekten für Unternehmen. In diesem Beitrag betrachte ich das Design System deshalb nicht als Toolthema, sondern als gemeinsame Infrastruktur für Entscheidungen.

Was ist ein Design System?

Ein Design System ist eine gemeinsame Quelle, die zentrale Gestaltungsentscheidungen wie Farbe, Typografie und Abstände, die daraus gebauten wiederverwendbaren Komponenten, die Regeln für ihren Einsatz und den Prozess für Änderungen festlegt. Kurz gesagt nutzen Design und Entwicklung damit dieselbe Entscheidung unter demselben Namen.

Entscheidend ist dabei das Wort "lebendig". Ein PDF, das nach der Übergabe niemand mehr öffnet, ist also kein Design System. Ein echtes System hat Code, eine Versionshistorie und einen klaren Verantwortlichen. Das GOV.UK Design System der britischen Regierung zeigt das gut. Dort erklärt jede Komponentenseite, wann Sie sie einsetzen, wann nicht und welche Hinweise zur Barrierefreiheit gelten. Somit funktioniert das System als gemeinsame Sprache für öffentliche Dienste und nicht nur als Bildbibliothek.

Aus welchen Ebenen besteht ein Design System?

Fast jedes funktionierende System, das ich in der Praxis gesehen habe, trägt vier Ebenen zugleich. Fehlt eine, verfallen die anderen mit der Zeit. Deshalb empfehle ich, die Einführung entlang dieser vier Punkte zu planen:

• Design Tokens: benannte Werte für die kleinsten Entscheidungen, etwa Farbe, Schriftgröße, Abstand, Radius, Schatten und Bewegung.
• Komponentenbibliothek: Buttons, Eingabefelder, Karten, Dialoge und Tabellen, die es sowohl in der Designdatei als auch im Code gibt.
• Dokumentation: Zweck, Varianten, richtige und falsche Beispiele, Hinweise zur Barrierefreiheit und Textregeln für jede Komponente.
• Governance: wer was ändern darf, wie neue Vorschläge geprüft werden und wie Releases die Teams erreichen.

Allerdings hängt das Gewicht jeder Ebene vom Unternehmen ab. Bei einem einzelnen Produkt stehen Tokens und Komponenten im Vordergrund. In einer Gruppe mit mehreren Marken tragen dagegen Governance und Theming die Hauptlast. Trotzdem gilt: Bleibt eine Ebene leer, wird das System zu einem Archiv, dem niemand vertraut.

Worin unterscheidet sich ein Design System von Styleguide und UI Kit?

Diese drei Begriffe geraten in Meetings ständig durcheinander. Dabei beeinflusst der Unterschied Budget und Erwartungen direkt. Ein Styleguide beschreibt meist die visuellen Regeln der Marke. Ein UI Kit hingegen enthält fertige Bausteine in einer Designdatei. Das Design System umfasst beides und ergänzt Code, Dokumentation und Prozesse.

Anders gesagt: Eine saubere Figma Bibliothek bedeutet noch kein Design System. Den eigentlichen Arbeitsablauf in Figma beschreibe ich im Beitrag Webdesign mit Figma Schritt für Schritt. Hier geht es stattdessen um die organisatorische Ebene darüber.

Was sind Design Tokens und warum sind sie so wichtig?

Ein Design Token ist die benannte, plattformunabhängige Form einer Gestaltungsentscheidung. Statt "#0B5FFF" schreiben Sie "color.brand.primary". Somit wird dieselbe Entscheidung auf der Website zur CSS Variable, in der App zur Plattformkonstante und in der Designdatei zum Stil.

In diesem Bereich gab es zudem einen wichtigen Schritt. Die Design Tokens Community Group beim W3C hat im Oktober 2025 die erste stabile Version ihrer Spezifikation für das Tokenformat (2025.10) angekündigt. Laut Ankündigung unterstützt das Format Theming, mehrere Marken, moderne Farbräume und Verweise zwischen Tokens. Außerdem haben Werkzeuge wie Figma, Penpot und Sketch Unterstützung angekündigt oder bereits umgesetzt.

Was heißt das konkret für Sie? Speichern Sie Tokens im Standardformat, behalten Sie Ihre Entscheidungen auch beim Wechsel des Werkzeugs. Daher ist die Tokenebene meist der langlebigste und portabelste Teil des Systems.

In welche Stufen sollten Sie Tokens gliedern?

Eine flache Farbliste funktioniert am Anfang. Kommt dann eine zweite Marke oder ein dunkles Theme, bricht sie zusammen. Deshalb baue ich Tokens in Unternehmensprojekten in drei Stufen auf:

1. Basistokens: Rohwerte wie "blue.600" oder "space.4". Sie tragen keine Bedeutung und definieren nur die Palette.
2. Semantische Tokens: Sie beschreiben den Zweck, etwa "background.accent" oder "text.error", und verweisen auf Basistokens.
3. Komponententokens: Sie gehören zu genau einer Komponente, etwa "button.primary.background", und verweisen meist auf ein semantisches Token.

Der Nutzen zeigt sich beim Themewechsel. Für ein dunkles Theme ändern Sie nicht den Komponentencode, sondern nur die Zuordnung der semantischen Tokens. Allerdings ist es ebenfalls ein Fehler, alles in Komponententokens zu verwandeln, denn der Pflegeaufwand wächst schnell. In der Praxis bewährt sich eine reiche semantische Stufe und eine schlanke Komponentenstufe.

Beim Aufbau der Palette können Sie Farbtöne und Kontraste mit dem Tool HTML Farbcodes testen.

Wie planen Sie die Komponentenbibliothek?

In der Komponentenbibliothek werden Tokens zu echten Bildschirmen. Brad Frosts Ansatz Atomic Design liefert dafür ein hilfreiches Denkmodell. Sie beginnen mit kleinen Teilen, den Atomen, und bauen dann Moleküle, Organismen, Vorlagen und Seiten. Ich nutze das Modell allerdings weniger als starres Rezept, sondern eher als gemeinsames Vokabular.

Für die erste Bibliothek empfehle ich folgende Reihenfolge. Zunächst die meistgenutzten Teile: Buttons, Links, Eingabefelder und Hinweisboxen. Danach inhaltstragende Bausteine wie Karten, Listen, Tabellen und Tabs. Schließlich Seitenlayouts wie Kopfbereich, Navigation, Fußzeile und Formularvorlagen.

Designdatei und Code müssen bei jeder Komponente dieselben Namen, Varianten und Zustände tragen, also Hover, Fokus, deaktiviert und Fehler. Heißt ein Button im Design "Primary Large" und im Code "btn_main_lg", entstehen innerhalb weniger Monate zwei verschiedene Buttons. Zudem bemerken Sie die Abweichung oft erst durch eine Kundenbeschwerde.

Was gehört in die Dokumentation?

Die Dokumentation ist die Ebene, die ich am häufigsten vernachlässigt sehe. Teams bauen eine Komponente und sagen dann, sie sei ja in Figma. Eine neue Entwicklerin oder eine externe Agentur trifft die richtige Entscheidung jedoch nur mit schriftlichen Regeln.

Auf einer guten Komponentenseite suche ich deshalb Folgendes:

• Einen Satz zum Zweck der Komponente.
• Einen klaren Abschnitt, wann Sie sie einsetzen und wann nicht.
• Ein Livebeispiel und kopierbaren Code.
• Richtige und falsche Beispiele.
• Tastaturbedienung, Fokusreihenfolge und Hinweise für Screenreader.
• Textregeln für Buttonbeschriftungen und Fehlermeldungen.
• Versionshistorie und eine verantwortliche Person.

Vor allem die Textregeln machen einen großen Unterschied. Auf vielen Websites erledigen "Absenden", "Speichern", "OK" und "Weiter" dieselbe Aufgabe. Diese Uneinheitlichkeit kostet außerdem Conversions. Beispiele dazu finden Sie im Beitrag über Call to Action Buttons.

Warum scheitert ein Design System ohne Governance?

Governance legt fest, wer das System ändert und über welchen Prozess. Das klingt bürokratisch. Trotzdem habe ich oft gesehen, was ohne sie passiert. Jedes Team baut die Variante, die es braucht, im eigenen Code. Nach einem Jahr liegen in der Bibliothek Komponenten, die niemand nutzt, und in den Projekten Kopien, die die Bibliothek nie gesehen hat.

Daher verlange ich zu Beginn schriftliche Antworten auf einige Fragen. Wer darf eine neue Komponente vorschlagen? Wer prüft den Vorschlag, und innerhalb welcher Frist? Wie kündigen Sie eine inkompatible Änderung an? Wie lange unterstützen Sie eine alte Version? Fehlen diese Antworten, hängt das System an Einzelpersonen und bleibt stehen, sobald sie gehen.

Andererseits schadet auch zu strenge Governance. Warten Produktteams für jede Kleinigkeit wochenlang, finden sie Wege um das System herum. Das gesunde Gleichgewicht ist also ein Prozess, der Beiträge zulässt und die Qualität trotzdem klar sichert.

Welches Governance Modell passt zu Ihnen?

Nathan Curtis, eine bekannte Stimme auf diesem Gebiet, beschreibt drei verbreitete Modelle: solitär, zentral und föderiert. Je nach Unternehmensgröße lese ich sie so:

• Zentral: Ein eigenes Team pflegt die Bibliothek, Produktteams nutzen sie. Die Qualität bleibt hoch, allerdings kann das Kernteam zum Engpass werden.
• Föderiert: Mitglieder mehrerer Produktteams tragen bei. Die Verantwortung verteilt sich, dafür braucht es Abstimmung.
• Hybrid: Ein kleines Kernteam hütet das Fundament, Produktteams tragen über einen festen Prozess bei. In mittleren und großen Unternehmen funktioniert dieses Modell am häufigsten.

Egal welches Modell Sie wählen, Sie brauchen einen schriftlichen Leitfaden für Beiträge und ein regelmäßiges Review. Zum Beispiel reicht ein kurzer Termin alle zwei Wochen meist aus, um offene Vorschläge abzuarbeiten. Dieser Rhythmus ist ein Startwert aus der Praxis, keine Garantie.

Warum ist ein Design System für Unternehmenswebsites unverzichtbar?

Unternehmensprojekte haben eine Gemeinsamkeit: Kein einzelnes Team baut die ganze Website. Das Marketing startet Kampagnenseiten, das Produktteam entwickelt das Kundenportal, eine Agentur liefert die Karriereseite, und die Personalabteilung will ein Bewerbungsformular. Ohne Design System trifft jedes dieser Teams eigene Entscheidungen.

Folglich entstehen drei Probleme. Erstens eine uneinheitliche Marke: Nutzer fühlen sich, als wechselten sie zwischen verschiedenen Firmen. Zweitens Tempoverlust, denn jedes Team gestaltet und testet Buttons, Formulare und Tabellen neu. Drittens Qualitätslücken, weil ein Team Regeln zu Barrierefreiheit und Performance einhält und das andere sie vergisst.

Ein Design System löst alle drei zugleich, denn Sie treffen eine Entscheidung einmal und nutzen sie überall. Deshalb sehe ich es im Unternehmensmaßstab als Infrastruktur und nicht als Luxus. In meinen Webdesign Projekten mit mehreren Teams gehören Tokens und Basiskomponenten daher zu den ersten Lieferungen.

Wie sichert es Einheitlichkeit über viele Teams hinweg?

Einheitlichkeit entsteht, wenn alle dieselbe Quelle nutzen. Das System verpackt diese Quelle. Teams kopieren keine Komponenten mehr, sondern binden sie aus einem versionierten Paket ein. Somit erreicht eine Farbkorrektur oder ein neuer Fokusstil alle Projekte, sobald das Paket aktualisiert ist.

Hier passiert allerdings ein typischer Fehler. Man veröffentlicht das Paket und wartet einfach, bis alle aktualisieren. In stressigen Phasen schieben Produktteams Updates auf, und die Projekte laufen auf unterschiedlichen Versionen. Deshalb empfehle ich einen festen Updatekalender mit Release Notes und ein klares Enddatum für alte Versionen.

In der Architektur zeigt sich dasselbe Muster. Teilen Sie das Frontend in unabhängige Teile, hält nur ein gemeinsames System die visuelle Sprache zusammen. Diesen Zusammenhang beleuchte ich im Beitrag über Micro Frontends.

Beschleunigt ein Design System Projekte wirklich?

Die kurze Antwort lautet ja, aber nicht ab dem ersten Tag. In der Aufbauphase wird das Team zunächst langsamer, denn es sichtet bestehende Seiten, diskutiert Entscheidungen und schreibt Komponenten neu. Der Zeitgewinn zeigt sich meist erst, wenn das System steht und einige Projekte es nutzen.

In meiner Erfahrung kommt das Tempo aus drei Quellen. Erstens setzen Designer fertige Komponenten zusammen, statt bei null zu zeichnen. Zweitens verbringen Entwickler weniger Zeit mit Fehlersuche, weil sie getestete Teile nutzen. Drittens werden Reviewrunden kürzer, denn die Diskussion über abweichende Buttons entfällt.

Trotzdem nenne ich keinen festen Prozentwert. Die Größe des Gewinns hängt von der Zahl der Teams, der Vielfalt der Seiten und der tatsächlichen Nutzung ab. Messen Sie den Effekt also, statt ihn zu behaupten. Weiter unten finden Sie dafür passende Kennzahlen.

Wie wirkt sich ein Design System auf Barrierefreiheit aus?

Barrierefreiheit ist einer der stärksten Hebel eines Systems. Bauen Sie eine Komponente einmal korrekt, erbt jede Seite, die sie nutzt, dieselbe Qualität. Löst die Bibliothek zum Beispiel Fokusanzeige, Formularlabels und die Verknüpfung von Fehlermeldungen, müssen Produktteams nicht jedes Mal daran denken.

Als Referenz nutze ich die WCAG 2.2 des W3C. Die Richtlinien definieren prüfbare Erfolgskriterien, unter anderem für Textkontrast, Tastaturbedienung, sichtbaren Fokus und Zielgröße. Diese Kriterien auf Tokenebene für Farbpaare und auf Komponentenebene für Tastaturverhalten zu testen, ist deutlich effizienter als Korrekturen Seite für Seite.

Allerdings reicht das System allein nicht. Man kann die richtige Komponente immer noch im falschen Kontext einsetzen. Schreiben Sie daher Hinweise zur Barrierefreiheit direkt in die Dokumentation, und schulen Sie auch die Redaktionsteams kurz.

Was bringt es für SEO und Performance?

Ein Design System ist kein direkter Rankingfaktor, denn Google weiß nicht, ob Sie eines haben. Die Nebenwirkungen zeigen sich jedoch in SEO und Nutzererfahrung. Eine einheitliche Überschriftenhierarchie, Komponenten mit semantischem HTML und kontrollierte CSS Größe schaffen auch für Suchmaschinen eine saubere Basis.

Bei der Performance ist der deutlichste Gewinn weniger doppelter Style und Scriptcode. Schreibt jedes Team eigene Buttonstile, wachsen die CSS Dateien. Gemeinsame Komponenten optimieren Sie dagegen an einer Stelle. Geben Sie der Bildkomponente zum Beispiel ein festes Seitenverhältnis, verringern Sie Layoutverschiebungen auf der gesamten Website auf einmal.

Mehr dazu lesen Sie in meinen Beiträgen wie die Ladezeit SEO beeinflusst und SEO und UX. Zusammengefasst ist ein System der praktischste Weg, technische SEO Regeln fest in Komponenten einzubauen.

Wie hängen Markenidentität und Design System zusammen?

Die Markenidentität legt fest, wie ein Unternehmen aussieht und spricht. Das System übersetzt diese Identität in Regeln für digitale Produkte. Die Brücke bilden die Tokens: Markenfarbe, Schrift und Bildsprache gelangen als Tokens ins System.

Ein häufiges Problem: Das gedruckte Corporate Design hat kein Gegenstück am Bildschirm. So liefert eine Markenfarbe aus dem Printhandbuch als Textfarbe auf Weiß womöglich zu wenig Kontrast. Dann sollte das System bildschirmtaugliche semantische Töne ableiten, ohne die Marke zu brechen. Diesen Weg beschreibe ich im Beitrag Corporate Design digital umsetzen.

Planen Sie Markenarbeit und Systemaufbau deshalb nicht als getrennte Projekte, sondern als zwei Phasen, die sich gegenseitig speisen. Jede Entscheidung aus der Arbeit an der Markenidentität sollte ein Token im System finden.

Wie gehen Sie mit Themes und mehreren Marken um?

In Unternehmensgruppen sehe ich oft dieses Szenario: Eine Dachmarke, zwei Tochtermarken und eine Kampagnenmarke wollen dieselbe Plattform nutzen. Bauen Sie für jede eine eigene Bibliothek, vervielfacht sich der Pflegeaufwand mit jeder Marke. Gemeinsame Komponenten und nur eine austauschbare Themeebene sind dagegen deutlich nachhaltiger.

In der Praxis bringt jede Marke ihre eigene Basispalette und Schrift mit. Die semantischen Tokens behalten in allen Marken denselben Namen; nur ihre Zuordnung ändert sich. So erhält "text.primary" in jeder Marke die richtige Farbe, während der Komponentencode einmalig bleibt.

Der Dark Mode folgt derselben Logik. Verstehen Sie ihn trotzdem nicht als bloß invertierte Farben. Sie müssen die Kontraste für jedes Theme eigens prüfen und auch Schatten und Ebenen neu denken. Halten Sie die Zahl der Themes also so klein wie nötig, denn jedes neue Theme bedeutet eine weitere Kombination zum Testen.

Wie arbeiten Sie mit externen Agenturen und Dienstleistern?

In Unternehmensprojekten übernehmen externe Agenturen einen großen Teil der Arbeit. Die Kampagnenseite kommt von einer Agentur, die App von einem anderen Team, die Karriereseite von einem dritten Dienstleister. Ohne gemeinsame Quelle setzt jeder die Marke nach eigenem Verständnis um.

Deshalb empfehle ich, das System zum Vertragsbestandteil zu machen. Geben Sie der Agentur schon in der Angebotsphase Zugang zur Bibliothek. Lassen Sie sich bei der Abnahme zudem auflisten, welche Komponenten sie genutzt und welche neuen Teile sie gebaut hat. Sind die neuen Teile nützlich, übernehmen Sie sie über den Beitragsprozess in die Bibliothek.

Dieser Ansatz verkürzt außerdem die Einarbeitung. Eine neue Agentur arbeitet dank schriftlicher Regeln und fertiger Komponenten schon in der ersten Woche produktiv. Kurz gesagt senkt ein gut dokumentiertes System auch die Kosten eines Dienstleisterwechsels.

Wie sollten Sie Versionen und Änderungen steuern?

Führen Sie das Komponentenpaket wie jedes Softwarepaket. Am verbreitetsten ist semantische Versionierung: Kleine Korrekturen erscheinen als Patch, abwärtskompatible Neuerungen als Minor Release und inkompatible Änderungen als Major Release. So erkennen Teams das Risiko eines Updates schon an der Versionsnummer.

Veröffentlichen Sie dann zu jedem Release kurze, klare Änderungshinweise. Nennen Sie, was sich geändert hat, wen es betrifft und was Teams für die Umstellung tun müssen. Gerade bei inkompatiblen Änderungen hilft es, das alte Verhalten eine Weile mit Warnung weiterzuführen. Zum Beispiel können Sie eine alte Komponente über ein Übergangsrelease mit Konsolenwarnung etwa zwei Monate lang behalten. Dieser Zeitraum ist ein Erfahrungswert, keine Garantie.

Außerdem empfehle ich visuelle Regressionstests in der Pipeline. Automatische Screenshotvergleiche zeigen, welche Seiten eine Tokenänderung betrifft, und ersparen Ihnen Überraschungen im Livebetrieb.

Wie bringen Sie Teams dazu, das System zu nutzen?

Selbst die beste Bibliothek ist wertlos, wenn niemand sie nutzt. Akzeptanz ist daher weniger eine technische Frage als eine Frage von Menschen und Gewohnheiten. Teams wechseln erst, wenn sie sehen, dass ihre Arbeit leichter wird.

Veranstalten Sie deshalb praktische Sessions statt einer Ankündigungsmail. Überführen Sie mit jedem Produktteam gemeinsam eine seiner eigenen Seiten ins System. So lernt das Team die Komponenten kennen und meldet Lücken aus erster Hand. Zudem sorgt eine feste Ansprechperson pro Team dafür, dass Fragen über einen Kanal laufen.

Zwang bringt dagegen selten Akzeptanz. Statt eigene Komponenten im Code Review zu verbieten, fragen Sie besser, warum das Team eine brauchte. Oft zeigt diese Frage eine Variante, die in der Bibliothek fehlt. Jede Ausnahme ist also ein Datenpunkt, um das System zu verbessern. Ein regelmäßiger Updatekanal, kurze Demovideos und eine sichtbare Roadmap stärken außerdem das Vertrauen.

Mit welchen Kennzahlen messen Sie den Erfolg?

Wer in ein System investiert, will zu Recht Ergebnisse sehen. Starten Sie deshalb schon beim Aufbau einige einfache Messungen:

• Nutzungsquote: Anteil der Bibliothekskomponenten gegenüber selbst gebauten Komponenten in Projekten.
• Versionsverteilung: wie viele Projekte die aktuelle Version nutzen.
• Lieferzeit: wie lange eine vergleichbare Seite vom Design bis zum Livegang braucht, vorher und nachher.
• Oberflächenfehler: Zahl der Fehler zu visueller Uneinheitlichkeit und Barrierefreiheit.
• Beiträge: Vorschläge und Pull Requests aus den Produktteams.

Sammeln Sie diese Werte in einem Dashboard und prüfen Sie sie einmal im Quartal. Dann sehen Sie, ob das System wirklich genutzt wird und welcher Bereich Unterstützung braucht. Die Logik aus meinem Beitrag über Online Marketing KPIs gilt auch hier: wenige Kennzahlen, aber solche, die Entscheidungen auslösen.

Welche Fehler passieren bei einem Design System am häufigsten?

Über die Jahre habe ich dieselben Fehler in verschiedenen Unternehmen immer wieder gesehen. Am häufigsten begegnen mir diese:

• Das System als einmaliges Projekt übergeben und ohne Verantwortlichen lassen.
• Es nur in der Designdatei bauen, ohne Gegenstück im Code.
• Am ersten Tag mit Hunderten Komponenten starten wollen.
• Das System Produktteams überstülpen, ohne sie einzubeziehen.
• Tokens nach Wert benennen ("blauer Button") statt nach Zweck.
• Die Dokumentation auf später verschieben.

Alle diese Fehler haben dieselbe Ursache: Man betrachtet das System als Ergebnis und nicht als Produkt. Ein Produkt hat jedoch Nutzer, hier also die Teams, dazu eine Roadmap und ein Budget für die Pflege. Wie Schwächen in der Oberfläche Umsatz kosten, zeigt mein Beitrag über UX Fehler, die Umsatz kosten.

Braucht auch ein kleines Unternehmen ein Design System?

Nicht jedes Unternehmen braucht ein System im Konzernformat. Bei einer einzigen Website, einer Designerin und einem Entwickler kann ein vollständiges System mehr Pflege kosten, als es bringt.

Dennoch lohnt sich auch im Kleinen eine schlanke Version. Einige Basistokens für Farbe, Schrift und Abstand, etwa zehn Grundkomponenten und eine Seite mit Nutzungshinweisen geben Ihnen eine solide Grundlage für späteres Wachstum. Das gilt vor allem, wenn Sie eine zweite Website, eine App oder die Arbeit mit einer externen Agentur planen. Die schlanke Version erspart Ihnen dann später eine teure Aufräumaktion.

Für die Entscheidung hilft eine Frage: Wie viele Teams oder Personen arbeiten an der Oberfläche, und wächst diese Zahl im nächsten Jahr? Lautet die Antwort ja, ist jetzt der richtige Zeitpunkt für die Planung. Welche Fragen Sie vor einer Beauftragung stellen sollten, habe ich in der Checkliste für UI und UX Design gesammelt.