Web Components: Die nächste Entwicklungsstufe von Designsystemen
Die komplexe Entwicklungslandschaft gewachsener Organisationen
Folgendes Szenario kommt euch vielleicht bekannt vor: Ein größeres Unternehmen, sagen wir aus dem digitalen Bereich, hat eine Vielzahl von Touchpoints mit dem Kunden, darunter ganz unterschiedliche Anwendungen und Produkte, die wieder auf verschiedenen Plattformen und in verschiedenen Settings genutzt werden sollen. Die Teams, die die Produkte betreuen, haben entsprechend heterogene Anforderungen (und auch Vorlieben) nach denen sie nun ihre Entwicklungstools auswählen. Dabei setzen die einen zum Beispiel auf Frameworks wie Angular oder Vue.js, andere auf Libraries wie React.js. Das ist nun grundsätzlich nicht schlecht; jedes Team sollte genau die Technologien auswählen, mit denen es am besten arbeiten kann. Für solche Frameworks spricht auch, dass sie durch Standardisierung den Arbeitsaufwand reduzieren und Fehlerraten senken sollen. Problematisch wird es aber, wenn nun die Designer um die Ecke kommen…
Stellen wir uns nun vor, dass in demselben Konzern nun ein neues Design über alle Produkte ausgerollt werden soll. Da die Teams nun aber nun unterschiedliche Frameworks nutzen, bedeuten Anpassungen im Styling zumindest in einigen davon ungeliebte Kleinstarbeit, wenn Designkomponenten nicht auf der Logik des jeweiligen Frameworks basieren. Developer haben nun mehr und nicht weniger Arbeitsaufwand, da sie für die jeweilige Komponente gemäß den Designrichtlinien individuell neuen Code schreiben müssen. Der Aufwand, den jede einzelne Komponente bedeutet, wächst mit der Zahl der Teams expontenziell, während die Zusammenarbeit zwischen Designern und Entwicklern nicht mehr reibungslos ablaufen kann. In einer Wirtschaft, die durch ständigen technologischen Wandel auch ständig besseres Design fordert, kann diese Mehrarbeit schnell aus dem Ruder laufen.
Web Components: Framework-agnostische Weiterentwicklung eines Designsystems
Warum aktuelle Designsysteme nicht ausreichen
Den Markenauftritt konsistent zu halten ist eine Herausforderung, deren Komplexität mit der Größe eines Unternehmens zunimmt: Der Prozess zwischen Design und Development läuft in der Regel asynchron und linear, wobei zentrale Designvorgaben in der Entwicklung dezentral umgesetzt werden sollen. Durch den Mehraufwand entsteht so häufig ein Akzeptanzproblem für Design. Individuelle Anpassungen sind außerdem fehleranfällig und können zu Inkonsistenzen im Portfolio oder in der Customer Journey führen. Grundsätzlich ist nun die Idee eines Designsystems, diesen ineffizienten Prozess zu vereinfachen, indem es Designkomponenten als Bausteine für ein organisationsweites Ökosystem zur Verfügung stellt. Diese Basics, die bei kleinsten Grundlagen wie Typographie, Farben, Spacing und dergleichen anfangen, bilden dann die Grundlage für den Bau von Applikationen. Der Einsatz dieser Komponenten soll dann Design wiederverwertbar machen.
Mit diesem Ziel haben unter anderem Technologiekonzerne mit bemerkenswerter Designkompetenz mittlerweile Designsysteme entwickelt. Jedoch können auch die das Konsistenzproblem nicht lösen: Entweder basieren diese auf einem spezifischen Framework (z. B. Airbnbs Design Language System DLS, das mit React Components und Sketch arbeitet) oder wurden zumindest mit dem Fokus auf eines entwickelt, wobei Komponenten für andere Frameworks jeweils einzeln ebenfalls unterstützt werden (z. B. IBMs Carbon, das „React first“ ist, aber auch Komponenten in vanilla JS, Angular und Vue bietet.) Sobald also in eurem Unternehmen mehr als ein Framework genutzt wird, bleibt der asynchrone Prozess zwischen Design und Entwicklung sehr wahrscheinlich bestehen.
Designsystem mit Web Components: Vorteile für Entwickler und Designer
Web Components sind ein (nicht mehr ganz) neuer Webstandard, der von einigen wichtigen Unternehmen im digitalen Umfeld (z. B. Apple, Google, Mozilla) vorangetrieben wird. Bereits Frameworks wie Vue, Angular oder React haben komponentenbasierte Architekturen. Der Unterschied ist allerdings, dass Web Components auf einer tieferen Abstraktionsstufe ansetzen. Damit sind sie durch alle Frameworks und Browser interpretierbar, ohne nochmals angepasst werden zu müssen. Da macht sie zu einer idealen Grundlage, um die Logik bestehender Designsysteme weiterzuentwickeln. Die Idee ist ein Framework-agnostisches Designsystem, das viele Probleme der Markenkonsistenz trivialisiert.
Konkretes Beispiel: Haben früher Designer ein einziges Inputfield (inklusive Visualisierung, Agent States etc.) vorgeschlagen, musste es in den jeweiligen Frameworks jeweils separat nachgebaut werden. Als Web Component liegt das Design jedoch im Code und kann in Form einer einzigen Zeile universell verfügbar gemacht werden. Für Entwickler bedeutet das im Endeffekt, dass Themen wie Layout, Style, Responsivität durch die Komponenten selbst bereits definiert sind und man sich nicht mehr mit CSS und Styling befassen muss. Damit hat man mehr Zeit, sich auf die Logik der Anwendung zu konzentrieren und eine (aus Designsicht) häufige Fehlerquelle wird eliminiert. Gleichzeitig ist auch weniger Abstimmungsarbeit mit den Designern notwendig, wodurch alle Beteiligten effizienter arbeiten können. Und durch die universelle Anwendbarkeit der Komponenten gilt das für alle Teams, unabhängig von Entwicklungsumgebung oder Anforderungen. Das macht die Idee gerade für große Organisationen (mit vielen Teams, Touchpoints usw.) interessant.
Haben früher Designer ein einziges Inputfield (inklusive Visualisierung, Agent States etc.) vorgeschlagen, musste es in den jeweiligen Frameworks jeweils separat nachgebaut werden. Als Web Component liegt das Design jedoch im Code und kann in Form einer einzigen Zeile universell verfügbar gemacht werden. Tim Zeidler
Entwicklung des Iconstorm Designsystems: Der Prozess und unsere Erfahrungen
Warum basieren nicht alle Designsysteme auf Web Components?
So einleuchtend das Konzept auch klingt, bisher gibt es nur wenige Unternehmen, die ein Designsystem nutzen, das auf Web Components basiert. In Deutschland machen das erfolgreich beispielsweise Porsche und die Telekom, während viele Namen, die man an dieser Stelle vermuten würde, fehlen. (Wenn ihr mehr kennt, lasst es uns gerne wissen!) Das liegt vor allem daran, dass insbesondere viele Tech- und Digitalunternehmen bereits Designsysteme entwickelten, als Web Components noch nicht weit verbreitet waren; und deren Entwicklungen basieren – wie in oben gezeigten Beispielen – deshalb in der Regel auf einem spezifischen Framework. Sie waren schlicht zu früh.
Um ein neues Designsystem zu entwickeln hingegen ist viel Aufwand notwendig. Und gerade, wenn dessen Komponenten nun im Code liegen sollen, müssen zudem Design und Entwicklung eng zusammenarbeiten. Das allerdings ist nicht einfach, da es sich hier um unterschiedliche Kompetenzbereiche handelt, deren Prozesse teils nicht derselben Systematik folgen. Damit ist also viel Denk-, Arbeits- und Organisationsaufwand notwendig, um diese Idee auf die Strecke zu bringen. Genau diese Fragen haben uns selbst bei Iconstorm bei der Entwicklung des eigenen Designsystems beschäftigt. Developer wie ich mussten erst eingestellt werden und wir alle mussten neue Prozesse erarbeiten und lernen, um eine gute Zusammenarbeit zwischen Entwicklung und Design auf die Beine zu stellen.
Ein Designsystem auf Web Components entwickeln? Hier nur einige Fragen, die sich für Iconstorm stellten:
Wie erweitern wir das soziale Gehirn unseres Teams, um so etwas überhaupt bauen zu können? Welche Entwickler stellen wir ein und wie arbeiten wir mit ihnen zusammen?
Können wir ein System bauen, dass die individuellen Bedarfe verschiedener Organisationen abdecken kann?
Wieviel Vorarbeit ist notwendig? Wieviele Komponenten müssen wir selbst entwickeln, um das System interessant für mögliche Kunden und Partner zu machen?
Macht das System Design skalierbar und reduziert es tatsächlich Komplexität in einer Form, dass es sich refinanziert?
Anwendung in der Praxis
Status quo des Iconstorm Designsystems
Trotz (oder vielleicht gerade wegen) dieser Herausforderung fanden wir das Vorhaben nun so gut, dass wir es in die Tat umgesetzt haben. Heißt: Mittlerweile haben wir ein praxisfertiges System entwickelt. Was in einem Satz leicht geschrieben ist, bedeutete dabei aber nichts weniger als ein Mammutprojekt: Dazu gehörte die Erweiterung unseres Teams um Entwickler wie mich, die Etablierung neuer Arbeitsprozesse, viel Research und noch mehr hemdsärmlige Entwicklungsarbeit über einen langen Zeitraum.
Die Arbeit hat sich aber gelohnt, denn im Ergebnis steht heute eine fertige Toolchain mit vorgefertigten Komponenten, die Nutzer des Systems jeweils für ihre eigenen Zwecke anpassen können. Unter anderem testen wir es nun in der Praxis mit zwei DAX-30-Unternehmen. Dabei deutet sich schon an, dass es nicht nur die Arbeit mit Marke für alle Beteiligten erleichtert, sondern sich dabei durch die entstehende Effizienzsteigerung sogar noch selbst finanziert. Entsprechend sind wir der Meinung, dass die Zukunft von Designsystemen erstmal den Web Components gehört.
