Sie verwenden derzeit einen Browser, der nicht mehr unterstützt wird und bei dem es daher zu Darstellungsfehlern kommen kann. Wechseln sie den Browser, um ein noch schöneres Design zu erleben.

Cookies helfen uns bei der Bereitstellung unserer Dienste. Durch die Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies setzen. Mehr erfahren.

Close

Über den Tellerrand geschaut

Genügt es, ein Design System zu erstellen?

Günter Pellner

Dieser Artikel beschäftigt sich nicht mit den Grundlagen von Design Systemen (wie z.B. „Was ist ein Design System?“, „Wie funktioniert es?“, oder „Brauche ich es?“ (die Antwort hierauf lautet natürlich „Ja“)). Auch Tool-spezifische Themen (Carbon, KSS, Pattern Lab, Sketch, Adobe XD, Invision, UXpin… es gibt so viele) werden nicht behandelt. Der Artikel soll einen grundlegenden Überblick der einzelnen Herausforderungen geben, denen sich Firmen stellen müssen, wenn sie ein Design System zum ersten Mal etablieren wollen.

Eine Frage, die wir öfter von unseren Kunden gestellt bekommen, lautet in etwa so: „Wie können wir ein Design System erstellen?“ oder den Wunsch: „Wir möchten, dass Centigrade für uns ein Design System erstellt“. Welche Frage dies aber eigentlich impliziert und was für uns als Dienstleister wichtiger ist:

„Genügt es, ein Design System zu erstellen?“

Die Kurzantwort darauf lautet: Nein.
Herzlichen Glückwunsch! Du musst nicht weiterlesen. Jetzt kannst du nach draußen gehen und das Leben genießen.

Für diejenigen, die nicht gerne draußen sind, oder, die etwas mehr in die Tiefe gehen möchten, folgt hier die ausführlichere Antwort:

Ein Design System zu bauen ist nicht schwer (es ist viel Arbeit, aber nicht übermäßig komplex). Das Schwierige ist, die festgelegten Regeln über 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 zu eliminieren. Zudem ist es auch nicht gerade einfach, Mitarbeiter dazu zu motivieren das System überhaupt zu benutzen. Es gibt leider kein Template, das für jedes Team/ jedes Unternehmen/ jede Plattform/ jedes Produkt/ jeden Workflow passend ist. Es bringt nicht viel, wenn man das fancy Carbon Design System für ein Winforms oder Java Produkt benutzt, das Design Team nicht mit Sketch arbeitet oder man noch nicht einmal Designer hat.

Vielleicht entspricht ein „geschlossenes/ vorgefertigtes System“ dem Workflow deines Teams gar nicht. Vielleicht wird alles über Jira/ Confluence oder Microsoft TFS und Sharepoint geregelt. Dein Entwicklerteam ist es ggf. gewohnt, Tickets zu bekommen, eine Dokumentation zu überprüfen und dann das Ticket abzuschließen. In dem Fall wäre es umständlich, wenn Entwickler an einer ungewohnten Stelle neue Controls suchen müssen, deren Dokumentation und Konzeption lesen müssen, nur um herauszufinden, dass es sowieso die falsche Komponente war. Nach meiner Erfahrung präferieren Entwickler spezifische Aufgaben mit spezifischen Parametern.

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änglich und selbsterklärend ist, wird es darüber hinaus niemand korrekt benutzen.

Die gute Nachricht ist: Solange ihr nicht alles komplett zufällig macht, gibt es schon irgendeine Art von System. Wahrscheinlich aber hilft das aktuelle System noch nicht dabei, konsistente Designs und Usability umzusetzen.

Brauchen wir ein Design System Team?

Ich bin mir sicher, dass es Unternehmen gibt, die ein Design System erfolgreich betreiben ohne ein dediziertes „Design Team“ zu haben. Allerdings fühlt es sich deutlich besser an, wenn man feste Ansprechpartner hat, die ausschließlich (oder zumindest zum großen Teil) verantwortlich für die Integration und Instandhaltung des Design Systems sind. Ich spreche hier im Plural, da dafür niemals eine Einzelperson verantwortlich sein sollte. Erstens, der Arbeitsaufwand ist meist schlichtweg zu hoch (natürlich kommt es hierbei auch auf die Größe des Unternehmens/ Teams/ Produktes an). Zweitens, wenn man diese Person verliert, verliert man das Design System. Drittens, ein Design System umzusetzen erfordert Fähigkeiten in unterschiedlichen Bereichen. Man benötigt Erfahrung in Visual Design, Usability und Entwicklung (zumindest muss man wissen, was die eigenen Entwickler brauchen und wie sie arbeiten). Die wenigstens werden genügend Erfahrung in all diesen Bereichen haben, um alleine an einem Design System zu arbeiten.

