Bei Designsystemen geht es um Beziehungen

Designsysteme können unglaublich hilfreich sein. Sie bieten wiederverwendbare Elemente und Richtlinien zum Aufbau eines einheitlichen „Look and Feel“ für alle Produkte. Infolgedessen können Benutzer das, was sie von einem Produkt gelernt haben, auf ein anderes anwenden. Ebenso können Teams gut getestete Muster für die Navigation oder Bewertungen einführen, um Produkte vertrauenswürdiger zu machen. Effektive Designsysteme lösen langweilige Probleme auf wiederholbare Weise, sodass sich Entwickler und Designer auf die Lösung neuartiger Probleme konzentrieren können.

Wenn jedoch jemand in einem Meeting den Begriff „Designsystem“ verwendet, bin ich mir nie ganz sicher, welche Reaktionen zu erwarten sind. Ich habe Neugier und Aufregung beim Ausprobieren einer neuen Arbeitsweise erlebt, aber ich habe auch Frustration und Besorgnis über die Idee eines Systems gesehen, das die Kreativität von Designern einschränkt. Einige Designer argumentieren, dass Designsysteme die Kreativität schwächen oder dass sie Lösungen auf der Suche nach einem Problem sind. Designsysteme können im Laufe der Zeit fragmentieren, was dazu führt, dass Teams sie nicht mehr verwenden.

Designsysteme verschwinden jedoch nicht. Laut einer Umfrage fehlte 2018 nur 15 % der Unternehmen ein Designsystem. Das ist ein Rückgang von 28 % im Vorjahr. Einige Teams verwenden große, universelle Designsysteme wie Material Design von Google, während andere kleinere, maßgeschneiderte Systeme wie Cedar von REI und Protocol von Mozilla verwenden.

Designsysteme sollten Teams stärken, nicht einschränken. Dazu müssen wir anfangen, ganzheitlicher zu denken. Ein Designsystem besteht nicht nur aus Code, Designs oder Dokumentation. Es sind all diese Dinge, plus die Beziehungen zwischen den Leuten, die das System machen, und den Leuten, die es benutzen. Es umfasst nicht nur CSS-Dateien und Sketch-Dokumente, sondern auch Vertrauen, Kommunikation und gemeinsames Eigentum. Wie sich herausstellt, gibt es ein ganzes Studiengebiet, das sich der Erforschung solcher Systeme widmet.

Das große Bild

Ein Artikel aus dem Jahr 1960 mit dem Titel „Socio-technical systems“ untersuchte die Wechselwirkungen zwischen Technologie, Menschen und der größeren Umgebung, in der sie existieren. Enid Mumford erklärte, dass die Forscher zunächst untersuchten, wie bessere Beziehungen zwischen Managern und Mitarbeitern aufgebaut werden können, sich aber in den 1980er Jahren darauf konzentrierten, die Arbeit effizienter und kostengünstiger zu gestalten. Im Jahr 2011 schrieben Gordon Baxter und Ian Sommerville, dass diese Forschung dazu beigetragen hat, benutzerzentriertes Design zu inspirieren, und dass noch viel zu tun bleibt.

Baxter und Sommerville argumentierten, dass es heute noch eine Spannung zwischen „humanistischer“ Forschung, die sich auf die Lebensqualität der Mitarbeiter konzentriert, und „Management“-Forschung, die sich auf ihre Produktivität konzentriert, gibt. Sie erklärten auch, dass es wichtig sei, sowohl Technologie als auch menschliche Interaktionen zu berücksichtigen: „Die Systemleistung beruht auf der gemeinsamen Optimierung der technischen und sozialen Subsysteme.“

Ich würde argumentieren, dass Designsysteme soziotechnische Systeme sind. Sie umfassen Interaktionen zwischen den Personen, die das System erstellen, den Personen, die Produkte mithilfe des Systems erstellen, und den Endbenutzern, die mit diesen Produkten interagieren. Sie rufen auch die gleiche Spannung zwischen Effizienz und Humanismus hervor, die Baxter und Sommerville sahen.

