Bauanleitung für eine Pattern Library – Teil 3: Prinzipien für eine Lean Pattern Library

Im zweiten Teil dieser Artikelserie habe ich unseren Weg zur schlanken Pattern Library beschrieben. Eine solche Pattern Library schlank zu betreiben und schlank zu halten ist aber nicht nur eine Frage des richtige Tools und der richtigen Struktur. Auf dem Weg zu OTTOs heutiger Pattern Library haben wir daher Prinzipien, Regeln und Prozesse aufgestellt um dies zu gewährleisten.

Prinzip 1: Ein klare Definition, was ein Pattern ist (und was nicht)

Die wichtigste Voraussetzung für eine schlanke Pattern Library ist, dass in ihr auch nur relevante Elemente enthalten sind. Ein erster Reflex ist oft, jedes Element in jeder Variante zu dokumentieren. Zu viele, wahllos aufgenommene Elemente machen eine Pattern Library erstens unübersichtlich, zweites gibt sie so den Designern keine Führung mehr und drittens wird sie mit jedem zusätzlichen Element aufwändiger in der Handhabung.

Je größer das zu begleitende Produkt ist, desto wichtiger sind also klare Regeln. Als Basis dafür kann meine Design-Pattern-Definition aus dem ersten Teil dieser Serie dienen:

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

Wichtig ist hier vor allem der zweite, fette Teil der Definition. Ein Element, muss sich wiederholen, um ein Pattern zu sein. Gibt es dieses Element nur ein einziges Mal im Produkt und ist auch nicht absehbar, dass es mittelfristig wiederverwendet wird, hat es in der Pattern Library nichts verloren.

Gleiches gibt für Varianten von Patterns: Nicht immer passt ein bestehendes Pattern auf jeden neuen Einsatzzweck. Im Idealfall würde man nun das Pattern so anpassen, dass es für alle Zwecke funktioniert. Oft ist dies aber nicht möglich und so wird eine Variation des Patterns für die entsprechende Stelle erstellt. Ist nicht abzusehen, dass diese Variante zu einem Regelfall wird, so sollte diese nicht in die Library aufgenommen werden. (Es kann aber sinnvoll sein, zumindest die Existenz von Abwandlungen beim Ursprungspattern zu dokumentieren).

Wie in vielen Dingen hilft eine gute Portion gesunder Menschenverstand, die Pattern Library schlank zu halten: Nicht jedes Element, dass formell die Definition eines Patterns erfüllt, hilft einem Designer oder Entwickler bei seiner Arbeit. Ein gutes Beispiel sind die Header und Footer von Webseiten. Diese wiederholen sich zwar über die gesamte Seite, würden aber niemals in anderen Kontexten eingesetzt und müssen so niemanden als flexible Komponente zur Verfügung stehen.

Gerade in komplexen Produktorganisationen kann es neben diesen Grenzen auch noch technische oder organisatorische Gründe geben, die für oder gegen die Aufnahme eines Elements als Pattern sprechen. Bei OTTO werden im Moment zum Beispiel Patterns, die nur von einem einzigen agilen Team verwendet werden, nicht in die Pattern Library aufgenommen. Sehr hohe Performance-Anforderungen und die Minimierung von Abhängigkeiten zwischen den Teams fallen stärker ins Gewicht als die Schaffung einer wirklich kompletten Übersicht.

Ganz egal, wie die Regeln gewählt werden, ein wichtiger Schritt ist es, ein gemeinsames Verständnis zwischen allen Beteiligten (insbesondere unter den Designern und Entwicklern) zu schaffen, was ein Pattern ist und was nicht. Andernfalls können hier Konflikte oder eine inkonsistente Befüllung der Library entstehen.

Prinzip 2: Flexible Patterns

