Argumente für ein offenes Designsystem

Für die Fähigkeiten, die in diesem Post genannt werden, wird ein Figma Organisation-Abo benötigt. Mehr erfahren.

Dieser Artikel ist der dritte einer dreiteiligen Serie. Sie befasst sich im Detail mit den Erfahrungen von Workday, die das Unternehmen machte, als das Designsystem entwickelt, zum Produkt gemacht und letztendlich veröffentlicht wurde. Erfahre hier mehr zu Teil I, Designsysteme gehen alle an und Teil II, So machst du dein Designsystem zu einem Produkt.

Das Herzstück eines jeden Designsystems ist die dazugehörige Community. Sie ist der Motor, der das Workday Canvas Designsystem antreibt, wobei sich unsere Community über Transparenz und Inklusion definiert. Mit anderen Worten: Unser Anspruch ist es, offen zu sein.

In diesem Artikel gehen wir darauf ein, was „offen sein“ bedeutet, sowohl als Vision als auch als das, was heute bei Workday tatsächlich geschieht. Außerdem zeigen wir anhand konkreter Beispiele, warum Offenheit wichtig ist und wie wir davon profitiert haben.

Auf dem Weg zur Offenheit

Unser Designsystem war nicht immer ein „offenes“ Konzept, wobei wir argumentieren könnten, dass die meisten Designsysteme in ihren Anfängen das auch nicht sein sollten. Sie sind Ideen und Konzepte, die geschützt und gepflegt werden müssen, bis der richtige Zeitpunkt gekommen ist. Hinter den Kulissen war viel Arbeit nötig, um Canvas auf den Weg zu bringen (mehr dazu ist in Teil 2 unserer Serie zu lesen), aber als die Akzeptanz zunahm, mussten wir unsere Entscheidungen transparenter machen und das System für neue Ideen unserer Benutzer*innen öffnen.

Unser Weg zur völligen Offenheit ist noch nicht zu Ende. Doch in der relativ kurzen Zeit unserer Reise haben wir drei wichtige Erkenntnisse gewonnen, die wir mit dir teilen möchten:

1. Offenheit schafft Fortschritt
2. Offenes Arbeiten fördert Kommunikation und Verantwortlichkeit
3. Eine erste Verlangsamung ermöglicht uns, später schneller zu werden

Offenheit schafft Fortschritt

Hattest du schon einmal eine Idee, bei der du einfach nicht weitergekommen bist? Ob beim Schreiben von Code oder beim Entwerfen von Designs – um Fortschritte zu erzielen, genügt es oft schon, die Perspektive zu wechseln. Dies kann in Form eines Kundenhinweises geschehen, der eine neue Sichtweise auf ein altbekanntes Problem eröffnet. Es kann eine treffende Beobachtung einer geschätzten Kollegin sein. Manchmal reicht auch ein Spaziergang in der Natur (ernsthaft). Neue Perspektiven geben unserem Gehirn neuen Schwung.

Für uns bestand die Suche nach neuen Perspektiven darin, den Zugang zu unserem Designsystem zu verbessern. Dies taten wir in zweierlei Hinsicht: Erstens wechselten wir unsere Produktdesign-Tools zu Figma, einer cloudbasierten Plattform, und zweitens migrierten wir unsere Entwicklerbibliotheken (Canvas Kit) zu Github.com, sodass unser Quellcode nun jederzeit für alle zugänglich ist. Dies hat dazu geführt, dass nun wesentlich mehr Teams sehen können, woran wir arbeiten, und dass wir dank ihrer Sichtweise in kürzester Zeit unglaubliche Fortschritte erzielen.

Ganz allgemein gesprochen kann ein Prozess durch zu viele Meinungen auch verlangsamt werden. Wir haben festgestellt, dass das Feedback uns geholfen hat, bessere und schnellere Entscheidungen zu treffen. Angesichts der Vielzahl von Benutzer*innen und Produkten in unserer Suite erfordern Sonderfälle, Verfügbarkeiten und Optimierungen von Komponenten umfangreiche Nachforschungen und Rücksprachen. Diese Anforderungen fließen nun als natürlicher Nebeneffekt der zunehmenden Öffnung unseres Systems in unseren Prozess ein.