Designsysteme bestehen nicht nur aus Bildern und Code; Sie beinhalten Gespräche zwischen Designern, Entwicklern, Produktmanagern, CEOs und zufälligen Personen auf GitHub. Diese Interaktionen finden in verschiedenen Kontexten statt – einem Unternehmen, einer Open-Source-Community, einem Zuhause – und sie finden über Kulturen und Organisationsgrenzen hinweg statt. Der Aufbau eines Teams kann bedeuten, Menschen aus Disziplinen wie Animation, Sounddesign, Datenvisualisierung, Haptik und Texterstellung zusammenzubringen. Die Erstellung eines erfolgreichen Designsystems erfordert gleichermaßen technisches Know-how und Soft Skills.

Und doch, lesen Sie Design- oder Engineering-News-Aggregatoren und Sie werden wahrscheinlich einen deutlichen Fokus auf dieses „technische Subsystem“ sehen – Code und Tools, eher als Menschen und Gespräche. Welches Kreativtool ist das beste, um Design-Tokens im Auge zu behalten? Welche JavaScript-Technologien sollten zum Erstellen wiederverwendbarer Komponenten verwendet werden – React, Webkomponenten oder etwas anderes? Welches Build-Tool ist das beste?

Die Antwort auf diese Fragen lautet natürlich „es kommt darauf an!“ Wer wird das System entwerfen, bauen und verwenden? Was sind ihre Bedürfnisse? Unter welchen Einschränkungen arbeiten sie? Mit welchen Tools und Technologien sind sie vertraut? Was wollen sie lernen?

Um diese Art von Fragen zu beantworten, empfehlen Baxter und Sommerville zwei Arten von Aktivitäten:

• Sensibilisierungs- und Sensibilisierungsaktivitäten
  Lernen Sie die verschiedenen Menschen kennen, die das System erstellen und daran teilnehmen werden, und teilen Sie diese Informationen weit und breit.
• Konstruktives Engagement
  Rollenübergreifend kommunizieren, Prototypen bauen und sowohl die technischen als auch die sozialen Teile des Systems berücksichtigen.

Eingraben

Anfang 2019 war ich Teil eines Teams – nennen wir es „Team Blue“ – das ein Designsystem für eine große Organisation aufbaute. Ich führte informelle Gespräche mit diesem Team und „Team Green“, das das Designsystem zum Erstellen einer Webanwendung verwendete. Alle paar Wochen haben wir alle Entwickler und Designer an einen Tisch versammelt und darüber gesprochen, was wir bauen und welche Probleme wir zu lösen versuchen. Diese Chats waren unsere „Sensibilisierungs- und Sensibilisierungsaktivitäten“.

Wir hatten keine Erlaubnis, unser Designsystem öffentlich zu machen, also haben wir das Nächstbeste getan: Wir haben es wie ein kleines Open-Source-Projekt innerhalb der Organisation behandelt. Wir legten den Code in einem Repository ab, auf das beide Teams zugreifen konnten, und baten um Beiträge. Team Blau war für die Überprüfung und Genehmigung dieser Beiträge verantwortlich, aber jeder in beiden Teams konnte einen Beitrag leisten. Team Blue baute auch eine eigene Anwendung, also waren sie in gewisser Weise sowohl Benutzer als auch Verwalter des Designsystems.

Diese Interaktionen halfen den Teams, bessere Produkte zu entwickeln, aber was ebenso wichtig ist, sie schafften Vertrauen zwischen den Teams. Team Blue erfuhr, dass die Leute das System mit Bedacht nutzten und darauf clevere neue Ideen bauten. Team Green erfuhr, dass das System wirklich auf ihre Bedürfnisse zugeschnitten war, sodass sie damit statt dagegen arbeiten konnten. Baxter und Sommerville könnten diese Arbeit „konstruktives Engagement“ nennen.

Wir stellten fest, dass beide Teams unter dem Druck standen, neue Technologien zu erlernen und schnell ein vollständiges Produkt zu liefern. Mit anderen Worten, sie arbeiteten bereits unter einer ziemlich beträchtlichen kognitiven Belastung. Als Ergebnis einigten sich die beiden Teams darauf, sich darauf zu konzentrieren, das System benutzerfreundlich zu gestalten. Das bedeutete, die ganze Debatte über Webkomponenten zu umgehen, sich hauptsächlich auf CSS zu konzentrieren und sicherzustellen, dass unsere Dokumentation klar und benutzerfreundlich war.

