Basis für digitale Kreativität?
Design-Systeme.

Toolbox

Was ist ein Design-System und warum brauche ich eins?

„Alles, was zur Design-Entwicklung innerhalb einer Organisation gehört, macht ein Design-System aus“, so der Designer Brad Frost. Dazu zählen allgemeingültige Design-Prinzipien und Testing-Methoden genauso wie konkrete UI- und Code-Komponenten oder Tools für Teams. Und wie jedes andere Produkt benötigt es einen definierten Prozess, Ressourcen und Ownership, um erfolgreich zu sein. Der Designer Nathan Curtis nennt es „kein Projekt, sondern ein Produkt, das Produkten dient“.

Welche Vorteile bietet mir ein Design-System?

Durch klare Vorgaben und Wiederverwendung von Design-Elementen beschäftigt man sich als Designer mit den eigentlichen Fragen rund um ein Produkt, anstatt Design-Bausteine und Prozesse im Kleinen ständig neu zu erfinden. Man konzentriert sich auf die User Experience und macht kontextbasiert punktgenaue Vorschläge und Empfehlungen für die Nutzer. Außerdem spart man Zeit und Geld und gewinnt enorm an Geschwindigkeit beim Launch des nächsten Produkts. Die Wiederverwertung von Komponenten hilft Entwicklern, Redundanzen zu vermeiden und letztlich bis zu 20 Prozent Entwicklungszeit zu sparen. Nicht nur die Produktreife wird schneller erreicht, sondern gleichzeitig steigt auch die Qualität des Ergebnisses, weil das System solide getesteten Code anbietet und dessen Einsatz die Performance schlank und schnell macht. 

Und was ist ein Styleguide?

Die erste Anlaufstelle in einem Design-System ist der Styleguide. Er stellt quasi das Schaufenster eines Shops dar und gibt einen Überblick über das gesamte Angebot an Design-Elementen. (Das gesamte System wäre damit ähnlich der Nachbarschaft oder der Straße, an der der Shop liegt).

Während Schaufenster-Besucher aus der gesamten Organisation kommen können, interessiert sich eine kleine Zahl von Leuten eher für die Werkstatt im Hinterhof. Diese Leute heißen „Designer“ oder „Entwickler“. Sie bauen die Einzelteile – die Toolbox –, halten das System am Laufen und erfinden eine gemeinsame Sprache für die Dinge. (Diese ist übrigens entscheidend, denn ein Styleguide richtet sich an Macher und Nutzer des Design-Systems gleichermaßen.)

Die Toolbox ist die Summe der vielen Kleinteile, die künftige Teams brauchen werden, um neue Produkte zu entwickeln (oder um existierende zu erweitern) – Websites, Apps, Prototypen, Kampagnen.

Bei der Arbeit in der Werkstatt kommen Tools wie Sketch (UX, Design-Entwicklung), InVision (Austausch im Design-Prozess), Confluence (Dokumentation finaler funktionaler UX- und Design-Spezifikationen) und auch Slack (Kollaboration im Team) zum Einsatz. Der Styleguide ist der konkrete und greifbare Mittelpunkt eines Design-Systems.

Warum ist verständliche Sprache in einem Design-System so wichtig?

Bereits beim Gestalten sollte das Projektteam Ihrer Agentur auf eine klare Sprache und Systematik der Elemente achten und ID-basiert arbeiten. Das erfordert Abstimmungsaufwand vorab, zahlt sich aber unmittelbar aus, sobald Ihr Team und/oder der Zeitdruck wächst.

Beispiel: Miles & More
Bei der Design-Entwicklung der neuen Miles & More Website hat unser Design-Team jede einzelne Komponente detailliert beschrieben und die Abstände zwischen und innerhalb von Komponenten mit individuellen IDs belegt (spx1, spx8, spx160 etc.). Die Abstandslogik richtete sich dabei nach dem Basisraster 8px x 8px aus Googles Material Design.

Diese systematische und allgemein verständliche Beschreibung half dem Team aus fünf Designern auch über verschiedene Standorte hinweg, zügig ein konsistentes Ergebnis zu schaffen.
Die Abstände waren – wie jedes andere Design-Element auch – in einer Sketch-Bibliothek ständig für alle Teammitglieder verfügbar.

