Design System für die Unternehmenswebsite: Ab welcher Größe es sich rechnet

Styleguide, Bauteil-Bibliothek oder vollständiges Design System: was die Stufen unterscheidet, wie groß die Teams dahinter sind, woran ihr erkennt, ob es sich lohnt, und eine Excel-Vorlage für die Bestandsaufnahme eurer Website.

Datum

/

Kategorie

Webdesign & UX

Webdesign & UX

/

Autor

Dustin Tatarowicz

Dustin Tatarowicz

Titelbild zum Beitrag

Brauchen wir für unsere Website ein Design System? Die Frage kommt meist auf, wenn mehrere Agenturen an einer Website gebaut haben, jede Landingpage anders aussieht oder die neue Karriereseite nicht zur Startseite passt. Ein Design System verspricht Ordnung. Es ist aber auch ein Produkt, das Leute, Zeit und Pflege braucht, und für viele Unternehmenswebsites reicht eine leichtere Stufe.

Für diesen Ratgeber haben wir die Definitionen der Nielsen Norman Group, den Design Systems Report 2026 von zeroheight, die Studie von Figma zur Zeitersparnis und die öffentlichen Design Systems der Verwaltung (KERN), der Deutschen Bahn, von Porsche und Siemens angesehen, dazu die neue Spezifikation für Design Tokens. Am Ende bekommt ihr eine Excel-Vorlage, mit der ihr zählt, wie viele Farben, Schriftgrößen und Bauteile eure Website heute tatsächlich verwendet.

Kurz gesagt (Stand Oktober 2026)

Ein vollständiges Design System lohnt sich, wenn mehrere Teams oder Agenturen über Jahre an mehreren digitalen Angeboten bauen. Für eine einzelne Unternehmenswebsite reicht meist ein Styleguide mit einer gepflegten Bauteil-Bibliothek im Website-System. Die Nielsen Norman Group schreibt, Design Systems seien am besten, wenn ein Unternehmen „years of future, replicable design work“ vor sich sieht. Ein eigenes System braucht ein Team: Laut zeroheight arbeiten bei den befragten Unternehmen mit 1.000 bis 5.000 Beschäftigten im Schnitt fünf Personen daran, und 61 Prozent der Teams fühlen sich unterbesetzt. Den wirtschaftlichen Nutzen weist kaum jemand nach: Nur 5 Prozent der befragten Teams messen den Return on Investment. Wer klein anfängt, macht zuerst eine Bestandsaufnahme und legt Farben, Schriften und Bauteile fest, bevor er über Werkzeuge spricht.

Drei Stufen: Styleguide, Bauteil-Bibliothek, Design System

Nicht jede Ordnung im Design ist gleich ein Design System, und für die Entscheidung hilft es, die Stufen auseinanderzuhalten. Die Nielsen Norman Group definiert ein Design System als „a complete set of standards intended to manage design at scale using reusable components and patterns“. Ein Styleguide ist dort nur ein Teil davon: Gestaltungsregeln, visuelle Beispiele und Prinzipien. Eine Komponentenbibliothek beschreibt einzelne Bauteile wie Buttons, Formularfelder oder Karten.

Schaubild mit drei Stufen: Styleguide, Bauteil-Bibliothek im Website-System und vollständiges Design System, jeweils mit Inhalt und wofür die Stufe reicht

Unser Stufenmodell der Ordnung im Design. Für die meisten Unternehmenswebsites ist Stufe 2 das Ziel, Stufe 3 erst bei mehreren Teams und Angeboten.

  • Stufe 1, Styleguide: Logo, Farben, Schriften, Bildsprache und Tonalität, meist als PDF oder Webseite. Der Styleguide der Bundesregierung ist ein gutes Beispiel für diese Stufe: Er regelt das Erscheinungsbild, enthält aber keinen Code.

  • Stufe 2, Bauteil-Bibliothek im Website-System: Farben und Schriften als zentrale Stile, dazu wiederverwendbare Bauteile wie Kopfbereich, Teaser, Formular und Fußzeile, die überall gleich aussehen und an einer Stelle geändert werden.

  • Stufe 3, Design System: Design Tokens, Komponenten im Designwerkzeug und im Code, Dokumentation, Regeln für Beiträge und ein Team, das alles pflegt. Der KERN UX-Standard der Verwaltung beschreibt sich selbst als „mehr als ein Design-System“.