Defizite werden zu Optimierungen

Ein großartiger Nebeneffekt der zunehmenden Öffnung deines Designsystems ist, dass Defizite zu Optimierungen werden. Selbst die ausgereiftesten Designsysteme haben Schwachstellen. Bei Workday mussten wir uns mit fehlenden/inkompatiblen Komponenten in unseren Figma-Bibliotheken befassen und browserübergreifende Fehler in der Codebasis beheben. Jedes Mal, wenn uns jemand auf diese Fehler aufmerksam macht, werden wir besser. Seit Canvas Kit im Juli 2019 der Öffentlichkeit zugänglich gemacht wurde, haben wir mehr als 90 gemeldete Fehler in unserer Codebasis behoben. Viele davon wurden von Mitwirkenden außerhalb unseres eigenen Teams gelöst. Außerdem hat sich unsere interne Canvas-Community auf Slack seit der Umstellung auf Figma mehr als verdoppelt. Diese Community macht uns jede Woche auf mindestens eine Unstimmigkeit in unserem Designsystem aufmerksam. Als Designschaffende sind wir oft darauf konditioniert, unsere Fehler zu verbergen, damit wir ein ausgefeiltes Produkt präsentieren können. Ignoriere diesen Drang. Bei Designsystemen funktioniert das nicht, denn sie dienen als Grundlage für das Produktdesign. Je eher wir in der Lage sind, Unzulänglichkeiten aufzudecken, desto schneller können wir die Plattform verbessern, auf die sich unsere Community stützt.

Entwicklung wird vielfältig

Die Entwicklung eines echten skalierbaren Designsystems ist eine nahezu unmögliche Aufgabe für ein einzelnes Team. Man denke nur an das umfangreiche Know-how, das in die Gestaltung, Entwicklung, Zugänglichkeit, Internationalisierung und Prüfung einfließt. Das kann, gelinde gesagt, entmutigend sein. Für uns ist es wichtig, die Fachleute in unserem Umfeld zu nutzen, damit das Designsystem und seine Komponenten für alle funktionieren. Wir erreichen dies durch Offenheit. Unsere Profis für Barrierefreiheit führen beispielsweise regelmäßig Audits neuer und bestehender Komponenten durch, da sie wissen, dass unser neuester und bester Code jederzeit für sie verfügbar ist.

Wir wollen keineswegs behaupten, dass deine Probleme allein durch ein offenes Designsystem und Crowd-Sourcing gelöst werden. Aber wir sind der Meinung, dass in einem offenen Designsystem die Entwicklung vielfältig wird. Der wahre Wert besteht darin, dass wir in der Lage sind, die Wirkung dieser unterschiedlichen Standpunkte durch das Designsystem zu vervielfachen. Teams, die bisher nur begrenzten Zugang zu entsprechenden Fachleuten hatten, können deren Know-how nun indirekt über die Komponenten des Designsystems, die Figma-Bibliotheken und die Dokumentation in ihre Produkte einfließen lassen.

Aus strenger Prüfung wird Nachhaltigkeit

Wenn „mehr Offenheit“ so klingt, als würde man damit eine Menge kritischer Blicke auf sich ziehen, dann liegt das daran, dass es so ist. Aber in einem offenen Designsystem wird aus der strengen Prüfung Nachhaltigkeit. Indem wir unser Designsystem für die ganze Welt öffnen, sammeln wir verschiedene Meinungen zu unserer Arbeit und geben Einblick darin, was noch nicht ganz richtig läuft. Die Dinge ändern sich, wenn man an die Öffentlichkeit tritt.

