Systeme entwerfen: Lektionen von Vivid

Unser CSS-Spezialist Rachel Tannenbaum hielt einen erstaunlichen Vortrag, als Vonage die Pull Anfrageein Open-Source-Community-Treffen. Sie hielt einen Vortrag über Designsysteme, ihr Schwerpunkt in den letzten 3 Jahren. Aber jeder sollte etwas über Designsysteme lernen, nicht nur diejenigen, die das Glück haben, an einem Meetup teilzunehmen. Deshalb werde ich in diesem Artikel meine Eindrücke aus ihrem Vortrag teilen und die folgenden Fragen beantworten:

Was meinen wir, wenn wir von Planungssystemen sprechen? Warum brauchen Organisationen überhaupt ein Designsystem? Sind Designsysteme die Aufgabe des Designteams oder des Entwicklungsteams? Wie werden Designsysteme implementiert?

Was sind Entwurfssysteme?

Es begann alles mit Büchern!

Das Markenbuch war die einzige Quelle der Wahrheit, um die Integrität und Einheitlichkeit der Marke zu wahren.

coca-cola-brand-book.png

Vor langer Zeit, als die Menschen noch ohne Internet leben konnten, hatten Unternehmen ein Markenbuch. Dieses Buch enthielt die Markenphilosophie des Unternehmens: Farben, Schriftarten, Bildsprache usw. Es definierte verschiedene Stile in verschiedenen Umgebungen, z. B. eine Zeitungsanzeige gegenüber einer Plakatwerbung. Das Markenbuch von Coca-Cola enthielt zum Beispiel sogar Richtlinien für die Form der Glasflaschen! Dieses Buch ermöglichte es, die Marke und ihre Sichtbarkeit aufrechtzuerhalten, unabhängig davon, wer das Endprodukt herausgab.

Markenbücher werden digital: Style Guides

Aber heute können die Menschen nicht mehr ohne das Internet leben. Aus einseitigen Websites sind ausgedehnte Webanwendungen mit Unterseiten geworden. Es ist für einen einzelnen Designer nicht mehr möglich, die Anwendungen eines Unternehmens zu pflegen. Da die Designteams wachsen, um dieser Herausforderung gerecht zu werden, ist eine neue Ressource entstanden, um das Chaos zu ordnen. Wo es in der analogen Welt das Markenbuch gab, gibt es in der digitalen Welt den Styleguide.

vonage-style-guide-example.png

Ein Style Guide ist die Quelle der Wahrheit für die digitalen Assets einer Marke. Zu diesen Assets gehören grundlegende Bausteine wie Farben, Icons, Typografie und Elemente wie Schaltflächen. Dazu gehören auch komplexere Elemente wie Datumsauswahlen, Menüs und mehr. Natürlich experimentieren auch Softwareunternehmen, die Designtools entwickeln.

Aber was haben Styleguides mit Frontend-Designsystemen zu tun? Stellen Sie sich den Prozess der Frontend-Entwicklung wie das Bauen mit Legosteinen vor. Styleguides nehmen abstrakte Ideen wie Farben und Formen und verwandeln sie in ein Buch mit Anweisungen. Designsysteme nehmen diese Anweisungen und setzen sie in die reale Welt um, indem sie Bausteine zu Objekten zusammensetzen. Der Vorteil eines Designsystems gegenüber einem Styleguide besteht darin, dass ein Designsystem Codeabschnitte, so genannte Komponenten, enthält, die innerhalb einer Anwendung schnell wiederverwendet werden können. Die Verwendung von Komponenten gewährleistet die Einheitlichkeit der Marke und spart wertvolle Entwicklungszeit. Außerdem sind Designsysteme leicht skalierbar und dynamisch. Mit Designsystemen bauen Sie also keinen Code mehr wie ein Handwerker, sondern wie eine leistungsstarke industrielle Fabrik mit niedlichen Legosteinen.

Warum sollten Sie ein Gestaltungssystem verwenden?

Jedes digitale Produkt braucht ein UX-Design-System!

Ok, vielleicht nicht jedes digitale Produkt braucht ein Designsystem. Die Frage, die Sie Ihrer Organisation stellen müssen, lautet: Sind wir ein Ford oder ein Ferrari?

Die Einrichtung und Pflege von Designsystemen kann sehr zeitaufwändig sein. Die großen Vorabinvestitionen lohnen sich nur bei großen Projekten, bei denen Sie langfristig Zeit sparen werden. Ihr Team sollte abwägen, wie viele Entwickler das Designsystem verwenden werden, wie groß der Umfang Ihres Produkts bzw. Ihrer Produkte ist und wie die Standards und die Kommunikation in Ihrem Entwicklungsteam aussehen.

