Design Systems 101 – Teil 3: Patterns identifizieren und strukturieren

Zum Aufbau einer Pattern Library oder eines Design System braucht man Patterns. Natürlich. Im ersten Teil haben wir gelernt was ein Pattern ist. In diesem Teil soll es nun darum gehen, welche Arten von Patterns es gibt, wie man diese in seinem Produkt identifiziert und wie man mit den gefundenen Patterns ein verständlich strukturiertes Design System aufbaut.

Darüber hinaus möchte ich einige pragmatische Ansätze zeigen, wie man mit neu entstehenden Patterns umgeht und wann man entscheidet, dass ein Element kein Pattern ist.

← Zum Anfang der Serie

Als Ausgangspunkt will ich meine Definition eines Design Patterns in Erinnerung rufen:

Ein Design Pattern ist die Lösung zu einem wiederholt auftretendem Problem. Als Element eines digitalen Produkts tritt es in unterschiedlichen Kontexten und/oder mit unterschiedlichen Inhalten auf.

Dies bedeutet, wir müssen die Augen nach Elementen offen halten, die sich in irgendeiner Form wiederholen oder zumindest das Potenzial für einen wiederholten Einsatz in sich tragen.

Typen von Design Patterns

Nehmen wir als Beispiel wieder ein bekanntes Objekt: das vereinheitlichte Produktempfehlungs-Kino der neuen OTTO-Plattform:

Der Button ist uns als Pattern bereits bekannt. Andere Elemente, die der Pattern-Definition entsprechen, die sich also in anderen Kontexten und/oder mit anderen Inhalten wiederholen werden, sind zum Beispiel die Headline und die Artikelbeschreibung. Aber auch das Format des Artikelbildes, bestehend aus Bildgröße, Seitenverhältnis und Einpassungs-Verfahren (crop/fill) lässt sich sinnvoll als Pattern festlegen.

Patterns sind aber nicht nur kleine, logisch unteilbare Elemente, wie die oben genannten, sondern können auch komplexere Gebilde darstellen. So können Patterns ihrerseits wiederum aus Patterns bestehen. In unserem Beispiel lässt sich auch das ganze Empfehlungs-Kino als Pattern sehen.

Das Kino-Pattern umfasst die oben genannten Tochter-Patterns und reichert diese mit zusätzlichen Eigenschaften, wie Zusammensetzungs-Regeln oder Interaktions- und Animations-Verhalten an.

Um hier besser unterscheiden zu können, haben Inken und ich uns damals auf die Begriffe „Baustein“ für unteilbare, atomare Patterns und „Komponenten“ für Patterns die wiederum auf Patterns bestehen geeinigt. (Ein vergleichbares Naming-Schema hat einige Zeit nach uns Brad Frost mit seinem Konzept des Atomic-Design aufgestellt, auf dass ich unten noch genauer eingehen werde.)

Unsere Kollegen hatten allerdings Schwierigkeiten, sich zu merken, welcher der beiden Begriffe für welchen Elementtyp gedacht war. Um das ganze merkbarer zu gestalten, haben wir uns an visueller Unterstützung versucht:

Das Konzept der Patterns, die aus Patterns bestehen, lässt sich analog zum Atomic Design weiterdenken hin zu Templates (Komponenten, die aus Komponenten bestehen). In Hinblick auf Multi-Device- und Multi-Brand-Ansätze kann es auch Sinn machen, ganze Seiten als Pattern zu definieren.

Ebenfalls wiederverwendbar und damit ein Pattern wären auch:

  • Übergänge und Animationen (z.B. die Links-Rechts-Bewegung des Kino-Inhalts)
  • Responsive-Design-Mechaniken (z.B. nach welchen Mustern sich der Inhalt anpassen soll)
  • Flows (z.B. das Fehler- und Erfolgs-Verhalten von Nutzerdialogen)
  • Wordings (z.B. dass ein Merkzettel im gesamten Produkt und auf allen Plattformen auch immer „Merkzettel“ heißt und nicht „Merkliste“)
  • Dialoge (z.B. die Art der Gesprächsführung eines Chatbots oder Voice-Assistenten)
  • Auch das Visual Design eines Produkts lässt sich mithilfe von Style-Tiles als Pattern definieren.
  • Es gibt sogar Bestrebungen ganze Experiences als Pattern zu definieren.

Dimensionen von Patterns

Neben den Unterschiedlichen Größen und Arten von Patterns lassen sich diese auch in drei Dimensionen betrachten:

Ein ideales Pattern umfasst alle drei Dimensionen und vereinheitlicht diese. Wir haben aber festgestellt, dass es auch Elemente gibt, die zwar das selbe Aussehen und die selbe Funktionalität, aber aus irgendwelchen Gründen einen anderen technischen Aufbau haben. Oder Funktionalität und Code sind der gleiche, aber das Visual Design weicht immer wieder ab. Diese Sichtweise ermöglicht uns, auch Patterns zu dokumentieren, bei denen eine Einheitlichkeit in allen drei Dimensionen nicht möglich oder nicht gewünscht ist.

Patterns im eigenen Produkt identifizieren

Eigene Patterns aufzudecken ist kein Hexenwerk. Man erkundet mit offenen Augen sein Produkt und notiert sich wiederkehrende Elemente. Insbesondere Bausteine bzw. Atome sollten so schnell gesammelt sein.

Auch Komponenten lassen sich so selbstverständlich entdecken. Da aber oft gleiche Sachverhalte an unterschiedlichen Stellen des Produktes nicht einheitlich gelöst sind, kann es auf Komponenten-Ebene so starke Inkonsistenzen geben, dass ein Pattern unter Umständen nicht erkannt wird. Dagegen hilft ein zweiter Durchgang mit einer anderen Perspektive: In diesem werden größere Komponenten dahingehend beurteilt, welche Aufgabe diese Erfüllen bzw. welches Problem sie lösen sollen und dann Parallelen gesucht.

Wiederkehrende Aufgaben sind ein guter Indikator für den Einsatz von Patterns, auch wenn sie aktuell durch verschiedene Lösungen umgesetzt sind.

Um so einen ganzheitlichen Überblick zu bekommen, haben wir damals unsere Seiten ausgedruckt, mit Schere zerschnitten und die Elemente entlang unserer Kern-User-Flows aufgeklebt:

Ob man diese Übung anhand von Flows macht oder eine andere Form der Struktur nutzt ist relativ unerheblich. Aber das Herauslösen der Elemente aus den sie umgebenen Seitenstrukturen eröffnet eine neue Perspektive auf das eigene Produkt und ist so eine große Hilfe, wiederkehrende Aufgaben und Strukturen und damit Patterns zu erkennen.

Was sind keine Pattern?

Genau so wichtig wie die Definition, was ein Pattern ist, ist ein Bewusstsein dafür zu entwickeln, welche Elemente kein Pattern sein sollen. Beim Aufbau eines Design Systems ist man schnell versucht, alles zu dokumentieren und systematisieren, was einem in die Finger kommt. Vieles davon wird in Zukunft aber niemandem einen Nutzen bringen. Abgesehen von viel überflüssiger Arbeit handelt man sich ein unübersichtliches und schwer zu wartendes Design System ein.

Meine Empfehlung ist darum, für sein Produkt und sein Team eine pragmatische Lösung zu finden. Man startet erst einmal „lean“ mit den offensichtlichsten Pattern und baut dann sukzessive seine Library auf, wenn sich neue Patterns zeigen oder wenn drohende Inkonsistenzen den Bedarf nach Systematisierung wecken.

In der OTTO Pattern Library ist zum Beispiel der Header samt Navigation nicht als Pattern dokumentiert, obwohl er durchaus die Definition eines Patterns erfüllt:

Allerdings ist der Header immer gleich und immer an der gleichen Stelle. Er wird niemals anders eingesetzt als oben auf einer Seite von otto.de. Weder Designer noch Entwickler von uns hätten damit einen Vorteil, wenn der Header Teil unserer Pattern Library wäre. Darum haben wir nicht den, für dieses Element durchaus beachtlichen, Aufwand betrieben, unseren Header zu dokumentieren. (Ein Aufwand, den auch Brad Frost scheuen würde: Dealing with site headers in Design Systems)

Witzigerweise ist das Produktkino, dass ich so gern als plakatives Beispiel nehme, auch nicht als Pattern in unserer Library aufgeführt. Gleiches gilt für viele andere Komponenten, die eigentlich nach allen Regeln der Kunst Pattern sind. Das ist dem Aufbau unserer Produktorganisation geschuldet: Ein gutes Dutzend agiler Teams hat die OTTO-Plattform unter sich aufgeteilt. Die Aufteilung erfolgte allerdings nicht anhand von Seiten sondern von fachlichen Domänen, die sich anhand der Kern-Ziele und -Bedürfnisse im eCommerce definieren. So ist für unser Empfehlungskino das Team „Entdecken“ zuständig. Ganz unabhängig ob das Kino auf der Startseite, der Artikeldetailseite oder in der Bestellübersicht eingesetzt wird, das Kino gehört immer diesem Team.

