So machst du dein Designsystem zu einem Produkt

Damit du die in diesem Beitrag genannten Kompetenzen nutzen kannst, ist das Figma-Preismodell Organization erforderlich. Mehr erfahren.

Dieser Artikel ist der zweite einer dreiteiligen Serie. Sie befasst sich im Detail mit der Erfahrung von Workday bei der Entwicklung, Produktüberführung und Veröffentlichung seines Designsystems. Erfahre hier mehr zu Teil I, Designsysteme gehen alle an.

Komplexität akzeptieren

Designsysteme sind das Branchengeheimnis für die Skalierung der Benutzerfreundlichkeit im Unternehmen. Wir sind der Überzeugung, dass ein Designsystem, je nach Größe und Komplexität des Unternehmens, von einem Stickerbogen bis hin zu einem voll ausgereiften Produkt reichen kann. Bei Workday war der entscheidende Wendepunkt der Entschluss, unser Designsystem wie ein Produkt zu behandeln.

Seit dem Start unseres Designsystems vor drei Jahren ist Workday gewaltig gewachsen. Wir haben nun über 12.000 Arbeitskolleg*innen und Hunderte einzigartiger Produktanwendungen, alle mit dem Zweck, Kund*innen mit Tausenden bis Hunderttausenden eigenen Mitarbeitenden zu unterstützen. Unser System komplex zu nennen, wäre eine Untertreibung.

Das Designsystem „Canvas“ von Workday ermöglicht es uns nun, der Größe und Komplexität dieses Systems vollständig gerecht zu werden. Inzwischen kann es wie ein eigenständiges Produkt verwendet werden und ist damit in der Lage das zu leisten, was Designsysteme am besten können: den Benutzer*innen die Möglichkeit zu geben, auf effiziente Art und Weise für ein einheitliches und hochwertiges Benutzererlebnis zu sorgen.

In diesem Artikel erzählen wir, wie unser Designsystem ein „Produkt für Produkte“ wurde und was das für uns als Designer*innen bedeutet. Uns ist bewusst, dass es in der Welt der Designsysteme keine Einheitsgröße gibt, die für jedes Unternehmen passt. Doch indem wir unsere Perspektive und unseren Lernprozess teilen, hoffen wir, dass du dir ein besseres Bild von den möglichen Schwierigkeiten und Erfolgen machen kannst, die euch im Zuge der Produktüberführung eures Designsystems erwarten.

Behandle dein Designsystem wie ein Designproblem

Es ist zwar offensichtlich: Eines der schwierigsten Dinge am Designen von Systemen im Unternehmensbereich ist, all die Benutzer*innen und Stakeholder*innen zu unterscheiden und zu priorisieren, die von unserem System betroffen sind. Im Gegensatz zu Teams, die sich auf ein bestimmtes Produkt oder bestimmte Benutzer*innen konzentrieren, wird unser System für vielfältige Zwecke eingesetzt. So differenzierten wir beispielsweise zwischen Mitarbeitenden, die Workday nutzen, Berufstätigen, die bei Workday arbeiten, interne Entwickler*innen, die Workday aufbauen oder externe Entwickler*innen, die außerhalb von Workday eine einzigartige Anwendung erschaffen.

Ein wichtiges Elemente der Bestimmung und Priorisierung unserer wertvollsten Benutzergruppen durch unser Team war die Zuordnung der Stakeholder*innen. Als Team haben wir jede Funktion, jedes Team und jedes Unternehmen aufgelistet, das entweder von Canvas von Workday betroffen ist oder das System beeinflussen kann. Dadurch haben wir herausgefunden, dass Designer*innen und Entwickler*innen unsere wertvollsten Benutzergruppen sind. Anschließend machten wir uns daran, durch qualitative und quantitative Forschungein besseres Verständnis zu entwickeln, welche Teile des Systems für diese Gruppen funktionierten und welche nicht.

Dadurch bekamen wir eine Reihe an Einblicken rund um designspezifische Themen wie Kommunikation, Dokumentation und Bildung, und anhand dieser Einblicke konnten wir Prioritäten setzen. Sie geben uns ein sicheres Fundament, wenn wir den Fokus verlieren, unseren Zweck in Frage stellen oder wenn wir Ad-hoc-Anfragen außerhalb des definierten Bereichs unseres Teams erhalten.

Erkenntnisse:

• Gehe an dein Designsystem wie an ein menschenzentriertes Designproblem heran.
• Ordne deine Stakeholder*innen zu und bestimme so, wer deine primären Benutzer*innen sind. Außerdem erfährst du dabei, wer von Änderungen an deinem System betroffen ist.

Priorisiere geeignete Ressourcen

Ein weiterer Aspekt der Produktüberführung unseres Systems war durch die Einstellung geeigneter Produktmanager*innen und technischer Ressourcen, die mit unserem Designerteam zusammenarbeiteten. Als Team mit neuen Ressourcen öffneten wir zuerst Source Developer Kits für unser Designsystem. (In Teil 3 dieser Serie gehen wir näher darauf ein.)

