Das wahre Potenzial von Design-Systemen
Die Design-Welt entwickelt sich immer weiter: "Designer können über Design-Tokens auf die Entwicklung unmittelbar Einfluss nehmen – endlich dauert eine CI-Anpassung nur noch halb so lang!" So oder so ähnlich könnten Sätze in der nahen Zukunft lauten. Aber wie soll das gehen? Designer und Entwickler sprechen doch in komplett unterschiedlichen Sprachen. Und genau hier bieten Design-Systeme den Brückenschlag beim Finden einer gemeinsamen Sprache zwischen Designern und Entwicklern – um besser miteinander arbeiten zu können und viel schneller voranzukommen.
Warum Design-Systeme und was gewinnt man dadurch?
In den letzten Jahren hat sich das Thema Design-Systeme vielseitig und vielschichtig entwickelt. Ein kurzer Blick zurück: Die Digitale Transformation schaffte neue Bedürfnisse und stellte neue Herausforderungen an Unternehmen und Marken.
Im Zuge der Digitalen Transformation ist der lang bestehende kleine Stern "Online Styleguide" im großen Markendesign-Universum explodiert: Die neue Galaxie heißt "Design-Systeme". Der Grundsatz von Design-Systemen ist immer noch derselbe wie der der Styleguides: Vorgaben und Vorlagen zum Einsatz von interaktiven Elementen zur Verfügung zu stellen, die allgemeingültig für das Unternehmen in der Entwicklung digitaler Produkte eingesetzt werden können.
Die Anforderungen sind heute allerdings breiter gefächert als noch vor einigen Jahren. Digitale Anwendungen werden immer komplexer, es gibt immer mehr Frameworks und Devices, auf denen die Anwendungen funktionieren müssen. Sowohl das Design als auch die Entwicklung sind um ein Vielfaches facettenreicher geworden. Benutzer erwarten zu jeder Zeit ein nahtloses Markenerlebnis, egal ob in Form von Unternehmens-Software, Web-Apps, Bedienoberflächen oder X-Reality-Produkterlebnissen.
Die Idee eines Design-Systems versucht dieser Flut an digitalen In- und Outputs Herr zu werden. Es verfolgt den Ansatz der Wiederverwendbarkeit durch Zerlegung und Systematisierung der Bauteile einer Anwendung. Ein Bauteil ist zum Beispiel ein Interaktionselement wie ein Button. Der Button und all seine Varianten werden jetzt in einem gemeinsam abgestimmten System definiert, aufbereitet und funktionstüchtig zur Verfügung gestellt. Dabei handelt es sich im Gegensatz zu einem Styleguide nicht nur um Vorlagen, sondern um einsatzfähige Komponenten. Das Ziel ist es, den aktuellen Stand verfügbarer Buttons mit allen Stakeholdern zu synchronisieren und dadurch ein einheitliches Markenbild zu bewahren. Wie das funktioniert? Ein bisschen wie Lego – eine Anzahl von festgelegten Einzelbausteinen (Komponenten) in einer Kiste mit Angaben zu ihrer Verwendung (Guidelines). Aber anders als bei früheren Styleguides gibt es kein einmaliges Regelwerk anhand einiger Beispiele, sondern agile, sich weiterentwickelnde und einsatzfähige Bausteine für Designer und Developer. Der Fokus von Design-Systemen liegt dabei auf Wiederverwendbarkeit, der Vermeidung von Redundanzen und der Wahrung von Aktualität.
Wie und warum ein Design-System Chancen und Potenziale birgt, dazu finden sich zahlreiche Definitionen und Erklärungen im Internet. Einfach nachzulesen mit Chat GPT Prompts wie z. B. "Design-System als Single Source of Truth" oder "Innovationstreiber Design-System". Diese Definitionen lesen sich schön und spiegeln den theoretischen, fertig umgesetzten und aktiv laufenden Idealzustand eines Design-Systems und seiner Outputs wieder.
Ein gut funktionierendes und richtig eingesetztes Design-System bietet die Möglichkeit, Kosten und Zeit bei der Entwicklung und Umsetzung neuer Produkte einzusparen. Aber wie kommt man dort hin? Wo fängt man an? Welcher Weg ist der richtige für das Unternehmen? Für die Marke? Wen und was brauche ich dafür?
Unsere Erfahrungen im Aufbau und Umgang mit Design-Systemen zeigen, dass eine bessere und effizientere Zusammenarbeit zwischen UI/UX-Designern und Frontend-Developern erfolgt, wenn bereits im Kern, bei der Erstellung von Komponenten, eine gemeinsame Sprache gesprochen wird.
Aus welchen Bausteinen besteht ein Design-System?
Wie oben erwähnt ist ein Design-System im Kern wie eine "digitale Kiste Lego" – ausgestattet mit ausgewählten und definierten Bausteinen und Werkzeugen, um damit arbeiten zu können und Richtlinien, wie damit zu arbeiten ist. Alle digitalen Produkte eines Unternehmens werden aus diesen Bausteinen gefertigt. Ein Design-System gewährleistet so ein durchgängig visuelles und funktionales Erscheinungsbild über alle digitalen Anwendungen eines Unternehmens hinweg. Was sind jetzt die Bausteine, Werkzeuge und Richtlinien eines Design-Systems genau?
- Richtlinien & Dokumentation sind Elemente wie Gestaltungsprinzipien und Brand-Guidelines. Diese geben die strategische und gestalterische Ausrichtung des Unternehmens wieder und vermitteln sie an Nutzer des Design-Systems. Die Dokumentation und Erklärung der Bausteine ist ein wichtiger Teil und für den Betrieb des Design-Systems nicht zu unterschätzen.
- Durch die Bausteine wird das Design-System konkret und anschaulich. Aus den Markendesignelementen werden alle Bausteine definiert. Einfache und komplexe UI-Komponenten, Patterns, Layouts bis hin zu Templates werden kreiert.
- Werkzeuge machen das Design-System mit Design- und Code-Bibliotheken betriebsbereit, die einsatzfähige und wiederverwendbare Komponenten bereitstellen. Diese werden mittels verschiedener Software, Designer- und Developer-Tools erstellt, betrieben und zur Verfügung gestellt. Beispiele dafür sind: Figma, Sketch, Adobe XD, Storybook, Style Dictionary, Github etc.
Wer sind die Stakeholder eines Design-Systems?
Design-Systeme als Single Source of Truth bauen eine Brücke zwischen nichttechnischen und technischen Stakeholdern. Product Manager, Digital-Designer [1] und Software Developer können so effizienter und abgestimmter miteinander neue Produkte entwickeln. Dafür müssen sie verschiedensten Ansprüchen gerecht werden und idealerweise allen Stakeholdern über einen Zugriffspunkt relevante Ressourcen bereitstellen.
Die Entwicklung erfordert also eine übergreifende Zusammenarbeit. Dabei sind UI/UX-Designer und Frontend-Developer treibende Kräfte bei der Erstellung von Design-Systemen. Denn den gestalterischen Kern bilden die Design- und Code-Bibliotheken (Design- und Component-Libraries) und ihre Dokumentation. Darüber hinaus sind bei der übergreifenden Entwicklung Fachleute aus Bereichen wie Branding & Marketing, Research & Strategy sowie Accessibility, Content und dem Projektmanagement wichtig. Sie tragen mit ihrer Nutzerperspektive und fachlichen Kompetenz wesentlich zum erfolgreichen Betrieb eines Design-Systems bei.
Wie läuft die Zusammenarbeit bei einem Design-System?
Wie fängt man am besten an? Was existiert bereits und muss berücksichtigt werden? Mit welchen Tools & Ressourcen wird gearbeitet? Das wichtigste ist, sich ein erreichbares Ziel zu setzen, einen Rahmen abzustecken und loszulegen, auch wenn zu Beginn noch vieles diffus und ungeklärt ist.
- UI/UX-Designer entwickeln, gestalten und arbeiten am Design. Sie definieren die Design-Variablen (Design Tokens), wie Farben, Formen, Typografie, Icons, Illustrationen, Animation, ihr Verhalten und ihr Zusammenspiel im Layout. Sie sind verantwortlich für die Design-Library.
- Frontend-Developer entwickeln, implementieren und arbeiten am User-Interface. Sie definieren die Interface-Oberfläche, ihre Interaktionsfähigkeit und Benutzbarkeit. Sie implementieren die Design-Variablen (Tokens) und sind verantwortlich für die Component-Library.
- Projektmanager organisieren die Aufbereitung und Kommunikation der Ergebnisse von Designern und Developern. Sie ermöglichen den breiten Zugang und die Nutzung der erstellten Komponenten des Design-Systems. Sie steuern und fördern die Dokumentation, den Betrieb und damit maßgeblich den Erfolg des Systems.
Was ist die Rolle von Design-Tokens in der Kommunikation?
Design-Tokens bilden Design-Entscheidungen ab. Sie transportieren die aus der Programmierung bekannte Denkweise in Variablen in die Design-Umgebung. Damit entstehen echte Chancen und großes Potenzial in der Kommunikation und der prozessualen Zusammenarbeit von Designern und Entwicklern. Der Nutzen von Design-Tokens bzw. ein sich Einlassen auf ein gemeinsames Austauschformat zwischen Designern und Entwicklern könnte auch als eine neue, gemeinsame (halbformale) Sprache bezeichnet werden.
Was sind also diese Design-Tokens?
Dazu blicken wir kurz zurück auf die Atomic-Design-Grundsätze von Brad Frost. Atomic Design ist ein Methodenansatz aus dem Development, den Brad Frost im Jahr 2013 für den Aufbau von Web-Applikationen gesetzt hat. Er versucht darin, mit Analogien aus der Chemie, dem Design von Web-Applikationen einen methodischen Ansatz zu verleihen, sich wiederholende Gestaltungsmuster und Grundsätze zu kapseln, zu modularisieren und so wiederverwendbar zu machen. Das Design ist demnach aus Atomen, Molekülen und Organismen aufgebaut [2].
- Atome (zum Beispiel ein Button oder ein Eingabefeld) bilden die kleinste Einheit im Interaction-Design.
- Moleküle (zum Beispiel ein Input-Feld + Button) sind Kombinationen aus solchen Atomen und ergeben wiederum komplexere Interaktionseinheiten.
- Organismen (z. B. ein Header-Bereich, in dem ein Input-Feld + Button integriert sind) vereinen mehrere Moleküle und formen einen noch komplexeren und konkreteren Baustein einer Applikation.
Ändert man ein Atom, beispielsweise den Button, so ändert sich damit auch jedes Molekül und jeder Organismus, welche dieses Atom benutzen. Die Applikation als Summe aller Atome ist damit von jeder Änderung betroffen. Wie auch in den Wissenschaften bereitet eine Entdeckung den Weg für die nächste Entdeckung. Im Brad Frosts Atomic Design wurden Atome ursprünglich als die kleinste mögliche Einheit des Designs beschrieben.
Was aber bestimmt dabei die Eigenschaften eines Atoms? Ein Button-Design besteht zum Beispiel aus Sub-Atomen wie Schrift, Form, Farben, Größe. Diese Einzelbestandteile eines Atoms werden Design-Tokens genannt und als Variablen definiert.
Welchen Sinn macht diese Aufspaltung der Atome in Design-Tokens?
Werfen wir einen genaueren Blick auf das Beispiel in der Grafik: Der Farbwert der Akzentfarbe wird als Variable mit einem konkreten Wert definiert: bg-color-default des Atoms greift auf das Design-Token accent-color-default zu. In accent-color-default als Variable ist ein bestimmter Hexadezimal-Wert gespeichert, der den Farbton definiert.
Ändert sich nun der Wert der Variable accent-color-default, so erfolgt die Anpassung nicht nur an einem Atom, sondern bei allen Atomen, die mit dieser Variablen definiert wurden und damit das gesamte Design.
Wie komplex können Design-Tokens werden?
Um der Komplexität vieler Design-Tokens entgegenzuwirken, hat sich der Ansatz durchgesetzt, die Tokens bzw. Variablen hierarchisch aufeinander aufzubauen und in Gruppen einzusortieren. Die oberste Hierarchie bilden dabei die Component-Tokens, dazwischen liegen die Semantic-Tokens und die Basis bilden die Core-Tokens [3]. Die Design-Tokens verweisen dabei jeweils aufeinander und Design-Änderungen sind dadurch leichter steuerbar.
Tabelle: Es gibt noch keine standardisierte Syntax für die Design-Tokens. Bestehende Tools orientieren sich oft an einem W3C Community Group Draft, den wir hier aufgegriffen haben [4].
| Token Level | Token Name | Token Value |
| Core Token | mw.core.color.pink.500 | #ed2985 |
| Semantic Token | mw.semantic.color.accent. primary.default | {mw.core.color.pink.500} |
| Component Token | mw.component.button.filled. color.bg.default | {mw.semantic.color.accent. primary.default} |
In Analogie zu einem "Headless CMS" kann mit Design-Tokens ein sogenanntes "Headless-Design-System“ entstehen, indem Funktion und Design einzelner Design-Komponenten, wie z. B. ein Button, voneinander getrennt werden. Die Gestaltung eines UI-Elements wird verändert, seine Funktion und Einbettung in der Applikation bleiben bestehen. Integriert man diesen Ansatz im Aufbau eines Design-Systems, entsteht ein adaptives, skalierbares und wiederverwendbares Multi-Marken-Design-System.
Solch ein Umgang mit Variablen und ihrer Referenzierung aufeinander ist für Entwickler nichts Neues. Die Integration in die Design-Umgebung und den -Prozess allerdings schon. Sie bilden eine "echte" Schnittmenge von Design und Entwicklung.
Es gibt derzeit verschiedene Möglichkeiten, Design-Tokens von Design-Systemen festzuhalten und zwischen UI/UX-Design und Frontend-Development zu kommunizieren. Angefangen von einfachen Tabellen, in denen die Tokens aufgelistet sind, über Tools zur Anlage und Verwaltung von Design-Tokens bis hin zu einer Beta-Integration in der bekannten UI/UX-Software Figma. Seit 2023 gibt es in Figma grundlegende Funktionen zur Definition und Verwaltung von Design-Tokens, hier werden sie "Variables" genannt [5].
Inwieweit lässt sich der Workflow automatisieren?
In der kleinsten gemeinsamen Einheit – den Variablen – steckt für die Zusammenarbeit von Designern und Developern viel Potenzial. Mit Design-Tokens kann ein teilautomatisierter Workflow zwischen Design und Frontend hergestellt werden, der Designanpassungen, quasi auf "Knopfdruck", gleich an die Frontend Komponenten ausspielt und umgekehrt.
Das Einbinden von Design-Tokens in Figma und in einer Web-Component Library ermöglicht es, Design und Code zu synchronisieren. Änderungen an den Tokens können durch automatisierte Prozesse an beiden Stellen zugleich sichtbar gemacht werden. Beides dient als Basis zur Gestaltung und zum Aufbau aller Applikationen. Die unterschiedlichen Frameworks greifen bei der Entwicklung von UI-Komponenten auf die Design-Tokens zu. So lebt und wächst sowohl die Design- als auch die Frontend-Library synchronisiert und aufeinander abgestimmt. Und die Design-Tokens sind dabei die DNA-Bausteine.
Zu Beginn bedeutet die Arbeit mit Design-Tokens eine Umstellung der Arbeitsweise als Designer. Die Definition einer Design-Token-Syntax und das Arbeiten mit Design-Tokens sind neue Aufgaben im Umfeld eines Designers. Schnell zeigt sich aber, dass dadurch tatsächlich eine konkretere Kommunikation mit den Entwicklern möglich wird. Designer und Entwickler benutzen gleiche Begrifflichkeiten, sie nähern ihre Sprachen und ihr Verständnis zum Aufbau von Applikationen aneinander an.
In der Projektarbeit wird deutlich, dass mit der Verwendung von Design-Tokens Designentscheidungen einfacher in den Code einfließen. Greifen sowohl Entwickler als auch Designer auf dieselben Design-Tokens zu, entstehen Synergien und eine engere Zusammenarbeit. Wir empfehlen, von Anfang an einen klaren Prozess für die Zusammenarbeit zu definieren und dort, wo es möglich ist, wiederkehrende Arbeitsschritte zu automatisieren und mit Tests und Reviews die Konsistenz und Qualität des Design-Systems sicherzustellen. Die folgende Grafik zeigt unseren Workflow zur teilautomatisierten Synchronisierung von Design und Frontend.
Die Designer gestalten in Figma UI-Elemente. Über ein frei verfügbares Plugin (Tokens Studio) werden alle Design-Styles im Plugin als Tokens definiert [6]. Mittlerweile entwickelt sich das Plugin zu einer eigenständigen Software (Stand 2023). Über das Plugin werden die Tokens in einem Repository synchronisiert. Unser Workflow nutzt dafür GitHub als Plattform. Mittels dieser "Token Farm" werden Design-Tokens zwischen Designer- und Developer-Umgebung synchronisiert und versioniert. Developer haben einfachen Zugang und greifen jederzeit auf den aktuellen Stand zu.
Änderungen der Tokens resultieren im Repository, was einen GitHub Workflow auslöst. Dieser automatisierte Prozess löst zunächst Referenzen zwischen den Tokens auf. Style Dictionary unterstützt im nächsten Schritt, unterschiedlichste Dateiformate aus diesem Input zu erzeugen, wie zum Beispiel CSS- oder Javascript-Variablen. Hier können nach Bedarf beliebige Formate definiert werden, um unterschiedlichste Technologien und Medien zu unterstützen. Bei der Umsetzung dieser Automatisierungsschritte sollte darauf geachtet werden, Änderungen mit Tests und Reviews zu prüfen und versioniert verfügbar zu machen.
Nachdem die Design-Tokens im Anschluss an diesen Schritt für das Web direkt als CSS-Variablen nutzbar sind, werden diese Werte mit einer Component-Library verbunden. Die implementierten Web-Components sind dabei unabhängig von Frontend-Frameworks im Web nutzbar.
Welche Herausforderungen sehen wir beim Aufbau von Design-Systemen?
In unserem IT-Projektalltag haben wir zahlreiche Erfahrungen mit token-basierten Design-Systemen gemacht. Folgende Herausforderungen möchten wir gerne teilen:
Zum einen ist die Erstellung der Design-Komponenten in Verbindung mit dem Aufsetzen einer Design-Token-Logik, deren Verknüpfung und das Referenzieren untereinander, gepaart mit der Erarbeitung einer Syntax-Definition für die Design-Tokens, sehr komplex. Erfahrungsgemäß tritt hier öfter ein Henne-Ei-Problem auf und vieles muss wieder und wieder angefasst und angepasst werden, wenn z. B. die Syntax noch nicht steht und das Design der Komponenten bereits voranschreitet.
Zum anderen ist eine gründliche Dokumentation von Beginn an enorm wichtig. Sie sollte nicht unterschätzt werden. Sobald neue Leute ins Team kommen, steht man ohne gute Dokumentation vor einem Problem. Wie sind die Tokens miteinander verknüpft, wie funktioniert die Schnittstelle zur Development-Umgebung? Wie ist der Workflow genau? Das sind an sich einfache Fragen, wenn sie dokumentiert sind. Weil aber jedes Design-System andere Anforderungen hat und damit auch anders aufgebaut ist, kann vermutlich kein Design-System ohne Dokumentation komplett selbsterklärend sein. Und wir sprechen hier nur von der Dokumentation für Designer und Developer, also für die Libraries. Nicht von einer Dokumentation für andere, nicht-technische Stakeholder.
Die größte Herausforderung ist und bleibt die enge Zusammenarbeit zwischen Designern und Entwicklern – das "Design Engineering". Design-Tools wie Figma und der Einsatz von Design-Systemen bringen Entwickler und Designer näher zusammen. Sie haben mehr Schnittstellen. Vor allem in der Aufbauphase eines Design-Systems ist es wichtig, sich permanent auszutauschen, offene Fragen disziplin-übergreifend zu diskutieren und die Kommunikationsbasis zu definieren. Ist der Kern des Design-Systems aufgesetzt, ist die Zusammenarbeit noch lange nicht am Ende. Ganz im Gegenteil, denn das Design-System ist ein lebender Organismus, der von dem beidseitigen Design- und Development-Input lebt.
Fazit: Am Ball bleiben!
Da das Thema Design-Tokens – nicht nur bei den Global Players – immer mehr zum Standard für Design-Systeme wird, befindet sich die Technologie aktuell in einem stetigen Umbruch. Regelmäßig findet man neue konzeptionelle Ansätze, Ideen und technologische Weiterentwicklungen für den Aufbau eines token-basierten Design-Systems. Auch ist es denkbar, KI-Tools zukünftig zu nutzen, um Design-Systeme und damit einhergehende Prozesse noch effizienter zu gestalten.
Hier gilt es am Ball zu bleiben, abzuschätzen, was Relevanz hat und für einen selbst gut anwendbar ist. Auch wenn es initial viel Aufwand und eine fortwährende intensive Auseinandersetzung bedeutet, lohnt es sich, diesen Weg zu gehen. Ist ein token-basiertes Design-System erst einmal aufgesetzt, kann es im Betrieb die Entwicklungszeit und -kosten für neue digitale Anwendungen erheblich reduzieren und dabei gleichzeitig das einheitliche Erscheinungsbild des Unternehmens wahren.
- Informatik Aktuell – M. Beck: Wir brauchen mehr Digital Design!
Dr. Frank Termer: Rollenideal "Digital Designer" - B. Frost: Atomic Design Mehology
- N. Curtis: Naming Tokens in Design Systems
- W3C Design Token Community Group
- Figma Learn – Figma Variablen erstellen und verwalten
- Tokens Studio for Figma Docs