Ein Pattern ist nur hilfreich, wenn es genügend Flexibilität für den Einsatz mit unterschiedlichen Inhalten und in unterschiedlichen Kontexten mitbringt. Bei der Konzeption eines neuen Bausteins oder einer neuen Komponente sollte also ein großes Augenmerk darauf gelegt werden, ob z.B. auch andere (längere, kürzere,…) Inhalte integriert werden können oder ob das Element in unterschiedlichen Raumsituationen (volle Seitenbreite, nur eine Grid-Spalte,…) funktioniert.

Natürlich darf es auch Patterns mit einem sehr kleinen, spezifischen Einsatzrahmen geben, insbesondere Bausteine (Buttons, Formularfelder usw.) sollten aber auf größtmögliche Flexibilität getrimmt werden, um einen späteren Wildwuchs an Varianten zu vermeiden.

Eine weitere gute Maßnahme gegen unnötige Varianten ist es, Außenabstände nicht als Teil des Patterns zu sehen. Um eine gute visuelle Hierarchie in einem User Interface herzustellen bedarf es oft des finetunings von Abständen zwischen den Elementen. Bringt nun jedes Element seine vorgegebenen Abstände mit, ist dies nicht oder nur noch durch das Erstellen von Pattern-Varianten mit anderen Abständen möglich. Besser man verzichtet also ganz auf die Definition von Abständen als Teil des Patterns oder beschränkt sich auf Standard- bzw. Mindestabstände, wo diese unbedingt notwendig sind (z.B. um den vertikalen Rhytmus der Typographie zu gewährleisten).

Neben der gestalterischen Flexibilität sollten Patterns auch technisch so flexibel wie möglich umgesetzt werden. Bei OTTO verzichten wir vollständig auf den Einsatz von Bildern sondern nutzen ausschließlich HTML, JavaScript, CSS3-Effekte (z.B. für runde Ecken und Gradienten), Webfonts und Icon-Fonts zum Bau unserer Patterns.

Zusätzlich zur Flexibilität im Einsatz hat diese Vorgehensweise noch eine Reihe weiterer Vorteile:

• Die visuelle Veränderung von Patterns ist in der Regel durch wenige Zeilen Code umsetzbar.
• Die Patterns lassen sich sauber skalieren und sehen damit auf gezoomten Ansichten sowie auf hochauflösenden Displays stets gut aus.
• Durch den Verzicht auf Bilder sind die Patterns vollständig parametrisierbar und damit geeignet für Responsive Design.
• Weniger Bilder müssen gepflegt und durch den Server ausgeliefert werden.

Als Konsequenz kann es natürlich passieren, dass der Look unserer Patterns auf veralteten Browsern abweicht. Solange Erkennbarkeit und Funktionalität aber gegeben sind, wird das Pattern nicht mit Hacks oder Workarounds aufgeblasen, sondern die abweichende Optik akzeptiert.

Prinzip 3: Schlanke Dokumentation und schlanke Prozesse

Einer der großen Treiber von unnötigem Arbeitsaufwand ist die Dokumentation. Das Yahoo-Beispiel aus dem vorherigen Teil zeigt, wie übertrieben genaue Dokumentation und umständliche Abstimmungsprozesse letztlich zu einer veralteten und damit nutzlosen Pattern Library führen. Eine nicht perfekt dokumentierte Library wäre damit immer noch besser als eine perfekt dokumentierte aber veraltete.

Folglich sollte sich der Umfang der Dokumentation stets auf das Allernotwendigste reduzieren. Was dieses Allernotwendigste ist, hängt von Größe und Aufbau der Produktorganisation ab, insbesondere wie viele Personen über die Verwendung eines Patterns entscheiden und wie eng diese zusammen arbeiten. Fünf Interaktionsdesigner, die im selben Raum arbeiten, brauchen deutlich weniger Dokumentation als eine Organisation mit 20 über den Globus verteilten, autarken Produktteams.

