„Wo ist nochmal der Button in groß – und warum gibt es drei fast gleiche?“ Solche Fragen tauchen in Teams fast immer dann auf, wenn ein Designsystem wächst. Der Hauptgrund ist selten mangelndes Design-Können, sondern ein fehlendes, gemeinsames Benennungsschema. Ein gutes Naming macht UI-Assets auffindbar, reduziert Missverständnisse und sorgt dafür, dass neue Teammitglieder schneller produktiv sind.
Wichtig dabei: Naming ist kein Selbstzweck. Es ist ein Vertrag zwischen Design, Entwicklung und Content. Je klarer dieser Vertrag ist, desto weniger wird „nach Gefühl“ gebaut – und desto weniger entstehen Varianten, die niemand pflegt.
Warum konsistentes Naming in UI-Bibliotheken so viel Zeit spart
In der Praxis entstehen Naming-Probleme meist schleichend: Erst kommen ein paar Komponenten hinzu, dann Varianten, dann neue Seiten und Kampagnen. Plötzlich ist die Library voll, aber die Suche liefert zehn Treffer mit ähnlichen Namen. Ein sauberes System verhindert genau diese Reibungspunkte.
Typische Symptome von schlechtem Naming
- Assets sind schwer zu finden (Suche liefert zu viele oder zu wenige Ergebnisse).
- Gleiche Dinge heißen unterschiedlich („Primary Button“, „Main CTA“, „Button/Primary“).
- Unklare Zustände (ist „disabled“ ein Zustand oder eine eigene Komponente?).
- Lokale Workarounds statt Wiederverwendung (neue Komponente statt Variante).
- Mehr Abstimmung in Reviews, weil Begriffe nicht eindeutig sind.
Was gutes Naming leistet
Ein einheitliches Schema sorgt dafür, dass Komponenten logisch gruppiert sind und Varianten sich nachvollziehbar lesen. Das hilft nicht nur in Figma, sondern auch im Handoff und beim Mapping auf Code. Besonders wirksam ist das, wenn parallel auch Typografie, Abstände und Farben klar strukturiert sind (siehe Design Tokens im UI: Abstände, Farben und Schrift sauber steuern).
Ein Naming-System, das Design und Entwicklung gemeinsam tragen
Ein Naming-System funktioniert nur, wenn es beide Seiten abholt: Designer:innen brauchen schnelle Orientierung und gute Suchbarkeit, Entwickler:innen brauchen Stabilität und eindeutige Begriffe. Dafür sind drei Prinzipien entscheidend.
Prinzip 1: Einheitliches Muster statt kreative Namen
Statt „sprechender“ Fantasienamen ist ein strukturiertes Format besser. Bewährt hat sich die Logik: Objekt → Rolle → Variante → Zustand. So bleibt der Name lesbar, aber auch maschinen- und suchfreundlich.
Beispiele (vereinheitlicht):
- Button / Primary / Size: M / State: Default
- Button / Primary / Size: M / State: Hover
- Input / Text / Size: M / State: Error
Prinzip 2: Gleiche Begriffe in Design und Code
Wenn im Code von „primary“ und im Design von „main“ gesprochen wird, ist Chaos vorprogrammiert. Sinnvoll ist eine kleine, gemeinsame Vokabelliste (z. B. primary/secondary/tertiary; default/hover/active/disabled). Das reduziert Diskussionen bei jeder neuen Komponente.
Gerade bei Interaktionen lohnt es sich, Zustände sauber zu definieren – viele Teams klären das im Zuge von State-Design (siehe UI-States designen – Hover, Active, Disabled sauber lösen).
Prinzip 3: Stabilität vor Perfektion
Ein System muss nicht „für immer“ perfekt sein – aber es muss stabil bleiben. Häufiges Umbenennen zerstört Verknüpfungen, macht Dokumentation unzuverlässig und kostet Zeit. Besser: Regeln festlegen, später behutsam migrieren und Altlasten gezielt abbauen.
Konkrete Regeln für Komponenten-Naming (mit Beispielen)
Damit Naming im Alltag funktioniert, braucht es wenige, aber klare Regeln. Die folgenden Punkte sind so formuliert, dass sie in kleinen Teams ebenso funktionieren wie in großen Designsystemen.
Regel A: Erst die Komponentengruppe, dann die Spezialisierung
Die erste Ebene sollte immer die „Familie“ sein (Button, Input, Card, Modal). Danach folgt die Rolle (Primary, Secondary, Danger). So bleiben ähnliche Dinge zusammen.
- Button / Primary
- Button / Secondary
- Button / Danger
Regel B: Varianten als Attribute, nicht als neue Komponenten
„Größe“, „Icon links/rechts“, „Full width“ sind oft Varianten, keine neuen Komponenten. Werden daraus eigene Komponenten, wächst die Library unnötig. In Figma helfen Varianten und Properties (Eigenschaften), damit sich ein Button konfigurieren lässt statt dupliziert zu werden. Wer Layouts ohnehin flexibel baut, kann das gut mit Auto Layout kombinieren (siehe Figma Auto Layout meistern – flexible UI-Layouts mit System).
Regel C: Zustände klar benennen und wiederverwenden
Zustände sollten überall gleich heißen. Ein Button hat „hover“, ein Input hat „focus“ – aber die Schreibweise bleibt konsistent. Wichtig: Zustände gehören nicht in kreative Abkürzungen, sondern in klare, wiedererkennbare Begriffe.
Varianten, Properties und Layer: was wie benannt wird
Benennung betrifft nicht nur die Komponente, sondern auch ihre inneren Bausteine. Je sauberer die Struktur, desto weniger „Warum ist das so?“ in Reviews.
Properties (Eigenschaften) nach Nutzerentscheidung benennen
Properties sollten die Entscheidung beschreiben, die jemand trifft: „Size“, „State“, „Icon“, „Width“. Keine internen Konstrukte wie „v2“ oder „neu“. Beispiele:
- Size: S / M / L
- State: Default / Hover / Active / Disabled
- Icon: None / Leading / Trailing
- Width: Hug / Fill
Layer-Namen: kurz, funktional, wiederholbar
Layer sollten die Aufgabe beschreiben, nicht die Optik. „Label“ ist besser als „Text White“, weil sich die Farbe ändern kann. Sinnvolle Layer-Namen sind z. B. Label, Icon, Container, Helper text, Error text.
Wer dazu passende Textregeln etablieren will, kann Microcopy parallel vereinheitlichen (siehe UI-Text im Webdesign: Microcopy, die Nutzer führt).
Kurzer Ablauf, der in jedes Team passt
- Komponentenliste erstellen: Welche Bausteine sind „Grundausstattung“ (z. B. Button, Input, Select, Card)?
- Vokabular festlegen: primary/secondary, default/hover/active/disabled, size S/M/L.
- Namensmuster definieren: Gruppe / Rolle / Attribute / Zustand.
- Library bereinigen: Dubletten zusammenführen, alte Namen auf neue mappen.
- Regeln dokumentieren: 10 Zeilen reichen, Hauptsache sichtbar und verbindlich.
Vergleich: kurzes Naming vs. sprechendes Naming
| Ansatz | Vorteile | Nachteile |
|---|---|---|
| Sehr kurz (z. B. „Btn P M“) | Schnell zu tippen, kompakt | Schlecht verständlich, schwer für neue Teammitglieder, fehleranfällig |
| Strukturiert (z. B. „Button / Primary / Size: M / State: Default“) | Leicht zu suchen, eindeutig, gut für Handoff | Etwas länger, braucht Regeln |
| Sehr sprechend (z. B. „Großer Hauptbutton Startseite blau“) | Wirkt im Moment verständlich | Wird schnell falsch, wenn sich Kontext oder Farbe ändern; uneinheitlich |
Entscheidungshilfe: neue Komponente oder neue Variante?
Viele Naming-Probleme entstehen, weil zu früh neue Komponenten erstellt werden. Eine kleine Entscheidungslogik hilft, konsistent zu bleiben:
- Ändert sich nur die Darstellung, aber die Funktion bleibt gleich?
- Ja → Variante (z. B. Größe, Icon, Breite).
- Nein → weiter prüfen.
- Gibt es andere Regeln für Verhalten oder States?
- Ja → eigene Komponente (z. B. Button vs. Toggle).
- Nein → weiter prüfen.
- Ist es ein anderes Muster mit anderer Erwartung der Nutzer?
- Ja → eigene Komponente (z. B. Input vs. Search field mit Vorschlägen).
- Nein → Variante.
Häufige Fragen aus Projekten (und klare Antworten)
Sollte Naming auf Deutsch oder Englisch sein?
Entscheidend ist die Teamrealität: Wenn Design, Code und Tickets überwiegend auf Englisch laufen, ist Englisch konsistenter. Wenn das Team klar deutsch arbeitet und die Entwicklung ebenfalls, ist Deutsch möglich. Wichtig ist weniger die Sprache als die Einheitlichkeit. Mischformen („Primary“ neben „Fehlerzustand“) sollten vermieden werden.
Wie geht man mit Legacy-Namen um?
Legacy (Altbestand) ist normal. Sinnvoll ist ein klarer Cut: Neue Komponenten folgen den Regeln, bestehende werden bei Bedarf migriert. Für eine Übergangszeit kann eine kleine Mapping-Liste helfen („Altname → Neuer Name“), damit niemand blockiert.
Welche Rolle spielen Design Tokens beim Naming?
Tokens sind benannte Werte (z. B. Farben, Abstände, Typografie), die im Designsystem wiederverwendet werden. Wenn Tokens sauber benannt sind, werden Komponenten einfacher: Statt „Blue-500“ oder „Spacing-16“ nach Gefühl zu nutzen, greifen Teams auf konsistente Begriffe zurück, die auch im Code Sinn ergeben.
Praxisbeispiel: Button-Familie mit klarer Struktur
Eine häufige Baustelle ist der Button. Oft gibt es „Primary“, „CTA“, „Main“, „Submit“ und „Weiter“ als getrennte Komponenten. Besser ist eine Familie, die alles abdeckt.
Empfehlung als Struktur:
- Komponenten-Naming: Button / Role / Size / State / Icon
- Role: Primary, Secondary, Tertiary, Danger
- Size: S, M, L
- State: Default, Hover, Active, Disabled, Loading
- Icon: None, Leading, Trailing
Das Ergebnis: Statt zehn Button-Komponenten existiert eine Button-Komponente mit klaren Varianten. Das verbessert Suche, Konsistenz und Pflegeaufwand.
Wie Naming im Team verankert wird, ohne zu nerven
Regeln bringen nur dann etwas, wenn sie im Alltag funktionieren. Statt langer Dokus helfen kleine, sichtbare Touchpoints:
- Ein kurzer Naming-Guide direkt in der Library-Beschreibung oder im ersten Frame.
- Review-Routine: Bei neuen Komponenten wird Naming genauso geprüft wie Abstände und States.
- Ein „Owner“-Prinzip: Eine Person oder ein kleines Duo entscheidet bei Grenzfällen, damit Diskussionen nicht ausufern.
- Einmal pro Quartal aufräumen: Dubletten markieren, veraltete Komponenten archivieren.
Wenn Reviews ohnehin stattfinden, lohnt zusätzlich ein strukturierter Blick auf Konsistenz (siehe Design Review im Webdesign – Feedback, das wirklich hilft).
Mini-Standard, der sofort startet: 10 Regeln in einem Satz
Ein schneller Start ist besser als ein perfektes Konzept. Als Basis reicht oft dieser Standard: Gruppe zuerst, Rolle danach, Attribute als Properties, Zustände einheitlich, keine optischen Begriffe im Namen, keine Kontextnamen (wie „Startseite“), keine Versionsnummern, keine Abkürzungen, gleiche Schreibweise, und Änderungen nur mit Plan.
Naming-Konventionen sind am Ende ein Werkzeug für Zusammenarbeit: weniger Suchzeit, weniger Doppelarbeit, klarere Übergaben. Wer das System klein startet und konsequent hält, bekommt ein Designsystem, das mitwächst – statt zu zerfasern.
