Ein Rezept für ein gutes Designsystem

Dieser Artikel wurde freundlicherweise von unseren lieben Freunden bei Backlight unterstützt, einer kollaborativen Plattform, die Front-End-Teams in die Lage versetzt, großartige Designsysteme zu entwickeln und zu liefern. Danke!

Theoretisch hat jeder ein relativ ähnliches Konzept dafür, was ein „Designsystem“ bedeutet, obwohl Nuancen auftauchen, wenn wir uns der realen Welt nähern. Das Ziel mag immer noch dasselbe sein, aber unterschiedliche Organisationen benötigen unterschiedliche Strategien, um es zu erreichen. Wie bei vielen komplizierten Aufgaben in Ingenieurwesen und Architektur gibt es keinen Königsweg für ein gutes Designsystem.

Obwohl erfolgreiche Bemühungen einige gemeinsame Muster aufweisen, die das Entstehen von Werkzeugen und Best Practices ermöglicht haben. In diesem Artikel werden wir einen Blick darauf werfen, welche Lösungen in das Dach eines Designsystems passen, und einige wichtige Schritte und Prüfpunkte, die Sie während Ihrer Projekte im Auge behalten müssen. Unsere Erfahrungen mögen unterschiedlich sein, aber hoffentlich gibt es Erkenntnisse für Sie, bei denen ich persönlich gescheitert und erfolgreich war.

Ziel und Bedeutung

Betrachten wir ein „System“ als eine Kombination von Teilen, die zusammenarbeiten, und „Design“ als den Plan des Aussehens und der Funktion von etwas. Dann können wir das Designsystem als ein Kollektiv von Definitionen verstehen, die Muster vorschreiben, in denen die miteinander verbundenen Teile eines Systems aussehen, sich anfühlen und funktionieren. Das ist immer noch ziemlich abstrakt, aber genug, um es als mehr als nur Aussehen zu verstehen.

Es ist keine Komponentenbibliothek, die Sie wie ein Puzzle zusammensetzen und zu einem konsistenten Layout gelangen. Ein Designsystem hat zwar einen Präsentationsaspekt, aber es geht auch um Funktion und Integration. Es geht um Erfahrung .

• Benutzererfahrung
  Mit einer zuverlässigen und funktional konsistenten Benutzeroberfläche.
• Entwicklererfahrung
  Mit einfach zu integrierenden Komponenten und definierten Mustern.
• Stakeholder-Erfahrung
  Mit einem allgemeinen Überblick darüber, wie sich das Produkt entwickelt und wächst.

Bei so vielen beweglichen Teilen ist es verständlich, dass es nicht eine einzige Antwort für alle Designsysteme gibt.

Absichtlich vs. Organisch

Wenn ein Team beschließt, ein Designsystem zu erstellen, gibt es zwei Ansätze, bei denen es sich im Voraus entscheiden muss:

• Organisch
  Nehmen Sie eine vorhandene App als Referenz, extrahieren Sie Teile davon und abstrahieren Sie sie so weit, dass sie von einer anderen App verwendet werden können. Dieser Ansatz erfordert von Anfang an weniger Entscheidungen, erfordert jedoch mehr reaktive Bemühungen des Teams, um neu gefundenen Anforderungen von Anwendern gerecht zu werden. Architekturentscheidungen werden in der Regel nach Bedarf statt proaktiv getroffen.
• Absicht
  Token, Muster und Komponenten werden im Voraus gedacht. Die Grenzen eines Minimal Viable Product (MVP) sind definiert und die Arbeit beginnt. Für diesen Ansatz ist das Festlegen von Zielen und Anforderungen ein wichtiger Schritt, um die Erwartungen mit den Stakeholdern in Einklang zu bringen.

Organisch

