Illustration Pattern Library

Bauanleitung für eine Pattern Library – Teil 1: Warum braucht man eigentlich eine Pattern Library?

Wer Design Patterns keinerlei Beachtung schenkt, landet früher oder später in Teufels Küche. Versprochen. Design Patterns sind wichtig für ein nutzerfreundliches Produkt und insbesondere große Produktteams können mit einer Design Pattern Library Inkonsistenzen, Wildwuchs und unnötige Doppelarbeit vermeiden. In dieser Artikelserie will ich euch den Umgang mit Design Patterns näher bringen und zeigen, wie in den letzten zwei Jahren bei OTTO eine sehr leistungsstarke Pattern Library entstanden ist, die zum Erfolg des Produkts nachhaltig beträgt.

Bevor ich tiefer einsteige, möchte ich kurz erklären, wie ich selbst zu diesem Thema gekommen bin: Im Oktober 2011 habe ich als Interaction Designer im eCommerce von OTTO angeheuert. Zur gleichen Zeit nahm das interne Projekt „Lhotse“ Fahrt auf, in dem bis zum erfolgreichen Launch im Oktober 2013 die komplette eCommerce-Plattform des Unternehmens von Grund auf neu entwickelt wurde. Ziel des Projekts war es, zuerst ein Minimum Viable Product zu entwickeln. Eine sinnvolle Entscheidung, um bei einer so großen Plattform überhaupt erfolgreich zum Ziel zu kommen – wir reden hier von Umsätzen im Milliarden-Euro-Bereich, Millionen täglicher Visits und einem Artikelspektrum vom Bikini bis zur Kettensäge. Positiver Nebeneffekt der MVP-Philosophie war aber auch der (vorläufige) Abschied von unzähligen historisch gewachsenen Features.

Diesem Wildwuchs sollte auch auf Seiten des User Interfaces Einhalt geboten werden. Der komplette Neustart einer Produktentwicklung ist dafür auch eine gute Voraussetzung, aber noch lange nicht ausreichend. Insbesondere bei großen Teams und Produkten: Von Beginn des Lhotse-Projekts arbeiteten drei agile Teams an Nutzer-Features. Mittlerweile sind es fünf Teams und damals wie heute sollen diese Teams möglichst unabhängig voneinander ihr Teilprodukt discovern, gestalten und entwickeln. Da sich hier schnell wieder neue Inkonsistenzen zeigten, bekam ich nach einigen Monaten den Auftrag, eine Pattern Library zu konzipieren. (Dankenswerterweise bekam ich etwas später auch noch meine heutige Co-Autorin Inken zur Seite gestellt, ohne deren Hilfe ich bestimmt nicht so weit gekommen wäre.)

In Teufels Küche

Wie verheerend der Wildwuchs über die Jahre die Qualität und Benutzbarkeit eines Produkts beeinträchtigen kann, zeigen zeigten sehr schön die Produktempfehlungs-Kinos auf der alten OTTO-Plattform. 2012 konnte ich insgesamt acht Varianten ausmachen. Jede mit abweichendem Design, Informationsgehalt und Interaktionen.

Kinos auf OTTO.de 2012

Die Kinos stehen hier stellvertretend für zahlreiche Stilblüten auf der alten Plattform. Ein solches Bild findet man regelmäßig bei sehr alten, immer wieder erweiterten Produkten. Je größer aber eine Produktorganisation wird, je mehr Produktmanager, Designer und Entwickler parallel arbeiten, desto kurzfristiger können solche unerwünschten Folgen auftreten. Dies hat drei Ursachen:

Problem 1: Fehlende Synchronisierung

Stellen wir uns einmal folgende Situation vor: Die Product Discovery oder der Product Design Sprint ist in einem unserer Produkt-Teams jüngst zu Ende gegangen und für ein Designproblem hat sich das Team für eine bestimmte Lösung entschieden, die nun von dem Designer an den Entwickler gebrieft wird.