Alles zusammenfügen

Organisationen jeder Größe erstellen wiederverwendbare Designelemente, um Teams beim Erstellen konsistenterer, eleganterer Anwendungen zu unterstützen. Die Bedürfnisse und Dynamiken verschiedener Organisationen werden in ihren Designsystemen ausgedrückt. Hier nur einige Beispiele:

• Das Material Design von Google hat mehrere Implementierungen in verschiedenen Frameworks und Sprachen. Es wird von einer Vielzahl von Personen innerhalb und außerhalb von Google verwendet und verfügt daher über eine umfassende Dokumentation und eine Vielzahl von Toolkits für das Design von Apps.
• Das Fluent Design System von Microsoft zielt auf vier sehr unterschiedliche Plattformen ab. Wie Material enthält es Toolkits für UX-Designer und eine umfassende Dokumentation.
• Das Mozilla-Protokoll ist in Sass und Vanilla JavaScript implementiert. Es hat einen starken Fokus auf Internationalisierung. Alex Gibson sagt, dass dieses System Mozilla hilft, „Markenwebseiten schneller mit weniger sich wiederholender manueller Arbeit zu erstellen“.
• Cedar von REI wurde mit Vue.js-Komponenten erstellt und kann nicht mit anderen JavaScript-Frameworks verwendet werden. Cedar wird hauptsächlich von den internen Entwicklern von REI verwendet und ist eng mit der Marke des Unternehmens verbunden. Der Code des Designsystems ist Open Source, seine Schriftarten jedoch nicht.
• Das Lightning Design System von Salesforce ist ein JavaScript-agnostisches CSS-Framework. Es kann optional zusammen mit dem Lightning Component Framework verwendet werden, das zwei JavaScript-Implementierungen enthält: eine mit Webkomponenten und eine mit dem proprietären Aura-Framework von Salesforce.
• PatternFly von Red Hat wurde entwickelt, um eine konsistente Benutzererfahrung über die Cloud-Plattformprodukte des Unternehmens hinweg zu bieten, sodass es eine relativ hohe Informationsdichte aufweist und eine Vielzahl von Datenvisualisierungskomponenten enthält. Das PatternFly-Team hat kürzlich nach einigen Experimenten mit Webkomponenten von Angular zu React gewechselt. PatternFly enthält auch eine JavaScript-agnostische Implementierung mit HTML und CSS. (Vollständige Offenlegung: Ich bin ein ehemaliger Red Hatter.)
• Das Carbon Design System von IBM bietet Implementierungen in React, Vue, Angular und Vanilla JavaScript sowie ein Design-Toolkit für Sketch. Das Carbon-Team experimentiert mit Webkomponenten. (Hutspitze an Jonathan Speek für das Aufspüren dieses Repositorys.)

Systeme wie diese sind konsistent und zuverlässig, weil Menschen aus verschiedenen Teams und Rollen zusammengearbeitet haben, um sie aufzubauen. Diese Systeme lösen echte Probleme. Sie sind nicht das Ergebnis von Entwicklern, die versuchen, Designern ihren Willen aufzuzwingen oder umgekehrt.

Josh Mateo und Brendon Manwaring erklären, dass die Designer von Spotify „ihre Rolle als zentrale Mitwirkende und Mitautoren eines gemeinsamen Systems sehen – eines, das ihnen gehört“. Mina Markham beschreibt sich selbst als „Übersetzerin zwischen Technik und Design“ im Pantsuit-Designsystem. Jina Anne vertieft sich in die Teamdynamik und Benutzerforschung hinter Designsystemen: „Spoiler-Alarm! Sie brauchen mehr als nur Designer.“

Lass uns ein paar Sachen bauen!

