Einheitliche Schnittstellensprache

1) Was ist eine einheitliche Schnittstellensprache und warum wird sie benötigt?

Die Unified Interface Language (YEI) ist ein gemeinsames System von Konzepten, visuellen Regeln und Interaktionen, das von Designern, Ingenieuren, Analysten und Inhaltsautoren geteilt wird.

• Konsistenz: Gleiche Komponenten und Begriffe in verschiedenen Produkten und Teams.
• Geschwindigkeit: Schnelle Montage, weniger Holyvars, schnelleres Onboarding.
• Qualität: UX konsistente Muster, Verfügbarkeit „Standard“.
• Skalierbarkeit: Sichere Evolution ohne Trennung zum „UI Zoo“.

2) Schichten einer einzigen Sprache

1. Tokens (Farbe, Typografie, Größen, Schatten, Einzüge, Radien, Animationen).
2. Komponenten (Schaltflächen, Eingabefelder, Tabellen, Grafiken, Modals, Toasts, Tabs).
3. Muster (Formulare, Validierung, Schritt-für-Schritt-Assistenten, Listen/Tabellen, Benachrichtigungen).
4. Inhalte (Microcopywriting, Terminologie, Fehlermeldungen).
5. Ikonographie und Illustrationen (Familie, Stil, Größen und Linien).
6. Verfügbarkeit und i18n/RTL (A11y, Übersetzbarkeit, Lokalität).
7. Prozesse (Versionen, Haidrails, Revuen, Linters, Vitrinen und Beispiele).

3) Design-Token (Grundlage der Ausdruckskraft)

Token sind benannte Werte, die in allen Produkten wieder verwendet werden.

3. 1 Aufbau der Token (Beispiel)

json
{
"color": {
"bg": { "base": "#FFFFFF", "subtle": "#F7F8FA" },
"fg": { "primary": "#11131A", "muted": "#656D76" },
"accent": { "primary": "#2F6BFF", "warning": "#FF9F1A", "critical": "#E53935", "success": "#2EAE60" }
},
"space": { "xs": 4, "sm": 8, "md": 12, "lg": 16, "xl": 24, "2xl": 32 },
"radius": { "sm": 8, "md": 12, "lg": 16, "pill": 1000 },
"shadow": { "sm": "0 1px 2px rgba(0,0,0,.08)", "md": "0 4px 12px rgba(0,0,0,.10)" },
"font": { "family": "Inter, system-ui", "size": { "sm": 12, "md": 14, "lg": 16, "xl": 20 } },
"motion": { "duration": { "fast": 120, "base": 200, "slow": 320 }, "curve": { "inout": "ease-in-out" } }
}

3. 2 Token-Namensgebung

Vom Allgemeinen zum Privaten: 'color. accent. primary`, не `primaryBlue`.
Ohne Markenbezug in der Namensgebung (Marke ist ein Thema, nicht der Name des Tokens).
Abstufungen: 'fg. muted`, `fg. primary`, `fg. inverse`. Codieren Sie die Helligkeit im Namen ('blue500') nicht ohne System.

3. 3 Token-Themen

Hell, dunkel, kontrastreich: Werte ändern, keine Namen.
Themen sind die Override-Ebene, die Benutzeroberfläche bleibt konsistent.

4) Komponenten: Vertrag, Zustände, Verfügbarkeit

Komponente = visuell + Verhalten + Vertrag Props + A11y.

4. 1 Beispiel für einen Button-Vertrag

ts type ButtonProps = {
kind: "primary"      "secondary"      "tertiary"      "danger";
size: "sm"      "md"      "lg";
icon?: "plus"      "download"      "trash";
disabled?: boolean;
loading?: boolean;
ariaLabel?: string;
onClick?: (e: MouseEvent) => void;
};

Zustände: 'default/hover/active/focus/disabled/loading'.
Verfügbarkeit: Fokusring, Zielgrößen ≥ 40-48 px, 'aria-pressed' für Toggle.

4. 2 Komponentengarantien

Stabile Abmessungen (Linienhöhe, Paddings).
Verfügbarkeit aus der Box (Rolei/Aria, Tastatur, Kontrast).
Invarianten: Fehler im Feld immer von unten und mit 'aria-describedby'.

5) UX-Muster (wiederholbare Logik)