Pattern Kommunikation Abweichung

In unserem zweiten Produkt-Team ist kurze Zeit später Designer Nummer 2 mit einem sehr ähnlichen Designproblem konfrontiert, wie sein Kollege aus Team 1. Mangels Referenz und Austausch überlegt sich dieser eine komplett andere Lösung und gibt diese in die Entwicklung. In kurzer Zeit haben wir uns so ein inkonstientes User Interface eingehandelt. (Merke: Nicht immer ist Konsistenz die richtige Vorgehensweise, je nach Kontext ist eine Abweichung durchaus sinnvoll, dies sollte aber stets eine bewusste Entscheidung sein.)

Das Problem kann auch auftreten, wenn es nur ein Produktteam mit nur einem Designer gibt: Jedem Designer ist es bestimmt schon passiert, dass er er sich nicht mehr so recht erinnert hat, keine Zeit für eine Recherche hatte oder einfach mal etwas neues ausprobieren wollte und dann für das selbe Problem eine komplett neue Lösung vorgeschlagen hat.

Problem 2: Schlechte Kommunikation und Missverständnisse

Unabhängig von der Größe des Teams kann es bei der Kommunikation zwischen Designer und Entwickler (oder Produktmanager und Designer, oder…) zu Missverständnissen kommen. Im Idealfall war der Entwickler natürlich schon in der Discovery involviert und hat damit kein Problem, die Lösung zu verstehen. Es würde aber auch reichen, wenn sich Designer und Entwickler präzise und ausführlich austauschen. Aber wir alle wissen genau, dass diese Kommunikation nicht immer so perfekt läuft. Besonders schlimm ist das, wenn Designer und Entwickler sich überhaupt nicht austauschen und das Briefing einfach nur „über den Zaun geworfen wird“.

Pattern Kommunikation Missverständnis

Es ist unerheblich ob hier nun der Designer oder der Entwickler oder beide nicht genügend kommuniziert haben oder ob die Organisationsform keine ergiebigere Kommunikation zugelassen hat. Letzterer versteht in unserem Beispiel das Briefing nicht richtig und setzt eine abweichende Lösung um. Die nächste Inkonsistenz ist entstanden. Solche Abweichungen sind oft besonders Problematisch, da sie dank visueller Briefings oft ähnlich wie die geplante Lösung aussehen und erst im Verhalten oder im Code grundlegend abweichen. Bei Design-Reviews sind sie dadurch nur schwer zu entdecken.

Problem 3: Mehrfache Arbeit

Selbst wenn wir im „Erdbeerland“ wären und alle die gleiche Lösung für das gleiche Problem wählen würden und jedes Mal präzise und unmissverständlich diese Lösung briefen würden, würde immer noch jede Lösung in jedem Team unnötig mehrfach kommuniziert.

Pattern Kommunikation Mehrfach

An diesen drei Problemen wird schnell deutlich, dass ohne eine Pattern Library als zentrale Referenz für Kommunikation und Lösungsfindung mit großer Sicherheit Inkonsistenzen im Interface auftreten werden, Missverständnisse entstehen können und viele doppelt erledigte Arbeiten (vom Briefing bis zur QA) anfallen.

Aber was ist eigentlich genau ein Pattern?

Definition eines Design Patterns

Der Begriff „Pattern“ – auf Deutsch „Muster“ – beschreibt eine Struktur, der ein oder mehrere wiederholende Elemente zugrunde liegen. Das Begriffsspektrum reicht hier von psychologischen Verhaltensmustern bis hin zu grafischen Mustern, wie zum Beispiel die ganz banale Tapete.

