Design Systems 101 – Teil 1: Warum braucht man 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. Insbesondere große Produktteams können mit einer Design Pattern Library bzw. einem Design System 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 fünf Jahren bei OTTO eine sehr leistungsstarke Pattern Library entstanden ist, die zum Erfolg des Produkts otto.de nachhaltig beträgt.

Als erster Teil, wird dieser Artikel vor allem auf die Grundlagen eingehen: Wie entstehen inkonsistente Produkt-Erlebnisse, wie kann eine Pattern Library helfen dieses Problem zu vermeiden und was ist überhaupt ein Design Pattern?

Diese Artikelserie ist ursprünglich 2014 unter dem Titel „Bauanleitung für eine Pattern Library“ erschienen und leider nach dem vierten Teil eingeschlafen. Da die Artikel der Serie zu den beliebtesten Beiträgen auf produktbezogen gehören und das Thema immer noch hoch relevant ist, habe ich den 5. Geburtstag der OTTO-Pattern-Library zum Anlass genommen, die Serie grundlegend zu überarbeiten, neu zu publizieren und mit weiteren Artikeln zu ergänzen.

Als ich Ende 2011 im eCommerce-Bereich von OTTO als Interaction Designer angeheuert habe, nahm dort das Projekt „Lhotse“ fahrt auf. In diesem wurde die vorher genutzte Intershop-Lösung durch eine komplett inhouse entwickelte Plattform für otto.de ersetzt. Das Mammutprojekt wurde im Oktober 2013 erfolgreich gelaunched und bedeutete neben einer modernen Architektur auch den 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 selbst dann wird das Design ohne Unterstützung nicht automatisch konsistent. Besonders gilt das für große Produkte mit vielen Produktteams: Von Beginn des Lhotse-Projekts arbeiteten drei agile Teams an Nutzer-Features. Mittlerweile sind es zwölf Teams und damals wie heute sollen diese Teams möglichst unabhängig voneinander ihr Teilprodukt discovern, gestalten und entwickeln. Da sich damals schnell wieder neue Inkonsistenzen zeigten, bekam ich nach einigen Monaten den Auftrag, eine Pattern Library zu konzipieren. Zur Seite gestellt bekam ich dafür einen Frontend-Entwickler und meine heutige Co-Autorin Inken, 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 Intershop-Plattform. 2012 konnte ich insgesamt acht Varianten ausmachen. Jede mit abweichendem Design, Informationsgehalt, Interaktionen und Animationen.

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 Produkt-Organisation wird, je mehr Produktmanager, Designer und Entwickler parallel arbeiten, desto kurzfristiger können solche unerwünschten Folgen auftreten.

So ist OTTO natürlich kein Einzelfall: Mariah Muscato von HubSpot zeigt in ihrem Artikel „How building a design system empowers your team to focus on people — not pixels.“, wie viele verschiedene Button-Varianten ihr Design-Team bei einem Assessment der Seite gefunden hat:

 

Dass so viele digitale Produkte Probleme mit diesem Wildwuchs haben, hat vier 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.

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 kürzester Zeit haben wir uns so ein inkonsistentes 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 Produkt-Team 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: Zu wenig 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 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 in Teams und Organisationen, wo Designer und Entwickler sich überhaupt nicht austauschen und das Briefing einfach nur „über den Zaun geworfen wird“.

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. Der Entwickler 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: Denken in Seiten

Insbesondere die Grundstruktur des Webs mit seinen Seiten hat dazu geführt, dass viele Designer und Entwickler auch heute noch in unabhängigen Seiten denken. Wer einen Webshop baut, denkt vielleicht als erstes daran, dass er eine Startseite, eine Produktliste, eine Detailseite und einen Warenkorb benötigt.

Wer in Seiten und nicht in Nutzerzielen oder Funktionen denkt, übersieht, dass einzelne Komponenten auf mehreren Seiten bzw. über mehrere Seiten hinweg funktionieren könnten und baut unabhängige und damit inkonsistente Lösungen. Das passiert um so mehr, wenn die Verantwortung für einzelne Seiten bei unterschiedlichen Designern oder Team liegen.

Problem 4: Mehrfache Arbeit

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

Dieses Problem führt zwar nicht zu inkonsistentem Design aber kostet viel Zeit durch doppelte Gestaltung, Entwicklung und QA und führt zudem zu redundantem Code. Die Produktentwicklung wird weniger Effizient und die Lade-Performance des Produkts nimmt ab.

 

An diesen vier Problemen wird schnell deutlich, dass ohne eine Pattern Library oder Design System 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 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:

Bild von Max Braun (Lizenz: CC BY-SA 2.0)

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.