Die Teams entwickeln ihren Teil von otto.de als eigenes Produkt. Sie sind interdisziplinär aufgestellt, dass sie dieses Produkt vom UX-Design bis hin zur Daten-Anbindung alleine und möglichst ohne Abhängigkeiten zu anderen Teams entwickeln können. Somit ist die fachliche wie technische Expertise für die jeweiligen Komponenten in einem Team und somit in relativ wenigen Personen gekapselt. Egal wo künftig ein Empfehlungskino eingebaut werden sollte, das Team „Entdecken“ wäre in Sachen Produktverantwortung, UX, Entwicklung und Tests involviert.

Der Aufwand, die vollständig von einem Team verantworteten Patterns und Komponenten über die Pattern Library anderen Teams zur Ansicht zu stellen, steht im keinen Verhältnis zum Nutzen. Auch das mussten wir erst lernen und akzeptieren, denn natürlich wollten wir anfangs eine vollständige Pattern Library haben.

Um dem Umstand gerecht zu werden, dass wir einerseits zentral entwickelte und über die Pattern Library bereit gestellte und andererseits innerhalb von Teams entwickelte Patterns haben, haben wir die Bezeichnungen globale und lokale Patterns eingeführt. In einigen Teams haben sich Mini-Komponenten-Libraries entwickelt, um die lokalen Pattern für bestimmte Zielgruppen zu dokumentieren, z.B. gibt es einen Überblick über die verschiedenen Teaserformate für unsere Shop-Manager.

Umgang mit neuen Patterns

Ein digitales Produkt wird in der Regel kontinuierlich weiterentwickelt. Dass dabei neue Patterns entstehen können, ist keine Überraschung. Es ist darum wichtig, einen Umgang zu finden, neue Elemente auf ihr Pattern-Potenzial zu überprüfen.

Bei OTTO nutzen wir dazu unseren wöchentlichen Austausch der UX-Designer. Dort werden unter anderem neue Interaktionsdesigns diskutiert und dabei potenzielle Patterns vom entsprechenden Designer vorgeschlagen oder von den anderen entdeckt. In so einem Fall treffen wir eine Entscheidung aus vier Optionen:

  1. Das neue Element hat keinerlei Vorteile: Bitte ein bestehendes Pattern nutzen.
  2. Das neue Element hat einen klar erkennbaren Nutzen und kann an weiteren Stellen im Produkt eingesetzt werden: Aufnahme als neues Pattern oder als neue Pattern-Variante in unsere Library.
  3. Das neue Element ist in jeglicher Hinsicht eine bessere Lösung als ein bisheriges Pattern und kann dieses vollständig ersetzen: Aufnahme in unsere Pattern Library, Markierung des bisherigen Patterns als „deprecated“ und sukzessiver Austausch.
  4. Das neue Element hat im präsentierten Kontext einen klar erkennbaren Nutzen aber wir sehen keine weiteren Einsatzorte: Eine einmalige Abweichung wird akzeptiert. Das Element wird aber nicht in die Pattern Library aufgenommen.

Patterns strukturieren

In der Regel besteht ein digitales Produkt nicht aus einer Handvoll Patterns. Inklusive Untervarianten ist man schnell bei dutzenden bis hunderten Patterns, die in einer Library zugänglich gemacht werden müssen. Es ist also wichtig eine Struktur oder Informationsarchitektur zu finden, die Patterns schnell und verständlich auffindbar und entdeckbar macht.

Das sicher bekannteste System, um Design Patterns zu strukturieren, ist das bereits oben erwähnte Atomic Design von Brad Frost.

Atomic Design definiert Elemente nach ihrer technischen Komplexität. Atome entsprechen einzelnen, unteilbaren HTML-Objekten, wie Input-Felder oder Buttons. Einfache Kombinationen aus Atomen bilden Moleküle, die wiederum komplexere Komponenten, die Organismen, bilden. Das ganze baut sich auf über Templates bis hin zu ganzen Seiten.

Während diese Struktur aus technischer Sicht durchaus Sinn machen kann, fanden wir sie aus der Perspektive des User Experience Designs eher hinderlich. Ganz abgesehen von der sehr abstrakten, wenig intuitiven Taxonomie, ist viel Metawissen nötig, wo man welches Pattern einsortiert hat. Finde ich Element A bei den Atomen oder Molekülen? Und war das größere Element B ein Molekül oder schon ein Organismus. (Nebenbei erntet man von seinen Kollegen komische Blicke, wenn man das Kontaktformular als Organismus bezeichnet.)

Atomic Design ist noch lange kein schlechtes Konzept und es gibt viele Erfolgsgeschichten, aber wir sind auch nicht die einzigen, die sich nicht damit anfreunden konnten. So berichten die Teams von Sipgate („Warum unsere Pattern Library kein Atomic Design mehr benutzt”) und General Electric („GE’s Predix Design System – Issues with Atomic Design Taxonomy“) von einer nachträglichen Abkehr vom Atomic Design.