In den sechziger Jahren beschrieb der US-amerikanische Architekt Christopher Alexander in seinem Werk „A Pattern Language“ wiederkehrende Muster in der Architektur. Er wird damit gern als Begründer des Pattern-Begriffs in der modernen Produktentwicklung und Erfinder der ersten Pattern Library zur Lösung von Designproblemen angesehen. Während sein Konzept in der Architektur eher verhalten aufgenommen worden ist, setzte sich die Philosophie zwei Dekaden später in der Softwareentwicklung und mit dem Buch „User Centered System Design” von Donald Norman und Stephen Draper im Interaktionsdesign durch.

Für die Produktentwicklung will ich ein Design Pattern folgendermaßen definieren:

Ein Design Pattern ist ein Element eines Produkts, welches ein bestimmtes Problem löst und sich in unterschiedlichen Kontexten (bzw. mit unterschiedlichen Inhalten) wiederholt.

Das Paradebeispiel für ein Pattern ist der Button. Dieser kommt in Produkten in der Regel in unterschiedlichen Kontexten (Kontaktformular, Suche, Login) und mit unterschiedlichen Inhalten („Absenden“, „Suchen”, „Anmelden“) vor.

Pattern Beispiel Button

Ein Pattern ist aber nicht nur das Bild eines Buttons oder der Code für einen Button, sondern kann durchaus umfassend dokumentiert sein kann. So definiert Jared Spool ein Pattern folgendermaß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.“

Neben unserem Button bieten sich unzählige Aspekte eines Produkts an, als Pattern definiert und dokumentiert zu werden:

Typen von Design Patterns

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

Pattern Beispiel Kino 1

Der Button ist uns als Pattern bereits bekannt. Andere Elemente, die der Pattern-Definition entsprechen, die sich also in anderen Kontexten und 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 lässt sich sinnvoll als Pattern festlegen.

Pattern Beispiel Kino 2

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.

Pattern Beispiel Kino 3

Um hier besser unterscheiden zu können, haben Inken und ich uns 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:

An seiner Hierarchie sieht man, dass auch ganze Templates und Seitentypen als Patterns denkbar sein können – insbesondere in einem Multi-Device-Kontext. Ebenfalls wiederverwendbar und damit ein Pattern wären auch:

  • Übergänge und Animationen (z.B. die Links-Rechts-Bewegung des Kino-Inhalts)
  • 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“)
  • 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.

Vorteile des Einsatzes von Patterns und einer Pattern Library

Viele Aspekte eines Produkts lassen sich also in einer Pattern Library dokumentieren und zentral für Produktmanager, UX-Designer, Entwickler und alle weiteren Beteiligten verfügbar machen. Richtig eingesetzt hat eine Pattern Library zahlreiche Vorteile:

  1. Design Patterns verbessern die User Experience: Für gleiche Designprobleme werden gleiche Lösungen eingesetzt. Das UI wird damit konsistent und für den Nutzer verständlicher und vorhersagbarer. Durch Patterns lassen sich zudem schneller Prototypen bzw. Lösungen entwickeln, so dass Zeit für weitere Iterationen oder für die Bearbeitung neuer Probleme gewonnen wird.
  2. Design Patterns sind erprobt: Patterns sind in der Regel bereits getestet und robust. Damit profitieren alle weiteren Einsatzorte von dieser Vorarbeit. Insbesondere Seiten mit geringem Business Value – die „dunklen Ecken“ des Produkts – erhalten so verlässliche Lösungen, ohne dass Aufwand für Entwicklung oder Tests anfällt.
  3. Design Patterns ermöglichen eine klare und effiziente Kommunikation: Durch die Pattern Library haben alle Beteiligten der Produktentwicklung ein gemeinsames Verständnis von der Lösung. Missverständnisse werden vermieden und die Kommunikation kann knapper und damit effizienter erfolgen. Insbesondere die manchmal angeschlagene Beziehung zwischen Designern und Entwicklern kann sehr davon profitieren.
  4. Design Patterns verbessern die Code-Qualität: Das Briefing von Patterns erlaubt Entwicklern bereits erstellten Code wieder zu verwenden, damit Zeit zu sparen und Code-Redundanzen zu vermeiden. Dies vereinfacht auch die Qualitätssicherung. (Ich werde in einem der folgenden Artikel noch darauf eingehen, warum es wichtig ist, beim Aufbau einer Pattern Library eng mit Entwicklern zusammen zu arbeiten.)
  5. Design Patterns reduzieren Komplexität: Eine Pattern Library beinhaltet nie die Antwort auf alle Probleme. Aber sie sie enthält erprobte Lösungen oder Lösungsansätze für viele Situationen. Damit macht sie die Arbeit an komplexen Interfaces viel beherrschbarer. (Selbst Responsive Design lässt sich mit Patterns einfacher umsetzen, auch ein Thema für einen späteren Artikel).
  6. Design Patterns erleichtern das OnBoarding neuer Teammitglieder: Eine Pattern Library ist ein guter Einstieg und Orientierungspunkt für neue Designer und Entwickler, die hier auf einen Blick eine Referenz über alle verfügbaren Elemente und Lösungen vorfinden.

