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.

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.