Christopher Alexander definiert ein Pattern in seinem Buch folgendermaßen:

Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
— Christopher Alexander

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

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.

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.

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 hat schon vor etlichen Jahren Jared Spool ein Pattern folgendermaßen definiert:

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

Neben unserem Button bieten sich unzählige Aspekte eines Produkts an, als Pattern definiert und dokumentiert zu werden. Seien es kleine Elemente, wie Checkboxen und Headlines, ganze Komponenten wie Produktkinos, komplette Seiten-Templates oder abstraktere Patterns wie Verhalten, Formulierungen, Animationen oder das Dialogverhalten eines Chatbots oder Voice-Assistenten. Im dritten Teil der Serie werde ich darauf eingehen, wie sich Patterns identifizieren und strukturieren lassen.

Vorteile des Einsatzes von Patterns, Pattern Libraries und Design Systemen

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 nachhaltig: Im Gensatz zu „Irgendwas was irgendein Designer irgendwann gebaut hat“ sind Patterns zentral dokumentiert und haben bestenfalls einen „Owner“. Sie bekommen so kontinuierlich Aufmerksamkeit und können somit regelmäßig überprüft, angepasst, weiterentwickelt und irgendwann auch in den Ruhestand geschickt werden. Oder wie Paul Saffo so passend forderte: „It used to be that designers made an object and walked away. Today the emphasis must shift to designing the entire life cycle.“
  3. 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.
  4. 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 und ein gemeinsames Vokabular. 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.
  5. 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.
  6. 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 Produkten viel beherrschbarer.
  7. 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.

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

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.

Styleguide, Pattern Library, Design System??? Wie heißt das Ding nun?

Es herrscht einiges an Verwirrung über die korrekte Benennung von Pattern-Sammlungen. An machen Stellen werden zum Beispiel die Begriffe Styleguide oder Component Library synonym zu Pattern Library verwendet und seit etwa zwei Jahren ist der Begriff Design System auf dem Vormarsch.

Zu den unterschiedlichen Bezeichnungen habe ich mich bereits im letzten Jahr in meinem Let’s Talk Patterns Interview mit Peter Boersma unterhalten:

Style guides are are traditionally made with a focus on visual design aspects. […] Pattern Libraries are, at the core, “just” a format for documenting patterns. But when done well, it is a very powerful format that can be expanded infinitely, and can exists of many layers, each focusing on other details of a solution, ranging from the business reasons, via the functional layers, to the front-end or even back-end code. […] Design Systems are supposed to combine all of the above. And they’re supposed to cover all of a companies’ product and service touchpoints. […]— Peter Boersma

Und Nathan Curtis formuliert in seinem Artikel „A Design System isn’t a Project. It’s a Product, Serving Products.“ die folgende Unterscheidung:

A style guide is an artifact of design process. A design system is a living, funded product with a roadmap and backlog, serving an ecosystem.
— Nathan Curtis

Zusammenfassend würde ich für mich die folgende Unterscheidung machen:

  • Ein Styleguide ist ein statisches und abgeschlossenes Dokument, welches z.B. als Deliverable eine Agentur oder Manifest eines Unternehmens vornehmlich Aspekte des Visual Designs definiert. Der Styleguide ist damit eng verwand mit dem Corporate Design Manual, ist verglichen mit diesem aber in der Regel detaillierter und auf ein oder mehrere spezielle Produkte fokussiert.
  • Die vor allem vor 10-15 Jahren vorherrschende Form der Pattern Library nenne ich „traditionelle“ Pattern Library. Diese ebenfalls ein (relativ) statisches Dokument, welches Lösungsstrategien für Designprobleme abstrakt, also ohne direkten Produktbezug, dokumentiert. Ein gutes Beispiel dafür ist die Welie-Library.
  • Eine Pattern Library ist ein dynamisches Verzeichnis von Interaktions-Patterns, Styles und ggf. Code-Snippets mit direktem Produktbezug. Die Inhalte verändern sich analog zur Evolution des Produkts und sind im Idealfall direkt in der Library erlebbar. Der richtige Einsatz der Patterns wird über fachliche und technische Dokumentation sichergestellt.
  • Ein Living Styleguide enthält die gleichen Elemente wie ein Styleguide. Er ist aber ein dynamisches Dokument, welches sich analog zum Produkt weiterentwickelt und ggf. sogar direkt aus dem Produktcode generiert wird. Der Fokus ist in der Regel weiterhin auf das Visual Design, die Grenzen zu einer Pattern Library sind aber fließend.
  • Ebenfalls nah an der Pattern Library ist die Component Library. Oft wird der Begriff Synonym verwndet, ich würde aber zur Abgrenzung die Component Library als „grobe“ Pattern-Library sehen. Sie dokumentiert keine Atome oder Fragmente sondern nur in sich geschlossene Funktions- und Inhaltsblöcke aus denen dann Seiten oder Screens zusammengesetzt werden.
  • Im Gegensatz zu den Styleguides und Libraries sind Design Systeme die umfassendsten und komplexesten Gebilde. Ihr Ziel ist es, das Design von mehreren Produkten und auf mehreren Plattformen (auch nicht-digitalen) zu harmonisieren und gleichzeitig Alignment innerhalb von großen und ggf. verteilten Design-Organisationen herzustellen. Design Systeme bestehen aus einer oder mehrere Pattern Libraries ergänzt durch Design Prinzipien, Guidelines, Entscheidungsbäume, Prozesse, Vorlagen und vielem mehr.