Vor diesem Hintergrund haben wir zahlreiche Sicherheitsvorkehrungen wie visuelle Regressionstests in allen von uns unterstützten Browsern und formelle Designdokumentationsprozesse eingeführt, größtenteils weil viele Teams jeden unserer Schritte genau beobachten. Doch diese Kontrolle wirkt sich zu unseren Gunsten aus, und wir haben unglaubliche Fortschritte bei der Entwicklung eines nachhaltigeren, besser dokumentierten Designsystems gemacht.

Wie offen du den Zugang zu deinem Designsystem gestaltest, hängt weitgehend von den Zielen deiner Organisation ab, aber wir empfehlen, möglichst viele unterschiedliche Perspektiven einzubeziehen. Unsere Erfahrung zeigt: Wenn wir uns die Zeit nehmen, die Community durch Offenheit und Transparenz aufzubauen, steigt die Bereitschaft der Einzelnen, sich einzubringen. Dadurch entsteht ein Gefühl der Mitverantwortung. Ebenso bedeutend ist aber, dass mehr Menschen das Designsystem weiterentwickeln. Einige der Teams, mit denen wir durch Kommunikation und Kooperation eng zusammengearbeitet haben, gehören heute zu den größten Mitwirkenden an unserer Codebasis.

Offenes Arbeiten fördert die Kommunikation

Wenn die Community das Herz eines guten Designsystems ist, dann kann man sich die offene Entwicklung wie die Arterien und Venen vorstellen: Sie befördert lebenserhaltende Kommunikationsprinzipien wie Klarheit, Transparenz und Verantwortung durch den ganzen Körper und zurück zum Herzen. Wenn wir von „Entwicklung“ sprechen, ist damit nicht nur unsere Codebasis auf Github gemeint, sondern auch unsere Designspezifikationen und Dokumentation auf Plattformen wie Figma und Confluence. Außerdem sind alle willkommen, sich an unseren Slack-Kanälen und Sprint-Demos zu beteiligen.

Offenheit bedeutet nicht nur, den Schleier über unserem Code zu lüften, sondern auch die Art und Weise, wie wir als Team arbeiten. Bei den vierzehntägigen Demos, die wir für unser Engineering Kit abhalten, gehen wir auf bevorstehende Änderungen oder neu veröffentlichte Funktionen ein. Wir erläutern, warum diese Änderungen vorgenommen wurden, und bitten um Feedback. Durch diese Offenheit können die Benutzer*innen unseres Designsystems sehen, wie wir über Änderungen entscheiden, die für sie am nützlichsten sind. Es ist ein bisschen so, als würde man seine Arbeit in einem Mathe-Test zeigen. Wenn der Lehrer sieht, dass deine Herangehensweise an das Problem richtig war, selbst wenn die Antwort falsch ist, wird er deine Überlegungen verstehen und dir vielleicht einen Teil der Gesamtpunkte geben.

Durch Transparenz versuchen wir, mit der Community und den Entwickler*innen, die unsere Codebasis nutzen, zusammenzuarbeiten. Bevor wir zu Open Source übergegangen sind, hat uns dieser Ansatz auch geholfen, Vertrauen innerhalb unserer Organisation aufzubauen.

Wenn wir uns bemühen, so offen wie möglich für möglichst viele Menschen zu sein, hat das einen interessanten Nebeneffekt: Die offene Entwicklung zwingt uns dazu, Verantwortung zu übernehmen. Je mehr Teams bei Workday von Canvas Gebrauch machen, desto mehr Anfragen, Erwartungen und Ergebnisse werden an uns herangetragen. Das ist beängstigend. Aber auch wenn Verantwortung furchteinflößend sein kann, ist eine gesunde Portion Respekt eine gute Sache! Im Jahr 2019 war unser größter Funktionswunsch eine Roadmap und ein Veröffentlichungsrhythmus. Unsere Benutzer*innen wollen wissen, was kommt und wann. Daher haben wir einen schreibgeschützten Slack-Kanal eingerichtet, damit unsere Leute immer über unsere Vorhaben informiert sind.

Eine Verlangsamung ermöglicht uns, später schneller zu werden

