Bauanleitung für eine Pattern Library – Teil 2: Auf der Suche nach der perfekten Pattern Library

Design Patterns sind wenig wert ohne Struktur. 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. Besonders möchte ich dabei auch auf die ersten beiden Versuche eingehen, die zwar mehr oder minder gescheitert sind, bei denen wir aber viele wertvolle Dinge gelernt haben.

Erster Versuch: 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:

„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.“

Eine Pattern Library, die sich sehr gut an diese Definition hält und lange Zeit als die Genre-Referenz galt ist die Yahoo Design Pattern Library:

Screenshot Yahoo Pattern Library

Die Dokumentation der Patterns ist ausführlich und enthält 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 stammt:

Yahoo Pattern Library

In bald fünf Jahren 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 aber nicht weiterentwickelt. Wir haben uns dennoch etwas tiefer mit der Yahoo-Library beschäftigt und uns ist der folgende Workflow in die Arme gefallen:

Pattern Library Workflow

Yahoo Pattern Library Workflow (Quelle: boxesandarrows.com)

Wir sehen unzählige beteiligte Personen und Abstimmungsrunden nach Abstimmungsrunden nach Abstimmungsrunden… Unsere Vermutung an dieser Stelle ist, dass die Yahoo Pattern Library durch zu aufwändige Dokumentation und zeitraubende Prozesse ausgebremst worden ist und so nach und nach veraltete.

Die größte Gefahr für eine Pattern Library ist, nicht mehr aktuell zu sein. Sobald dieser Fall eintritt, werden die zuständigen Designer 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 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.

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. Im Idealfall sollte der zusätzliche Pflegeaufwand für ein neues Pattern geringer sein als die Zeitersparnis bei der zweiten Verwendung des Patterns im Produkt. Das ist gewiss utopisch (vor allem bei einfachen Patterns), sollte aber Zielbild für eine effiziente Pattern Library dienen. Spart eine Pattern Library keine Zeit oder erzeugt sogar dauerhaft zusätzlichen Aufwand, wird sie automatisch Akzeptanzprobleme bekommen. Und Akzeptanzprobleme führen früher oder später zu veralteten Inhalten.

Zweiter Versuch: 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
  • 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, 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 ist 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, getrennt nach Bausteinen und Komponenten. Für einen neuen Entwurf müsste 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)

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 Initiative die Entwickler mit ins Boot zu holen (und umgekehrt). Beide Parteien 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:

Designers love Developers

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 kann.

Screenshot Code Pattern Library Button

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

Code Pattern Library Quellcode

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

Struktur 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 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 Baustein geändert wurde, mussten alle Patterns, die diesen Baustein enthalten 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 eine grandiose Idee. In der Praxis haben diese Vorlage-Dateien die Rechner unserer Designer aber gern 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, die lieber Screenshots aus der CoPaLi nahmen, als die schwerfälligen PSDs zu laden.

Dritter Versuch: Lean Pattern Library

Wir mussten also feststellen, dass wir uns mit unserer 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 sind 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 hinterfragen wir gerade unsere Tools um agiler gestalten zu können. Die Tage von Photoshop als zentrales Design-Tool sind meiner Meinung nach weitgehend gezählt. Mit welchem Tool wir hier weiterarbeiten werden, wird sich erst in den nächsten Monaten herausstellen. Vielleicht wird es ja soweit kommen, dass auch wir Designer nur noch mit HTML arbeiten, dann bräuchten wir keine zusätzlichen Vorlagensammlungen mehr.

Das Modul für Dokumentation und Kommunikation haben wir nicht komplett abgeschafft. Wir brauchen es weiterhin, um Nutzern außerhalb von OTTOs eCommerce-Bereich (Print-Designer, externe Agentuen, usw.) unsere Patterns zur Verfügung zu stellen. Insbesondere wenn diese mit HTML-Patterns wenig anfangen können oder keinen Zugriff auf den Code bekommen sollen. Um den Overhead so gering wie möglich zu halten, beschränken wir uns hier nur noch auf eine Teilmenge unserer Patterns: solche die wir als stabil und markenprägend (Elemente mit starkem Einfluss auf den Look & Feel von OTTO, z.B. die roten Buttons) einordnen.

Im Kern besteht unsere Pattern Library heute nur noch aus der Code Pattern Library mit erweiterter Dokumentation. Der Overhead für die Pflege von Patterns ist dadurch so gering geworden, dass man mit Recht von einer „Lean Pattern Library“ sprechen kann.

Screenshot OTTO Pattern Library

Ich kann an dieser Stelle leider keinen Live-Einblick in OTTOs Pattern Library geben. Einen guten Eindruck geben aber andere öffentliche Pattern Libraries, die ähnlich schlank aufgebaut sind, z.B von MailChimp und Lonely Planet.

Screenshot Lonely Planet Pattern Library

Lonely Planet Pattern Library

Im nächsten Artikel will ich detailliert auf die einzelnen Prinzipien und Prozesse eingehen mit denen wir sicherstellen, dass unsere Pattern Library auch wirklich Lean ist und bleibt.

Zum dritten Teil →

Weitere Artikel aus dieser Serie:

Über Wolf Brüning

Wolf arbeitet als Senior 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.

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.