Wenn es dem Designsystem ermöglicht wird, sich organisch zu entwickeln, hängt der Erfolg des Unterfangens vom Buy-in von Stakeholdern und Anwendern ab. Und wie effektiv das Team reagieren kann, wenn es alle Unbekannten beseitigt , die es auf dem Weg findet, ohne übermäßig störend mit kontinuierlicher Unterstützung zu sein. Es ist ein schwieriger Weg und Kommunikation ist der Schlüssel. Es gibt keinen klaren Aktionspfad, da er eng mit dem Kontext des Teams verknüpft ist.

Darüber hinaus ist es schwierig, das System während des Betriebs zu optimieren (fragen Sie Ihren örtlichen Elektriker), und da die Aufgaben Zeit brauchen, können sich die Anforderungen ändern: Der Markt wird nicht auf Ihre Komponentenbibliothek warten. Ein üblicher „Make it or break it“-Moment für ein organisches Designsystem besteht darin, die Entwicklungsgeschichte für ein Komponenten-MVP (Minimum Viable Product) herauszufinden.

Auf der einen Seite haben wir Entwickler und Designer, die die bestmögliche Erfahrung und die Quintessenz der Codequalität schaffen wollen; Auf der anderen Seite gibt es KPIs, ROIs und seine Akronyme, um den Erfolg zu messen. Das Gleichgewicht zu finden und skalierbar zu bleiben, ist schwierig. Wie man etwas Unfertiges abstrahiert, ist sogar noch kniffliger, und zu vermeiden, dass diese Folgeaufgaben im Backlog vergessen werden, ist die Eine-Million-Dollar-Frage des Produktmanagements.

Die Fähigkeit, Ihr Designsystem schnell und inkrementell zu iterieren, wird zu einer Grundvoraussetzung, wenn Sie sich mit dem organischen Ansatz befassen. Und es erfordert auch ein zusätzliches Maß an Klarheit von Ihren Verbraucherentwicklern (falls es separate Teams gibt: eines erstellt das Designsystem, das andere erstellt Produktfunktionen). Beide müssen die Erwartungen klar an Produktanforderungen und Entwicklererfahrungsanforderungen ausrichten, um eine richtige Symbiose einzugehen. Denn ein Design System ist nichts, wenn es lästig zu bedienen ist oder das Benutzererlebnis in irgendeiner Weise verschlechtert.

Absicht

Es ist viel mehr Planung erforderlich, Unbekanntes muss geklärt und die Infrastruktur vorbereitet werden, wenn man die bewusste Entscheidung trifft, das Designsystem zu erstellen, bevor man ein Produkt hat, auf dem man es verwenden kann. Die Kehrseite bringt mehr Klarheit bei Einschränkungen. Ziele und Erwartungen. Wenn die Segel vor dem Verlassen des Hafens noch einmal überprüft werden, ist der Sturm weniger beängstigend.

Auch die Vorhersagbarkeit des Systems wächst mit der Vorausplanung, denn das Design System wird zu einem eigenen Produkt und nicht zum Werkzeug, um andere besser zu machen. Mit dieser Abstraktion lassen sich Muster und Lösungen, die in anderen verwendet werden, leichter transportieren.

Obwohl es für Teams mit weniger Erfahrung zunächst kontraproduktiv erscheinen mag, „Intentional“ statt „Organic“ zu wählen, da sie keinen Proof-of-Concept zum Testen haben, ist es besonders hilfreich, häufige Fallstricke zu Beginn zu vermeiden. „Auf den Schultern von Giganten stehen“ ist ein gängiger Jargon und gilt in diesem Fall als wahr. Das beste Rezept für die Zukunft sollte also ungefähr so ​​​​aussehen:

1. Identifizieren Sie grundlegende Anforderungen;
2. Recherchieren Sie frühzeitig und gründlich nach ähnlichen Fällen;
3. Ergebnisse aus 2 für implizite Lösungen und Strategien überfliegen;
4. Machen Sie es sich zu eigen, indem Sie eine Kombination gängiger Lösungen zusammenstellen und Ihre eigene Soße hinzufügen;
5. Iterieren.

