Das Minimum Viable Design System

Wachsendes UXPin Design System, das in der UXPin Design System Library gespeichert ist

In den letzten Wochen hatte ich das Vergnügen, über den Ansatz von UXPin zu sprechen, ein Designsystem auf mehreren Meetups und Webinaren aufzubauen (Sie können eines davon hier ansehen). Es hat mir viel Spaß gemacht, unsere Erfahrungen auszutauschen, die ich durch all die schönen Gespräche nach meinen Gesprächen gelernt habe.

Eine Frage, die mir mehrmals gestellt wurde und auch bei meinen Gesprächen mit unserem Team bei UXPin auftauchte, war:

Wie lange dauert der Aufbau eines Designsystems?

Es gibt keine falschen Fragen und ich habe jedes Mal gerne geantwortet. Wenn ich jedoch diese Frage höre, habe ich das Gefühl, dass sie auf ein tieferes Problem hinweist: Design-Systeme werden immer noch missverstanden und mit einem alten Ansatz zur Erstellung eines Style-Guides verwechselt.

Das Vermächtnis des Zombie Style Guide

Früher wurde einem unglücklichen Mitglied des Design- oder Front-End-Entwicklungsteams die Aufgabe anvertraut, alle vom Team genehmigten Konventionen zu dokumentieren. Farbpaletten, Textstile, Codestandards, manchmal sogar Benutzeroberflächenmuster.

Klingt nach einem Design-System? Du hast recht. Es klingt wie ein Design-System, ist es aber nicht.

Diese alte Herangehensweise beim Erstellen eines Styleguides zielte darauf ab, ein Artefakt zu produzieren. Es soll ein Derivat eines Dokumentationsprozesses sein. Und jedes Mal ...

Bevor der Styleguide fertig war, hatte er sich bereits in einen Zombie verwandelt.

Warum? Ganz einfach, weil die dynamische Welt der Produktentwicklung, in der Änderungen ständig stattfinden, nicht gut auf statische Assets reagiert, deren Aufbau Wochen in Anspruch nimmt. Während ein Design- / Entwicklungsmärtyrer Mühe hatte, jede Konvention zu dokumentieren, änderten sich die Konventionen ständig. Einen Styleguide zu erstellen war eine Sisyphus-Aufgabe.

Die Unmöglichkeit, Styleguides zu erstellen und zu pflegen, ermutigte unsere Branche, den Prozess der Wahrung der Konsistenz von Erfahrung und Code zu überdenken. Geben Sie das Konstruktionssystem ein.

Das Design System ist ein Prozess

Im Gegensatz zu statischen Styleguides sind Designsysteme dynamisch. Was heißt das? Der Styleguide ist ein Artefakt, das Designsystem ein Prozess.

Artefakte sind statisch, Prozesse sind dynamisch.

Anstatt eine Person mit der Erstellung der Dokumentation zu beauftragen, planen wir in der Welt des Design-Systems einen neuen Workflow, in dem alle Informationen hinzugefügt, entfernt und geändert werden, um das Benutzererlebnis zu verbessern.

Anstatt an den Liefertermin zu denken, planen Design-System-Teams (in der Regel als Design Operations-Teams bezeichnet), Organisationen dabei zu unterstützen, die innere Konsistenz der Schnittstelle schrittweise zu verbessern und großartige Projekte schneller auf den Markt zu bringen.

Verwalten der Entropie mit einem Style Guide und einem Design System

Gegen Entropie geeint

Wie bei jedem geschlossenen System nimmt die Entropie eines digitalen Produkts weiter zu, sofern es nicht absichtlich verwaltet wird. Jedes neue Feature, jedes neue Mitglied des Teams, jede neue Managementebene oder die Interaktion zwischen Stakeholdern und Kunden tragen zur Entropie der Erfahrung bei.

Das Produkterlebnis wird allmählich zum Chaos.

Das Wachstum der Entropie ist konstant und kann nur durch ständiges Einwirken kontrolliert werden. Aus diesem Grund ist das Endspiel für ein Design Operations-Team kein statisches Artefakt, sondern ein Workflow, in dem eine vereinte Organisation von Designern, Entwicklern, PMs und anderen Teammitgliedern ein Design-System zum Erstellen von Benutzererlebnissen erstellt.

Unendliches Minimum an lebensfähigem Produkt

Die Frage nach dem Liefertermin eines Konstruktionssystems scheint eine versteckte Annahme zu sein, dass es irgendwann einen Zeitpunkt gibt, an dem das Konstruktionssystem „fertig“ ist. Der prozessuale Charakter eines Entwurfssystems hebt diese Annahme auf.

Konstruktionssystem ist ein Prozess und daher gleichzeitig immer bereit und nie fertig.

Ein Konstruktionssystem bleibt in einem konstanten Zustand, in dem es ein minimal lebensfähiges Produkt darstellt. Der Zeitpunkt, zu dem ein Entwurfssystem plötzlich an Wert gewinnt, existiert nicht. Sobald der Entwurfssystemprozess festgelegt und vereinbart ist, ist der Mindestwert erreicht. Mit jeder weiteren Veröffentlichung wird das Design-System leistungsfähiger, erreicht jedoch nie den endgültigen Wert. Die Entropie wächst weiter, die Schnittstelle verändert sich weiter und das Design-System muss sich als Prozess ohne Ende weiterentwickeln.

Starten Sie häufig ein kleines Schiff

Ein Entwurfssystem entsteht, wenn eine Organisation erkennt, dass zunehmende Inkonsistenzen in der Benutzeroberfläche durch neue Workflows behoben werden müssen.

Die Entropie wächst nicht mehr mit der ersten Konvention, die von einer Design-Organisation vereinbart und umgesetzt wurde. Im Gegensatz zu einem Styleguide kann der Wert eines Designsystems sofort erlebt werden. Das Design-System fängt sofort an, Mehrwert zu schaffen, selbst wenn die erste Konvention nur ein Satz von 5 Primärfarben mit der entsprechenden Namenskonvention ist. In der Tat würde ich argumentieren, dass:

Ein einziges Designsystem, das von einer Organisation definiert, richtig benannt, implementiert und akzeptiert wird, ist besser als ein vollständiger statischer Styleguide.

Warum? Weil diese Farbe die Entropie sofort verringert, im Gegensatz zu einem statischen Styleguide, der immer veraltet bleibt und niemals implementiert wird.

Anstatt sich Gedanken über den Liefertermin eines Konstruktionssystems zu machen, akzeptieren Sie dessen Prozesscharakter, beginnen Sie klein und versenden Sie häufig. Du bist im Krieg gegen das Chaos und jede kleine Schlacht ist wichtig.

Viel Glück.

Möchten Sie sehen, wie wir unser Designsystem aufbauen? Folgen Sie unseren Design Operations Sprints:

  • Design Systems Sprint 0: Die Silberkugel der Produktentwicklung.
  • Design Systems Sprint 1: Das Interface-Inventar
  • Design System Sprint 2: Eine Farbpalette für alle
  • Design System Sprint 3: Grundlagen verwalten
  • Konstruktionssystem Sprint 4: Konstruktionsprinzipien
  • Design System Sprint 5: Typografie verwalten
  • Design System Sprint 6: Die schnellsten Icons der Welt

Und hier ist eine breitere Perspektive auf Entwurfssysteme:

Designsysteme sind eine Sprache. Und dies verändert die Softwareentwicklung für immer.

Beitreten: https://www.uxpin.com/design-systems-early-access