Was ein eigenes Design System kostet

Der größte Posten ist nicht die Erstellung, sondern das Team, das das System dauerhaft pflegt. Die Nielsen Norman Group schreibt: „Creating and maintaining a design system is a time-intensive activity which requires a dedicated team.“ Wie groß solche Teams sind, zeigt der Design Systems Report 2026 von zeroheight, einem Anbieter von Software für Design Systems. Befragt wurden 147 Fachleute, die meisten aus Unternehmen mit mehr als 1.000 Beschäftigten und überwiegend aus Nordamerika und Westeuropa.

Diagramm aus dem zeroheight Design Systems Report 2026: durchschnittlich 2, 4, 5 und 11 Personen im Design-System-Team je nach Unternehmensgröße, 61 Prozent fühlen sich unterbesetzt

Durchschnittliche Größe des Design-System-Teams nach Unternehmensgröße und Anteil der Teams, die sich unterbesetzt fühlen. Quelle: zeroheight Design Systems Report 2026, 147 Befragte, Anbieterstudie.

83 Prozent der Befragten haben ein eigenes Team für ihr Design System. Im Schnitt sind es zwei Personen in Unternehmen bis 100 Beschäftigte, vier bei 100 bis 1.000, fünf bei 1.000 bis 5.000 und elf ab 5.000 Beschäftigten. Trotzdem sagen 61 Prozent, sie hätten nicht genug Leute für ihre Ziele. Zum selben Schluss kommt die Nielsen Norman Group in einem Beitrag vom Mai 2026: „if an organization wants to scale the support a design system offers, it needs to start by properly resourcing the team“.

Für ein mittelständisches Unternehmen heißt das: Ein eigenes Design System ist kein Projekt, sondern eine Daueraufgabe. Die Nielsen Norman Group nennt als Mindestbesetzung je eine Person für Interaktionsdesign, visuelles Design und Entwicklung. Wer das nicht dauerhaft stellen kann, ist mit Stufe 2 besser bedient. Unter den Wegen zu einem Design System ist laut Nielsen Norman Group „using an existing design system is the lowest-cost approach“, gepflegt werden muss aber auch ein übernommenes System.

Was es bringt, und wie selten das gemessen wird

Eine oft zitierte Zahl ist ein Laborwert, und den Return on Investment misst kaum ein Team. Der Anbieter Figma hat 2019 Designerinnen und Designer zwei gleich aufwendige Aufgaben lösen lassen, eine mit Design System und eine nur mit alten Designdateien. Ergebnis: Mit System „completed their objective 34% faster than without a design system“. Der Autor schränkt selbst ein, das sei „the maximum time savings one would find in a real-world scenario“. Die Aufgabe war ein App-Bildschirm, keine Website, und die Zahl der Teilnehmenden ist nicht angegeben.

Screenshot des Figma-Beitrags zur Zeitersparnis: 34 Prozent schneller mit Design System, markiert auch der Hinweis, dass dies die maximale Ersparnis im Alltag sei

Der Beitrag von Figma zur Zeitersparnis: 34 Prozent schneller (1), aber laut Autor die maximal zu erwartende Ersparnis (2).

Im Alltag wird es dünner. Laut zeroheight messen nur 5 Prozent der Teams den Return on Investment. Am häufigsten wird die Nutzung gemessen (41 Prozent), die Entwicklungsgeschwindigkeit messen 31 Prozent. Nur 7 Prozent sagen, ihr System sei in allen Teams voll übernommen, 22 Prozent sprechen von geringer Übernahme. Und die Zufriedenheit mit dem Rückhalt aus der Organisation ist von 42 auf 32 Prozent gefallen. Ein Design System, das nicht genutzt wird, kostet Geld, ohne Ordnung zu schaffen.