Diese fünf Schritte mögen einfach und offensichtlich klingen, sind es aber nicht. Es ist einfach, eine der Anforderungssammlungen zu überspringen oder die Recherche abzubrechen. Tipp: Sie zahlen Zinsen für Schritt 4, wenn Sie eines davon vergessen haben.

Auf Effizienz ausgelegt

Kein Paketkonsument freut sich, wenn ein Abhängigkeitsupdate seine App in irgendeiner Weise beschädigt. Es ist nicht anders, wenn das betreffende Paket Teil eines Designsystems ist. Eigentlich könnte man darauf hinweisen, dass es schlimmer ist. Die Gegenreaktion einer internen Abhängigkeit, die eine App bricht, ist tendenziell größer als wenn es sich um ein Open-Source-Paket handelt, außerdem neigen UI-Änderungen dazu, zuerst vor den Augen der Endbenutzer „still zu brechen“, was besonders frustrierend ist.

Vor diesem Hintergrund können wir bereits einige Probleme aufstellen:

• API-Dokumentation
  Machen Sie es einfach zu entdecken und zu verwenden.
• Versionierung
  Gibt an, wie sich Freisetzungen voraussichtlich auf die Verbraucher auswirken werden.
• Änderungsprotokoll
  Gibt an, welche Änderungen jede Version enthält.
• Loslassen
  Eine vernünftige Möglichkeit, stabilen Code für alle Verbraucher einfach bereitzustellen.
• Entwicklungsumgebung
  Es gibt noch keine App, die es verwendet, muss herausfinden, wie man Artefakte präsentiert und entwickelt.

Es ist wichtig darauf hinzuweisen, dass die Priorität jedes dieser Elemente je nach Kilometerstand variieren kann. Aber die Notwendigkeit für sie wird zunehmen, wenn das Designsystem skaliert, die Akzeptanz zunimmt und die Funktionen wachsen. Sie reichen vielleicht nicht aus, um ein Team daran zu hindern, voranzukommen, aber sie werden mit Sicherheit die Produktivität beeinträchtigen, wenn die Kapazität verzerrt ist, um diese Lösungen zu finden.

Quelle der Wahrheit

Ein weiterer potenzieller Schmerzpunkt, mit dem viele Teams konfrontiert sind, ist die Identifizierung der Quelle der Wahrheit in einem Designsystem. Ist es Code, UI oder Dokumentation? Bei vielen Arten von Produkten schauen wir einfach auf die Verbraucherseite und können leicht erkennen, was der Hauptausstoß ist. Der Grund, warum es in diesem Fall schwierig wird, liegt darin, dass jede Art von Verbraucher es anders verwendet und die Antwort daher je nach demografischer Frage variiert.

Ein Designsystem ist oft eine Mischung aus einer Komponentenbibliothek, Dokumentation und einem Styleguide. Und nicht nur der Konsument ist bei jedem dieser Artefakte anders, sondern auch der Handwerker ist anders. Ein Entwickler, ein Designer, ein technischer Redakteur; Für die Erstellung jeder Ausgabe sind unterschiedliche Personen erforderlich.

Heiße Kartoffel

Um die Lieferung konsistent zu halten, sind Kommunikation und Zusammenarbeit entscheidend. Und der bereits etablierte wasserfallartige Prozess ist für beide nicht ermutigend.

Es gibt keinen entworfenen (Wortspiel-beabsichtigten) Raum für Zusammenarbeit oder Iteration basierend auf jeder Spezialität. Oft sind sich Designer einiger Codebeschränkungen nicht bewusst, und der Entwickler hat keine Ahnung von der UX, die für die Ausgabe vorgesehen ist. Dieser Ansatz ist nicht extrem nachteilig, es ist möglich, ein gutes Produkt damit zu erstellen. Aber ein großartiger ist schwer, jeder Teil des Prozesses ist fast getrennt, es sei denn, das Team bemüht sich aktiv, ihn zu korrigieren.