Eine schnelle Umfrage über unseren Twitter-Account zum Thema Patterns @TalkingPatterns zeigt, dass der Begriff „Pattern Library“ auf jeden Fall noch am geläufigsten ist:

Beispiele für Pattern Libraries und Design Systeme

Um zum Abschluss dieses Artikels von der Theorie einen kleinen Sprung zur Praxis zu wagen, habe ich nachfolgend drei schöne Beispiele für öffentliche Libraries ausgewählt:

Lightning Design System
Das Lightning Design System von Salesforce ist sicher der Posterboy der letzten Jahre. Und das zu recht. Sehr strukturiert und sehr ausführlich wird hier alles von Design-Prinzipien und Guidelines bis zu den Grundelementen der Gestaltung, Patterns und Komponenten für eine komplexe Produktfamilie dargestellt und erklärt. → lightningdesignsystem.com
Mailchimp Pattern Library
Mailchimp hat nicht nur ein Produkt mit liebevoll gestalteter User Experience. Ähnlich viel Liebe zum Detail ist in die Pattern Library des Mailchimp UX Teams geflossen. → ux.mailchimp.com/patterns
otto.de Pattern Library
Natürlich soll an dieser Stelle unsere eigene Pattern Library nicht fehlen. In den folgenden Artikeln werden ich genauer auf Konzept und Struktur unserer Library eingehen. → patterns.otto.de

Mehr schöne Beispiele werde ich im letzten Teil der Serie verlinken. Im Netz findet ihr mit Adele und styleguides.io zwei umfangreiche Sammlungen öffentlicher Pattern Libraries und Design Systeme.

Gibt es auch Situationen in denen man keine Pattern Library braucht?

Die gibt es tatsächlich. In folgenden Situationen bringt einen ein Design System oder eine Pattern Library (noch) nicht weiter oder behindert sogar das Arbeiten:

  • Das Produkt besteht (fast) nur aus einem einzigen Screen: Bei One Pagern und anderen, sehr überschaubaren Produkten ist die Pattern Library die Seite selbst. Zusätzlich eine Dokumentation anzulegen, ist hier definitiv Overkill.
  • Das Produkt ist in einem sehr frühen Stadium: Sollten sich Produkt und UI noch stark im Fluss befinden, kostet der Aufbau und die ständige Anpassung einer Pattern Library unnötig Zeit, die besser zur Erkenntnisgenerierung und Weiterentwicklung genutzt werden sollte. Schlimmer noch kann ein zu frühes Festschreiben von Optik oder Interaktionen als Patterns nötige Evolutionssprünge verhindern. (Als UX-Designer kann man hier trotzdem „lean“ starten und entwickelte Elemente und Komponenten in einer gesonderten Datei des bevorzugten Design-Programms sammeln.)
  • Sehr kurzlebige Produkte: Landing Pages für Marketing-Kampagnen sind oft stark individualisiert und dazu sehr kurzlebig. Damit helfen einem Patterns weder bei der aktiven noch bei der als nächstes entwickelten Seite wirklich weiter.

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 Patterns identifiziert, 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 →

Alle Artikel der Serie Design Systems 101

 

 

Dazu gibt es noch einige weitere Interviews und Artikel zum Thema Patterns auf unserem Blog:

Und für noch mehr Material zum Thema, folgt doch einfach unserem Account @TalkingPatterns auf Twitter.

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

6 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

  4. Daniel

    Vielen Dank & Super Posting. Muss mich gerade in Pattern Libraries einarbeiten. War eine gute Starthilfe!

  5. Peter Boersma

    Lovely series, Wolf! I’m forwarding parts to pattern library friends.

    Quick fix: The link „Zum zweiten Teil“ at the bottom, actually goes to part 4.

  6. Wolf Brüning Artikelautor

    Hey Peter, glad you liked it und thanks for forwarding. Hope you’ll like the rest that is coming.

    And thanks for pointing out the misguided link. Darn you, copy & paste!

Schreibe einen Kommentar

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