Ab wann es sich rechnet

Eine belastbare Schwelle in Beschäftigten oder Seiten gibt es nicht, wohl aber klare Signale. Figma bringt es in seinem Leitfaden zu Enterprise-Design-Systems auf den Punkt: „One team can keep a design system in their heads. Five teams, each shipping their own product, can't.“ Brad Frost, Autor des Buchs „Atomic Design“, antwortete 2019 im Smashing Magazine auf die Frage, ob jede Website ein Design System braucht: „I generally think so, yes.“ Eine aufwendige Dokumentation wie bei großen Systemen brauche es für kleinere Websites aber „Probably not, for those smaller sites, and that's fine.“ Entscheidend sei, dass „every single website could benefit from component driven architecture, design, and development principles“.

Aus diesen Quellen leiten wir sechs Signale ab. Je mehr davon zutreffen, desto eher lohnt Stufe 3:

Sechs Signale für ein eigenes Design System als Checkliste, von mehreren Teams und Marken bis zu Personal für die Pflege, mit Empfehlung je nach Anzahl

Sechs Signale für ein eigenes Design System. Vorschlag von marschfahrt.de, teils abgeleitet aus Nielsen Norman Group, Figma und Brad Frost, teils eigene Einschätzung.

  • Mehrere Teams oder Agenturen bauen gleichzeitig an Website, Shop, Portal oder App.

  • Mehrere Marken oder viele Länder nutzen dieselbe Grundlage mit eigenen Anpassungen.

  • Regelmäßig neue Seiten, etwa Kampagnen-Landingpages jeden Monat, die schnell und trotzdem einheitlich entstehen sollen.

  • Eigene Entwicklung mit Code, der über Jahre wächst, nicht nur ein Website-Baukasten.

  • Pflichten zur Barrierefreiheit, etwa nach dem Barrierefreiheitsstärkungsgesetz, die zentral sichergestellt werden sollen.

  • Personal für die Pflege, mindestens anteilig in Design und Entwicklung, mit Rückhalt aus der Leitung.

Trifft nur das erste oder zweite Signal zu und entwickelt ihr eigene Anwendungen, kann ein vorhandenes offenes System die Grundlage sein. Für eine reine Website reicht dann meist Stufe 2.

Stufe 2 im Website-System: das leichte Design System

Moderne Website-Systeme bringen die Werkzeuge für Stufe 2 bereits mit, ihr müsst sie nur konsequent nutzen. In Framer legt ihr Farben und Schriften als zentrale Stile an und baut Bauteile als Komponenten mit Varianten. Über die Bibliothek eines Workspace lassen sie sich in mehreren Projekten nutzen. Ändert ihr ein Bauteil, gilt laut Framer-Hilfe: „all projects using the component instance (without detaching) can pull the latest updates“. Wir bauen meist mit Framer, die nötigen Werkzeuge gibt es aber ebenso anderswo: Webflow bietet Variablen, Komponenten und geteilte Bibliotheken, WordPress zentrale Einstellungen über die Datei theme.json und wiederverwendbare Block-Vorlagen.

Der Unterschied zum vollen Design System: Die Bauteile bleiben im Wesentlichen an das Website-System gebunden, und meist gibt es keine eigene Dokumentation. Für eine Unternehmenswebsite mit Landingpages, Karriereseite und einigen Länderversionen ist das oft genau richtig. Wichtig ist eine Regel, die oft gebrochen wird: Bauteile nicht für jede Kampagne kopieren und abwandeln, sondern Varianten im Bauteil anlegen. Sonst habt ihr nach einem Jahr wieder viele fast gleiche Buttons.

Barrierefreiheit: zentral besser, aber nicht automatisch

Ein gutes Design System hebt die Barrierefreiheit aller Seiten auf einmal an, nimmt euch die Prüfung aber nicht ab. Der KERN UX-Standard der Verwaltung schreibt auf seiner Seite zur Barrierefreiheit, die Code-Basis seiner Komponenten erfülle „mindestens das AA-Level nach BITV 2.0“. Kurz danach steht: „Dies bedeutet jedoch nicht, dass ein damit entwickeltes Angebot automatisch barrierefrei ist.“ Und: „Die Verantwortung dafür liegt bei den umsetzenden Teams, nicht bei KERN.“

Screenshot der Seite Barrierefreiheit im KERN Design-System: Komponenten erfüllen mindestens BITV 2.0 AA, ein Angebot ist dadurch aber nicht automatisch barrierefrei

Die Seite zur Barrierefreiheit im KERN Design-System: Komponenten auf BITV-2.0-AA-Niveau (1), aber keine automatische Barrierefreiheit des fertigen Angebots (2).

Das britische GOV.UK Design System sagt dasselbe: „Using the GOV.UK Design System in a service does not immediately make that service accessible.“ Der Vorteil liegt trotzdem auf der Hand. Wer Kontraste, Fokus, Beschriftungen und Tastaturbedienung einmal im Bauteil richtig macht, hat sie auf allen Seiten als Grundlage. Im Zusammenspiel der Seite muss trotzdem geprüft werden. Welche Pflichten das Barrierefreiheitsstärkungsgesetz für Unternehmenswebsites mit sich bringt, steht in unserem Ratgeber zum BFSG.

Vorbilder aus Deutschland, öffentlich einsehbar

Ihr müsst nicht bei null anfangen, mehrere große Organisationen zeigen ihre Systeme offen. Sie eignen sich als Anschauung, wie Struktur und Dokumentation aussehen können, und teilweise als technische Grundlage:

  • KERN UX-Standard: Open-Source-Design-System für die Verwaltung, gestartet von Hamburg und Schleswig-Holstein. Der IT-Planungsrat übernimmt KERN laut Landesregierung Schleswig-Holstein zum 1. Januar 2027 in sein Produktportfolio.

  • DB UX Design System: Komponenten und Design Tokens der Deutschen Bahn für Web-Oberflächen, Code unter Apache-2.0-Lizenz.

  • Porsche Design System: Design Tokens, Komponenten und Richtlinien, laut Barrierefreiheitserklärung auf Basis von WCAG 2.2 AA, Quellcode unter Apache-2.0-Lizenz.

  • Siemens iX: „Siemens Industrial Experience“, Komponenten und Muster, Code unter MIT-Lizenz.

Ob und wie ihr den Code nutzen dürft, regelt die jeweilige Lizenz. Das Markenbild der Unternehmen gehört nicht dazu. Als technische Grundlage passt ein fremdes System vor allem dann, wenn ihr ohnehin eigene Anwendungen entwickelt.

Design Tokens: die Spezifikation ist jetzt stabil

Wer Farben, Abstände und Schriften als Design Tokens anlegt, kann sie zwischen Werkzeugen austauschen, und dafür gibt es seit Oktober 2025 eine stabile Spezifikation. Die Design Tokens Community Group beim W3C hat am 28. Oktober 2025 das „Design Tokens Format Module 2025.10“ veröffentlicht. Ein Token ist dort „information associated with a human readable name, at minimum a name/value pair“, also etwa ein Name wie „Farbe Primär“ mit einem Farbwert. Wichtig für die Einordnung: Die Spezifikation ist laut eigenem Text „not a W3C Standard nor is it on the W3C Standards Track“, sondern der Bericht einer Community Group.

Für Stufe 2 braucht ihr dafür kein eigenes Werkzeug. Es reicht, Farben und Schriften im Website-System mit sprechenden Namen anzulegen, etwa „Text Standard“ statt „Grau 3“. Wer später auf Stufe 3 wechselt, kann diese Namen als Tokens übernehmen.

So fangt ihr an: erst zählen, dann entscheiden

Bevor ihr über Werkzeuge sprecht, zählt, was eure Website heute verwendet. Eine Bestandsaufnahme zeigt nach unserer Einschätzung in wenigen Stunden bis Tagen, ob es ein Ordnungsproblem gibt und wie groß es ist. Unsere Excel-Vorlage für die Bestandsaufnahme führt euch durch vier Schritte:

  • Farben erfassen: jede Farbe, die auf der Website vorkommt, mit Fundstelle und Zweck

  • Schriften erfassen: Schriftarten, Größen und Stärken je Seitenart

  • Bauteile erfassen: Buttons, Teaser, Formulare, Kopfbereiche, mit der Zahl der Varianten, die ihr findet

  • Soll festlegen: für jede Gruppe, wie viele Varianten ihr wirklich braucht

Die Auswertung zeigt, wo ihr am meisten Wildwuchs habt und wie viele Varianten wegfallen können. Ein ausgefülltes Beispiel mit erfundenen Werten liegt bei.

Ausschnitt aus der Excel-Vorlage UI-Inventar mit erfundenen Beispielwerten: gefundene und benötigte Varianten je Bauteil und Auswertung mit Empfehlung

Ausschnitt aus dem ausgefüllten Beispiel mit erfundenen Werten: gefundene Varianten je Bauteil, Soll und Einsparung.

Häufige Fragen

Die meisten Fragen drehen sich um Aufwand, Werkzeuge und Zuständigkeit.

Reicht ein Figma-File als Design System?

Für Stufe 1 und als Grundlage für Stufe 2 ja. Ein vollständiges Design System lebt aber auch im Code beziehungsweise im Website-System. Eine Figma-Bibliothek, die niemand in die Website überträgt, schafft keine einheitlichen Seiten.

Wer sollte es verantworten?

Eine Person mit klarer Zuständigkeit, auch in Teilzeit. Figma schreibt: „A part-time owner with clear standards and a short review queue beats an elaborate governance structure nobody has time to run.“

Können wir ein fremdes Design System übernehmen?

Den Code je nach Lizenz ja, das Markenbild nicht. Für eine reine Unternehmenswebsite ist das selten nötig. Für eigene Portale oder Anwendungen kann ein offenes System wie KERN, DB UX oder Siemens iX viel Arbeit sparen.

Wie lange dauert der Aufbau?

Eine Bestandsaufnahme dauert nach unserer Einschätzung einen Nachmittag bis wenige Tage, Stufe 2 entsteht am besten beim nächsten Relaunch mit. Ein vollständiges System ist nie fertig, es wird wie ein Produkt laufend gepflegt.

Was sich geändert hat und was das für euch heißt

Standards und Vorbilder sind seit Herbst 2025 deutlich reifer geworden.

28. Oktober 2025: Die erste stabile Spezifikation für Design Tokens erscheint. Wer Tokens anlegt, kann sie künftig leichter zwischen Werkzeugen übertragen.

2026: Der fünfte Design Systems Report von zeroheight zeigt kleine, oft unterbesetzte Teams und wenig Messung. Plant Personal ein, bevor ihr baut.

1. Juli 2026: Schleswig-Holstein meldet, dass der IT-Planungsrat KERN zum 1. Januar 2027 übernimmt. Für Unternehmen, die mit Verwaltung arbeiten, kann KERN zum Bezugspunkt werden.

Stand dieser Fassung: 31. Oktober 2026.

Fazit

Ein Design System ist kein Projekt, sondern ein Produkt mit eigenem Team, und es rechnet sich erst, wenn mehrere Teams über Jahre davon profitieren. Für die meisten Unternehmenswebsites ist eine konsequent gepflegte Bauteil-Bibliothek im Website-System der richtige Schritt: zentrale Farben und Schriften, wenige Bauteile mit Varianten, eine verantwortliche Person. Wer mehrere Marken, Länder, Teams und eigene Anwendungen hat, sollte über ein volles System nachdenken und das Personal dafür gleich mit einplanen.

Ladet euch die Excel-Vorlage für die Bestandsaufnahme herunter und zählt zuerst eure Buttons. Wenn ihr dabei mehr als eine Handvoll findet, schaut euch an, wie wir Unternehmenswebsites mit wiederverwendbaren Bauteilen aufbauen.