An dieser Stelle empfiehlt sich – wie so oft – agiles Vorgehen: Die erste Dokumentation eines Patterns sollte nur Informationen umfassen, ohne die das Pattern nicht verstanden werden kann. Bei vielen einfachen Patterns kann das sogar bedeuten, dass zuerst gar keine Dokumentation angelegt wird. Erst wenn Fragen zu oder Probleme mit einem Pattern auftreten, wird die Dokumentation entsprechend ergänzt.

Wie die Dokumentation selbst, sollten auch die Prozesse zur Erstellung und Veränderung von Patterns minimal gehalten werden. Aufwändige Abstimmungsrunden lassen sich am ehesten vermeiden, indem man die Verantwortung auf möglichst wenige Köpfe verteilt.  Das untenstehende Schaubild verdeutlicht das System mit dem wir bei OTTO bisher am besten fahren:

Jeder unserer Interaktionsdesigner kann, wenn er auf ein neues Design-Problem trifft, neue Elemente definieren und testen. In Abstimmung mit den anderen Interaktionsdesignern, kann er dann bewerten, ob wirklich ein Pattern vorliegt. Im nächsten Schritt gibt es dann genau einen Visual Designer und genau einen Entwickler, die in enger Abstimmung das Pattern umsetzen und es über die Pattern Library den Entwicklungsteams zur Verfügung stellen.

Durch die Reduktion des eigentlichen Umsetzungsprozesses auf zwei Personen entsteht für Designer und Entwickler ein Single Point of Contact in allen Pattern-Fragen und Abstimmungen können schlank gehalten werden.

Wenn der Einsatz einer Pattern Library im Ganzen mehr Zeit spart als er kostet, ist jeder motiviert, diese auf einem aktuellen Stand zu halten. Diesen Zustand zu erreichen und zu bewahren ist definitiv der wichtigste Faktor für eine erfolgreiche Implementation einer Pattern Library.

Prinzip 4: Dokumentation im Code

Auf dem Weg zu unserer perfekten Struktur haben wir die Code Pattern Library unserer Entwickler als Basis für unsere Pattern Library verwendet. Die Dokumentation im Live-Code hat uns aber nicht nur ein schlankes und unkompliziertes Tool beschert, sondern viele weitere Vorteile:

• Patterns in der Library sind keine hypothetischen Photoshop-Simulationen sondern sehen exakt so aus, wie auf der Webseite.
• Das Grundlegende Verhalten der Patterns (z.B. Mouseover, Klickverhalten, Animationen) lässt sich direkt im Browser ausprobieren.
• Mithilfe von Entwicklungs-Tools lassen sich die Patterns mit eigenen Inhalten testen.
• Ebenso lassen sich visuelle Änderungen (z.B. des Ecken-Radius) direkt verproben.
• Die Code-nahe Arbeit führt zu einem besseren Technologie-Verständnis bei den Designern und verbessert die Zusammenarbeit zwischen Design und Entwicklung.
• Komponenten müssen nicht einzeln aktualisiert werden, wenn sich ihre Sub-Patterns ändern.
• Tests und Qualitätssicherung der Patterns lassen sich zentral in der Pattern Library durchführen.

Damit stets ein realistischer Zustand abgebildet wird, nutzt die Pattern Library von OTTO das selbe CSS wie die Shop-Plattform. Somit können wir sicher sein, dass die enthaltenen Patterns immer auf einem aktuellen Stand sind. Jede Plattform-Instanz (Live-System, Entwicklungs- und Testsysteme) hat zudem eine eigene Instanz der Pattern Library, so dass auch weitreichende Änderungen an den Patterns vorgenommen werden können, ohne dass diese zu früh beim Nutzer landen. (In Teil 6 wird auf die technischen Grundlagen genauer eingegangen.)

Prinzip 5: Eine Balance zwischen Stabilität und Veränderung finden

Eine Pattern Library muss stabil sein. Es ist niemandem geholfen, wenn im Wochentakt Patterns verändert oder mit jedem Feature unreflektiert neue Patterns eingeführt werden. Ein solcher Missbrauch führt zu einem Wildwuchs unnötiger Inhalte und die Library verliert sehr schnell ihren Status als Referenz.