Der immer wieder erstaunliche Dan Mall und Brad Frost haben den ebenso großartigen Namen für ein neues Verfahren geprägt: Hot Potato. Dieser Prozess fördert nicht nur die Kommunikation, sondern zwingt dem Team auch direkt die Zusammenarbeit auf, indem er die Quelle der Wahrheit der Arbeit vereinheitlicht. Damit haben alle gelieferten Artefakte nicht nur einen gemeinsamen Ursprung, sie sind auch ein Produkt der Expertise des kombinierten Teams.

Diese Art der Zusammenarbeit reibungslos zu gestalten, ist jedoch leichter gesagt als getan. Sie sitzen sogar nebeneinander, um „Sie sind stummgeschaltet“, „Meine Verbindung wurde unterbrochen“ und „Können Sie mich hören?“ auszuweichen. Ärger, wenn der Informationsaustausch zusammengelegt wird, neigt er dazu, leicht informell zu werden, und dann kann der Prozess am Ende schwer zu dokumentieren oder zu synchron sein. Wir wollen weniger Engpässe, nicht mehr.

Die Live-Zusammenarbeit zwischen Kollegen hat sich zu großen Teilen entwickelt. Wie VSCode Share oder FigJams von Figma, Cloud-IDEs, gibt es viele Optionen. Aber wenn es darum geht, zwischen verschiedenen Spezialitäten zu iterieren, ist es nicht sehr einfach. Fügen Sie dies zu dem Stapel von Werkzeugen, Architektur oder Prozessen hinzu, die in den vorherigen Abschnitten erwähnt wurden, und Sie haben einen Haufen Arbeit zu erledigen, bevor Sie überhaupt mit der Arbeit beginnen.

Architektur eines Systems

Wie oben erwähnt, ist die Pflege eines Designsystems eine Menge Arbeit. Der beste Rat ist wahrscheinlich, zu versuchen, die Dinge nach Möglichkeit nicht von Grund auf neu zu machen. Nutzen Sie Community-Ressourcen, wo es Ihnen passt. Dadurch wird weniger Zeit für die Wartung bestimmter Punkte des Systems wettgemacht, und es hilft beim Onboarding von Ingenieuren und Designern, wenn sie bereits mit bestimmten Teilen des Systems vertraut sind.

In kommt Hintergrundbeleuchtung. Es ist eine Plattform als Service, die eine Reihe von Tools auf eigensinnige, aber flexible Weise zusammenstellt, um diesen gesamten Architekturaufbau zu beschleunigen. Sie können entweder bei Null anfangen oder eine Startervorlage auswählen, die am besten zu Ihrem Projekt passt. Es werden keine Räder neu erfunden, wenn es nicht unbedingt notwendig ist, sie verwenden Community-Ressourcen in all ihren Startern (der, den ich ausprobiert habe, Yogi, basiert auf ChakraUI), weniger Wartung für sie und der Verbraucher macht sich keine Sorgen darüber, eingesperrt zu sein. Darüber hinaus wird Code auf Ihre Versionierungsplattform gepusht, so dass es nur ein paar Shell-Befehle entfernt sind, wenn nötig.

Sobald es dort angekommen ist, wird es die Integration mit einer Versionierungsplattform (Gitlab und GitHub werden unterstützt), einer Storybook-basierten Sandbox, einer VSCode-basierten IDE, Komponententests und sogar der Veröffentlichung in der NPM-Registrierung arrangieren (letzteres hängt von Ihrem Plan mit ihnen ab). kann auf Ihr Konto oder deren sein).

Mehrere Ausgänge

