Design Systems 101 – Teil 2:Auf der Suche nach der perfekten Pattern Library

Design Patterns sind wenig wert ohne Struktur, die sie auffindbar macht und erklärt. Sie brauchen eine Pattern Library oder ein Design System. Im ersten Teil der Artikelserie habe ich gezeigt, warum Design Patterns wichtig sind. In diesem Teil werde ich zeigen, wie wir für die Patterns von OTTO.de eine effektive und praktikable Pattern Library aufgebaut haben, die auch heute – fünf Jahre nach dem Launch – immer noch ein wichtiges Werkzeug in unserer Produktentwicklung ist. Besonders möchte in dieser Case Study auf die ersten beiden Versuche eingehen, die zwar mehr oder minder gescheitert sind, bei denen wir aber viele wertvolle Dinge gelernt haben.

← Zum Anfang der Serie

Erste Iteration (2012): Getreu nach Lehrbuch

In das Thema Pattern Library sind Inken und ich zuerst mit einer ausgiebigen Recherche eingestiegen. Unter anderem sind wir dabei auf die folgende Definition von Jared Spool gestoßen, die wir schon im ersten Teil erwähnt haben:

A typical pattern describes the problem, the chosen solution, the rationale behind that solution, related patterns that the designer should be aware of, and other relevant details, such as the results of usability testing.– Jared Spool

Eine Pattern Library, die sich sehr gut an diese Definition hielt und lange Jahre als die Genre-Referenz galt ist die Yahoo Design Pattern Library. Leider ist sie seit dem Verkauf von Yahoo an Comcast nicht mehr im Netz zu finden.

Screenshot Yahoo Pattern Library

Die Dokumentation der Patterns war sehr ausführlich. Sie enthielt ganz im Sinne Jared Spools eine Beschreibung des zu lösenden Problems, Handlungsempfehlungen für den Einsatz, Argumentationshilfen und Randbedingungen.

Beim Versuch, unsere Patterns nach Vorbild der Yahoo Pattern Library zusammenzutragen, fiel uns schnell auf, dass diese Art zu dokumentieren wenig flexibel und vor allen Dingen mühsam ist. Ein kritischer Blick in die Yahoo Pattern Library offenbarte zudem, dass das aktuellste Pattern aus dem Jahr 2009 stammte:

In damals schon drei Jahren (und all den Jahren danach) hat also niemand Hand an die Pattern Library gelegt, obwohl sich Web-, UI- und Interaktionsdesign seitdem deutlich weiterentwickelt haben. An dieser Stelle könnte man gehässig sein und sagen, Yahoo hätte sich seitdem auch nicht weiterentwickelt. Wir haben uns dennoch etwas tiefer mit der Yahoo-Library beschäftigt und uns ist der folgende Workflow in die Arme gefallen:

Yahoo Pattern Library Workflow (Quelle: boxesandarrows.com)

Wir sehen unzählige beteiligte Personen und Abstimmungsrunden nach Abstimmungsrunden nach Abstimmungsrunden… Unsere Vermutung an dieser Stelle war, dass die Yahoo Pattern Library durch zu aufwändige Dokumentation und zeitraubende Prozesse ausgebremst worden ist und so nach und nach veraltete. In den letzten Jahren ist sie dann nur noch als Zombie-Pattern-Library durch das Netz gegeistert. Dies brachte uns zu unserer ersten wichtigen Erkenntnis:

Die größte Gefahr für Pattern Libraries und Design Systeme ist, nicht mehr aktuell zu sein.

Sobald dieser Fall eintritt, werden die zuständigen Designer und Entwickler entweder wieder „ihr eigenes Ding“ machen, unwissentlich mit den veralteten Lösungen arbeiten oder bestenfalls ausgebremst, da sie auf der Website nach der aktuellen Variante des Patterns suchen müssen.