Nachdem wir nun die Recherche und einige Beispiele durchgegangen sind, wollen wir darüber sprechen, wie man ein neues Designsystem erstellt. Beginnen Sie damit, mit Menschen zu sprechen. Finden Sie heraus, wer Ihr Designsystem verwenden und zu ihm beitragen wird. Diese Leute werden wahrscheinlich eine Vielzahl von Disziplinen abdecken – Design, Entwicklung, Produktmanagement, Business und dergleichen. Informieren Sie sich über die Bedürfnisse und Ziele der Menschen und bitten Sie sie, mitzuteilen, woran sie arbeiten. Erwägen Sie, ein informelles Treffen mit Snacks, Kaffee oder Tee zu planen, um eine einladende Atmosphäre zu schaffen. Bauen Sie regelmäßige Kommunikation mit diesen Leuten auf. Das kann bedeuten, einem gemeinsamen Chatroom beizutreten oder regelmäßige Meetings zu planen. Halten Sie den Ton locker und freundlich und konzentrieren Sie sich auf das Zuhören.

Wenn Sie darüber sprechen, woran Sie arbeiten, suchen Sie nach gemeinsamen Problemen und Zielen. Möglicherweise stellen Sie fest, dass Teams große Datenmengen anzeigen müssen, und untersuchen daher Tools zum Anzeigen von Tabellen und zum Erstellen von Berichten. Priorisieren Sie Lösungen für diese Probleme.

Suchen Sie auch nach sich wiederholenden Mustern und Variationen zu ähnlichen Themen. Möglicherweise stellen Sie fest, dass Schaltflächen und Anmeldeformulare je nach Team etwas anders aussehen. Welche Bedeutung haben diese Variationen? Welche Variationen sind beabsichtigt – zum Beispiel eine primäre Taste im Vergleich zu einer sekundären Taste – und welche Variationen sind zufällig entstanden? Ihr Designsystem kann die absichtlichen Muster und Variationen benennen und katalogisieren, und es kann die „zufälligen“ Variationen eliminieren.

Das Ziel hier ist es, eine schnelle Feedback-Schleife mit Menschen aufzubauen, die das Designsystem verwenden. Schnelleres Feedback und kleinere Iterationen können dazu beitragen, dass Sie nicht zu weit in die falsche Richtung gehen und den Kurs drastisch ändern müssen. PJ Onori nennt diese plötzlichen, großen Veränderungen „Thrash“. Er sagt, dass etwas Thrash gut ist – es ist ein Zeichen dafür, dass man lernt und auf Veränderungen reagiert – aber dass zu viel störend sein kann. „Man sollte sich vor Thrash nicht fürchten“, sagt er, „aber man muss wissen, wann es nützlich ist und wie man seine Nachteile mindern kann. Eine der besten [Möglichkeiten], um die Nachteile von Thrash abzumildern, besteht darin, klein anzufangen – mit allem .“

Erwägen Sie, klein anzufangen, indem Sie einige grundlegende Elemente einrichten:

• Ein Versionskontrollsystem zum Speichern Ihres Codes. GitHub, GitLab und Bitbucket sind hier großartige Optionen. Stellen Sie sicher, dass jeder, der das System verwendet, auf den Code zugreifen und Änderungen vorschlagen kann. Erwägen Sie nach Möglichkeit, den Code Open Source zu machen, um das größtmögliche Publikum zu erreichen.
• CSS-Code zur Implementierung des Systems. Verwenden Sie Sass-Variablen oder benutzerdefinierte CSS-Eigenschaften, um „Design-Token“ zu speichern – allgemeine Werte wie Breiten und Farben.
• Eine package.json-Datei, die definiert, wie Anwendungen das Designsystem erstellen und installieren können.
• HTML-Dokumentation, die die Verwendung des Designsystems demonstriert, idealerweise unter Verwendung des systemeigenen CSS.

Die node-sass-Dokumentation für das CSS-Framework Bulma beschreibt diese Schritte etwas ausführlicher. Sie können die Installation und den Import von Bulma überspringen, wenn Sie von vorne anfangen möchten, oder Sie können es einschließen, wenn Sie mit einigen der Grundlagen beginnen möchten.