Zu Gewährleistung der Stabilität helfen die folgenden drei Regeln:

1. Es dürfen nur dann neue Patterns von einem Designer eingeführt werden, wenn sich für ein Design-Problem mit den bestehenden Patterns keine zufrieden stellende Lösung finden lässt.
2. Ein Pattern darf erst verändert oder ersetzt werden, wenn es von einem neuen Pattern in Nutzer- oder A/B-Tests geschlagen wird.
3. Ein Pattern darf auch ersetzt werden, wenn eine andere Lösung zum Standard im Markt wird.

Eine Ausnahme bildet die Frühphase der Entwicklung eines neuen Produkts, insbesondere bei agiler Vorgehensweise, oder ein grundlegendes Redesign. Hier sind Patterns in der Regel noch unstabil und müssen häufig für neue Einsatzorte angepasst werden. Eine stabile Pattern Library ist in solchen Phasen nicht zu erwarten und ein zu frühes fixieren der Patterns ist in der Regel auch nicht hilfreich.

Auch später ist es nicht wünschenswert, dass eine Pattern Library zu stabil wird, da man sonst irgendwann ein Produkt mit veraltetem Interaktions- und Visual Design hat. Der wirklich konsequente Einsatz von Patterns birgt zudem die Gefahr, dass man vor lauter Konsistenz den Nutzerkontext aus dem Auge verliert und möglicherweise an einem spezifischen Ort eine deutlich bessere Lösung verpasst. (Also bitte nicht in diese sprichwörtliche Situation kommen: „Wer nur einen Hammer hat, für den sieht jedes Problem wie ein Nagel aus.“)

Consistent interfaces rule? "Nonsense! Different contexts demand different interfaces." Even on same device.—@wasbuxton #fowd

— Josh Clark (@bigmediumjosh) May 16, 2012

Das Ziel sollte daher eine langsame aber kontinuierliche Evolution der Patterns sein. Dafür ist es wichtig, in regelmäßigen Abständen die bestehenden Patterns in Frage zu stellen und immer wieder mit neuen Lösungen zu experimentieren.

Eine gute Balance aus Stabilität und Fortschritt zu finden, ist nicht einfach und kann auch von Produkt zu Produkt und Organisation zu Organisation sehr unterschiedlich ausfallen. Ein Grundmaß an Disziplin im Umgang mit den Patterns ist nötig, die Pattern Library darf aber nicht zu einem unüberwindbaren Gesetzbuch werden und jede Art von Weiterentwicklung blockieren. Mir gefällt daher die folgende Metapher von Lucas Pettinati (UX Lead, Google Apps) sehr gut:

„A pattern library is like a compass. It’ll tell you what direction you should go in, but it’s up to you to figure out how to get there.“

Eine gute Pattern Library ist ein Kompass und keine orthodoxe Religion.

Prinzip 6: Ein flexibles Naming Schema

Um den Rahmen an dieser Stelle nicht vollends zu sprengen, möchte ich dem sechsten und letzen Prinzip, dem Naming Schema, einen eigenen Artikel widmen.

Wer trotzdem jetzt und sofort mehr wissen will, dem möchte ich die Folien meiner Pattern-Vorträge vom UXCampEurope 2014 und vom UX-Roundtable Hamburg ans Herz legen. 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.

Zum vierten Teil →

Weitere Artikel aus dieser Serie:

• Teil 1: Warum braucht man eigentlich eine Pattern Library
• Teil 2: Auf der Suche nach der perfekten Pattern Library
• Teil 3: Prinzipien für eine Lean Pattern Library
• Teil 4: Ein flexibles Naming Schema für Patterns
• Teil 5: Patterns & Responsive Design
• Teil 6: Pattern Libraries aus Entwickler-Sicht (Gastbeitrag)
• Teil 7: Pattern Libraries für Agenturen und kleine Teams und andere Beispiele