Designsystem aufbauen: von Markenregeln zur nutzbaren Website

Die erste Seite sieht gut aus. Auf der zweiten braucht das Formular mehr Erklärung. Auf der dritten arbeitet ein anderes Team, das den Button kurzerhand neu baut. Obwohl alle denselben Brand Guide haben, entstehen unterschiedliche Lösungen für dieselbe Aufgabe.

Ein Designsystem kann solche Wiederholungen reduzieren. Dafür reicht eine aufgeräumte Designdatei nicht. Das Team muss wissen, welche Lösung es verwenden soll, wie diese sich verhält und wer sie verändert, wenn sie nicht mehr passt.

Unsere Empfehlung: Baue dein Designsystem zunächst für einen realen Ablauf auf. Prüfe danach, ob ein zweites Team die Lösung übernehmen kann. Dieser zweite Einsatz zeigt mehr als die Anzahl fertiger Komponenten.

Was ein Designsystem leisten muss

Ein Designsystem verbindet gemeinsame Gestaltungsregeln mit wiederverwendbaren Bausteinen und einem Verfahren für ihre Pflege. Es beschreibt nicht nur, wie eine Oberfläche aussieht, sondern auch, wie Menschen sie gestalten, umsetzen und weiterentwickeln. NN/g unterscheidet zwei Bestandteile: die Sammlung der Gestaltungsmittel und die Menschen, die sie pflegen. Design Systems 101

Eine Komponentenbibliothek ist ein Teil davon: Sie enthält beispielsweise Eingabefelder, Buttons und Navigationselemente. Sie kann bereits Regeln und Anwendungsbeispiele mitbringen. Ein Styleguide legt unter anderem Farben, Typografie und Sprache fest. Das Designsystem verbindet diese Grundlagen mit dem täglichen Einsatz. Es klärt etwa, wann ein Formularfeld einen Hilfetext benötigt, wie eine Fehlermeldung formuliert wird und welche geprüfte Umsetzung dafür vorgesehen ist.

Der Unterschied wird an einer einfachen Frage sichtbar: Kann jemand eine neue Seite bauen, ohne die grundlegenden Entscheidungen hinter jeder Komponente neu erfragen zu müssen?

Wann sich der Aufbau lohnt und wann du kleiner bleiben solltest

Investiere dort, wo eine gemeinsame Lösung wiederkehrende Arbeit tatsächlich ersetzt. Mehrere Teams, ähnliche Nutzerabläufe oder regelmäßig neue Seiten können dafür sprechen. Eine große Seitenzahl allein reicht als Begründung nicht: Viele Seiten können auf wenigen unveränderten Vorlagen beruhen. Umgekehrt kann ein kleines Produkt anspruchsvolle Zustände und häufige Änderungen haben.

Sieh dir die zuletzt umgesetzten Seiten oder Funktionen an. Wo wurden ähnliche Elemente erneut gestaltet? Welche Fehler mussten mehrfach korrigiert werden? Wo gingen Rückfragen zwischen Design, Redaktion und Entwicklung hin und her? Daraus entsteht der erste sinnvolle Umfang.

Für eine einmalige Kampagnenseite kann eine gemeinsame Gestaltungsvorlage mit wenigen wiederverwendbaren Bausteinen genügen. Ein aufwendig gepflegtes, produktübergreifendes System wäre dann möglicherweise mehr Arbeit als Hilfe. Auch bei einem noch ungeklärten Angebot solltest du zuerst prüfen, was Menschen überhaupt brauchen. Ein System macht eine falsche Lösung leichter wiederholbar, nicht richtiger.

Plane deshalb nicht nur den Aufbau ein, sondern auch Pflege, Tests und Unterstützung für die nutzenden Teams. Wenn niemand diese Arbeit übernehmen kann, reduziere den Umfang. Eine kleine gepflegte Lösung ist ein besserer Ausgangspunkt als eine umfangreiche Sammlung ohne Verantwortung.

