{"id":8461,"date":"2018-07-11T12:11:10","date_gmt":"2018-07-11T10:11:10","guid":{"rendered":"https:\/\/www.centigrade.de\/blog\/?p=8461"},"modified":"2019-06-13T20:57:44","modified_gmt":"2019-06-13T18:57:44","slug":"genugt-es-ein-design-system-zu-erstellen","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/genugt-es-ein-design-system-zu-erstellen\/","title":{"rendered":"Gen\u00fcgt es, ein Design System zu erstellen?"},"content":{"rendered":"

\"\"<\/a><\/p>\n

Dieser Artikel besch\u00e4ftigt sich nicht<\/strong> mit den Grundlagen von Design Systemen (wie z.B. \u201eWas ist ein Design System?\u201c, \u201eWie funktioniert es?\u201c, oder \u201eBrauche ich es?\u201c (die Antwort hierauf lautet nat\u00fcrlich \u201eJa\u201c)). Auch Tool-spezifische Themen (Carbon, KSS, Pattern Lab, Sketch, Adobe XD, Invision, UXpin\u2026 es gibt so viele) werden nicht behandelt. Der Artikel soll einen grundlegenden \u00dcberblick der einzelnen Herausforderungen geben, denen sich Firmen stellen m\u00fcssen, wenn sie ein Design System zum ersten Mal etablieren wollen.<\/p>\n

Eine Frage, die wir \u00f6fter von unseren Kunden gestellt bekommen, lautet in etwa so: \u201eWie k\u00f6nnen wir ein Design System erstellen?\u201c oder den Wunsch: \u201eWir m\u00f6chten, dass Centigrade f\u00fcr uns ein Design System erstellt\u201c. Welche Frage dies aber eigentlich impliziert und was f\u00fcr uns als Dienstleister wichtiger ist:<\/p>\n

\u201eGen\u00fcgt es, ein Design System zu erstellen?\u201c<\/p>\n

Die Kurzantwort darauf lautet: Nein.
\nHerzlichen Gl\u00fcckwunsch! Du musst nicht weiterlesen. Jetzt kannst du nach drau\u00dfen gehen und das Leben genie\u00dfen.<\/p>\n

F\u00fcr diejenigen, die nicht gerne drau\u00dfen sind, oder, die etwas mehr in die Tiefe gehen m\u00f6chten, folgt hier die ausf\u00fchrlichere Antwort:<\/p>\n

<\/p>\n

Ein Design System zu bauen ist nicht schwer (es ist viel Arbeit, aber nicht \u00fcberm\u00e4\u00dfig komplex). Das Schwierige ist, die festgelegten Regeln \u00fcber einen langen Zeitraum dort anzuwenden, wo wachsende und dynamische Teams (unterschiedliche Disziplinen und Erfahrung) in unterschiedlichen Umgebungen (Produkte, Arbeitsumgebung, Infrastruktur etc.) arbeiten. Noch schwieriger wird es das System zu erweitern (neue Regeln\/Komponenten\/Konzepte erstellen), alles in die laufenden Arbeitsprozesse zu integrieren und dabei noch konsistent zu bleiben sowie Design Debt<\/a> zu eliminieren. Zudem ist es auch nicht gerade einfach, Mitarbeiter dazu zu motivieren das System \u00fcberhaupt zu benutzen. Es gibt leider kein Template, das f\u00fcr jedes Team\/ jedes Unternehmen\/ jede Plattform\/ jedes Produkt\/ jeden Workflow passend ist. Es bringt nicht viel, wenn man das fancy Carbon Design System f\u00fcr ein Winforms oder Java Produkt benutzt, das Design Team nicht mit Sketch arbeitet oder man noch nicht einmal Designer hat.<\/p>\n

Vielleicht entspricht ein \u201egeschlossenes\/ vorgefertigtes System\u201c dem Workflow deines Teams gar nicht. Vielleicht wird alles \u00fcber Jira\/ Confluence oder Microsoft TFS und Sharepoint geregelt. Dein Entwicklerteam ist es ggf. gewohnt, Tickets zu bekommen, eine Dokumentation zu \u00fcberpr\u00fcfen und dann das Ticket abzuschlie\u00dfen. In dem Fall w\u00e4re es umst\u00e4ndlich, wenn Entwickler an einer ungewohnten Stelle neue Controls suchen m\u00fcssen, deren Dokumentation und Konzeption lesen m\u00fcssen, nur um herauszufinden, dass es sowieso die falsche Komponente war. Nach meiner Erfahrung pr\u00e4ferieren Entwickler spezifische Aufgaben mit spezifischen Parametern.<\/p>\n

Es ist nicht wichtig, ob du PDFs mit roten Linien, Word Dokumente, statische HTML Seiten, Sketch Dateien oder ein super dynamisches und build-server-integriertes living Design System hast. Solange es nicht teil des Standard-Arbeitsprozesses ist, wird es niemand benutzen. Und wenn es nicht einfach zug\u00e4nglich und selbsterkl\u00e4rend ist, wird es dar\u00fcber hinaus niemand korrekt benutzen.<\/p>\n

Die gute Nachricht ist: Solange ihr nicht alles komplett zuf\u00e4llig macht, gibt es schon irgendeine Art von System. Wahrscheinlich aber hilft das aktuelle System noch nicht dabei, konsistente Designs und Usability umzusetzen.<\/p>\n

Brauchen wir ein Design System Team?<\/h3>\n

\"\"<\/a><\/p>\n

Ich bin mir sicher, dass es Unternehmen gibt, die ein Design System erfolgreich betreiben ohne ein dediziertes \u201eDesign Team\u201c zu haben. Allerdings f\u00fchlt es sich deutlich besser an, wenn man feste Ansprechpartner hat, die ausschlie\u00dflich (oder zumindest zum gro\u00dfen Teil) verantwortlich f\u00fcr die Integration und Instandhaltung des Design Systems sind. Ich spreche hier im Plural, da daf\u00fcr niemals eine Einzelperson verantwortlich sein sollte. Erstens, der Arbeitsaufwand ist meist schlichtweg zu hoch (nat\u00fcrlich kommt es hierbei auch auf die Gr\u00f6\u00dfe des Unternehmens\/ Teams\/ Produktes an). Zweitens, wenn man diese Person verliert, verliert man das Design System. Drittens, ein Design System umzusetzen erfordert F\u00e4higkeiten in unterschiedlichen Bereichen. Man ben\u00f6tigt Erfahrung in Visual Design, Usability und Entwicklung (zumindest muss man wissen, was die eigenen Entwickler brauchen und wie sie arbeiten). Die wenigstens werden gen\u00fcgend Erfahrung in all diesen Bereichen haben, um alleine an einem Design System zu arbeiten.<\/p>\n

Mit all diesen netten Tools wie z.B. Carbon Design System<\/a>, Zeplin<\/a> und Brand.ai<\/a> (es gibt mittlerweile so viele wirklich gute Tools und Frameworks) ist es sehr leicht die Integration von Design Systems zu untersch\u00e4tzen. Es scheint als w\u00fcrden Tools momentan mehr Aufmerksamkeit bekommen als Teamkomposition oder die richtigen Arbeitsprozesse, allerdings werden gute Tools am Ende nicht gen\u00fcgen.<\/p>\n

In dem Kontext k\u00f6nnte man Tools mit Musikinstrumenten vergleichen. Wenn man sie nicht spielen kann, oder noch nicht einmal wei\u00df, welches Instrument man \u00fcberhaupt spielen m\u00f6chte, wird man letztendlich keine gute Musik spielen, geschweige denn die M\u00f6glichkeit erhalten, einer Band beizutreten. Ein Schlagzeuger in einer Band ist ein guter Anfang, aber wenn er auch noch Gitarre, Bass und Keyboard spielen soll, wird er vermutlich versagen. Insbesondere wenn er alles gleichzeitig spielen soll.<\/p>\n

Deswegen ben\u00f6tigt man ein interdisziplin\u00e4res Team, das am Design System arbeiten kann. Alles andere wird, h\u00f6chst wahrscheinlich deutlich komplizierter.<\/p>\n

Ich habe ein Team, und nun?<\/h3>\n

\"\"<\/a><\/p>\n

Jetzt da es ein Team gibt, muss es auch M\u00f6glichkeiten haben den laufenden Arbeitsprozess zu hinterfragen. Es ist sehr wahrscheinlich, dass der Prozess ge\u00e4ndert werden muss, um die Integration des Design Systems zu erm\u00f6glichen.<\/p>\n

Das ist entscheidend f\u00fcr die Integration. Das hei\u00dft nicht, dass ein neues Team alleine bestimmen sollte wie alles funktionieren muss. Allerdings m\u00fcssen sie die M\u00f6glichkeit haben mit Entwicklern, Marketing und Projekt Managern zu reden, um zusammen einen Weg zu finden, wie neue Prozesse etabliert werden k\u00f6nnen, die dem gesamten Team helfen.<\/p>\n

Wenn Designer und Entwickler im selben Team arbeiten (gleiche Scrum Sprints z.B.), werden sie zusammen mit den gleichen Herausforderungen konfrontiert. Designer werden besser verstehen was Entwickler ben\u00f6tigen und Entwickler werden besser verstehen was Nutzer wollen (Anforderungen von Designern sind im besten Fall von Nutzeranforderungen geleitet). Diese Zusammenarbeit wird Kompromisse deutlich erleichtern und verbessern.<\/p>\n

Hier sind einige Beispiele von typischen Problemen:<\/p>\n

Selbes Team:<\/h5>\n

Entwickler: \u201cUnser Framework bietet keinen Support f\u00fcr die fancy Combobox mit Bl\u00e4ttern-Funktion, die ihr designed habt. Wir haben au\u00dferdem keine Zeit eine eigene Komponente zu entwickeln.<\/p>\n

Designer: \u201cOk, ich versuche etwas zu machen, das mit unseren Standardcontrols umsetzbar ist.\u201d<\/p>\n

Verschiedene Teams:<\/h5>\n

Entwickler: \u201cIch kann die Designs nicht umsetzen\u2026 dann muss ich mir wohl selbst etwas ausdenken.\u201d<\/p>\n

Selbes Team:<\/h5>\n

Entwickler: \u201cDie Komponente hat deutlich mehr States als im Design spezifiziert. Kannst Du f\u00fcr die Visualisierung der restlichen States bitte neue Entw\u00fcrfe machen?\u201d<\/p>\n

Designer: \u201cklar, kein Problem!\u201d<\/p>\n

Verschiedene Teams:<\/h5>\n

Entwickler: \u201cIch habe keine Designs f\u00fcr die fehlenden States\u2026 muss ich wohl wieder kreativ werden.\u201c<\/p>\n

Es ist nat\u00fcrlich m\u00f6glich verschiedene Teams an verschiedenen Dingen arbeiten zu lassen und trotzdem ein gutes Produkt zu liefern. Aus meiner Projekterfahrung kann ich aber sagen, dass es vieles deutlich vereinfacht, wenn Designer im Entwicklungsprozess<\/a> (z.B. gleiches Scrum Team) von Anfang an voll (z.B. daily Stand Up) eingebunden sind. Wenn ein Design Team nur ein Design System als Tool \u201cliefert\u201d, wird man leider nicht einmal das richtige Feedback der Entwickler bekommen. Wenn nicht sichtbar wird, wie Entwickler genau arbeiten und wie sie mit dem System interagieren, wird man keine echten Probleme erkennen (wird alles gefunden? Fehlt Information? Wird es \u00fcberhaupt benutzt? Was passiert, wenn sie die richtigen Komponenten nicht finden?).<\/p>\n

Des Weiteren, und das ist wichtig, verhindert man, dass sich Fronten bilden. Es ist erfahrungsgem\u00e4\u00df sehr einfach daf\u00fcr zu sorgen, dass sich Entwickler und Designer hassen, solange sie nicht im selben Team an denselben Problemen arbeiten.<\/p>\n

Ich pers\u00f6nlich arbeite sehr gerne mit Entwicklern. Als Designer hilft mir Feedback von Entwicklern extrem weiter. Oft bekommt man eine gute Vorstellung von Power Usern und meistens k\u00f6nnen sie bestimmte Entscheidungen und Einschr\u00e4nkungen besser erkl\u00e4ren (technische Zusammenh\u00e4nge) als Produkt Manager.<\/p>\n

Wir haben ein integriertes Design System, wir sind fertig\u2026 oder?<\/h3>\n

Ein Design System im Arbeitsprozess integriert zu haben ist viel Arbeit. Du kannst sehr stolz sein. Doch leider wird das auf Dauer nicht ausreichen. Dinge werden sich \u00e4ndern. Verschiedene Produkte werden unterschiedliche Stile und Konzepte ben\u00f6tigen. Stakeholder, Produkte oder sogar Tochterunternehmen werden Abwandlungen ben\u00f6tigen. Um darauf reagieren zu k\u00f6nnen, muss das System (und die daran h\u00e4ngenden Arbeitsprozesse) f\u00fcr \u00c4nderungen und alternative Versionen konzipiert sein.<\/p>\n

Man k\u00f6nnte vermuten, dass die einfachste L\u00f6sung w\u00e4re mehrere dedizierte Design Systeme f\u00fcr jedes Produkt zu erstellen. Aber einer der wichtigen Aspekte eines Design Systems ist es, alle Abwandlungen zu einer koh\u00e4renten User Experience (f\u00fcr Nutzer, Kunden und Entwickler) zusammen zu f\u00fchren und diese eben nicht an ein einziges Device oder Produkt zu fesseln.<\/p>\n

Um dies zu erreichen, m\u00fcssen System und Prozess f\u00fcr \u00c4nderungen und alternative Versionen vorbereitet sein. Wenn das System in einer gro\u00dfen und komplexen Umgebung existiert (mehrere Teams, Produkte etc.) ist die Chance hoch, dass Stakeholder ihre Agenda durchbringen wollen. Oft ist es leider keine Top Priorit\u00e4t, dass alles konsistent \u00fcber mehrere Produkte und Devices zusammenspielt (\u201eUnsere Nutzer brauchen keine konsistente Experience \u00fcber alle Produktlinien, die benutzen eh nur ein Produkt\u201c). Das ist bedauerlich, aber in der echten Welt fast unvermeidbar. Die beste Strategie ist darauf vorbereitet zu sein.<\/p>\n

Das bedeutet, dass Komponenten und Konzepte einfach ver\u00e4ndert werden k\u00f6nnen. Es ist au\u00dferdem wichtig zu gew\u00e4hrleisten, dass Komponenten unterschiedliche Versionen oder Varianten haben k\u00f6nnen. Vielleicht ben\u00f6tigt man verschiedene primary Buttons oder einige Komponenten ben\u00f6tigen AR \/ VR support. Vielleicht hat ein Produkt ein anderes Farbschema oder komplett andere Navigationsm\u00f6glichkeiten.<\/p>\n

\"\"<\/a>Es ist unm\u00f6glich zu \u201craten\u201c was f\u00fcr ein Team, geschweige denn Unternehmen am besten funktioniert. Teams und Stakeholder m\u00fcssen definitiv zusammen eine L\u00f6sung finden. Die Verantwortlichkeiten m\u00fcssen au\u00dferdem klar benannt werden. Ansonsten besteht das Risiko, dass ein System (und alle<\/strong> Produkte, die daran h\u00e4ngen) aufgeblasen und sehr komplex zu verwalten wird. Dennoch ist es nat\u00fcrlich OK Ausnahmen zu haben. Konsistenz sollte nicht h\u00f6her als Usability bewertet werden. Aber unabh\u00e4ngig davon sollte klar sein, warum und wo eine Ausnahme existiert.<\/p>\n

Fazit<\/h3>\n

Ein Design System ist nicht einfach ein Tool oder Framework, um Komponenten zu organisieren. Tools sind nicht das wichtigste in einem Design System. Nat\u00fcrlich ist es hilfreich einen living Styleguide zu haben, in dem Designs, CSS und alle custom Komponenten automatisch in jedem Buildcycle aktualisiert werden. Wenn aber niemand dieses System benutzt, wird die Design Sprache trotzdem mangelhaft bleiben und es wird immer schwieriger die Menge an Design Debt unter Kontrolle zu halten. Dabei ist es letztendlich egal ob PDFs oder Carbon als Basis genutzt werden. Das System wird scheitern und auch nicht als Verbesserung zum vorherigen Status wahrgenommen werden.<\/p>\n

Ein Design System sollte komplett im Arbeitsprozess der Mitarbeiter eingebunden sein. Ein dediziertes Team mit Willen und M\u00f6glichkeiten Prozesse und Strukturen zu \u00e4ndern und zu adaptieren ist hierf\u00fcr sehr wichtig und wird dabei helfen eine gemeinsame Design Sprache \u00fcber unterschiedliche Produkte, Teams und Tochterunternehmen zu etablieren.<\/p>\n

Ein gutes Beispiel f\u00fcr ein funktionierendes Design System ist \u201eTouchpoint\u201c, welches wir bei Centigrade zusammen mit TRUMPF entwickelt haben und das mittlerweile mit mehreren Awards wie z.B. Red Dot und iF DESIGN Award ausgezeichnet wurde.<\/p>\n