Spacing MaterialMaM Spacing

Wie bleibt mein Design-System aktuell?

Waren in der Vergangenheit PDF-basierte Styleguides das Kommunikations-Tool erster Wahl, so steht heute ein Unternehmen vor den Fragen, wie tief ein Design-System in den Produktentwicklungsprozess integriert wird und ob ein Steuerungshebel etabliert werden soll.

Die folgende Übersicht zeigt die Entwicklungsgeschichte von Design-Systemen:

Maturity Model

Der Heilige Gral der Design-Systeme … Live Code. Jedes UI-Element ist mit HTML-Code hinterlegt, der synchron mit der echten Produktionsumgebung ist. Wenn das nicht der Fall ist, entsteht neuer Inhalt, der aufwendig gepflegt werden muss.

Live Code setzt voraus, dass Code teilbar ist (zwischen der Komponenten-Library und der Entwicklungsumgebung), versioniert ist und aktuell gehalten wird. Das Thema Aktualität ist wichtig, und Tools wie Bower, Grunt, Gulp automatisieren diesen Prozess bis zu einem gewissen Grad. Noch entscheidender ist allerdings die Governance – eine Person, die die Implikationen einer Änderung (einer Komponente) für alle Produkte versteht, in denen sie zum Einsatz kommt.

Wichtig ist hier ein technischer Lead bzw. eine zentrale Instanz, die für die Code-Qualität verantwortlich ist.


Beispiel: MAN Design-System
Als Lead-Agentur für MAN hält unser Entwicklungsteam den Code über alle Instanzen der betreuten Kanäle hinweg aktuell. Unser Team versioniert (und hostet) den Code in Git und kann dessen aktuellen Stand mittels eines Skripts in MANs Styleguide einspielen. So entsteht ein einheitlicher Wissensstand für alle MAN Nutzergruppen sowie eine konsistente UI über alle Kanäle.

Workflow Frontify

Wie viele Leute brauche ich für mein Design-System?

Salesforce hat seiner Komponenten-Library ein ganzes Team gewidmet. Ganz so weit muss man nicht gehen. Die Frage „Wie skaliert man ein Team für ein Design-System?“ hat der Designer Nathan Curtis so beantwortet: Man braucht ein kleines föderales Team der besten Leute aller Produktteams, bestenfalls eine Mischung diverser Disziplinen. (Gut auch deshalb, weil so die Ergebnisse automatisch wieder in die Teams zurückgetragen werden.) Die eigentliche Dokumentation erfolgt zentral durch eine oder zwei Personen, die einen Teil ihrer Teamrolle exklusiv dieser Aufgabe widmen. Sie schreiben Texte für Guidelines, bauen Komponenten in den Code, machen Updates zu Templates, pflegen zum Beispiel Sketch Libraries. Fazit: Ohne Ownership und feste Rollen wird ein Design-System nicht lange überleben. Föderal entscheiden, zentral dokumentieren.

Im Fall von MAN haben wir ein Micro-Team gestellt, bestehend aus Lead Developer, UX und Art Director. Die drei prüfen neue Anforderungen, halten das System schlank, verhindern Wildwuchs und setzen Impulse für neue Komponenten.

Macht ein Design-System meine Produkte nicht langweilig?
Wo bleibt die Innovation?

Entgegen verbreiteter Meinung, dass ein Design-System den Status quo festschreibt, langweilig ist und Innovation verhindert, ist es vielmehr so, dass – wenn man es richtig denkt – das System zu neuen innovativen Ideen ermutigt. Innovation kann in jedem laufenden Projekt entstehen, hier hat ein Team die Chance, das System herauszufordern und zu erweitern und gegebenenfalls auch eine Komponente gänzlich zu ersetzen. Ein „virtuous cycle“, meint Designer Josh Clark: "Die neuen coolen Tricks werden in Folge die neue Routine, bis zur nächsten Idee..."                                                                                                                                                                                              

Zitat HillaHilla Neske, 17.05.2018