Auch wer keine eigene Pattern Library anlegen kann oder will, kann von gut dokumentierten Design Patterns in öffentlichen Libraries profitieren. Gute Anlaufpunkte sind die Libraries von Android, Mailchimp, der BBC sowie UI-Patterns.com

Aber schränkt eine Pattern Library nicht die Kreativität ein?

Nein

Ganz im Gegenteil! Nicht jedes bereits gelöste Problem muss erneut gelöst werden und dank der Auswahl an Patterns lassen sich viel schneller Prototypen erschaffen und testen. Beides verschafft einem Zeit, sich auf die wirklich neuen Probleme zu konzentrieren oder um sich um Feinschliff und Details zu kümmern.

Und aus kreativer Selbstverwirklichung heraus jeden Button neu erfinden zu wollen, ist in meinen Augen eine sonderbare Art der Kreativität und hat in ernsthafter Produktentwicklung nichts verloren.

Wie geht es weiter?

Nachdem dieser Artikel vermittelt hat, was ein Pattern ist und wie eine Pattern Library in der Produktentwicklung helfen kann, will ich in den folgenden Artikeln auf die konkrete Entwicklung der OTTO.de Pattern Library eingehen. Insbesondere will ich zeigen, wie wir zu unserer heutigen Struktur und unseren heutigen Prozessen gefunden haben und warum das Konzept „Lean“ auch für Pattern Libraries gelten sollte.

Zum zweiten Teil →

(Die Bezeichnung, Reihenfolge und Aufteilung der Artikel kann sich durchaus noch ändern.)

Falls Ihr selber schon positive oder negative Erfahrungen mit einer Pattern Library gemacht habt, falls ihr Fragen zu diesem oder Wünsche für Folgeartikel habt, freue ich mich auf Eure Kommentare.

Über Wolf Brüning

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