Formulare: Label links/oben, Platzhalter ≠ Label, Fehler nebeneinander + in der Zusammenfassung, Eingabemasken und Hinweise.
Modalki: ein Haupt-CTA, 'Esc' schließt, Fokusfalle, Fokusrückkehr.
Tabellen/Listen: Sortierung, Sticky-Header, seitenweise, Export.
Filter: explizite Schaltfläche „Anwenden“, Zurücksetzen, gespeicherte Presets.
Benachrichtigungen: Toast ≤ 3-5 s, Pause beim Fokus, 'role = „status/alert“.
Dashboards: Top Insights → Kontext → Grafiken → CTAs.

6) Einheitliche Terminologie und Microcopywriting

6. 1 Glossar

Führen Sie ein einheitliches Glossar von Geschäfts- und UX-Begriffen. Jeder Schnittstellenartikel verweist darauf.
Für Dubletten - wählen Sie ein Wort („Wallet“ vs „Balance“), das zweite - als Synonym bei der Suche.

6. 2 Regeln des Textes

Kurz und bündig; Vermeiden Sie Jargon.
Fehler - erklären, was zu tun ist: „Geben Sie das Datum im Format JJJJ-MM-TT an“.
Überschriften sind Substantive; Schaltflächen - Verben (Speichern, Rückgängig).
Konsistente Einheiten: Datum/Uhrzeit in UTC oder locale, Währungen mit Code (EUR, USD).

7) Ikonographie und Illustrationen

Die Familie ist isomorph: Einzelwinkel, Linienstärke, Raster 24 × 24.
Status und Semantik: Farbe - sekundär; Form/Icon + Text - primär.
Skalierung: Piktogramme „schweben“ nicht in verschiedenen Dichten (1 ×/2 ×/3 ×).

8) Verfügbarkeit (A11y) und Lokalisierung (i18n/RTL)

Die Komponenten durchlaufen WCAG AA: Kontrast, Tastaturnavigation, Fokus, 'prefers-reduced-motion'.
Die zu übersetzenden Zeichenfolgen befinden sich in Ressourcen, nicht im Code. Platzhalter und Zahlen-/Datumsformat sind lokalisierbar.
RTL: Icon-Spiegelung, korrekte Tab-Reihenfolge, DnD-Logik von der Tastatur.

9) Zahlen, Daten, Währungen und Formate

Datum/Uhrzeit: ISO-8601, wahrer Zeitpunkt - UTC; Der Benutzer ist lokal.
Währung: minor units/dezimal strings; immer den Code angeben (z.B. "€12,34" oder "12. 34 EUR" - nach Standort).
Prozentsätze: '12,3%' und Punkte'+ 1,2 pp 'deutlich zu unterscheiden.
Rundung: bis zu signifikanten Entladungen; „k/m“ für große Zahlen.

10) Governans: Rollen, Artefakte, Kanäle

Design Language Council (DLC): Inhaber von Token/Komponenten, nach RFC.

• Komponentenbibliothek (Figma/Code) + Live-Katalog mit Beispielen.
• Dokumentation: Gaidrails, Muster, A11y, Content-Hyde.
• Tschejndschlog mit den Daten, den Niveaus (added/changed/deprecated/removed/fixed).
• Kanäle: wöchentliche Design-Sync, Slack-Kanal, Showcases von Implementierungen.

11) Versionierung und Evolution

SemVer für das Komponentenpaket: 'MAJOR. MINOR. PATCH`.
MINOR - additiv: neue Token, Props mit Defaults, neue Komponenten.
MAJOR - Breaking: Entfernen von Props, Änderung der Semantik → Migrationshydes.
Deprections: Warnungen, Fenster ≥ 90 Tage, Kompatibilitätsflags.

12) Linters und automatische Kontrollen

UI-Linter: Verbotene Farben außerhalb von Token, Anti-Muster (Div-Taste, Outline deaktiviert).
A11y-Checks: Kontrast, Rollen/Aria, Fokus, Tastatur.
i18n-linter: „harte“ Zeilen im Code, falsche Platzhalter.
Screenshot-Tests: Visuelle Regressionen der Komponenten.
Visualisierungs-API-Verträge (falls vorhanden): Datentypen, Bereiche, Signaturen.

13) Komponentenvitrine (Storybook/Sandbox)

Live-Beispiele mit Props-Kontrollen, Code, Staaten, A11y-Checker.
„Rezepte“: Anmeldeformular, Master 3 Schritte, Tabelle + Filter, Modalka + Toast.
„Sandbox locales“: Umschalten von Sprache/Formaten/RTL.

