Naming Convention: eine Hilfestellung für die Struktur von Design Systemen

In der Kommunikation und beim Austausch mit den Kolleg:innen ist es eher unproblematisch, da die meisten Benennungen doch irgendwie geläufig sind und jede:r jede:n versteht. Aber bei der Arbeit mit Design Systemen, wo mehrere unterschiedliche Parteien auf eine “Single Source of Truth” zurückgreifen, können inkonsistente Schreibweisen Fehler verursachen und zu mehr Zeitaufwand führen.

Ein Beispiel hierfür ist die Übergabe von Icons an die Entwicklung. Sind diese nicht korrekt im Design System benannt, um sie effizient zu implementieren, muss der/die Entwickler:in jedes Icon nach dem Export nochmal händisch umbenennen. Eine Fleißarbeit, die man sich durch eine Festlegung der Schreibweise im Vorhinein hätte sparen können.

Das Gleiche gilt bei der Suche nach Assets in Figma. Gibt man hier nicht die exakt richtige Schreibweise ins Suchfeld ein, wie etwa “btn” vs. “button”, braucht man länger, um einzelne Elemente zu finden. Oder die Suche verläuft schlichtweg ins Leere. Ein unnötiger Zeitaufwand für die Teammitglieder, die das Design System aufbauen und für alle Parteien, die das Design System für ihre Projekte nutzen.

Auch Missverständnisse können entstehen, wenn Benennungen nicht eindeutig definiert sind. Ein Beispiel dafür: In unserem Team hat sich erst während eines Austausches herauskristallisiert, dass ein Tool-Tip und ein Pop-up-Tip nicht dasselbe sind. Die beiden Elemente sind sich zwar sehr ähnlich, aber die Funktionalität ist verschieden, wenn auch minimal. (Ein Pop-up-Tip muss im Gegensatz zum Tool-Tip aktiv geschlossen werden.) Missverständnisse wie diese führen zu unnötigen Absprachen, zeitraubenden Diskussionen und nachträglichen Anpassungen, die man sich gern erspart.

Das alles sind nur kleine Hiccups, aber unterm Strich hat es jedes Mal Zeit gekostet – manchmal schlichtweg auch Nerven. Umso klarer wurde uns: Eine einheitliche Naming Convention muss her.

Aber wie dokumentieren wir diese? Wie schaffen wir eine Hilfestellung, worauf sowohl interne als auch externe Designer:innen, Entwickler:innen, Stakeholder und weitere involvierte Parteien Zugriff haben?

Da nun die Bedingungen unserer Hilfestellung definiert waren, haben wir zuallererst in einem Audit die wichtigsten und meist genutzten UI-Elemente, Komponenten und Styles gesammelt und geclustert. Diese Liste haben wir anschließend mit allen uns bekannten Benennungen ergänzt und die gängigsten Varianten im Vorfeld markiert.

Das Ergebnis wurde dann in Abstimmungsterminen mit Teammitgliedern aus anderen Gewerken wie UI, UX und Entwicklung abgeglichen, um gemeinsam einen Favorit pro Element festzulegen. Durch diesen Austausch konnten wir einen Einblick gewinnen, wie z. B. unsere Entwickler:innen die Elemente im Code benennen, was generell geläufiger ist und ob Kund:innen eventuell eine Präferenz haben. Schließlich war es uns wichtig, eine Entscheidung zu treffen, die für alle Teammitglieder logisch ist und funktioniert.

In einem Google Sheet Dokument haben wir dann unsere First-Choice-Benennungen als Konvention festgelegt und alle weiteren Varianten als Alternativen gekennzeichnet. Online hinterlegt, hat jede:r jederzeit Zugriff auf das Dokument und es lässt sich unkompliziert von jedem/jeder anpassen und duplizieren. Kann oder möchte ein Kunde den Google-Dienst nicht nutzen, können wir das Dokument als PDF oder Excel-Datei herunterladen und zur Verfügung stellen.

Der Teufel steckt im Detail, das wurde schnell deutlich. Denn: Nicht nur für die Benennungen von einzelnen Komponenten muss gesorgt werden, sondern auch folgende Aspekte sind relevant und sollten durchdacht sein:

states: "idle" vs. "default"
Selbst die States von interaktiven UI-Elementen benötigen eine einheitliche Benennung. Heißt es z. B. beim Button "default", aber beim Input-Field "idle", dann ist das inkonsequent und birgt Fehlerpotential. Wir haben als Konvention die weitaus gängigere und somit auch verständlichere Benennung "default" festgelegt. In unserer Abstimmung hatte sich herauskristallisiert, dass der Begriff "idle" nicht allen Nutzer:innen geläufig ist.

sizes: “extra-small" vs. "xs"
Ähnlich wie bei den States können die Benennungen auch bei den Größen auseinandergehen. Entsprechend kann die Suchfunktion für Nutzer:innen des Design Systems ergebnislos verlaufen. Wer z. B. "xs" eingibt, wird "extra-small" nicht finden. Wir haben uns für die kürzere und somit handliche Variante "xs" entschieden. Sie ist schneller zu schreiben und somit auch schneller zu suchen.

title case vs. lower case
Last but not least hat die Schreibweise “groß oder klein” zwar keine Auswirkung auf die Suchfunktion, eine einheitliche Schreibweise aber hilft, Fehlerquellen zu umgehen. Die Entscheidung fiel uns leicht: Da die UI-Benennungen in der Regel auf Englisch sind, werden sie dementsprechend klein geschrieben. Wir haben uns daher auf die durchgehende Verwendung von Kleinbuchstaben geeinigt. Das ist konsequent und praktisch, denn die Überlegung, wann etwas groß geschrieben werden muss, fällt für alle Anwender:innen weg.

Wir haben schnell gemerkt: Eine gemeinsame Sprache festzulegen, die alle ab sofort lernen und zu hundert Prozent anwenden, ist weder umsetzbar noch praktikabel. Und auch gar nicht notwendig: Denn als viel wichtiger stellte sich heraus, dass wir alle Teammitglieder dafür sensibilisiert haben, wie wichtig es ist, auf eine einheitliche Benennung von UI-Elementen zu achten.

Durch diese Sensibilisierung haben wir den aktiven Austausch im Team gefördert. Wir suchen früher und gezielter das Gespräch in Teammeetings, um beispielsweise bei ähnlichen Komponenten wie z. B. Content Switcher, Tab und Segmented Control zu definieren, wo genau ihre funktionalen Unterschiede liegen. Dadurch sind alle Teammitglieder im Loop und die Definitionen werden in unserem Dokument festgehalten.

Darüber hinaus hilft uns das Dokument auch immer wieder als Nachschlagewerk bei Unklarheiten und ist dazu ein wertvoller Onboarding-Input für alle neuen Teammitglieder.

**Aber wie kommt das Dokument bei Kundenprojekten zum Einsatz? **

Bevor wir beispielsweise mit der Arbeit an einer Pattern Library beginnen, duplizieren und teilen wir die Datei mit den relevanten Parteien. So kann z.B. das externe Development-Team gegenprüfen, ob es Benennungen gibt, die sie im Code anders verwenden würden. Alle Abweichungen werden in der duplizierten Datei festgehalten, damit sowohl in unseren Design-Files, als auch in sonstigen Übergabe-Dokumenten und im finalen Code dieselben Begrifflichkeiten verwendet werden.

Mit unserem Dokument haben wir eine Basis geschaffen, die flexibel und individuell für jedes Kundenprojekt erweitert und angepasst werden kann. Sie eint die Sprache von gewerkeübergreifenden Teams und minimiert so Missverständnisse und Zeitaufwand. Dank der Naming Convention lassen sich unsere Design Systeme intuitiver und effizienter nutzen. Daher können wir guten Gewissens sagen, dass sich die Zeit, die wir in unsere UI-Benennungen gesteckt haben, definitiv gelohnt hat.

Give-Away: Unsere Dokumentation für Naming Conventions

Möchtet Ihr auch ein Dokument für einheitliche UI-Benennungen erstellen? Dann könnt Ihr Euch hier unsere Vorlage kopieren.

Zur Vorlage