Welche Bestandteile zusammengehören

Ein digitales Designsystem braucht Regeln auf mehreren Ebenen. Die folgende Einordnung ist ein Arbeitsmodell für den Aufbau, keine vorgeschriebene Architektur. Am Beispiel einer Beratungsanfrage wird deutlich, welche Entscheidung wohin gehört.

Design Tokens speichern kleine Gestaltungsentscheidungen unter einem Namen. Die Design Tokens Community Group beschreibt dafür ein Austauschformat zwischen Werkzeugen. Dieses Format allein synchronisiert aber noch keine Website: Export, Verarbeitung, Einbindung und Aktualisierung müssen eingerichtet sein. Design Tokens Format Module

Atlassian zeigt, weshalb die Bedeutung eines Tokens wichtig ist. Ein Token wie color.icon.success bezeichnet die Farbe eines Erfolgssymbols, nicht einfach einen beliebigen Grünton. Die Dokumentation empfiehlt, Tokens nach ihrem Zweck auszuwählen. Nur weil zwei Farben heute gleich aussehen, sind sie nicht austauschbar. In einem anderen Farbschema kann die Verwechslung sichtbar werden. Atlassian: Design tokens explained

Prüfblick: Atlassian zeigt unter „What are themes?“ dieselbe Jira-Oberfläche in heller und dunkler Darstellung. Vergleiche Hintergründe, Schrift und Bedienelemente. Das Bild macht den Wechsel des Farbschemas sichtbar, nicht eine gemessene Verbesserung der Bedienbarkeit. Atlassian: Themes im Vergleich

Für dein Team folgt daraus: Lege zuerst fest, was ein Wert bedeutet. Entscheide dann, wie er heißt und in welchen Werkzeugen er verwendet wird. Sonst hat das alte Durcheinander lediglich neue Variablennamen.

Wie Markenregeln im Interface wirksam werden

Ein Designsystem sollte die Brand Identity nicht auf die richtige Schrift und die richtige Farbe reduzieren. Entscheidend ist auch, wie die Marke Menschen durch eine Aufgabe führt.

Nehmen wir eine fiktive Marke, die für verständliche Beratung steht. Ihr Anfrageformular sollte erklären, welche Angaben nötig sind und wofür sie gebraucht werden. Die Schaltfläche könnte „Beratung anfragen“ heißen. Nach dem Absenden bestätigt die Seite, dass die Anfrage eingegangen ist, und beschreibt den tatsächlichen nächsten Schritt. Eine konkrete Antwortzeit gehört nur hinein, wenn das Team sie einhalten kann.

Diese Entscheidungen lassen sich dokumentieren: Welche Informationen stehen vor dem Formular? Welche Inhalte darf die Redaktion ändern? Welche Hinweise dürfen nicht entfallen? So wird aus dem Markenversprechen eine prüfbare Regel für Inhalt und Funktion.

Nicht jede Seite muss dabei gleich aussehen. Eine Kampagne darf anders erzählen als eine Supportseite. Gemeinsam bleiben die Regeln, die Orientierung und Wiedererkennung tragen. Gestaltungsspielraum sollte dort möglich sein, wo die Aufgabe ihn rechtfertigt, nicht dort, wo jemand eine bestehende Lösung übersehen hat.

Inhaltsaufgaben brauchen mehr als einzelne Buttons

Im fiktiven Beratungsbeispiel braucht jede Angebotsseite eine verständliche Beschreibung des Angebots, nachvollziehbare Belege und einen passenden Weg zur Anfrage. Als gemeinsame Sektionen könnten ein Leistungsüberblick, ein Projektbeispiel und das Anfrageformular dienen. Die Inhalte unterscheiden sich je nach Angebot. Welche Angaben eine Sektion benötigt und welche Zustände sie unterstützen muss, legt das Team gemeinsam fest.

