Design Systems 101 – Teil 5: Anatomie der OTTO Pattern Library

In den beiden vorangegangenen Artikeln drehte sich alles um die Grundlagen von Patterns. So ging es zum Beispiel um das Identifizieren und Strukturieren von Patterns sowie die Erschaffung eines flexiblen und eindeutigen Naming-Schemas. Dieser Artikel soll nun als Case Study zeigen, wie wir auf Basis dieser Grundlagen die heutige OTTO-Pattern-Library konzipiert haben. Damit schließt er auch die im zweiten Teil beschriebene Entwicklungsgeschichte unserer Library ab.

← Zum Anfang der Serie

Damit dieser Artikel eigenständig funktioniert, werden hier einige Inhalte aus dem zweiten und dritten Teil wiederholt. Diejenigen, die diese Teile eben erst gelesen haben, möchte ich an dieser Stelle um Nachsicht bitten.

Wir beginnen mit einer wichtigen Erkenntnis:

Pattern Libraries und Design Systeme sind Produkte!

Wie Nathan Curtis so treffend schreibt: Design Systeme sind keine Projekte – sie sind Produkte. Design Systeme und Pattern Libraries sollten stets als Produkte betrachtet werden, die es zu pflegen und weiterentwickeln gilt. Produkte, die genau so einen Produktlebenszyklus haben und genau so eine Produktverantwortung benötigen, wie das Produkt oder die Produkte für die sie erschaffen worden sind. Denn solange sich diese Produkte immer weiter entwickeln, sollte auch das Design System niemals fertig sein.

Design Systeme und Pattern Libraries sind Produkte und keine Projekte. Genau wie die Produkte für die sie erschaffen worden sind, brauchen sie Produkt-Verantwortliche, die sie pflegen und weiterentwickeln.

Auf Twitter teilen →

Bereits ab der zweiten Iteration der OTTO Pattern Library haben wir diese als Produkt betrachtet und ihr somit stets eine Produktverantwortung zugeordnet. Die fachliche Verantwortung lag die meiste Zeit (und liegt immer noch) bei meiner Wenigkeit, als de-facto Product Owner. Die technische Verantwortung trägt unser Asset-Team, welches alle Komponenten und Tools verantwortet, die gemeinsam von den anderen Produktteams genutzt werden.

Und wenn eine Pattern Library ein eigenes Produkt ist, darf natürlich auch ein eigenes Logo nicht fehlen:

Inhalte, Darstellung von Patterns und Variablen

Die Patterns in unserer Library sind keine bildlichen Darstellungen, sondern sind in dem HTML-, CSS- und JavaScript-Code geschrieben, der auch auf unserer E-Commerce-Plattform im Einsatz ist. Unser Ziel ist es, die Patterns für die Nutzer der Library möglichst realistisch erlebbar zu machen. Gleichzeitig werden alle zulässigen Varianten des Patterns sowie relevante inhaltliche Variationen gezeigt.

Teil der OTTO Pattern Library sind auch Elemente, die nach Definition kein Design Pattern sind aber dennoch zentrale Elemente für die Gestaltung von OTTO darstellen, zum Beispiel Farben, Schriftgrößen und Icons:

Von Nutzungsszenarien zur Struktur

Um dieser großen Menge an Patterns und Elementen eine für den Nutzer nachvollziehbare Struktur zu geben, haben wir in einem ersten Schritt zwei hauptsächliche Nutzungsszenarien identifiziert:

1. Exploration

Der Nutzer möchte eine Lösung (Feature, Teilprodukt, Produkt) entwickeln, weiß aber noch nicht, welche Patterns dafür geeignet sind. In der Regel geht es hierbei um eine fachliche Perspektive auf die einzelnen Patterns. Also was ihr Zweck ist, welche Nutzerprobleme sie lösen, ob es Einschränkungen oder Alternativen gibt. Typische Rollen mit diesen Bedürfnissen sind vor allem UX-Designer und Produktmanager.

2. Gezielter Aufruf

Das Pattern ist dem Nutzer bekannt – sei es durch Erfahrung oder ein Briefing – und er möchte auf kürzestem Wege dorthin gelangen, um das genaue Aussehen, Verhalten oder Details für die Implementierung zu erfahren. Hierbei geht es um eine sehr konkrete technische Perspektive auf das Interaktionsdesign und die Implementierung. Typische Rollen mit diesen Bedürfnissen sind vor allem Entwickler, QA und UX-Designer.