Yahoos veraltete Library hat uns daher eine wichtige Lektion gelehrt: Es ist sicher lobenswert, Patterns so ausführlich wie nur irgendwie denkbar zu dokumentieren und im Entstehungsprozess auch jeden Stakeholder abzuholen. Das alles ist aber keinen Pfennig Cent wert, wenn die Pattern Library aufgrund dieses Overheads irgendwann nicht mehr aktuell ist. Angelehnt an den zweiten Punkt des Agilen Manifests („Working software over comprehensive documentation.“) haben wir als Grundprinzip für unsere Pattern Library festgelegt, dass für ein Design Pattern Aktualität viel wichtiger ist, als gründliche Dokumentation und ausschweifende Abstimmungsrunden. Analog zum „over“ im agilen Manifest soll das aber nicht heißen, dass Dokumentation gänzlich unwichtig ist.

Vielleicht kann man es mit rigiden Prozessen und viel Aufwand schaffen, auch eine Pattern Library nach Yahoo-Modell aktuell zu halten. Aber man würde einen der Kernvorteile einer Pattern Library wegschmeißen: Die Zeitersparnis.

Spart eine Pattern Library keine Zeit oder erzeugt sogar dauerhaft zusätzlichen Aufwand, wird sie automatisch Akzeptanzprobleme bekommen.

Und Akzeptanzprobleme führen erst zu fehlenden Inhalten und früher oder später zu einer gescheiterten Pattern Library

Zweite Iteration (2012-2013): Der modulare Ansatz

Nachdem wir unseren ersten Ansatz glücklicherweise schnell verwerfen konnten, stellte sich uns die folgende Frage: Wie können wir eine Pattern Library mit möglichst geringem Aufwand für Betrieb und Pflege aufstellen, die dennoch allen Beteiligten weiterhilft? Und Beteiligte gibt es in einem großen Konzern wie OTTO nicht zu knapp:

  • Interaction Designer
  • Visual Designer
  • User Experience Manager
  • Entwickler
  • QA-Experten
  • Produktmanager
  • Projektmanager
  • Content Designer
  • Corporate Designer
  • Externe Agenturen
  • Konzerntöchter (OTTO Austria, OTTO Holland, usw.)

Eine One-Size-Fits-All-Lösung erschien uns nach den Erfahrungen des ersten Versuchs als unrealistisch. Schließlich wären hier Tool, Dokumentation und Prozesse wieder zu komplex und damit der Overhead zu groß geworden. Wir entschlossen uns folglich, einen modularen Lösungsansatz auszuprobieren: Nicht ein großes, aufgeblasenes Tool, sondern mehrere schlanke Library-Module, die die Ansprüche der jeweiligen Zielgruppen ideal erfüllen und die über ein einheitliches Naming Schema (dazu komme ich noch im übernächsten Teil der Serie) synchron gehalten werden.

Natürlich wäre es kontraproduktiv, für jede der oben genannten Zielgruppen ein eigenes Tool zu entwickeln. Zur Vereinfachung haben wir daher drei Anwendungsszenarien definiert, die jeweils ein eigenständiges Modul der Pattern Library bekommen sollten:

Modul 1: Dokumentation & Kommunikation

Dieses Modul sollte zur langfristigen Dokumentation und und Kommunikation der Patterns innerhalb des eCommerce-Bereichs aber auch nach außen dienen und damit das Herzstück unserer Pattern Library werden. Als Dokumentationsform wählten wir einen klassischen Ansatz: Ein Bild des Patterns mit möglichst knapper Dokumentation (Regeln für den Einsatz und Ansprechpartner).

Da diese Art der Dokumentation technisch relativ anspruchslos ist, wollten wir dafür auf ein bestehendes Tool zurückgreifen. Nach ersten Tests mit dem bestehenden Confluence-Wiki fiel unsere Wahl fiel auf den „Brand Experience Guide”. Dieser war ein eigens für OTTO entwickeltes CMS, welches bislang zur Dokumentation des Corporate Designs diente und gegenüber dem Wiki einige Vorteile in Sachen Strukturier- und Durchsuchbarkeit hatte.