Unsere Empfehlung: Ein Website-System sollte nicht nur einzelne Buttons verwalten. Es muss auch die wiederkehrenden Inhaltsaufgaben unterstützen. Wenn mehrere Angebotsseiten Problem, Lösung, Beleg und nächsten Schritt erklären, braucht das Team dafür passende Sektionen. Ein Raster allein entscheidet noch nicht, welche Inhalte eine Seite verständlich machen.

So baust du einen ersten nutzbaren Umfang auf

Starte mit einem klar begrenzten Pilotprojekt, das eine reale Nutzeraufgabe vollständig abbildet. Der folgende Ablauf ist unsere Empfehlung für ein Team aus Marke, Redaktion, Design und Entwicklung.

1. Einen Ablauf und seinen Engpass auswählen

Wähle eine Aufgabe, die an mehreren Stellen vorkommt. Das kann eine Beratungsanfrage, eine Produktauswahl oder die Anmeldung zu einer Veranstaltung sein. Halte fest, was heute unnötige Arbeit oder Verständnisprobleme erzeugt. „Unsere Buttons sehen verschieden aus“ ist ein Befund. „Jede neue Anfrageseite braucht eine eigene Abstimmung über Pflichtfelder und Bestätigung“ beschreibt bereits einen konkreten Arbeitsbedarf.

Definiere, was zunächst nicht dazugehört. Für den Formularpilot müssen weder die gesamte Navigation noch alle Kampagnenlayouts neu entstehen.

2. Den Bestand prüfen und Entscheidungen festhalten

Sammle die vorhandenen Varianten des gewählten Ablaufs. Prüfe nicht nur die Designdateien, sondern auch die tatsächlich umgesetzten Seiten und ihre Inhalte. Manchmal existiert die passende Lösung bereits, ist aber schlecht auffindbar. Manchmal sehen zwei Varianten ähnlich aus, erfüllen jedoch unterschiedliche Aufgaben.

Entscheide gemeinsam, welche Lösung übernommen, angepasst oder ersetzt wird. Prüfe dabei auch, ob vorhandene technische Komponenten als Grundlage taugen. Ein eigenes Designsystem verlangt nicht, jedes Eingabefeld von Grund auf neu zu programmieren. Anforderungen, Anpassbarkeit, Zugänglichkeit und spätere Pflege müssen zur gewählten Basis passen.

3. Design, Inhalt und Umsetzung zusammenführen

Definiere für jeden benötigten Baustein seinen Zweck, erlaubte Varianten, Inhalte und relevante Zustände. Beim Eingabefeld gehören dazu nicht nur der leere Ausgangszustand, sondern auch Fokus, fehlerhafte Eingabe und hilfreiche Rückmeldung. Für das gesamte Formular kommen die laufende Übermittlung und ein möglicher technischer Versandfehler hinzu. Lege fest, wie die Person erkennt, ob ihre Anfrage angekommen ist, und was sie bei einem Fehler tun kann.

Die Entwicklung kann solche Zustände beispielsweise in Storybook isoliert darstellen. Dort werden Varianten als „Stories“ festgehalten und für Entwicklung, Dokumentation und Tests verwendet. Das Werkzeug unterstützt die Arbeit am Baustein; es ersetzt nicht die Entscheidung über dessen richtigen Einsatz. Storybook-Dokumentation

Wenn das System in der Website-Umsetzung verwendet wird, gehört auch die Redaktion dazu. Ein CMS-Feld für einen Buttontext ist noch keine verständliche Handlungsaufforderung. Dokumentiere, welche Inhalte frei bearbeitet werden dürfen und welche funktionalen Anforderungen dabei erhalten bleiben müssen.

4. Am vollständigen Ablauf prüfen

Teste die Komponenten zunächst einzeln und anschließend zusammen in der tatsächlichen Seite. Funktioniert das Formular auf schmalen Bildschirmen? Sind lange Inhalte verständlich? Lässt es sich mit der Tastatur bedienen? Wird ein Fehler so erklärt, dass die Person ihn beheben kann? Prüfe auch die erfolgreiche Übermittlung und die Bestätigung, nicht nur das Absenden.