Als Konsequenz aus dieser Erkenntnis haben wir unsere Pattern Library mit zwei inhaltlichen Ebenen ausgestattet: Im Vordergrund steht die fachliche Perspektive, also Möglichkeiten einer optimalen explorativen Nutzung. Patterns sind dennoch durch Suche und URL direkt für eine konkrete Beurteilung schnell verfügbar. Die komplette technische Perspektive lässt sich für die entsprechenden Rollen leicht einblenden.

Informationsarchitektur & Navigation

Um den erwähnten explorativen Zugang zu unseren Patterns zu ermöglichen, haben wir die Informationsarchitektur dahingehend optimiert. So haben wir uns gegen Paradigmen wie Atomic Design entschieden, da hier eher die technischen Eigenschaften der Patterns führend sind. Stattdessen haben wir unsere Patterns nach den Aufgaben gegliedert, die diese in der Nutzerinteraktion erfüllen:

• Fragmente: Elemente, die zwar per Definition kein Pattern sind, auf die aber alle Patterns und viele weitere Elemente aufbauen. Dies sind unsere Standardfarben, Schriftschnitte, Standard-Schriftgrößen und der Überblick über unsere Icon-Font.
• Content: Patterns zur Darstellung unserer Inhalte, z.B. Textblöcke und Headlines.
• Gliederung: Patterns die zur Strukturierung und Gliederung unserer Inhalte dienen, wie Trennlinien oder Klappboxen und andere Progressive-Disclosure-Patterns.
• Interaktionen: Patterns, die eine direkte Interaktion des Nutzers ermöglichen sollen, z.B. Buttons und Auswahl-Kacheln.
• Formular: Alle Patterns, die es zum Bau von Formularen benötigt, inklusive unseres Standard-Rasters zum Aufbau längerer Formulare.
• Status & Feedback: Patterns, die dem Nutzer einen Systemzustand kommunizieren, wie Hinweiskommunikation, Lade-Animationen oder Badges.
• Layer & Popup: Modale Dialoge in vielen Varianten, PopUp-Fenster.
• Animationen: Unsere Prinzipien und Patterns zur Herstellung einheitlicher Animationen und Transitionen.

Die weitere Untergliederung der Patterns erfolgt dann nach dem folgenden Schema:

• Kategorie, z.B. Patterns zur Darstellung von “Content”
  • Pattern-Gruppe, z.B. “Copy”
    • Konkretes Pattern, z.B. “Copy100”
      • Variante des Pattens, z.B. “Copy100, 2. Ordnung”

Für eine klare Benennung von Patterns (“Copy100”) aber auch von Farbwerten (“Grey200”) und anderen Einheiten nutzen wir das im vorangegangenen Teil beschriebene City-Block-Naming-Schema.

Fachliche Perspektive

Die fachliche Ansicht besteht aus der Darstellung der Patterns auf Basis von Live-Code, so dass deren Funktion und Verhalten im Browser realitätsnah getestet werden kann – zumindest soweit es ohne die Anbindung an echte Shop-Inhalte möglich ist. Die Patterns werden dabei in allen definierten Varianten sowie mit unterschiedlichen Beispielen der inhaltlichen Befüllung dargestellt.

Ergänzt wird die Darstellung durch Hinweise zum Einsatz des Patterns. Hier kann der UX-Designer nachvollziehen, wie das Pattern einzusetzen ist (oder eben nicht) und in welchem Kontext welche Variante die Richtige ist.

Technische Perspektive

Neben jedem Pattern befindet sich ein blauer “Code”-Button, mit dem die technische Ansicht eingeblendet wird.

Die technische Ansicht besteht auch drei Komponenten:

1. Einem Pattern-Konfigurator zur schnellen Auswahl der richtigen Variante
2. Dem Code-Fenster zur Einblendung von HTML, SASS und JS
3. Umsetzungs-Hinweise für den Entwickler

Pattern Konfigurator

Damit insbesondere bei Patterns mit vielen Dimensionen und Varianten ein schneller Zugriff auf den richtigen Code für eine einzelne Ausprägung erfolgen kann, ist ein kleiner Pattern-Konfigurator Teil der Technischen Ansicht.

