Entscheidungen definieren, nicht nur eine Stilgalerie
Ein Designsystem ist mehr als Screenshots. Es dokumentiert wiederkehrende Entscheidungen: Abstände zwischen Abschnitten, Behandlung der primären Aktion, wie ein Formfehler funktioniert und welche Sprache nach Erfolg oder Fehler verwendet wird. USWDS beschreibt Design Tokens als diskrete Paletten für Werte wie Typografie, Abstände, Farbe, Zeilenhöhe und Deckkraft. Dokumentieren Sie die Regel, den Zweck, genehmigte Varianten und den Verantwortlichen. Beginnen Sie mit den Grundlagen und den fünf bis acht Komponenten, die in wichtigen Nutzerpfaden am meisten genutzt werden; die Standardisierung jeder Seite auf einmal erzeugt meist mehr Rauschen als Klarheit.
Halten Sie genehmigte Farbrollen, Schrift, Abstände, Rahmen, Radien, Breakpoints und Bewegungs‑Entscheidungen fest, die Ihre Site tatsächlich verwendet.
Nutzen Sie ein Pattern für eine wiederholbare Aufgabenanordnung, etwa Kontoerstellung oder Suchergebnisse, statt für eine einzelne visuelle Verzierung.
Tokens zur Steuerung wiederkehrender Werte verwenden
Ein Design Token ist ein menschenlesbarer Name, der mit einem Wert verknüpft ist. Die Design Tokens Community Group beschreibt Tokens als plattformunabhängige Art, Designentscheidungen auszudrücken; mindestens besteht ein Token aus einem Namen und einem Wert. Verwenden Sie Zweck‑Namen wie color-action-primary oder space-section, statt rohe Werte in Templates zu verstreuen. Bewahren Sie eine dokumentierte Zuordnung von Zweck‑Tokens zu Basiswerten. Tokens erleichtern koordinierte Änderungen, garantieren aber nicht automatisch Kontrast, Markenführung oder gute Hierarchie. Validieren Sie jede gerenderte Kombination und jeden Seitenzustand.
Erstellen Sie Tokens für wiederkehrende Entscheidungen, nicht für jede Ausnahme; sonst bewahrt die Token‑Liste nur bestehende Inkonsistenzen.
Für ein weit verbreitetes Token listen Sie betroffene Seiten auf, testen repräsentative Screens und geben Migrations‑ oder Rollback‑Hinweise, wenn nötig.
Komponenten mit Verhalten und Grenzen bauen
Eine Komponente ist ein wiederverwendbarer Interface‑Baustein mit Verhalten, nicht nur eine visuelle Form. Dokumentieren Sie semantische Struktur, erforderliche und optionale Eingaben, Varianten, responsive Verhaltensweisen und alle relevanten Zustände: Laden, deaktiviert, Fehler, leer und Erfolg. Schließen Sie Tastaturverhalten und Inhaltsanweisungen ein. Zwingen Sie nicht jedes Layout in eine Komponente. GOV.UK bewertet gemeinsame Komponenten nach Nützlichkeit, Einzigartigkeit, Benutzbarkeit, Konsistenz und Vielseitigkeit; das ist eine nützliche Disziplin, um zu entscheiden, was gemeinsame Pflege verdient. Eine breit genutzte Komponente kann einen Defekt breit streuen, deshalb testen Sie sie in den Seiten, in denen Menschen sie wirklich verwenden.
Listen Sie jeden für Nutzer sichtbaren Zustand auf und zeigen Sie echte Labels, lange Texte und Fehler, damit Implementierungsgrenzen sichtbar werden.
Kennzeichnen Sie alte Varianten klar, benennen Sie die Ersatzvariante und entfernen Sie alte Varianten erst, nachdem betroffene Nutzerpfade geprüft wurden.
Barrierefreiheit als Freigabebedingung festlegen
Barrierefreiheit muss im System verankert sein, weil sich wiederholte Entscheidungen auch Barrieren wiederholen können. WCAG 2.2 verlangt auf Level A Tastaturbedienung für Funktionalität, außer dort, wo ein Bewegungsweg inhärent ist, und verlangt eine sinnvolle Fokusreihenfolge, wenn die Sequenz wichtig ist. Machen Sie semantische Steuerelemente, sichtbaren Fokus, Labels, logische Fokusbewegung, Fehlererkennung und Aufgabenabschluss ohne Zeigegerät zum Bestandteil der Komponenten‑Anleitung. Nutzen Sie automatisierte Prüfungen früh, gefolgt von manuellen Tests mit Tastatur, Zoom, Responsive‑Checks und Seitenprüfungen. USWDS warnt, dass barrierefreie Komponenten keinen barrierefreien Dienst garantieren; benutzerdefinierter Code, Texte, Integrationen und Kontext müssen ebenfalls geprüft werden.
Bestätigen Sie, dass Menschen Steuerelemente ohne Maus erreichen, bedienen, verstehen und wieder verlassen können, ohne in einer Fokusfalle zu landen.
Rechtliche Pflichten variieren nach Gerichtsbarkeit und Vertrag. Holen Sie qualifizierte Zugänglichkeits‑ und Rechtsprüfung ein, wenn Compliance materiell ist.
Inhaltsstandards als Interface‑Standards behandeln
Worte sind Komponenten‑Eingaben, nicht Dekoration, die nach dem Design hinzugefügt wird. Legen Sie Regeln für Aktionslabels, Formularlabels, Fehlermeldungen, Überschriften, Links, Terminologie, Datumsformate, Zahlen und Abkürzungen fest. GOV.UK empfiehlt nach Möglichkeit die aktive Sprache und die direkte Anrede der Nutzer als "you"; verfolgen Sie das Prinzip klarer, konsistenter Sprache und passen Sie Stimme und Ton an Ihr Publikum an. Verknüpfen Sie Regeln mit einem Inhaltsmodell: geben Sie an, welche Felder erforderlich sind, sinnvolle Längenangaben und was passiert, wenn Informationen fehlen. Platzieren Sie die Anleitung in den Komponentendokumenten und den CMS‑Workflows, damit Redakteure sie verwenden können.
Sagen Sie, was fehlgeschlagen ist, wo es passiert ist und welcher nächste Schritt möglich ist, wenn das sicher und nützlich ist.
Eine Begrenzung ist ein Signal, neu zu entwerfen oder umzuschreiben, nicht die Erlaubnis, wesentlichen Inhalt zu entfernen.
Governance, bevor das System schneller wächst als Vertrauen
Governance ist der leichte Prozess für Eigentum, Anfragen, Prüfungen, Releases und Ruhestellung. Benennen Sie eine verantwortliche Person und eine Review‑Gruppe, die Design, Entwicklung, Inhalt und Zugänglichkeit abdecken kann. Stimmen Sie Evidenz mit der möglichen Wirkung ab. Ein lokales Pattern braucht möglicherweise eine Problembeschreibung und Seitentests. Eine gemeinsame Button‑ oder Tokenänderung sollte betroffene Nutzerpfade, Zugänglichkeitsprüfungen, visuelle Vergleiche, Migrationshinweise und Rollback‑Anweisungen enthalten. GOV.UK fordert Beitragende auf, zu zeigen, dass eine Komponente für viele Teams nützlich ist, keine Duplikation darstellt und mit repräsentativen Nutzern getestet wurde; nutzen Sie das als praktisches Modell, nicht als universelle Regel.
Speichern Sie Problem, Optionen, Entscheidung, Verantwortlichen, betroffene Version und Überprüfungsdatum dort, wo Teams es durchsuchen können.
Kennzeichnen Sie Änderungen als Patch, additive oder breaking, damit Verbraucher wissen, wann Migration und eine Kompatibilitätsperiode nötig sind.
Regressionen vor der Freigabe verhindern
Verbinden Sie das System mit der Auslieferung. Fordern Sie, dass eine Änderung berührte Tokens und Komponenten benennt und dann betroffene Zustände und repräsentative Seiten testet. Visuelle Vergleiche, Interaktionstests, Inhaltsprüfungen und Zugänglichkeitschecks finden unterschiedliche Defekte. Priorisieren Sie hochkonsequente Nutzerpfade ebenso wie stark frequentierte; Kontozugang und Kontaktformulare können wichtig sein, auch wenn der Traffic überschaubar ist. Das unterstützt die proaktive Uptime‑Optimierung und Remediation‑Arbeit von Status Is UP, indem der Defektraum eingeengt und eine genehmigte Korrektur leichter verifizierbar wird. Es ersetzt kein Verfügbarkeits‑Monitoring und keinen Incident‑Plan.
Bewahren Sie Komponenten‑Version, Testergebnisse, Befunde, Genehmigungen und akzeptierte Risiken mit dem Release‑Eintrag auf.
Bewahren Sie die vorherige stabile Version und testen Sie während wartungsarmer Zeiten dokumentierte Wiederherstellungs‑ und Verifikationsschritte.