3 Kommentare

  1. Detlev Petersen

    Hallo Wolf,

    für mich ist es spannend, etwas aus einem anderen Bereich zu lesen. Bei Dir geht es um Design Pattern für die Entwicklung von Internetseiten bzw. Webshops. Design Patterns gibt es auch in anderen Bereichen, z.B. der Softwareentwicklung für eingebettete Systeme.

    OTTO ist sicher gut im Geschäft, so dass die finanzielle Kraft da ist, ein größeres Projekt wie die Umgestaltung eines Webshops mit Millionen von Transaktionen zu stemmen. Ich bin im Turnkey-Projekt-Bereich tätig, wo die Margen nicht ganz so üppig waren und der Preiskampf hart ist, aber auch die Masse fehlt, noch genügend Gewinn zu machen. Das zwingt uns knappe Zeitstrecken und wenig Ressourcen zur Zielrealisierung auf.

    Meine Erfahrungen sind bezüglich Libraries und Design Patterns die, dass jeder Entwickler sich selbst hilft, um sein Ziel zu erreichen. Da gibt es quasi einen menschlichen Automatismus zum Einsatz einer Library. Das Rad nicht zweimal erfinden zu müssen, beschreibt den Nutzen von Libraries ganz gut. Als Realität stellt sich schnell heraus, dass jeder irgendwie seine eigenen Libraries nutzt. Ich nehme den Begriff Libraries jetzt in Analogie zu Design Patterns. Es entsteht ohne weiteren Eingriff ein Wildwuchs an verschiedenen Libraries. Oft ist die Zeit knapp, sich in neue Dinge einzuarbeiten, so auch in neue unbekannte Libraries. Der Zeitdruck ist hoch. So erkläre ich mir, dass jeder in einer solchen Situation geneigt ist, die Libraries zu nehmen, die er bereits gut kennt.

    Wenn mehrere Entwickler die Library Boost für C++ bereits kennen, ist das von Vorteil, weil es bereits schon eine gemeinsame Basis gibt. Oft ist das jedoch nicht der Fall, weil Libraries erst neu entwickelt oder passende erst gefunden werden müssen. Mir kam daher die Idee, einen extra Mitarbeiter in einem Team zu haben, der sich hauptamtlich um die Libraries kümmert. Dieser pflegt diese dann und sorgt für deren Einsatz. Er steht den anderen Entwicklern als Coach zur Verfügung, damit diese ihr Ziel mit seiner Hilfe schneller erreichen. Das nimmt anderen die Hürde, sich in die Libraries einzuarbeiten. Es sorgt dafür, dass alle die gemeinsame Library nutzen. Es geht in Richtung des Extreme Programming und der Vorteile der Nutzung eines kleinen Teams zur Lösung eines Problems, denn es sitzen schon 2 Menschen an der Lösung des Problems mit zumindest leicht unterschiedlichen Sichtweisen. Teilweise ist der Zeitdruck im Projekt so hoch, dass mit Paste and Copy schnell eine Lösung gezimmert wird, die dann projektspezifisch angepasst wird. Damit entwickeln sich ursprünglich gleiche Teile auseinander. Sich eine Lösung für alle Projekte auszudenken, scheitert am Ressourcenmangel oder am Mangel, überhaupt alle Anwendungsfälle für diese Library genug durchdrungen zu haben, vom erhöhten Testaufwand ganz zu schweigen.

    Von daher kann ich es mir sehr hilfreich vorstellen, in entsprechend großen Entwicklerteams auch extra Library-Coaches zu haben, welche die Library weiterentwickeln, aber auch deren Nutzung und Verbreitung im Team fördern. Eine solche Person schafft es eher, eine Library, ein Design Pattern für viele Nutzer und Anwender passend zu bauen, weil deren Fokus auf der Library an sich liegt und nicht vorrangig auf dem Problem, was mittels Library schneller zu lösen versucht wird.

    Was gegen einen gesonderten Library-Entwickler spricht, ist unter Umständen die Tatsache, dass eine Library-Entwicklung recht trocken sein kann, weil nur der Unterbau einer Gesamtanwendung damit entsteht. Das ist zwar ein wichtiger Teil und eine gute Library kann die Qualität eines schlechteren minimalen Oberbaus erhöhen, aber wir wissen alle, dass Menschen dazu neigen, nur die äußere Fassade wahrzunehmen. Damit kann schnell der wesentliche Beitrag guter Libraries als Teil von Produkten verkannt und die Library-Entwickler stehen damit schnell im Schatten der anderen.

    Das sind 2 Argumente, die gegen so eine extra Library-Entwickler-Stelle sprechen. Wenn aber jemand das gerne macht und den Wert dahinter auch sieht, dann ist es für ein Team in Summe goldrichtig, so einen Library-Coach und -Entwickler zu haben. Ich glaube jedenfalls daran, dass sich der schöngeistige Ansatz in der Realität schnell als Vorteil erweisen wird, weil Lösungen beschleunigt werden und auch alle Hürden aus dem Weg geräumt sind, die zum Nutzen einer Library in Breite führen.

    Daher wäre es interessant, ob es bei Euch eine extra Abteilung oder extra Entwickler gegeben hat, welche fürs Verbreiten und Nutzen der neuen einheitlichen Library auch gesorgt haben, damit jeder da auch mit zog an diesem einen Strang und auch keine Hürden hatte, die Library auf wirklich zu einzusetzen.

    Viele Grüße
    Detlev

  2. Wolf Brüning Artikelautor

    Moin Detlev,
    entschuldige zuerst die späte Antwort, aber ich war die letzten beiden Wochen in Italien und habe mich da – wenn überhaupt – eher mit architektonischen Patterns befasst.

    Und du hast natürlich recht. Design Patterns sind auch in der Software-Entwicklung ein wichtigstes Konzept. Sie sind dort sogar schon länger im Einsatz als im UI- und Interaktionsdesign. Im obigen Artikel gehe ich leider nur knapp in einem Halbsatz darauf ein.

    Dass jeder Entwickler eine persönliche Library aufbaut und einsetzt ist fern vom Idealfall aber schon ein großer Schritt in die richtige Richtung: Der Code eines jeden Entwicklers wird konsistenter und robuster. Ziel sollte aber immer eine gemeinsam genutzte Library sein.

    Um auf deine eigentliche Frage zurückzukommen: Hier bei OTTO haben wir wirklich eine Art „Pattern-Coaches“ im Einsatz. Aus den drei Disziplinen, die hauptsächlich Patterns erstellen und/oder diese nutzen – Interaktionsdesigner, Visual Designer und Entwickler – gibt es jeweils einen, der in Sachen Patterns den Hut aufhat. Dieser hat die Aufgabe, seinen Kollegen die Benutzung der Pattern Library zu erklären und zu vereinfachen sowie das Erstellen der Patterns nach unseren Standards zu garantieren. Gewiss ist das nicht die Lieblingsaufgabe eines jeden Designers oder Entwicklers, aber es gibt durchaus Leute, die Spaß daran haben. Bei einer so umfassenden Personaldecke wie bei OTTO ist es natürlich einfach, passende Charaktere zu finden. Und es kann durchaus eine erfüllende Aufgabe sein: Mit einer gut aufgestellten Pattern Library ist einem der Dank eines jeden Designers und Entwicklers sicher.

    Was die initialen Konzeption der Pattern Library betrifft, fiel natürlich noch einiger Evangelisierungs-Aufwand an. Im Großen und Ganzen kann man aber sagen, dass deine Schwester und ich offene Türen eingerannt haben. Insbesondere nach Integration der Entwickler hat sich das Thema positiv verselbstständigt.

    Nach meinen Erfahrungen wird sich eine Pattern Library weder von alleine entwickeln, noch von alleine aktualisieren, noch konsistent und nutzbar bleiben. Es muss eine Person oder einen kleinen Personenkreis geben, der das Thema von sich aus vorantreibt und am Laufen hält.

    Grüße, Wolf

  3. Detlev Petersen

    Hallo Wolf,

    jetzt habe ich einen Zeitschlitz gefunden, zu antworten. Es ist für mich gut zu wissen, dass Ihr erfolgreich gewisse Überlegungen umsetzen konntet, die mir aus einem etwas anderen Kontext heraus in den Sinn kamen. Das zeigt mir, dass meine Gedanken nicht völlig weltfremd sind.

    Natuerlich muss die Situation nicht so sein, dass dies alles realisierbar ist. Wenn die Geldmittel und Ressourcen es zulassen, dann erscheint es mir sehr sinnvoll zu sein, es genau auf diese Weise umzusetzen. Wenn das Ideal nicht zu leben ist, kann es immerhin noch zur Positionsbestimmung dienen, um zu wissen, wie weit man selbst davon entfernt ist.

    Viele Grüße
    Detlev

Schreibe einen Kommentar

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