14) Namens- und Strukturmuster

14. 1 Komponenten (EMV/Semantik, Beispiel CSS)

.btn/basic/
.btn--primary/view/
.btn--danger
.btn--lg/size/
.btn __ icon/part/

Der Code enthält monotone Props-Namen: 'size', 'kind', 'disabled', 'onClick'.

14. 2 Dateistruktur der Bibliothek

/tokens
/components
/button
/input
/modal
/patterns
/docs
/changelog

15) Anti-Muster

„Freie“ Farben/Einzüge außerhalb der Token.
Komponenten-Dubletten: „ButtonV2“, „PrimaryButtonNew“.
Platzhalter als einzige Feldmarke.
Deaktivierung der Outline und des „Div-Buttons“.
Unvorhersehbare Hover/aktiv/deaktiviert.
Transliterierte Begriffe statt normaler Übersetzung.
Fehlende Migrationswege bei Updates.

16) Qualitätsmetriken einer einzelnen Sprache

Coverage: Anteil der Bildschirme, die die Komponentenbibliothek verwenden.
Consistency Index: Wiederverwendung von Token gegen „manuelle“ Stile.
A11y Pass Rate: Prozentsatz der Komponenten, die WCAG AA passieren.
Defect Escape: UI/Content Defects in Prod auf 1k Commits.
Time-to-Ship: Zeit für die Implementierung eines typisierten Bildschirms vor/nach DLS.
Adoption: DAU Vitrinen, Anzahl PR mit Komponenten/Mustern.

17) Bildschirm-Checkliste

• Token (Farbe/Einzüge/Radien) werden verwendet, keine „harten“ Werte.
• Komponenten aus der Bibliothek; Nur mit RFC.
• Verfügbarkeit: Tastatur/Fokus/Kontrast/Rolei/aria.
• Einheiten: Datums-/Währungs-/Prozentangaben - auf Basis der Hyde-Formate.
• Mikrokopie: Buttons = Verben, Fehler = Aktion zur Korrektur.
• Locals/RTL machen das Layout nicht kaputt.
• Zustände: loading/empty/error sind vorgesehen.
• Visuelle Regressionstests aktualisiert.

18) Implementierungsplan (3 Iterationen)

Iteration 1 - Fundament (2-3 Wochen)

Tokens (Farbe/Typografie/Spacing/Motion), Basiskomponenten (Button, Input, Select, Tooltip, Modal), Content-Hyde (Ton, Labels, Bugs).
Schaufenster (Storybook) und A11y-Checker, Token-Linter.

Iteration 2 - Muster und Lokalisierung (3-4 Wochen)

Formular-/Tabellen-/Filtermuster, Iconpack 24 × 24, RTL/i18n-Sandbox, Zahlen-/Datums-/Währungsregeln.
SemVer, Changelog, RFC/Migrationsprozess, Autotests (visuell + A11y).

Iteration 3 - Skalierung und Evolution (kontinuierlich)

Kompositionskomponenten (Wizard, DataGrid, Chart primitives), Temmatisierung (hell/dunkel/kontrastierend), Qualitätsmetrikberichte, regelmäßige UX-Audits.

19) Mini-FAQ

Brauchen Sie sofort „alles auf einmal“?
Nein. Beginnen Sie mit Token und Basiskomponenten und fügen Sie dann Muster und Prozesse hinzu.

Wie kann ich Teams davon überzeugen, EYI zu verwenden?
Zeigen Sie Gewinne: Geschwindigkeit, weniger Defekte, fertige Bildschirmrezepte und A11y „out of the box“.

Was tun mit Legacy-Bildschirmen?
Migrationsplan, Brückenstile durch Token, Prioritätsbildschirme sind die ersten.

Summe

Eine einheitliche Schnittstellensprache ist nicht nur eine Bibliothek von Komponenten. Es ist ein System von Regeln und Prozessen, bei denen Token Expressivität, Komponenten - Verhalten und Verfügbarkeit, Muster - Wiederholbarkeit von Entscheidungen und Governance und Metriken - nachhaltige Evolution bestimmen. Machen Sie Ihre Sprache klar, überprüfbar und erweiterbar - und Ihre Produkte werden einheitlich, schnell und zuverlässig aussehen und funktionieren.