Um eine bessere Struktur zu finden, haben wir die zwei Kernszenarien bei ner Nutzung einer Pattern Library herangezogen:

  1. Gezielter Aufruf: Das Pattern ist dem Nutzer bekannt und er möchte auf kürzestem Wege dorthin gelangen.
  2. Exploration: Der Nutzer möchte eine Lösung (Feature, Teilprodukt, Produkt) entwickeln, weiß aber noch nicht, welche Patterns dafür geeignet sind.

Das erste Szenario war in unserer Pattern Library bereits durch die Suche und die Möglichkeit, Patterns direkt zu verlinken, ausreichend abgedeckt. Darum haben wir uns das Ziel gesetzt, eine Struktur zu finden, die eine effiziente Exploration ermöglicht.

Basierend darauf haben wir ein Card Sorting mit allen unseren damaligen Patterns veranstaltet. Teilnehmer waren hauptsächlich unsere UX-Designer als Hauptnutzer im explorativen Szenario:

Bei dem Card Sorting hat sich der Ansatz herauskristallisiert, die Patterns nach der durch sie zu lösenden Aufgabe zu gliedern, also z.B. nach Interaktions- und Inhaltselementen.

(Einen praktischen Ansatz, Patterns per Card Sorting zu strukturieren, zeigen Thomas Piribauer und Björn Ganslandt in ihrem Card-Studio-Artikel.)

Unsere Struktur

Nach einigen Detail-Iterationen haben wir der OTTO Pattern Library letztendlich die folgende Struktur gegeben:

  • 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-Pattern.
  • 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 Pattern zur Herstellung einheitlicher Animationen und Transitionen.

Verglichen mit dem Einstieg über die Atomic-Design-Begriffe Atome, Moleküle, Organismen usw. ist dies ein deutlich nutzerfreundlicherer Ansatz. Selbst unsere eigene Unterscheidung von Bausteinen und Komponenten wird heute kaum noch genutzt, da sie nicht wirklich einen Mehrwert bei der Auswahl von Patterns bietet. (Nichtsdestotrotz ließe sich so eine Struktur auch über ein mit Atomic Design aufgebautes Design System legen, als zweiter Zugangsweg für fachliche Nutzer.)

Fazit und wie es weiter geht

Wie bei allen digitalen Produkten gilt für eine Pattern Library als auch für ein Design System: Klein anfangen, testen, iterieren. Erliegt bitte nicht der Versuchung, gleich im ersten Schritt die ganze Welt eures Produkts bis ins kleinste Detail zu systematisieren. Seid pragmatisch! Beginnt mit den Patterns, die euch zuerst am meisten weiterhelfen. Baut dann nach und nach eure Library auf und gebt einer Struktur Zeit, sich zu entwickeln. Ignoriert Elemente, die niemandem weiterhelfen, auch wenn es nach allen Definitionen Patterns wären. So entsteht dann nach und nach ein immer mächtigeres System, ohne dass ihr zu früh oder zu lang in eine falsche Richtung lauft.

Nachdem wir nun Patterns identifiziert und strukturiert haben, will ich im nächsten Teil ein flexibles Naming-Schema für Design Patterns vorstellen.

Zum vierten Teil →

Alle Artikel der Serie Design Systems 101

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

Über Wolf Brüning

Wolf arbeitet als Executive UX Designer in der Abteilung User Experience der OTTO GmbH & Co KG und kümmert sich hier mit seinen Kollegen um Konzeption und Interaktionsdesign der vollständig inhouse entwickelten eCommerce-Plattform des Konzerns. Vor seiner Hamburger Zeit hat Wolf in verschieden Web- und Usability-Agenturen gearbeitet und in Magdeburg Computervisualistik studiert. Wolf ist Mitgründer von produktbezogen.de und kümmert sich neben den Inhalten auch um Design und Technik des Blogs.

2 Kommentare

  1. Johannes

    Hi Wolf,

    ich weiß nicht wie die aktuellen Aufrufzahlen zu deinem Artikel sind, aber oftmals haben solch qualitativ hochwertige Artikel weniger Kommentare und Interaktionen als “leichte” Kost.

    Da aber gerade Artikel wie deiner einen unglaublichen Mehrwert (in meinen Augen) für die wirkliche Arbeit eines UXlers, POs, Designer etc. darstellen, hier einfach auch nochmal ein großes Danke + Lob von meiner Seite.
    Nicht, dass der Eindruck entsteht, man macht sich viel Mühe für komplexe Themen und es wird nicht gewürdigt :)


  2. Wolf Brüning Artikelautor

    Hallo Johannes.
    Wow! Vielen Dank für das Feedback. Zu wissen, dass es wirklich weiter hilft, tut gut und motiviert mich, weiter zu machen.
    Viele Grüße,
    Wolf


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →