Anfang November 2020 kamen Designer und Entwickler aus verschiedenen Design-System-Projekten von Gofore zu einem Erfahrungsaustausch zusammen. Die insgesamt in vier verschiedene Projekte involvierten Beteiligten beleuchteten hierbei die von ihnen verwendeten Werkzeuge, Best Practices und weitere relevante Aspekte, die sie aus ihren Projekten mitgenommen haben.
In diesem Blog-Beitrag sehen wir uns die Werkzeuge, die bei Gestaltung, Entwicklung und Dokumentation von Design-Systemen zum Einsatz kommen, einmal genauer an.
Design-Tools
Design-Systeme bieten User Interface/User Experience-Designern, die an Produktfunktionen und User-Flow-Themen arbeiten, in der Regel eine Art Design-Bibliothek oder Style-Guide. Das für die Erstellung dieser Design-Bibliothek gewählte Werkzeug, auch Tool genannt, muss natürlich mit den von den Designern eingesetzten Programmen harmonieren.
Design- und Kollaborationstools, die in Design-Systemprojekten von Gofore zur Anwendung kommen
Es ist wenig überraschend, dass in drei von vier Design-Systemprojekten, die Gegenstand des Erfahrungsaustauschs waren, Sketch zum Einsatz kommt. Als Sketch im Jahr 2010 auf den Markt kam, galt es als bahnbrechende Innovation im Bereich User-Interface-Design und hat sich mittlerweile als Branchenstandard etabliert. Sketch besticht mit einem kompakten Ökosystem an Plug-Ins, mit denen sich die Kernfunktionen des Grundinstrumentariums erweitern und Aufgaben automatisieren lassen. Seit einigen Jahren wird die einst dominante Rolle von Sketch jedoch von neuen Tools, die sich durch neue Ideen auszeichnen, angefochten.
Der Sketch-Hauptkonkurrent, Figma, hat für Aufsehen bei der Design-Community gesorgt; mit einem All-in-One-Ansatz, dem Fokus auf dem Thema Teamarbeit, den Übergabeprozess zwischen Designer und Entwickler, sowie mit seinen am Design-System orientierten Funktionen. Außerdem ist das Handling von Designstilen bei Figma flexibler und das Layout verhält sich im Vergleich zu Sketch ein wenig mehr wie das HTML-Box-Modell – ein Umstand, den man von einem Tool, das speziell zur Gestaltung von Benutzeroberflächen entwickelt wurde, auch erwarten kann. Während Sketch nur für MacOS verfügbar ist, läuft Figma webbasiert und bietet außerdem eine Desktop-App für Mac und Windows.
Eine weitere Sketch-Alternative ist Adobe XD. Momentan ist XD im Bereich Design-Systeme generell nicht die erste Wahl; nachdem Adobe jedoch praktisch alle anderen Design-Tools fest im Griff hat, sollte man XD jedoch nicht gänzlich abschreiben.
Insgesamt betrachtet gibt es deutliche Anzeichen, dass Figma die Marktdominanz von Sketch zumindest auf lange Sicht beenden wird. Auch wenn alle vier Design-System-Projekte zunächst Sketch im Einsatz hatten, haben zwei der Teams zumindest einen Wechsel zu Figma in Betracht gezogen, wobei ein Team den Wechsel sogar bereits vollzogen hat; dieser Wechsel hat Berichten zufolge die Konsistenz der Benutzeroberflächen verbessert.
Kollaboration und Versionierung von Designs
Einer der Hauptgründe, weshalb Figma mittlerweile so stark Fuß gefasst hat, ist der Fokus dieser Lösung auf das Themenfeld der simplen Kollaboration.
Echte kollaborative Arbeitsabläufe gestalten sich bei Sketch oft umständlich, auch wenn Anfang 2020 mit der Sketch Cloud ein eigenes browserbasiertes Dateifreigabe- und Kollaborationswerkzeug vorgestellt wurde. Die Funktionalitäten in diesem Bereich sind jedoch noch recht grundlegend – so befindet sich zum Beispiel das File-Inspector-Tool immer noch im Beta-Stadium – wobei die Cloud definitiv ein Schritt in die richtige Richtung war.
Bisher wurden die Defizite von Sketch bei grundlegenden Kollaborationsfunktionen meist mit Hilfe von Abstract, einem separaten Design-Bibliothekstool, das über ein Plugin mit Sketch gekoppelt wird, behoben. Dieses bringt eine Git-ähnliche Versionskontrolle und einen branch-basierten Workflow für Designer mit und ermöglicht die Prüfung, das Kommentieren und die Analyse von Design-Dateien. Abstract vereinfacht auch das Sharing von Bibliotheksdateien zwischen Produktteams, was es zu einem erstklassigen Werkzeug für Design-Systeme macht. Ähnlich wie Sketch ist die Desktop-App nur für Mac-Systeme verfügbar, es existiert jedoch auch eine webbasierte Oberfläche.
Obwohl Abstract ein großartiges Werkzeug ist, das die Kollaboration unter Designern grundlegend verändert hat, funktioniert das Zusammenspiel mit den relevanten Schnittstellen noch nicht immer reibungslos. Die Tatsache, dass der gesamte Kollaborations-Workflow von zwei separaten Tools abhängt, die von verschiedenen Unternehmen gestellt werden, macht das Gesamtsystem auch deutlich anfälliger für Kompatibilitätsprobleme. Aus dieser Perspektive betrachtet wird die Strategie von Sketch, Kernfunktionen mit Plugins zu erweitern, von einem Alleinstellungsmerkmal zu einer Belastung. Und das ist genau der Punkt, an dem Figma mit seinen integrierten Kollaborations- und Kommunikationsfunktionen ansetzt.
Anders als Abstract unterstützt Figma keinen Git-ähnlichen Branching-Workflow; die Professional Version bietet vielmehr eine unbegrenzte Versionshistorie und erlaubt Teams eine gemeinsame Nutzung von Design-System-Bibliotheken. Die teurere Organisation Version bietet vielversprechende Analysewerkzeuge für das Design-System, mit deren Hilfe Adoptions- und Nutzungswerte des Design-Systems gemessen werden können. Dies ist mit Abstract nur schwer darzustellen, da hier lediglich einzelne Abhängigkeiten von der genutzten Bibliothek auf Dateiebene untersucht werden können.
Es wird sich zeigen, wie sich die Sketch Cloud entwickelt und ob diese Komponente Sketch in die Lage versetzt, im Wettbewerb mit Figma zu bestehen.
Entwicklungswerkzeuge und Frameworks
Die Fähigkeit wiederverwendbare und anpassbare Komponenten zu erzeugen ist für Entwickler die Grundlage aller Design-Systeme. Wie bei den Design-Tools hängen die technischen Lösungen, auf denen die Komponenten des Design-Systems aufsetzen, von den Produkttechnologien ab.
Front-End-Frameworks im Einsatz
Der Sieger unter den Front-End-Frameworks steht fest: Alle vier Design-Systeme sind mit React konstruiert.
Bibliotheken von Drittanbietern, wie Stilelemente, werden ebenfalls häufig verwendet, um die Entwicklung von Komponenten zu vereinfachen bzw. zu beschleunigen und um beispiels-weise knifflige Probleme im Hinblick auf Funktionalität und Barrierefreiheit zu lösen. Auch wenn diese Bibliotheken kurzfristige Vorteile und Zeitersparnisse mit sich bringen mögen, tendieren die meisten Design-System-Verantwortlichen dazu, Abhängigkeiten auf ein Minimum zu beschränken, um Probleme zu vermeiden, die entstehen sobald das System komplexer wird. Die Erstellung von Qualitätskomponenten für Design-Systeme – insbesondere von barrierefreien Komponenten – ist zwar zeitaufwändiger, wenn jedoch der Umfang des Design-Systems zunimmt, kann die Verwaltung von Abhängigkeiten den Prozess belasten und unerwartete Probleme mit sich bringen.
Code-Repositories und Entwicklungsumgebungen
Häufig erkennen Unternehmen den Bedarf an Design-Systemen erst dann, wenn die Produktentwicklung bereits fortgeschritten ist. Produktteams haben bereits Entwicklungs-abläufe und -umgebungen etabliert. Um Konsistenz zu schaffen und Redundanzen in der Entwicklungsarbeit zu reduzieren wird ein Design-System dann als Teil dieser bestehenden Umgebungen entwickelt.
Bei den Werkzeugen, die für die Versionierung und Distribution von Design-System-Repositorien verwendet werden, gibt es zwei Instrumente. Zwei der Projekte verwenden GitHub. Beide haben ihr Design-System als Open Source freigegeben, entsprechend ist Github eine einfache Lösung zur Umsetzung der gemeinsamen Zusammenarbeit am Code. Zwei der Projekte verwenden Azure DevOps, Teil der Microsoft Azure Cloud Computing Services, das ein umfassenderes Toolkit für DevOps und Projektmanagement bietet.
Als weitere Alternativen sind zum Beispiel GitLab und Bitbucket zu nennen. All diese Tools basieren auf Git, bieten aber unterschiedliche DevOps-Tools für CI/CD, die Erprobungsphase, das Projektmanagement, usw.
Komponentenentwicklung / verwendete Katalogplattformen
Die meisten Design-Systeme verwenden zusätzlich Entwicklungsumgebungswerkzeuge, wie Storybook und React Styleguidist. Wie diese Tools im Arbeitsablauf eingesetzt werden, ist hierbei von Projekt zu Projekt unterschiedlich. In der Regel werden sie als Plattform für die Entwicklung und die Erprobung von UI-Komponenten, sowie als Komponentenkatalog für Entwickler verwendet, mit denen Komponenten und ihre Funktionalitäten präsentiert und die entsprechenden Eigenschaften dokumentiert werden können.
Dokumentationsplattformen
Ohne eine Dokumentation, die entsprechende Prinzipien und Richtlinien für die Verwendung der Bausteine, sowohl im Bereich Design, als auch im Code beschreibt, ist das Design-System nur eine Ansammlung von Einzelkomponenten ohne klaren Zweck.
Welches Werkzeug für die Dokumentation eines Design-Systems am besten geeignet ist, hängt vor allem davon ab, wer Zugriff darauf haben und wer Inhalte hinzufügen können soll.
Verwendete Dokumentationsplattformen
Viele Design-Systeme, insbesondere Open-Source-Lösungen, bieten eine öffentliche Dokumentations-Website. Auch wenn die eigentlichen Komponenten und Design-Assets privat gehalten werden können, kann eine öffentliche Dokumentations-Website als Marketing-Tool dienen, das den Design-Ansatz des Unternehmens präsentiert.
Drei der vier eingesetzten Design-Systeme verwenden eine speziell angefertigte öffentliche Dokumentationsseite – alle basierend auf dem Open-Source Static Site Builder Gatsby oder einer wiederum darauf aufbauenden, dokumentationsseitenspezifischen Variante, wie zum Beispiel docz. Als weitere Open-Source-Alternativen sind zum Beispiel Docusaurus und Cupper zu nennen, die beide mit hoher Barrierefreiheit werben – einem Leistungsmerkmal mit dem docz ernsthafte Probleme hat.
Wenn das Design-System zur geschlossenen Verwendung bestimmt ist und innerhalb einer einzigen Organisation eingesetzt wird, kann die Dokumentation auch in einem organisations-internen Arbeitsbereich wie Confluence verwaltet werden. Eines der vier Projekte nutzte Confluence für die gesamte Dokumentation, ein anderes setzte es lediglich für die Aufzeichnung von Vorgängen ein, die mit dem Design-System zusammenhängen und nicht zur Hauptdokumentationsseite gehörten.
Beide Ansätze haben naturgemäß Vor- und Nachteile. Eine benutzerdefinierte Seite gibt dem Team freie Hand, die Dokumentation so zu gestalten, wie man es für richtig hält: Live-Demos und Component Playgrounds in die Dokumentation einbetten, Token-Listings automatisieren, usw. Im Vergleich zu Confluence ist Gatsby-Site in Sachen Einrichtung und Wartung aufwändiger. Außerdem müssen Redakteure zumindest über grundlegende Programmierkenntnisse verfügen, da die Dokumentation in Markdown und gelegentlich in HTML oder React erfolgt. Und, wie alle Abhängigkeiten, kann auch der Site Builder zur Last werden. Gatsby an sich ist beliebt und wird gut gepflegt, aber zum Beispiel wird docz nicht mehr unterstützt, so dass viele offene Probleme bestehen, die nicht behoben wurden.
Der Vorteil, die Dokumentation auf einer internen Plattform zu halten, ist, dass sie einfach einzurichten und zu pflegen ist, und es dabei auch für Nicht-Entwickler leicht ist, Inhalte hinzuzufügen. Confluence ist jedoch nicht wirklich für diese Nutzung konzipiert und der überschaubare Funktionsumfang kann entsprechend schnell einschränkend wirken. So stehen zum Beispiel nur wenige Möglichkeiten für Automatisierungen, Integrationen oder Live-Komponenten-Demos und Playgrounds zur Verfügung, so dass Dokumentationsarbeit häufig manuell erledigt werden muss.
Aus diesem Grund ist die Wahl des Dokumentationswerkzeugs von enormer Bedeutung. Eine aktuell-gehaltene Dokumentation ist entscheidend für den Erfolg des Design-Systems. Wenn die Dokumentation zu aufwändig zu erstellen ist, kann sie schnell veralten, ihren Zweck verlieren und das ganze Design-System zu einem Blindgänger machen.
Infolgedessen haben sich neue Dokumentationsplattformen auf dem Markt etabliert. Dienste wie Zeroheight und Frontify zielen darauf ab, die Flexibilität von individuell erstellten Dokumentationsseiten mit der einfachen Bearbeitung von Inhalten von Workspace-Plattformen zu kombinieren. Außerdem bieten sie leistungsstarke Integrationswerkzeuge mit gängigen Design- und Entwicklungswerkzeugen. Zeroheight und Frontify werden zwar nicht kostenlos angeboten, können aber erheblich dazu beitragen, wertvolle Zeit und Ressourcen im Bereich der Dokumentationsaufgaben einzusparen und die Dokumentation für Designer und Entwickler relevanter und leichter „verdaulich“ zu machen. Dienste wie diese könnten durchaus als nächster große Wurf im Bereich der Design-Systeme bezeichnet werden.
Zusammenfassung
Werkzeuge, aufgeschlüsselt nach Projekt
Die Wahl geeigneter Werkzeuge kann über den Erfolg oder Misserfolg eines Design-Systems entscheiden. Werkzeuge, die den Bedürfnissen von Designern, Entwicklern und anderen Stakeholdern nicht gerecht werden, können das Wachstum und die Anpassungsfähigkeit des Systems behindern. Heutige Tools entwickeln sich darüber hinaus ständig weiter; der Wechsel von Tools während ein Projekt bereits läuft ist jedoch mühsam und sollte deshalb nicht leichtfertig aufgrund eines Trends vorgenommen werden.
Aus diesem Grund sollte die Instrumentierung, also das Tooling der Systeme, basierend auf den Anforderungen der Produkte und Teams, für die sie konstruiert werden, von Beginn an entsprechend sorgfältig durchdacht werden.