Sie haben vielleicht bemerkt, dass ich hier nichts über JavaScript erwähnt habe. Vielleicht möchten Sie dieses Element irgendwann hinzufügen, aber Sie brauchen es nicht, um loszulegen. Es ist einfach, in ein Kaninchenloch zu gehen, um die besten und neuesten JavaScript-Tools zu recherchieren, und sich in dieser Recherche zu verlieren, kann den Einstieg erschweren. Zum Beispiel sind „5 Gründe, warum Webkomponenten perfekt für Designsysteme sind“ und „Warum ich keine Webkomponenten verwende“ wichtige Argumente, aber nur Sie können entscheiden, welche Tools für Ihr System richtig sind. Wenn Sie nur mit CSS und HTML beginnen, können Sie reales Feedback sammeln, das Ihnen helfen wird, diese Entscheidung zu treffen, wenn die Zeit gekommen ist.

Wenn Sie neue Versionen des Systems veröffentlichen, aktualisieren Sie die Versionsnummer Ihres Systems, um anzugeben, was sich geändert hat. Verwenden Sie die semantische Versionierung, um mit einer Zahl wie „1.4.0“ anzugeben, was sich geändert hat. Erhöhen Sie die letzte Zahl für Fehlerbehebungen, die mittlere Zahl für neue Funktionen und die erste Zahl für große, störende Änderungen. Kommunizieren Sie weiterhin mit den Leuten, die das Designsystem verwenden, bitten Sie um Feedback und Beiträge und nehmen Sie währenddessen kleine Verbesserungen vor. Diese kollaborative, iterative Arbeitsweise kann dazu beitragen, den „Thrash“ zu minimieren und ein Gefühl der gemeinsamen Verantwortung zu schaffen.

Erwägen Sie schließlich, Ihr Designsystem als Paket auf npm zu veröffentlichen, damit Entwickler es verwenden können, indem Sie den Befehl npm install your-design-system . Standardmäßig sind npm-Pakete öffentlich, aber Sie können auch ein privates Paket veröffentlichen, das Paket in einer privaten Registrierung veröffentlichen oder Entwickler bitten, das Paket direkt von einem Versionskontrollsystem zu installieren. Die Verwendung eines Paket-Repositorys erleichtert das Auffinden und Installieren von Updates, aber die Installation direkt aus der Versionskontrolle kann eine einfache kurzfristige Lösung sein, um Teams den Einstieg zu erleichtern.

Wenn Sie daran interessiert sind, mehr über die technische Seite der Dinge zu erfahren, bietet Katie Sylor-Millers Building Your Design System einen fantastischen Einblick in die Tiefe. (Vollständige Offenlegung: Ich habe mit Katie gearbeitet.)

Einpacken

Designsysteme bestehen aus Code, Designs und Dokumentation sowie aus Beziehungen, Kommunikation und gegenseitigem Vertrauen. Mit anderen Worten, sie sind soziotechnische Systeme. Um ein Designsystem zu erstellen, beginnen Sie nicht damit, Code zu schreiben und Tools auszuwählen; Sprechen Sie zunächst mit den Personen, die das System verwenden werden. Lernen Sie ihre Bedürfnisse und Einschränkungen kennen und helfen Sie ihnen, Probleme zu lösen. Berücksichtigen Sie bei technischen, gestalterischen oder strategischen Entscheidungen die Bedürfnisse dieser Personen und nicht die theoretisch „beste“ Vorgehensweise. Fangen Sie klein an, iterieren Sie und kommunizieren Sie, während Sie fortfahren. Halten Sie Ihr System so einfach wie möglich, um den Aufwand zu minimieren, und bitten Sie um Feedback und Beiträge, um ein Gefühl der gemeinsamen Verantwortung zu schaffen.

Indem wir technische und zwischenmenschliche Überlegungen gleichermaßen berücksichtigen, können wir die Vorteile von Designsystemen nutzen und gleichzeitig die Fallstricke vermeiden. Wir können effizient und menschlich arbeiten; wir müssen uns nicht für eines entscheiden. Wir können Teams stärken, anstatt sie einzuschränken. Befähigte Teams helfen uns letztendlich dabei, unsere Benutzer besser zu bedienen – und das ist schließlich der Grund, warum wir überhaupt hier sind.

Weiterführende Literatur zu SmashingMag:

• Tipps zum Verwalten von Designsystemen
• Einbinden von Animationen in Ihr Designsystem
• Beyond Tools: Wie der Aufbau eines Designsystems Ihre Arbeitsweise verbessern kann
• Aufbau eines groß angelegten Designsystems für die US-Regierung (Fallstudie)