OTTO Brand Experience Guide

Modul 2: Konzeption & Design

An dieser Stelle stand für uns ein möglichst schneller Überblick aller verfügbaren Patterns und deren schneller Einsatz beim Erstellen neuer Prototypen und Visual Designs im Vordergrund. Zentrales Arbeitstool unserer Designer war zu diesem Zeitpunkt Adobe Photoshop. Also war unsere Lösung, alle Patterns in eine Handvoll Vorlagen-PSDs zusammenzufassen. Für einen neuen Entwurf musste dann ein Designer nur noch die relevanten Vorlagen öffnen und sich alle gewünschten Patterns in seine neue Datei ziehen.

Ausschnitt aus einer Vorlage-PSD (zum Vergrößern anklicken)

Jedes Pattern ist in den Vorlagen in eine eigene Layergruppe zusammengefasst, die den einheitlichen Pattern Namen trägt. Zum Erstellen des Designbriefings kann der Designer dann einfach seine Ebenenliste durchgehen und seinem Entwickler so schnell die verwendeten Patterns mitteilen.

Vorlahe-PSD Ebenen

Modul 3: Entwicklung

Ziel dieses Moduls war es, Entwicklern die Einbindung von Patterns in ihre Templates möglichst einfach zu gestalten. Zur Konzeption haben wir einen Workshop mit den Frontend-Entwicklern aller Scrum-Teams von OTTO veranstaltet und glücklicherweise waren unsere Entwickler Feuer und Flamme für das Projekt. Ich kann nur jedem Designer empfehlen bei einer Pattern-Library- oder Design-System-Initiative die Entwickler mit ins Boot zu holen (und umgekehrt).

Designer und Entwickler profitieren am meisten von einer guten Pattern Library.

Das gemeinsame Verständnis und die Vermeidung von Missverständnissen werden zudem helfen, das oft strapazierte Verhältnis zwischen Designern und Entwicklern zu entspannen:

Inspiriert von den Patterns des Twitter Bootstrap Frameworks entstand im Workshop unsere „Code Pattern Library“ (kurz CoPaLi), eine lange HTML-Seite mit allen zu diesem Zeitpunkt existierenden Patterns in allen Varianten. Die Patterns waren bereits in HTML/CSS-Fassung, so dass man ihr Verhalten direkt in der Library ausprobieren konnte.

Zu jedem Pattern wurde ein „Source“-Button integriert, mit dem der Nutzer den zur Einbindung notwendigen Quellcode einblenden konnte:

Code Pattern Library Quellcode

Mit Fertigstellung der Code Pattern Library hatten wir also folgende Struktur für unsere modulare Pattern Library:

Diese modulare Pattern Library haben wir auch wirklich in Betrieb genommen und mehr als ein halbes Jahr im Einsatz gehabt. Im laufenden Betrieb lernt man natürlich am schnellsten und besten und so konnten wir feststellen, dass das Konzept noch zu viele Ecken und Kanten hatte:

  • Die Dreifachpflege der Patterns in PSDs, Brand Experience Guide und CoPaLi war deutlich umständlicher als gedacht und erforderte viel Disziplin. Erschwerend kam hinzu, dass unsere Patterns während der agilen Entwicklung im Projekt Lhotse noch nicht stabil genug waren und oft noch mehrfach angepasst werden mussten.
  • Umständlich war auch die Dokumentation von Komponenten (Patterns die aus Patterns bestehen). Sobald ein Element geändert wurde, mussten alle Patterns, die dieses enthielten manuell in den PSDs und dem Brand Experience Guide angepasst werden.
  • Alle Patterns in PSD-Dateien für einen schnellen Zugriff bereitzuhalten, ist in der Theorie vielleicht eine grandiose Idee. In der Praxis haben diese Vorlage-Dateien die Rechner unserer Designer aber regelmäßig in die Knie gezwungen.
  • Hingegen erfreute sich die Code Pattern Library durch ihren Aufbau, die schnelle Zugänglichkeit und ihre Interaktivität großer Beliebtheit – auch unter den Designern: Diese nahmen lieber Screenshots aus der CoPaLi, als die schwerfälligen PSDs zu laden.

Dritte Iteration (2013–2015): Code Pattern Library = Pattern Library

In der vorangegangenen Iteration mussten wir also feststellen, dass wir uns mit der modularen Lösung wieder sehr weit weg von unserem Ideal einer schlanken und einfachen Pattern Library wegbewegt haben. Der durchschlagende Erfolg einer der drei Komponenten wies uns zum Glück aber in die richtige Richtung:

Wir deklarierten die Code Pattern Library einfach zur eigentlichen Pattern Library um. Hierzu mussten wir das bestehende Konstrukt nur um einen zusätzlichen Button erweitern, der analog zum Source-Button die entsprechenden Verwendungshinweise zum Pattern einblendet.

Code Pattern Library Hinweis

Die PSD-Vorlagen wurden auf Eis gelegt. Wir waren aber weiterhin überzeugt, dass sich die zusätzliche Pflege solcher Vorlagen lohnt: Beim Erstellen von Prototypen und Visual Designs können diese eine immense Zeitersparnis bedeuten. Allerdings bremste die schlechte Performance der PSDs diesen Zeitvorteil wieder aus. Zusätzlich begannen wir zu der Zeit damit, Photoshop als zentrales Tool unserer Arbeit zu hinterfragen.

Das Modul für Dokumentation und Kommunikation wurde vorerst nicht komplett abgeschafft. Die Idee war, den BXG weiter zu nutzen, um Nutzern außerhalb von OTTOs eCommerce-Bereich (Print-Designer, externe Agentuen, usw.) zumindest unsere stabilen und markenprägenden Patterns zur Verfügung zu stellen.

Die dritte Iteration unserer Pattern Library bestand somit gewissermaßen nur noch aus der, mit erweiterter Dokumentation ergänzten, Code Pattern Library. Damit konnte sie uns als Single Point of Truth dienen und der Overhead für die Pflege von Patterns ist dadurch so gering geworden, dass wir sie knapp zwei Jahre produktiv als Grundlage für OTTOs neue eCommerce-Plattform eingesetzt haben.

Screenshot OTTO Pattern Library

Vierte Iteration (2014–2016): Mit heißer Nadel zur Responsive Pattern Library

2014, ein Jahr nach dem Launch des neuen otto.de, begannen die Vorbereitungen, den Shop mithilfe von Responsive Design zu befähigen, alle Devices von Smartphone bis Desktop-Rechner nutzerfreundlich zu bedienen.

Ein responsives Design lässt sich aus zwei Richtungen konzipieren: Einerseits klassisch Top-Down, beginnend mit der Definition von Grid und Breakpoints über das Sortieren aller relevanter Elemente in Content Hierarchy und Content Reference Wireframes bis hin zur konkreteren Ausgestaltung aller Größenvarianten.

Basierend auf den Atomic Design Prinzipien von Brad Frost lässt sich aber auch aus anderer Richtung, also Bottom-Up arbeiten. Man „responsiviert“ zuerst die kleinsten Elemente, die Atome, definiert dann das Verhalten von kleineren und größeren Komponenten (Moleküle und Organismen) und arbeitet sich so über Templates bis hin zu den fertigen Seiten.

 

So war es dann auch unser Auftrag, mit unserer Pattern Library einen entscheidenden Beitrag zu „Responsive otto.de“ beizutragen. Oberstes Ziel war es, die Patterns und Komponenten so zu gestalten, dass sie sich an jedem Breakpoint entsprechend anpassen und sich so UX-Designer, Produktmanager und Entwickler keine zusätzlichen Gedanken darüber machen müssen, wie das entsprechende Element auf allen Bildschirmgrößen funktionieren muss.