Unsere Produktmanager*innen erstellten Artefakte wie Businessfahrpläne und Backlogs und führten wiederkehrende Abläufe, wie Blitzplanung, tägliche Stand-up-Meetings und Retros ein. Unsere Designer*innen erstellten Prozesse, mit denen globale, zugängliche und wiederverwendbare Komponenten geschaffen wurden. Anschließend arbeiteten sie eng mit unserem dedizierten Entwicklerteam zusammen und definierten und programmierten den Code unseres Systems. So stärkten sie Canvas von Workday als sich ständig weiterentwickelnde Source of Truth.

Das war unser erster Versuch, als komplett funktionsübergreifendes Produktteam zu arbeiten, der sich als großer Erfolg herausstellte. Durch die Blitzplanung konnten wir fokussiert bleiben und unsere Bemühungen priorisieren. Durch die täglichen Stand-up-Meetings behielten wir die Verantwortung und waren uns weiterhin unserer Aufgaben bewusst, und die Retros gaben uns Zeit zu reflektieren, uns zu verbessern und unsere Erfolge zu feiern.

In der Welt der Unternehmenssysteme, in der die Dinge schnell komplex erscheinen, zeigte uns die Tatsache, dass wir den richtigen Prozess, die richtigen Strukturen und die richtigen Ressourcen hatten, wie erfolgreich unser Team sein konnte.

Erkenntnisse:

• Wenn dein Designsystem wie ein Produkt verwendet werden soll, braucht es dafür geeignete Technik-, Design- und Produktmanagement-Ressourcen.
• Führe wiederkehrende Abläufe und Prozesse ein, durch die dein Team greifbare Ziele und einen Fokus erhält.

Entwickle deine Art zu beraten

Wenn du an Designsystemen arbeitest, bist du wahrscheinlich daran gewöhnt, Nachrichten zu erhalten wie „Hi zusammen. Ich möchte diese neue Schaltflächenkomponente nutzen, die ich für meinen spezifischen Anwendungsfall erstellt habe.“

Hört sich stark nach einer Feature-Anfrage an, oder? Bevor wir an unser Designsystem wie an ein Produkt herangegangen sind, hätte unser Team bei so einer solchen verwegenen Art von Anfrage entsetzt nach Luft geschnappt. Tatsächlich hatten wir früher nie das Gefühl, dass wir uns mit der verfügbaren Anzahl an geeigneten Ressourcen in einem Tempo entwickeln konnten, das der Nachfrage entsprach. Der Versuch, unser Designsystem komplett zu kontrollieren war eine schlechte Vorgehensweise, an der wir zu lange festhielten.

Durch die Vorstellung, Konformität erzwingen zu wollen, – und unser Ego – standen wir uns bei der Entwicklung unseres Systems selbst im Weg. Doch schließlich erkannten wir, dass die Entwicklung unseres Designsystems durch unsere primären Benutzer*innen, also unsere Produktdesigner*innen, und die Bedürfnisse derer Anwender*innen vorangetrieben werden musste, und nicht durch uns selbst. Durch diese mächte Erkenntnis verschob sich unsere Einstellung, weg von der Vorstellung, die Entwicklung unseres Systems kontrollieren zu müssen, und hin zu der Erkenntnis, dass wir sie durch die Beiträge von Designer*innen und Entwickler*innen vereinfachen und verbessern konnten.

Während des Open Source-Projekts begannen wir, das Design und die Entwicklung unseres Open Source-Kits durch einen gemeinsamen Ansatz zu fördern. Durch den Beitrag von externen Entwicklungs- und Designteams, die bei der Erschaffung oder Wiederverwendung unserer Komponenten helfen wollten, ließ sich der Arbeitsaufwand verteilen und die Akzeptanz im gesamten Unternehmen erhöhen.

Zur Bearbeitung der eintreffenden „Feature“-Anfragen erstellen wir einen Aufnahmeprozess, dessen Grundlage es war, unseren Benutzer*innen zuzuhören. Wir lernten Fragen zu stellen wie „Was ist dein Anwendungsfall?“, „Warum erfüllen die existierenden Komponenten deine Anforderungen nicht?“ und „Welche Variablen und Eigenschaften benötigst du, damit diese Komponente für dich funktioniert?“ Durch einen solchen Austausch gehört das System nicht mehr nur uns allein und die Verantwortung liegt ebenfalls auch bei anderen. Zudem macht er es den Benutzer*innen möglich, direkten Einfluss auf die Verbesserung unseres Systems zu nehmen.

Im Rahmen dieses Austauschs fragten wir uns gleichzeitig „Wie könnte das von anderen Apps und Produktteams eingesestzt werden?“ Ganzheitlich zu denken und Verbindungen zwischen all unseren Produkten und Plattformen herzustellen, ist genauso wichtig, wie unseren Benutzer*innen zuzuhören.

Erkenntnisse:

• Höre zu und frage immer nach dem Grund.
• Betrachte die Designer*innen und Entwickler*innen in den Produktteams als die primären Beitragenden.
• Entwickle ein Gespür dafür, wann systematisches Denken angesagt ist.

Definiere deinen Verwaltungsprozess für Veränderungen

Genauso wie bei der Produktentwicklung waren bei der Erstellung unseres Designsystems ebenfalls viele Stakeholder*innen am Prozess beteiligt. Im Januar 2019 begannen wir damit, unser Designsystem quelloffen zur Verfügung zu stellen. Die Arbeit an diesem Meilenstein verdeutlichte uns die Auswirkungen, die Veränderungen innerhalb unseres komplexen Unternehmenssystems haben. Als immer mehr Benutzer*innen unser System zum Erstellen von Produkten verwendeten, erkannten wir, dass sich zunehmend mehr Abhängigkeiten einschlichen, insbesondere solche, die mit der Integrität unseres sich ständig entwickelnden Systems in Verbindung standen.

Wir verfeinerten unser System und entwickelten es auf den Meilenstein hin, zu dem wir es quelloffen anbieten wollten. Dabei übersahen wir, welche Wellen unsere vorgeschlagenen Änderungen im Unternehmen schlagen würden. Beispielsweise entschieden wir uns, die Farbe unserer Hauptschaltflächen aus Gründen der Barrierefreiheit von Orange zu Blau zu ändern. Wir wussten, dass solche Änderungen massive Folgen für Designer*innen und Entwickler*innen hatten, übersahen allerdings die Auswirkungen auf weitere Teams, die wir nicht berücksichtigt hatten. Unser Bildungsteam erkannte beispielsweise starke Auswirkungen auf die Lernmaterialien, die es erstellte.

Damit unser Team als Produkt agieren konnte, das andere Produkte unterstützt, mussten Veränderungen zielgerichtet verwaltet werden und Ergänzungen des Systems sorgfältig überdacht werden. Die Einführung von Maßnahmen zur Änderungsverwaltung bedeutete, dass wir Umgebungen schaffen mussten, in denen wir Beiträge testeten und überprüften, bevor wir sie in unsere Hauptbibliothek verschoben. Anschließend mussten wir regelmäßig mit allen betroffenen Stakeholder*innen kommunizieren. Die Verwaltung von Veränderungen hilft uns dabei, die Qualität unserer primären Komponentenbibliothek zu verwalten. Sie verringert die Störfaktoren, die durch zu wenig Kommunikation und kleine aber fatale Fehltritte in der Produktion hervorgerufen werden. Es war wie bei den meisten schmerzhaften Erfahrungen: Wir lernten eine Menge dazu und wuchsen letztendlich daran als Team.

Erkenntnisse:

• Finde unabhängig von der Größe deines Designsystems heraus, wie du die Abhängigkeiten bei jeder Veränderung beurteilen kannst.
• Erstelle einen Prozess für Fragen und Antworten und Testumgebungen, bevor du Beiträge in deine Hauptbibliothek verschiebst.

Höre nie auf zu wachsen

Bei Workday sind uns die Herausforderungen bewusst, die entstehen, wenn man ein vertrauenswürdiges System erstellt, das Veränderungen skalieren und sich an diese anpassen kann. Im Jahr 2016 wussten wir, dass unser Unternehmen schnell wuchs und wir Wege brauchten, um die Einheitlichkeit und die Qualität zu bewahren. Wir mussten mehrere Jahre herumprobieren, bis wir Prozesse fanden, die in der Praxis funktionierten. Im Rahmen unserer Entwicklung wird sich dies auch immer wieder wiederholen, denn Designsysteme verändern sich ständig. Das ist das Aufregende daran. Durch die Vorteile der Produktüberführung unseres Systems erhielten wir greifbare Ergebnisse. Dadurch konnten wir unsere wertvollsten Benutzergruppen bestimmen und priorisieren. Zudem konnten wir Rituale und Artefakte erstellen, um unseren Fokus zu lenken, und uns wurden die Auswirkungen bewusst, die unsere Entscheidungen haben würden. Was kommt als nächstes? Wir wollen als Produkt bestehen und nehmen unsere nächsten Schritte ins Visier: Wir werden uns intensiver mit Forschung und Überprüfung befassen, mehr Bildung und Schulungen entwickeln und es unseren Benutzer*innen ermöglichen, einheitliche, hochwertige Benutzererlebnisse zu schaffen – und das alles, während wir ihre Arbeit ein kleines bisschen einfacher machen.

Im dritten und letzten Teil dieser Serie geht es darum, wie Workday für ein offenes Designsystem eintrat und wie es seine Developer Kits veröffentlichte. Hier findest du Teil IDesignsysteme gehen alle an.