Wir haben zuvor abgebildet, dass es mindestens 3 verschiedene Ausgaben gibt, die die meisten Designsysteme benötigen: Dokumentation, Code, Benutzeroberfläche. Sobald die Architektur bereit ist, jeden von ihnen auszugeben, findet das Team normalerweise eine weitere Herausforderung heraus: sie synchron zu halten. Entwickler sind immer bestrebt, Änderungen atomar vorzunehmen, Sie berühren einen Ort und sie verteilen sich an jedem Ort, der diese Informationen verbraucht. Innerhalb eines Designsystems ist das nicht immer klar, wie man das bewerkstelligt.

Wenn Sie den Hot-Potato-Prozess nicht verfolgen, können Sie leicht den Überblick darüber verlieren, welche UI-Updates bereits von Entwicklern behoben wurden. Und selbst wenn, dann gibt es eine Dokumentation. Die Hintergrundbeleuchtung löst dieses Problem, indem sie alles zusammenfasst.

Und sobald Änderungen vorgenommen wurden, ohne das Dashboard der Plattform zu verlassen. Es ist möglich, die aktualisierte Live-Dokumentation zu überprüfen.

Und all dies kratzt nur an der Oberfläche dessen, womit sie Ihre Architektur verbessern können. Sie erhalten außerdem:

• Screenshot-Tests auf Pull-Requests mit ihrer „Visual Review“-Funktion
• Unterstützung für testgetriebene Entwicklung mit integrierten Unit-Tests
• Sandbox mit Live-Vorschau

Es ist eine vollständige Entwicklungsumgebung für Ihr Designsystem. Und Sie erhalten immer noch all diese Integrationen, auch wenn Sie sich entscheiden, ihre Starter nicht zu verwenden. Die Infrastruktur ist für Sie da, um die Komponentenbibliothek zu erstellen, die Ihr Designsystem von Grund auf neu füttert.

Remote-Zusammenarbeit in Echtzeit

Wie bereits erwähnt, kann der Hot-Potato-Prozess für Teams problematisch werden, wenn es darum geht, eine entfernte und asynchrone Arbeitsweise einzurichten. Die Hintergrundbeleuchtung adressiert dies mit einer Kombination aus zwei Funktionen:

• Designintegration;
• Teilen Sie einen Live-Link.

Die Designintegration bringt das Designartefakt aus Ihrem Designtool auf dieselbe Plattform. So kann der Rest des Teams direkt vom selben Dashboard aus nachsehen, Kommentare hinzufügen und nachschlagen:

Mit dieser Funktion beginnt der heiße Kartoffelprozess direkt am Reißbrett, egal wo sich Ihr Team befindet. Und ohne die Tabs zu wechseln, glättet es auch den Codierungsprozess mit der Link-Sharing-Funktion, die mit ihrem Werbe-Gif besser erklärt wird als alles, was ich selbst tun könnte. Entwickler können einen Echtzeit-Remote-Link ihrer Arbeit teilen, ohne Dinge irgendwo zu veröffentlichen, kein Zwischenprozess, das ist ein großer Schub für Teams, die detaillierte Arbeiten schnell iterieren müssen.

Imbiss

Falls dies noch nicht der Fall war, ist es hoffentlich jetzt klarer, was die Erstellung und Pflege eines Designsystems mit sich bringt. Viel mehr als eine Handvoll CSS-Klassen, Token-Definitionen und Schriftarten; es geht um Werkzeuge, aktive Unterstützung und Interessenvertretung. Die Nützlichkeit eines Projekts hängt von der Qualität seiner Ergebnisse ab und davon, wie schnell es sich an die sich ständig ändernden Anforderungen anpassen kann.

Bereiten Sie sich also darauf vor, bei der Erstellung Ihres Projekts produktiv und effizient zu sein. Wenn Sie sich noch nicht zurechtfinden, helfen Ihnen Tools wie Backlight mit vernünftigen Standardeinstellungen und einer großartigen Benutzererfahrung, die sofort einsatzbereit ist. Wenn Sie bereits mit einer bestimmten Architektur vertraut sind, wählen Sie Ihre Schlachten mit Bedacht aus und nutzen Sie die Community, um den Rest zu erledigen.