Nachdem die Breakpoints für otto.de festgelegt waren, war unser erster Ansatz, zu prüfen, wie sich unsere Patterns verändern würden.

otto.de Grid und Breakpoints

Relativ rasch hatten wir aber das Gefühl, nicht vernünftig damit voran zu kommen. Einerseits mussten wir viel spekulieren, denn es war noch keine Seite oder Template umgestellt. Andererseits merkten wir, dass wir anfingen eine Ebene an Komplexität in unsere Patterns einzuführen, die vielleicht gar nicht nötig war. Und es gibt wenig Schlimmeres als unnötige Komplexität.

Wir entschieden uns also, anstelle von Patterns mit unterschiedlichen Versionen für unterschiedliche Devices, unsere Patterns lieber so zu gestalten, dass sie ohne Änderung auf allen Endgeräten einsetzbar und benutzbar sind. Getreu unserer Prinzipien Mobile First und Touch First haben wir alle Patterns folgendermaßen angepasst:

  • Klicktarget-Größe nie kleiner als 40x40px (plus Schutzraum von 10px)
  • Text nie kleiner als 14px
  • Verzicht auf Bilder
  • Stattdessen Gestaltung durch CSS3-Effekte, Webfonts und Icon-Fonts und damit eine fluide und Auflösungs-unabhängige Darstellung

Mit diesen Parametern waren wir relativ zuversichtlich (und sind es heute auch noch), dass jedes Pattern auf jedem relevanten Device lesbar und benutzbar ist. Im Endeffekt blieben so nur verhältnismäßig wenige Komponenten übrig, denen wir wirklich ein Breakpoint-Verhalten auferlegen mussten (z.B. modale Overlays).

Nachdem wir Klarheit über unsere Patterns gewonnen hatten, ging es daran, auch die Library zu überarbeiten: In den vorhergehenden Iterationen hat sich gezeigt, dass es ein großer Mehrwert ist, wenn Patterns in der Library nicht nur in ihrem Look sondern auch in ihrem interaktiven Verhalten erlebbar sind. Dies sollte natürlich auch in Zukunft gelten. Wir haben also unser neues Library-Tool ebenfalls responsive gemacht und für es die gleichen Breakpoints und Grids gewählt, die auch für otto.de festgelegt worden waren. 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.

Patterns und Pattern Library mussten natürlich als Vorleistung stehen, bevor unsere agilen Teams losrennen konnten. Gleichzeitig waren durch die Natur des RWD-Projektes – auf einmal passierte gefühlt 80% der Entwicklungsarbeit im Frontend anstelle von bisher 80% Backend-Anteil – die Kapazitäten unserer Frontendler maximal ausgereizt. Den ambitionierten Zeitplan müssen wir dabei gar nicht weiter hervorheben. Dies alles führte dazu, dass wir den neuen, responsiven Fork der Library mit sehr heißer Nadel entwickeln mussten. Während wir also bei den Patterns stark auf Robustheit und Qualität achteten, mussten wir vorerst mit einem recht rudimentären MVP leben.

Das hat uns nicht aufgehalten und im April 2015 ging das responsive otto.de live. (Präzise gesagt, ging im April nur der letzte Rest live, aber das ist Stoff für eine eigene Artikelserie.)

Im Rahmen des RWD-Projektes wechselten wir UX-Designer von Photoshop zu Sketch. Sketch stellte sich als viel schneller heraus und konfrontiert mit der Gestaltung für mehrere Bildschirmgrößen war der Geschwindigkeitsnachteil von Photoshop nicht mehr tragbar.

Fünfte Iteration (2016–heute): Ein komplettes Tool

Das mit der heißen Nadel konnten wir natürlich nicht auf uns sitzen lassen. Und so wurde im Anschluss an das Responsive-Design-Projekt unsere Library um viele Funktionen ergänzt, die Patterns optimiert, aufgeräumt und von Altlasten befreit.

An dieser Stelle möchte ich nicht weiter ins Detail gehen, denn dem heutigen Stand unserer Library werde ich in dieser Serie einen eigenen Artikel widmen. Da sie mittlerweile aber frei zugänglich ist, könnt ihr sie euch gern schon mal anschauen: OTTO Pattern Library.

Den Ansatz aus der zweiten Iteration, die Pattern Library mit großen Photoshop-Dateien zu komplementieren, haben wir seitdem immer mal wieder weiterverfolgt. So haben wir unsere Patterns in Axure-Libraries und Sketch-Dateien überführt. Aber nie war die Praktikabilität größer als der Aufwand der Erstellung und zusätzlichen Pflege. Und kaum waren die Sammlungen veraltet, wurden sie auch schon immer öfter links liegen gelassen. Die Pattern Library bleibt auch für uns UX-Designer stets die erste Referenz. Angesichts der Weiterentwicklung des Symbol-Konzepts und der neuen Library-Funktion in Sketch liebäugele ich aber durchaus mit einem neuen Anlauf.

Wie geht es weiter?

Nachdem wir uns nun ausführlich mit der Geschichte von OTTOs Pattern Library befasst haben, wechseln wir zur Praxis und werden in den nächsten beiden Artikeln lernen, wie sich Patterns identifizieren, strukturieren und benennen lassen. Im 5. Teil werden wir dann genauer auf die heutige OTTO Pattern Library blicken und wie wir die Patterns in ihr strukturiert haben.

Zum dritten 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.

5 Kommentare

  1. Tamim Swaid

    Danke für diesen langen ausführlichen Artikel und für das Teilen der “Lessons Learned”. Schön war zu sehen wie ihr von Yahoo gelernt habt (Das Hierarchie Katalogisierungs Unternehmen) und dann euer “einfaches” Ding gebaut habt aber auch dass zu groß gedacht war. Code wins.



  2. Wolf Brüning Artikelautor

    Da wir uns im Moment mit dem Thema Responsive Design auseinandersetzen und Photoshop nun wirklich für das Interaction Design in den Ruhestand schicken wollen, probieren wir gerade einige Alternativen durch. Im Moment arbeiten wir viel mit Sketch. Macaw haben wir auch schon mal in kleinem Rahmen getestet, aber noch nicht so wirklich.

    Falls ihr zu Macaw interessante Erkenntnisse habt, insbesondere zu RWD, Patterns und generell dem codenahen Arbeiten von Designern, würde ich mich sehr über einen Austausch freuen.


  3. Clive K. Lavery

    Sehr gerne, noch ist es wirklich nur rumspielen und noch in keinem Kundenprojekt eingesetzt worden.

    Was bei einem Projekt allerdings schon die klassische Dokumentation/Feinkonzeption abgelöst hat, ist gemeinsam mit dem Entwicklern Jira Tickets schreiben, die dann zwischen Konzept/Design/Entwicklung hin und her gehen.

    Am Ende werden die mit “Konzept” getaggten Tickets exportiert und man hat im Handumdrehen eine vom Kunden gewünschte Dokumentation.


  4. Wolf Brüning Artikelautor

    Ich bin gespannt, was ihr lernen werdet. Wenn wir im kommenden Jahr gewissermaßen im responsiven Tagesgeschäft angekommen sind, werde ich einen Artikel über unsere Suche nach den besten Tools veröffentlichen.

    Die Idee mit den Jira-Tickets klingt sehr praktisch. Zumindest wenn die Disziplin vorhanden ist. Aber wenn die Vorgehensweise wirklich Arbeit spart, kommt die Disziplin oft von ganz allein.


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 →