GitHub dokumentiert in Primer einen ergänzenden Blick auf vollständige Nutzeraufgaben. Im „Scenarios Framework“ werden beispielsweise das Erstellen eines Issues oder das Hinzufügen eines Organisationsmitglieds als zusammenhängende Aufgaben beschrieben und mit Accessibility-Prüfungen verbunden. GitHub Primer: Scenarios Framework

Prüfblick: GitHubs bebilderte Anleitung zeigt, wie Repository-Auswahl, Titel, Beschreibung und Erstellen-Aktion zu einer Aufgabe zusammenkommen. Der Screenshot veranschaulicht den Aufbau des Formulars, nicht das Ergebnis eines Barrierefreiheitstests. GitHub: Ein Issue erstellen

Übertragen auf den Pilot heißt das: „Eingabefeld funktioniert“ und „eine Beratung anfragen können“ sind zwei unterschiedliche Prüfumfänge. Gute Einzelteile sind notwendig, aber kein Nachweis für einen funktionierenden Gesamtprozess. Die genannten Fragen sind erste Prüfaufgaben, kein vollständiger Barrierefreiheitsnachweis. Ergänze technische Prüfungen durch Beobachtungen mit Menschen aus der tatsächlichen Zielgruppe.

5. Die zweite Anwendung bewusst einplanen

Lass ein anderes Team oder eine bisher unbeteiligte Person die Lösung für eine weitere Seite verwenden. Stelle dafür ein auffindbares Übergabepaket bereit: Nutzungsregeln, Designvorlagen, umgesetzte Komponenten mit ihren Zuständen, den freigegebenen Versionsstand und einen Kontakt für Rückfragen. Erkläre nicht vorab jeden Sonderfall. Beobachte, wo Rückfragen entstehen und welche Informationen fehlen. Wenn die Übernahme nur mit persönlicher Dauerbegleitung funktioniert, ist die Lösung noch nicht ausreichend beschrieben oder zu kompliziert.

So könnte ein erster Pilotauftrag aussehen. Das Beispiel ist fiktiv und keine Projektmessung:

Pflege entscheidet, ob das System brauchbar bleibt

Lege vor der breiten Einführung fest, wie Änderungen ins System kommen. Ein Vorschlag sollte den konkreten Bedarf und betroffene Anwendungen nennen. Design, Redaktion und Entwicklung prüfen die Aspekte, für die sie verantwortlich sind. Anschließend wird dokumentiert, was sich ändert, wer aktualisieren muss und ob bisherige Varianten weiter funktionieren.

Bei einem neuen Pflichtfeld genügt es beispielsweise nicht, nur die Figma-Komponente zu ergänzen. Die Umsetzung, die Inhalte und die betroffenen Formulare müssen zusammenpassen. Eine gemeinsame Quelle hilft dabei. Sie nimmt dem Team die Prüfung und Verteilung der Änderung nicht ab.

Miss den Nutzen an der Arbeit, die du zu Beginn verbessern wolltest. Halte für vergleichbare neue Seiten fest, welche Bausteine übernommen wurden, welche Rückfragen blieben und welche Fehler erneut auftraten. Wenn du Aufwand vergleichst, berücksichtige auch Pflege und Einarbeitung. Eine schneller gestaltete Seite ist kein Nettofortschritt, wenn dafür an anderer Stelle mehr Nacharbeit entsteht.

Ein Designsystem kann so helfen, wiederkehrende Entscheidungen verlässlich umzusetzen. Es erzeugt keine Nachfrage und garantiert kein Wachstum. Sein Wert wird greifbar, wenn dein Team eine weitere Anwendung bauen kann, ohne dieselben Grundfragen erneut zu lösen, und Menschen diese Anwendung tatsächlich nutzen können.