Mit all diesen netten Tools wie z.B. Carbon Design System, Zeplin und Brand.ai (es gibt mittlerweile so viele wirklich gute Tools und Frameworks) ist es sehr leicht die Integration von Design Systems zu unterschätzen. Es scheint als würden Tools momentan mehr Aufmerksamkeit bekommen als Teamkomposition oder die richtigen Arbeitsprozesse, allerdings werden gute Tools am Ende nicht genügen.

In dem Kontext könnte man Tools mit Musikinstrumenten vergleichen. Wenn man sie nicht spielen kann, oder noch nicht einmal weiß, welches Instrument man überhaupt spielen möchte, wird man letztendlich keine gute Musik spielen, geschweige denn die Möglichkeit 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.

Deswegen benötigt man ein interdisziplinäres Team, das am Design System arbeiten kann. Alles andere wird, höchst wahrscheinlich deutlich komplizierter.

Ich habe ein Team, und nun?

Jetzt da es ein Team gibt, muss es auch Möglichkeiten haben den laufenden Arbeitsprozess zu hinterfragen. Es ist sehr wahrscheinlich, dass der Prozess geändert werden muss, um die Integration des Design Systems zu ermöglichen.

Das ist entscheidend für die Integration. Das heißt nicht, dass ein neues Team alleine bestimmen sollte wie alles funktionieren muss. Allerdings müssen sie die Möglichkeit haben mit Entwicklern, Marketing und Projekt Managern zu reden, um zusammen einen Weg zu finden, wie neue Prozesse etabliert werden können, die dem gesamten Team helfen.

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ötigen 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.

Hier sind einige Beispiele von typischen Problemen:

Selbes Team:

Entwickler: “Unser Framework bietet keinen Support für die fancy Combobox mit Blättern-Funktion, die ihr designed habt. Wir haben außerdem keine Zeit eine eigene Komponente zu entwickeln.

Designer: “Ok, ich versuche etwas zu machen, das mit unseren Standardcontrols umsetzbar ist.”

Verschiedene Teams:

Entwickler: “Ich kann die Designs nicht umsetzen… dann muss ich mir wohl selbst etwas ausdenken.”

Selbes Team:

Entwickler: “Die Komponente hat deutlich mehr States als im Design spezifiziert. Kannst Du für die Visualisierung der restlichen States bitte neue Entwürfe machen?”

Designer: “klar, kein Problem!”

Verschiedene Teams:

Entwickler: “Ich habe keine Designs für die fehlenden States… muss ich wohl wieder kreativ werden.“

Es ist natürlich möglich 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 (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 “liefert”, 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 überhaupt benutzt? Was passiert, wenn sie die richtigen Komponenten nicht finden?).

Des Weiteren, und das ist wichtig, verhindert man, dass sich Fronten bilden. Es ist erfahrungsgemäß sehr einfach dafür zu sorgen, dass sich Entwickler und Designer hassen, solange sie nicht im selben Team an denselben Problemen arbeiten.

Ich persönlich 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önnen sie bestimmte Entscheidungen und Einschränkungen besser erklären (technische Zusammenhänge) als Produkt Manager.

Wir haben ein integriertes Design System, wir sind fertig… oder?

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 ändern. Verschiedene Produkte werden unterschiedliche Stile und Konzepte benötigen. Stakeholder, Produkte oder sogar Tochterunternehmen werden Abwandlungen benötigen. Um darauf reagieren zu können, muss das System (und die daran hängenden Arbeitsprozesse) für Änderungen und alternative Versionen konzipiert sein.

Man könnte vermuten, dass die einfachste Lösung wäre mehrere dedizierte Design Systeme für jedes Produkt zu erstellen. Aber einer der wichtigen Aspekte eines Design Systems ist es, alle Abwandlungen zu einer kohärenten User Experience (für Nutzer, Kunden und Entwickler) zusammen zu führen und diese eben nicht an ein einziges Device oder Produkt zu fesseln.