Wie jedes andere Produkt sind auch Designsysteme nicht vor technischen Schulden gefeit.

Mit dem Wachstum deines Systems sollte auch die Zahl der Benutzer*innen steigen. Sobald du ein einigermaßen ansprechendes System hast, sollte das weitere Wachstum in einem ausgewogenen Verhältnis von Geschwindigkeit und Qualität stehen. Wir wissen, dass schnelle Iterationen wichtig sind, um Benutzer*innen einen Mehrwert zu bieten. Aber noch wichtiger ist es, sich Gedanken darüber zu machen, wie sich eine Änderung auf die Benutzer*innen und das System selbst auswirken könnte.

Für unser Designsystem ist eine Änderung an der Art und Weise, wie eine Komponente mit anderen Komponenten interagiert, ein konkretes Beispiel für eine Änderung mit potenziell unerwünschten Nebenwirkungen. Sie muss sorgfältig verwaltet und kommuniziert werden. Dies gilt jedoch nicht nur für technische Änderungen, sondern auch für visuelle. Die Änderung der Farbe einer Schaltfläche oder die Vergrößerung der Höhe einer Texteingabe kann weitreichende Auswirkungen haben. So kann sich beispielsweise das Layout einer Seite oder der gesamten Anwendung ändern. Dies wiederum kann Komponenten und Interaktionen in der Umgebung beeinträchtigen, Tests zum Scheitern bringen oder sogar eine Aktualisierung der Dokumentation erfordern. Diese Änderungen haben das Potenzial, bei der Einführung eines Designsystems Reibungsverluste zu verursachen. Diese Reibung ist unvermeidlich, doch kann ein bestimmter Veröffentlichungsrhythmus dazu beitragen, sie zu verringern.

Wir haben Mechanismen eingeführt, um geplante Änderungen durch Änderungsprotokolle zu kommunizieren. Wir vermerken alles, von der Aktualisierung einer Bibliotheksabhängigkeit bis hin zu einer grundlegenden visuellen Änderung. Durch die semantische Versionierung bündeln wir die Änderungen in größere Veröffentlichungen. So können wir unseren Benutzer*innen die Änderungen auf einfache Weise zugänglich machen.

Obwohl wir Prozesse eingerichtet haben, sind wir noch dabei, unseren Ansatz für grundlegende visuelle Änderungen zu verfeinern. Unser Ziel ist es, dass unsere Änderungen klar nachvollziehbar sind. In Verbindung mit den richtigen Kommunikationskanälen sollte der Upgrade-Pfad eines Teams eindeutig sein, um die Reibung zu verringern.

Wir arbeiten weiter am Rhythmus wichtiger Versionsveröffentlichungen. Wir prüfen, wie wir die visuelle Weiterentwicklung mit den Produktveröffentlichungen von Workday in Einklang bringen können. Bei uns ist das zweimal im Jahr der Fall. Die Anpassung an diesen Rhythmus bedeutet, dass wir interne Prozesse für das Änderungsmanagement für unsere Kunden nutzen können. Es ist jedoch gut zu wissen, dass wir technische Änderungen nicht auf diese Taktung abstimmen müssen.

Offenheit verstärkt die Effekte eines Designsystems

Ja, es gibt durchaus Bedenken bei einem offenen Designsystem. Für uns haben die Vorteile jedoch dazu geführt, dass wir eine Community für offenes Design aufbauen konnten.

Indem wir die Geschwindigkeit unserer Änderungen verlangsamt haben, ist es uns gelungen, die Auswirkung unseres Designsystems auf unserem Weg zu erhöhen.

Offenheit schafft Transparenz darüber, wie und warum wir Dinge tun. So schließt sich für uns der Kreis. Sie ermöglicht es uns, schneller zu iterieren und den Teams, die unser Designsystem verwenden, einen Mehrwert zu bieten und sie letztendlich in die Lage zu versetzen, ihren Benutzer*innen qualitativ hochwertige und einheitliche Anwendungserfahrungen bereitzustellen.