Responsive Design

Unsere Patterns sollen bereits innerhalb der Pattern Library weitestgehend testbar und realistisch erlebbar sein. Die Pattern Library nutzt darum das gleiche responsive Verhalten – also das gleiche Grid und die gleichen Breakpoints – wie otto.de. So haben wir die Möglichkeit, bereits in der Library das Aussehen und Verhalten der Patterns auf allen relevanten Bildgrößen und Devices zu überprüfen.

Die Pattern Library hat aus praktischen Gründen noch einen zusätzlichen Breakpoint, der nach Erreichen der Maximalgröße von otto.de die Navigation der Pattern Library permanent einblendet.

Selber ausprobieren

Die Pattern Library von OTTO ist frei zugänglich, so dass ihr das in diesem Artikel beschriebene Produkt selbst in Augenschein nehmen könnt:

OTTO Pattern Library aufrufen →

Ausblick

Ausgenommen der üblichen Optimierungen hier und ist da, ist diese fünfte Iteration unserer Pattern Library seit 2016 im Einsatz. Und da sie uns auch weiterhin effektiv unterstützt, wird das sicher auch noch weiter so bleiben. Trotzdem sind bereits Entwicklungspfade sichtbar, die unsere Library in Zukunft verändern können. Einerseits wird im Moment für unsere Markengestaltung ein System auf Basis von Frontify aufgebaut und wir überlegen, dieses mit unserer Pattern Library zu einem vollwertigen Design System zu verheiraten. Andererseits gibt es schon die Überlegung, irgendwann auch vollständig gekapselte Web-Komponenten moderner Prägung – also z.B. auf Basis von React oder Vue.js – über die Pattern Library bereit zu stellen. Eine weitere Herausforderung ist der Umgang mit Patterns aus unseren iOS- und Android-Apps. Was passieren wird, werden ihr irgendwann sicher hier auf produktbezogen lesen.

One more thing… oder: noch eine Pattern Library

An dieser Stelle soll nicht unerwähnt bleiben, dass die OTTO Pattern Library mittlerweile eine Schwester bekommen hat. Da OTTO in Begriff ist, sich in eine Handels-Plattform zu wandeln, werden künftig nicht mehr nur Verbraucher sondern auch Händler online mit OTTO agieren. Zur konsistenten Ausgestaltung dieser B2B-User-Experience ist in der IT-Organisation von OTTO eine zweite Pattern Library auf Basis unserer Software entwickelt worden:

Wie geht es in der Serie weiter?

Nach dem Blick auf das äußerliche Konzept der OTTO-Pattern-Library wollen wir im nächsten Teil unter die Haube schauen. Der sechste Teil wird sich darum drehen, wie die Pattern Library als Teil der OTTO-Plattform funktioniert und mit welchen technischen Mitteln Pattern und auch die Library definiert und entwickelt werden.

Alle Artikel der Serie Design Systems 101

• Teil 1: Warum braucht man eine Pattern Library Warum entstehen Inkonsistente UIs, was sind Design Patterns und welche Vorteile bringt ihr Einsatz.
• Teil 2: Auf der Suche nach der perfekten Pattern LibraryDie fünf Iterationen bis zur heutigen OTTO-Pattern-Library und was wir dabei gelernt haben.
• Teil 3: Patterns identifizieren und strukturierenWie man Patterns in seinem Produkt entdeckt und strukturiert.
• Teil 4: Ein flexibles Naming-Schema für PatternsWie man Patterns eindeutige Namen gibt und dabei flexibel auf Veränderungen und Wachstum reagieren kann.
• Teil 5: Anatomie der OTTO-Pattern-LibraryEinblick in Konzept und Funktion der aktuellen Library von OTTO.
• Teil 6: Technische Grundlagen einer Pattern LibraryErscheint Ende 2019
• Teil 7: Prinzipien für den Aufbau und Betrieb einer Pattern Library2020
• Teil 8: Ressourcen, Links und lose Gedanken2020

Wer sich so lange nicht gedulden mag, kann natürlich in den alten Fassungen der Artikel weiter lesen:

• Teil 7: Prinzipien für eine Lean Pattern Library (alt)