Was ein modernes Design System heute wirklich ausmacht

Frontend 8. Juni 2026 Marc Lettau-Poelchen 7 min Lesedauer

design-systemfrontendtokensaccessibilitykomponentendeveloper-experience

Ein Design System ist fertig, wenn man aufgehört hat, es zu pflegen. Das klingt zynisch, ist aber die Realität in vielen Projekten: eine Figma-Datei mit 200 Komponenten, ein Git-Repo mit einem components/-Ordner, der seit Monaten keinen Commit gesehen hat — und irgendwo dazwischen ein Team, das trotzdem jeden Button neu baut. Herzlichen Glückwunsch, das ist kein Design System. Das ist ein gut gemeintes Archiv.

Was ein modernes Design System heute wirklich ausmacht, ist eine andere Frage. Und die Antwort ist komplexer als „mehr Komponenten“ oder „bessere Doku“. Es geht um Infrastruktur. Um Prozesse. Und um die Fähigkeit, mit einem wachsenden Produkt und Team mitzuwachsen, ohne dabei auseinanderzufallen.

Foundations: Tokens statt Magic Numbers

Der Ausgangspunkt jedes ernsthaften Design Systems sind Design Tokens — keine Farben, die irgendwo in einer Sass-Variable stecken, sondern strukturierte, maschinenlesbare Werte, die als Single Source of Truth für Design und Code dienen.^[1]

Ein Token ist im Kern simpel:

{
  "color": {
    "brand": {
      "primary": { "value": "#0057FF", "type": "color" },
      "primary-hover": { "value": "#0041CC", "type": "color" }
    },
    "neutral": {
      "100": { "value": "#F5F5F5", "type": "color" },
      "900": { "value": "#1A1A1A", "type": "color" }
    }
  },
  "spacing": {
    "xs": { "value": "4px", "type": "dimension" },
    "sm": { "value": "8px", "type": "dimension" },
    "md": { "value": "16px", "type": "dimension" },
    "lg": { "value": "24px", "type": "dimension" }
  }
}

Aus diesen Tokens lassen sich dann plattformspezifische Ausgaben generieren — CSS Custom Properties für das Web, Swift-Konstanten für iOS oder XML-Ressourcen für Android. Tools wie Style Dictionary oder Theo übernehmen diese Transformation automatisch.^[2]

:root {
  --color-brand-primary: #0057ff;
  --color-brand-primary-hover: #0041cc;
  --color-neutral-100: #f5f5f5;
  --color-neutral-900: #1a1a1a;

  --spacing-xs: 4px;
  --spacing-sm: 8px;
  --spacing-md: 16px;
  --spacing-lg: 24px;
}

Der entscheidende Vorteil: Wenn sich die Primärfarbe ändert — weil das Rebranding endlich durch ist oder weil der Accessibility-Audit ergeben hat, dass der Kontrast nicht reicht — ändert man einen Wert. Nicht 47 Stellen im Code. Nicht 12 Figma-Frames. Einen Wert.^[3]

Moderne Systeme arbeiten außerdem mit semantischen Tokens, die über reine Werte hinausgehen:

{
  "color": {
    "action": {
      "default": { "value": "{color.brand.primary}", "type": "color" },
      "hover": { "value": "{color.brand.primary-hover}", "type": "color" },
      "disabled": { "value": "{color.neutral.100}", "type": "color" }
    }
  }
}

Semantische Tokens beschreiben Bedeutung, nicht Aussehen. color.action.default ist nicht „blau“, sondern „die Farbe, die eine primäre Aktion signalisiert“. Das macht Theme-Switching, Dark Mode und Multi-Brand-Setups erst wirklich handhabbar.^[1]

Komponenten: Mehr als hübsche Buttons

Eine Komponentenbibliothek ist das sichtbarste Artefakt eines Design Systems — und gleichzeitig das, worüber am meisten gestritten wird. Zu viele Varianten? Zu wenige? Zu starr? Zu flexibel?

Ein modernes System löst diesen Konflikt durch klare Kompositionsprinzipien. Komponenten sind atomar, kombinierbar und klar in ihrer API.^[4]

Hier ein Beispiel für eine Button-Komponente in Vue 3, die Tokens nutzt und Accessibility von Anfang an mitdenkt:

<template>
  <button
    :class="[
      'btn',
      `btn--${variant}`,
      `btn--${size}`,
      { 'btn--loading': loading },
    ]"
    :disabled="disabled || loading"
    :aria-busy="loading ? 'true' : 'false'"
    :aria-disabled="disabled || loading ? 'true' : 'false'"
    v-bind="$attrs"
  >
    <span v-if="loading" class="btn__spinner" aria-hidden="true" />
    <slot />
  </button>
</template>

<script setup lang="ts">
withDefaults(
  defineProps<{
    variant?: "primary" | "secondary" | "ghost" | "danger";
    size?: "sm" | "md" | "lg";
    disabled?: boolean;
    loading?: boolean;
  }>(),
  {
    variant: "primary",
    size: "md",
    disabled: false,
    loading: false,
  },
);
</script>

<style scoped>
.btn {
  display: inline-flex;
  align-items: center;
  gap: var(--spacing-xs);
  padding: var(--spacing-sm) var(--spacing-md);
  border-radius: 6px;
  font-weight: 500;
  cursor: pointer;
  transition: background-color 0.15s ease;
}

.btn--primary {
  background-color: var(--color-action-default);
  color: #fff;
}

.btn--primary:hover:not(:disabled) {
  background-color: var(--color-action-hover);
}

.btn:disabled,
.btn--loading {
  opacity: 0.5;
  cursor: not-allowed;
}

.btn:focus-visible {
  outline: 2px solid var(--color-brand-primary);
  outline-offset: 3px;
}
</style>

Wichtig ist hier: Die Komponente nutzt keine hardcodierten Designwerte. Alles läuft über Tokens. Ändert sich das Token, ändert sich die Komponente — ohne dass jemand in jeder Datei einzeln nachbessern muss.^[4]

Außerdem sind disabled, aria-busy und sichtbare Fokuszustände direkt Teil der Implementierung. Accessibility ist damit kein nachträglicher Kommentar im Jira-Ticket, sondern echter Bestandteil der Komponente.

Patterns: Wenn Komponenten allein nicht reichen

Einzelne Komponenten lösen keine UX-Probleme. Patterns schon. Ein modernes Design System dokumentiert deshalb nicht nur Button und Input, sondern auch zusammengesetzte Lösungen für wiederkehrende Aufgaben.^[5]

Typische Patterns sind zum Beispiel:

Formular-Layouts mit Validierung, Fehlerzuständen und Hilfetexten
Empty States mit klarer Handlungsaufforderung
Filter- und Suchoberflächen
Bestätigungsdialoge
Tabellen mit Sortierung, Pagination und Selection States
Skeleton Screens statt ewiger Spinner-Andachten

Ein Pattern ist keine Komponente. Es ist eine bewusste Entscheidung, die einmal sauber getroffen und dann dokumentiert wird — damit sie nicht in jedem Sprint neu diskutiert werden muss.^[5]

## Pattern: Formularvalidierung

### Wann

Immer wenn Nutzereingaben validiert werden müssen.

### Verhalten

- Validierung erst nach `blur` und erneut beim Absenden
- Fehlermeldung direkt unter dem betroffenen Feld
- Fehlermeldung mit `role="alert"` für Screenreader
- Submit-Button bleibt aktiv, damit Fehler gesammelt sichtbar werden

### Nicht so

- Fehlermeldungen nur als Toast
- Validierung ausschließlich serverseitig ohne direktes Feedback
- Rote Rahmen ohne erklärenden Text

Das klingt unspektakulär, ist in der Praxis aber Gold wert. Ohne solche Patterns baut jedes Team seine eigene Version derselben Interaktion — und am Ende hat man fünf verschiedene Fehlermeldungen in einer App. Konsistenz sieht anders aus.

Accessibility: Kein Add-on, sondern Fundament

Ein Design System ohne Accessibility-Grundlage ist 2026 ungefähr so modern wie ein Faxgerät mit USB-Anschluss. Und trotzdem wird Accessibility noch oft behandelt wie ein Feature für später. Also für das sagenumwobene „später“, das nie kommt.^[6]

Was ein modernes System konkret mitbringen sollte:

Kontraste, die mindestens WCAG 2.1 AA erfüllen
sichtbare Fokuszustände für Tastaturnavigation
semantisches HTML statt div-getriebener Abenteuerarchitektur
ARIA nur dort, wo natives HTML nicht ausreicht
Tests, die Accessibility-Prüfungen automatisiert absichern^[6]

Ein Beispiel mit axe-core in einem Testsetup:

import { axe, toHaveNoViolations } from "jest-axe";
import { render } from "@testing-library/vue";
import BaseButton from "./BaseButton.vue";

expect.extend(toHaveNoViolations);

test("BaseButton hat keine Accessibility-Verletzungen", async () => {
  const { container } = render(BaseButton, {
    slots: { default: "Speichern" },
  });

  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

Und dazu der passende Fokusstil:

.btn:focus-visible {
  outline: 2px solid var(--color-brand-primary);
  outline-offset: 3px;
}

Ein moderner Ansatz testet Accessibility nicht nur manuell, sondern integriert sie direkt in die Entwicklungsprozesse — idealerweise in CI, Pull Requests und Component Reviews. Sonst bleibt sie oft das, was sie nie sein sollte: ein nervöser Nachgedanke kurz vor dem Release.

Dokumentation: Die unterschätzte Hälfte des Systems

Eine Komponentenbibliothek ohne Dokumentation ist wie eine API ohne Docs. Theoretisch nutzbar. Praktisch eine Einladung zu Fehlverwendung, Workarounds und spontaner Kreativität an den falschen Stellen.

Moderne Design Systems dokumentieren in Tools wie Storybook, zeroheight oder internen Doku-Plattformen — und zwar nicht nur die Komponente selbst, sondern auch ihr Verhalten, ihre Grenzen und ihre Einsatzzwecke.^[7]

Dazu gehören typischerweise:

alle Varianten und States
Do's und Don'ts
Accessibility-Hinweise
Code-Snippets
Guidelines für Komposition und Einsatzkontext

export default {
  title: "Components/BaseButton",
  component: BaseButton,
  argTypes: {
    variant: {
      control: "select",
      options: ["primary", "secondary", "ghost", "danger"],
      description: "Visueller Stil des Buttons",
    },
    size: {
      control: "select",
      options: ["sm", "md", "lg"],
    },
  },
};

export const Primary = {
  args: { variant: "primary", default: "Speichern" },
};

export const Loading = {
  args: { variant: "primary", loading: true, default: "Wird gespeichert…" },
};

export const Disabled = {
  args: { variant: "primary", disabled: true, default: "Nicht verfügbar" },
};

Gute Dokumentation ist kein dekorativer Aufsatz, sondern ein Produktivitätswerkzeug. Sie beantwortet Fragen, bevor sie im Slack-Channel landen.

Governance: Wer entscheidet was?

Das unglamouröseste Thema im ganzen Design-System-Kosmos — und ausgerechnet deshalb oft das wichtigste. Denn ohne Governance wird aus dem System schnell ein Basar mit schönem Branding.^[8]

Ein modernes Design System hat klare Antworten auf Fragen wie:

Wer darf neue Komponenten vorschlagen?
Wer reviewt sie?
Wie wird zwischen Pattern und Sonderfall unterschieden?
Wie werden Breaking Changes kommuniziert?
Wie sieht Versionierung aus?

Ein möglicher Contribution-Workflow sieht so aus:

1. Issue erstellen: Problem oder Bedarf beschreiben
2. RFC verfassen (Request for Comments — Vorschlagsdokument zur Abstimmung): API, UX, Accessibility, Alternativen dokumentieren
3. Review durch Core-Team aus Design und Development
4. Umsetzung in Design, Code, Tests und Doku
5. Merge und Release mit Changelog
6. Gegebenenfalls Deprecation-Hinweise für alte Varianten

Ohne diese Regeln entstehen sehr schnell parallele Realitäten: mehrere Button-APIs, doppelte Komponenten, konkurrierende Patterns. Und plötzlich heißt „Single Source of Truth“ nur noch, dass es sehr viele Wahrheiten gibt.

KI als Beschleuniger — aber nicht als Ersatz für Denken

Natürlich spielt heute auch KI eine Rolle. Moderne Design Systems werden zunehmend so aufgebaut, dass sie mit KI-gestützten Workflows zusammenarbeiten können.^[9]

Das funktioniert vor allem dann gut, wenn das System sauber strukturiert ist. KI kann helfen bei:

automatischer Dokumentation
Erkennung von Inkonsistenzen
Generierung neuer Varianten auf Basis bestehender Komponenten
Analyse von Token-Nutzung im Code
Beschleunigung von Content- und UI-Prototyping

Was KI nicht ersetzt: gute Architekturentscheidungen, Produktverständnis, Accessibility-Kompetenz und Governance. Wer ein unstrukturiertes Komponenten-Chaos mit KI kombiniert, bekommt kein modernes System. Er bekommt nur schnelleres Chaos.^[9]

Fazit: Ein modernes Design System ist Infrastruktur

Ein modernes Design System ist heute nicht einfach eine Bibliothek mit UI-Bausteinen. Es ist eine organisatorische und technische Infrastruktur für konsistente digitale Produktentwicklung.^[1]^[8]

Es ist dann wirklich modern, wenn es:

token-basiert arbeitet
Design und Code miteinander verbindet
Accessibility von Anfang an integriert
Patterns statt nur Einzelteile dokumentiert
Governance und Versionierung ernst nimmt
skalierbar für Teams, Plattformen und Marken ist
anschlussfähig für KI bleibt, ohne von ihr abhängig zu sein

Früher war ein Design System oft eine Sammlung hübscher Assets. Heute ist es eher ein internes Produkt mit APIs, Regeln, Standards und einem klaren Betriebsmodell. Oder anders gesagt: weniger Moodboard, mehr Infrastruktur. Klingt nicht sexy, spart aber sehr viel Zeit, Geld und Diskussionen mit erstaunlich vielen Versionen desselben Buttons.