Ist Ihr Team also ein Ferrari? Wenn Sie ein Ferrari sind, haben Sie eine relativ kleine Produktlinie mit nicht allzu vielen wiederholbaren Komponenten. Ihre Produkte sind nicht auf große Stückzahlen ausgelegt, so dass Skaleneffekte bei Ihren Entwürfen Ihrem Unternehmen keine großen Einsparungen bringen würden.

Oder sind Sie ein Ford? Haben Sie viele Produkte, viele Teams und viele Designs, die eine große Anzahl von Seiten und Funktionen umfassen? Ein guter Test ist die Frage: Wenn Sie das Design all Ihrer Schaltflächen aktualisieren müssten, wäre das eine gigantische Aufgabe oder nur eine lästige? Wenn es eine gigantische Aufgabe ist, sind Sie wahrscheinlich ein Ford.

Design Systems Vorteile: Ordnung & Effizienz

Einfach ausgedrückt: Gutes Design verbessert die Nutzererfahrung und erhält die Markenkonsistenz durch Ordnung und Effizienz.

1. Bestellung

   • Bestellung in UI: Festlegung eines festen Designs, eines festen Musters von Verhaltensweisen, Gesten, Interaktionen usw.

   • Bestellung in der Entwicklung: Schafft Ordnung im Chaos, hilft, den Code zu säubern, und verhindert Code-Duplikation.

2. Wirkungsgrad

   • Effiziente Entwicklung: Verringert die Entwicklungszeit und ermöglicht es den Designern, bessere Entscheidungen zu treffen, wodurch Ihr Unternehmen Zeit und Geld spart.

   • Effiziente Updates: - Systemweite Updates im Handumdrehen.

gmail-ui-uniformity-example.png

Google Mail ist ein großartiges Beispiel für Designsysteme, die Ordnung schaffen und die Effizienz steigern. Auf jedem Gerät ist es für den Nutzer klar, dass es sich um ein Google-Produkt handelt. Allein anhand der UI-Komponenten ist dem Nutzer klar, welche Art von Interaktionen er erwarten kann. Und was die Effizienz angeht: Erinnern Sie sich, als Google von Material Design 2 auf Material Design 3 umstieg? Stellen Sie sich vor, überall mussten die roten und lila Navigationsleisten geändert werden, überall mussten die Ecken exakt gleich abgerundet werden. Anstelle von riesigen Kopfschmerzen über die gesamte Produktpalette hinweg sorgte ein Design System dafür, dass Gmail, Google Docs, Google Slides und all die anderen durch wiederverwendbare Komponenten genau gleich aussehen.

Lektionen von Vivid

vivid-vonage-design-system-cover.png

Implementierung eines Entwurfssystems in Iterationen

Bauen Sie nicht zuerst ein UX-Design-System! Denken Sie bei UX-Design-Systemen nach dem LEAN-Prinzip. Sie wollen die nützlichsten und am besten skalierbaren Komponenten bauen. Daher müssen Sie wissen, welche Komponenten von Ihrem Designteam tatsächlich verwendet werden. Das bedeutet, dass Ihr Unternehmen zunächst sein Produkt bzw. seine Produkte erstellen und dann bewerten sollte, welche Komponenten am häufigsten wiederverwendet werden. Konstruktionssysteme sind nicht für V0.1 Ihres Produkts gedacht, sondern erst ab V1.0 und später.