Um dies zu erreichen, müssen System und Prozess für Änderungen und alternative Versionen vorbereitet sein. Wenn das System in einer großen 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ät, dass alles konsistent über mehrere Produkte und Devices zusammenspielt („Unsere Nutzer brauchen keine konsistente Experience über alle Produktlinien, die benutzen eh nur ein Produkt“). Das ist bedauerlich, aber in der echten Welt fast unvermeidbar. Die beste Strategie ist darauf vorbereitet zu sein.

Das bedeutet, dass Komponenten und Konzepte einfach verändert werden können. Es ist außerdem wichtig zu gewährleisten, dass Komponenten unterschiedliche Versionen oder Varianten haben können. Vielleicht benötigt man verschiedene primary Buttons oder einige Komponenten benötigen AR / VR support. Vielleicht hat ein Produkt ein anderes Farbschema oder komplett andere Navigationsmöglichkeiten.

Es ist unmöglich zu “raten“ was für ein Team, geschweige denn Unternehmen am besten funktioniert. Teams und Stakeholder müssen definitiv zusammen eine Lösung finden. Die Verantwortlichkeiten müssen außerdem klar benannt werden. Ansonsten besteht das Risiko, dass ein System (und alle Produkte, die daran hängen) aufgeblasen und sehr komplex zu verwalten wird. Dennoch ist es natürlich OK Ausnahmen zu haben. Konsistenz sollte nicht höher als Usability bewertet werden. Aber unabhängig davon sollte klar sein, warum und wo eine Ausnahme existiert.

Fazit

Ein Design System ist nicht einfach ein Tool oder Framework, um Komponenten zu organisieren. Tools sind nicht das wichtigste in einem Design System. Natürlich 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.

Ein Design System sollte komplett im Arbeitsprozess der Mitarbeiter eingebunden sein. Ein dediziertes Team mit Willen und Möglichkeiten Prozesse und Strukturen zu ändern und zu adaptieren ist hierfür sehr wichtig und wird dabei helfen eine gemeinsame Design Sprache über unterschiedliche Produkte, Teams und Tochterunternehmen zu etablieren.

Ein gutes Beispiel für ein funktionierendes Design System ist „Touchpoint“, 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.

Mehr Informationen zum Thema Design Systeme und wie wir bei einer Umsetzung unterstützen können, findest Du auf unserer UX Management Service Seite.

Möchten Sie mehr zu unseren Leistungen, Produkten oder zu unserem UX-Prozess erfahren?
Wir sind gespannt auf Ihre Anfrage.

Corporate Experience Manager
+49 681 959 3110
Kontaktformular

Bitte bestätigen Sie vor dem Versand Ihrer Anfrage über die obige Checkbox, dass wir Sie kontaktieren dürfen.
  • Saarbrücken

    Science Park Saar, Saarbrücken

    Standort Südwest

    Hauptsitz Saarbrücken
    Centigrade GmbH
    Science Park 2
    66123 Saarbrücken
    Deutschland
    Saarland
    Auf der Karte

    +49 681 959 3110

    +49 681 959 3119

  • Mülheim an der Ruhr

    Games Factory Mülheim an der Ruhr

    Standort Nordwest

    Geschäftsstelle Mülheim
    Centigrade GmbH
    Kreuzstraße 1-3
    45468 Mülheim an der Ruhr
    Deutschland
    Nordrhein-Westfalen
    Auf der Karte

    +49 208 883 672 89

    +49 681 959 3119

  • Haar · München

    Haar / München

    Standort Süd

    Geschäftsstelle München
    Centigrade GmbH
    Bahnhofstraße 18
    85540 Haar · München
    Deutschland
    Bayern
    Auf der Karte

    +49 89 20 96 95 94

    +49 681 959 3119

  • Frankfurt am Main

    Frankfurt am Main

    Standort Mitte

    Geschäftsstelle Frankfurt
    Centigrade GmbH
    Kaiserstraße 61
    60329 Frankfurt am Main
    Deutschland
    Hessen
    Auf der Karte

    +49 69 241 827 91

    +49 681 959 3119