Wie können Sie feststellen, welche Komponenten Sie benötigen? Sie können immer mit den grundlegendsten Elementen beginnen: Typografie, Farben, Schaltflächen usw. Diese Elemente werden unabhängig vom Produkt häufig verwendet. Von dort aus wird sich Ihr Designsystem entwickeln. Nathan Curtis hat einen ausgezeichneten Artikel (https://medium.com/eightshapes-llc/the-component-cut-up-workshop-1378ae110517) mit dem Titel "The Component Cut-Up Workshop" veröffentlicht, in dem Sie den Arbeitsablauf bei der Aufteilung einer Website in die Komponenten sehen können, aus denen das Designsystem besteht.

vivid-abstract-artwork.png

Bei Vonage durchlief unser Designsystem viele Iterationen. Das erste Projekt hieß Volta und trug maßgeblich zur Standardisierung von CSS bei. Als das Projekt dann mehr Unterstützung von der Führung erhielt, wurde es als Vivid bekannt.

Vivid-2 basierte auf Material Design. Bald wurde uns klar, dass dies in mehrfacher Hinsicht problematisch war:

• zu schwer für das, was wir brauchten

• nicht kommunikativ gegenüber der Gemeinschaft und Änderungswünschen/Bugs

• nicht an der Spezifikation ausgerichtet

• nicht vollständig zugänglich

• nicht als Grundlage für die Schaffung eines Entwurfssystems gedacht

Vivid 3: Alles neu überdenken

Beim Wechsel von Vivid 2 zu Vivid 3 haben wir beschlossen, alles völlig neu zu überdenken. Also haben wir die Schnelle Bibliothek von Microsoft als Basis. Wir haben uns für Fast entschieden, weil es speziell als Grundlage für ein Designsystem entwickelt wurde. Gleichzeitig ist sie leichtgewichtig, wird aber auch ständig weiterentwickelt, um neue Komponenten und Funktionen hinzuzufügen. Und am wichtigsten ist, dass sie in Übereinstimmung mit W3C und OpenUI entwickelt wurde.

Vivid-3 hat nicht nur alle Vorteile von Fast, sondern auch verbesserte:

• Testabdeckung - von 70% auf 100% gestiegen

• Dokumentation - mit fertigen Codeschnipseln, die es den Entwicklern leicht machen, einfach zu kopieren und einzufügen, was sie brauchen

• Zugänglichkeit - in Übereinstimmung mit WCAG 2

• weiße Beschriftung

Eine Brücke bauen

Team als Brücke

Ihr Entwurfssystem sollte als Brücke dienen. Bauen Sie Ihr Team mit den richtigen Interessenvertretern auf, die alle ihr Fachwissen einbringen und das Designsystem so gestalten, dass es den Anforderungen der einzelnen Unternehmensfunktionen gerecht wird.

Wer ist für den Aufbau des Entwurfssystems verantwortlich? Kurz gesagt - das Entwicklungsteam. Das Entwicklungsteam sollte die Hauptverantwortung für die Erstellung des Entwurfssystems tragen, aber es ist nicht allein verantwortlich. Einer der wichtigsten Vorteile eines Designsystems ist, dass es als Brücke zwischen Ihren Designern und Entwicklern fungiert. Das Designsystem dient als Leitfaden und bietet eine gemeinsame Sprache, um die Kommunikation zwischen Entwicklern und Designern zu klären. Je mehr Verantwortung zwischen diesen Teams geteilt wird und je mehr Input von jedem Team in die Erstellung eines Designsystems investiert wird, desto besser wird das Endprodukt sein und die Synergien in Ihrem Unternehmen verbessern.

Brücke mit Tooling

Parallel zu unserer API unterhalten wir eine Komponentenbibliothek in Figma für die Designer. Wenn sie an der Gestaltung einer Seite, einer App oder etwas anderem arbeiten, können sie die Asset-Bibliothek von Vivid schnell zu ihren Designkomponenten hinzufügen. Auf diese Weise erhalten sie ein einheitliches Design. In der endgültigen Figma-Datei haben die Entwickler alles, was sie zum Programmieren brauchen: genau die zu verwendenden Komponenten und ihre exakten, pixelgenauen Spezifikationen (Größe, Form, Schriftart usw.).

vivid-component-library-figma.png

Außerdem exportieren wir Design-Token für Farben, Typografie und Größen aus Figma zur Verwendung in der Code-Bibliothek. Das Tolle an den Design-Token ist, dass eine Änderung der Figma eines der Token und deren Export automatisch die gleiche Änderung in Vivid zur Folge hat.

Identifizieren Sie die Hauptanliegen Ihrer Organisation

identify-main-concerns-investigate.png

Vonage ist ein sehr großes Unternehmen mit vielen Entwicklerteams, die an einer breiten Palette von Produkten arbeiten. Dies führt dazu, dass eine große Anzahl von Front-End-Entwicklungsbibliotheken im gesamten Unternehmen verwendet wird: Vue.js, React Native, Angular, und mehr. Die Aufgabe von Vivid ist es, das Design all dieser Projekte zu vereinheitlichen. Für Vivid haben wir 3 Hauptanliegen identifiziert: Skalierbarkeit, Einheitlichkeit zwischen den Frameworks und Barrierefreiheit. Vivid muss sich über eine große Anzahl von Produkten hinweg einheitlich aktualisieren lassen. Wir müssen sicherstellen, dass das Endergebnis unabhängig vom Frontend-Framework ist. Und schließlich müssen wir sicherstellen, dass die Lösung den neuesten Standards für Barrierefreiheit entspricht.

Um diesem Bedarf gerecht zu werden, basiert Vivid auf Webkomponenten.

Was sind Webkomponenten?

Webkomponenten sind eine Reihe verschiedener Technologien, die es Ihnen ermöglichen, wiederverwendbare benutzerdefinierte Elemente zu erstellen, deren Funktionalität vom restlichen Code abgekapselt ist, und sie in Ihren Webanwendungen zu verwenden. Im Grunde genommen besteht das Endprodukt einer Webkomponente aus HTML, CSS und Javascript, was bedeutet, dass sie sich an jede Entwicklungsumgebung anpassen kann. Um mehr zu erfahren, empfehle ich folgende Lektüre Erste Schritte mit Webkomponenten.

Webkomponenten enthalten 3 Hauptelemente:

1. Benutzerdefiniertes Element

Dies ist das "Host"-Element. Es wird im DOM angezeigt und hat normalerweise einen eindeutigen Namen. Bei Vivid Components beispielsweise beginnt der Name des benutzerdefinierten Elements immer mit vwc. Diese Initialen stehen für Vivid Web Components. Der zweite Teil des Elements ist der Name des Elements, der als Beschreibung seines Zwecks dient. Zum Beispiel vwc-button, vwc-dialog, usw.

1. Schatten-Dom

Eine Art "Sub-DOM", das nicht sichtbar ist und unter dem Host-Element, dem benutzerdefinierten Element, liegt. Es ermöglicht einer Komponente, ihren eigenen "Schatten"-DOM-Baum zu haben, auf den nicht versehentlich vom Hauptdokument aus zugegriffen werden kann, und kann lokale Stilregeln haben und mehr.

1. Vorlage

Innerhalb der Schattenkammer sehen wir die HTML-Vorlage, die die Elemente oder Teile der Komponente enthält.

Bei den Web-Komponenten von Vivid müssen die Benutzer die Komponenten nach ihren Bedürfnissen definieren (Text, Symbol usw.) und erhalten im Gegenzug voll funktionsfähige und gestaltete Komponenten, fast ohne Programmierung und ohne Eingriffe in die HTML-Struktur der Komponente selbst.

Um zum Beispiel ein Modal zum Projekt hinzuzufügen, brauchen Sie nur dies:

Unter der Haube, in der Schattenkammer, wird der gesamte Code dem Projekt hinzugefügt:

<vwc-elevation dp="12">
  <dialog class="base icon-placement-side hide-body hide-footer" open="">
  <slot name="main">
    <div class="main-wrapper">
      <div class="header border">
        <slot name="graphic">
          <vwc-icon class="icon" name="info"></vwc-icon>
        </slot>
        <div class="headline">Dialog Headline</div>
        <div class="subtitle">subtitle content</div>
        <vwc-button size="condensed" class="dismiss-button" icon="close-line">   
        </vwc-button>
      </div>
    </div>
  </slot>
  </dialog>
</vwc-elevation>

Um sicherzustellen, dass der Dialog in einem Modal geöffnet wird, muss das Öffnen mit einer FunktionshowModal aktiviert werden.

<script>
  function openDialog() {
    dialog = document.querySelector('vwc-dialog');
    dialog.showModal();
  }
</script>

Das Endprodukt wird so aussehen:

vivid-dialog-component.png

Essen Sie das Hundefutter

Von allen Werkzeugen, die bei der Entwicklung von Designsystemen helfen, Geschichtenbuch wahrscheinlich das beliebteste. Aber trotz all seiner Vorteile ist es nicht einfach, Webkomponenten richtig zu handhaben. Es zeigt den Code der Komponenten nicht korrekt an und generiert keine Code-Snippets für Entwickler.

Aus diesem Grund ist die Dokumentation von Vivid mit...Vivid! Die Verwendung unserer eigenen Komponenten führte zu Verbesserungen bei den Komponenten selbst und ihrer Dokumentation.

Die Verwendung der Komponenten außerhalb der Entwicklungsumgebung ist unerlässlich. Allerdings sollten die Entwickler von Designsystemen immer daran denken, dass sie nicht die Nutzer der Bibliothek sind. Gehen Sie nicht davon aus, dass die Art und Weise, wie Sie die Komponenten verwenden, die einzige oder die richtige ist, sondern kommunizieren Sie mit Ihren Benutzern.

Schlussfolgerung

Jetzt, wo Sie ein wenig mehr darüber wissen, wie wir Vivid aufgebaut haben, sollten Sie es ausprobieren! Schau dir das Bilderbuch oder Github Repo. Wir würden gerne sehen, was Sie mit Vivid entwickeln oder von Ihren eigenen Erfahrungen beim Aufbau eines Designsystems hören. Schreiben Sie uns eine Nachricht in der Vonage Developer Community Slack oder auf Twitter.