+++ ACHTUNG: Dieser Artikel ist veraltet +++
Wir haben unsere Pattern Library seit der Veröffentlichung dieses Artikels konsequent weiterentwickelt und dabei wahnsinnig viel gelernt. Einige Empfehlungen in diesem Artikel würden wir heute nicht mehr aussprechen. So haben wir uns z.B. mittlerweile von Atomic Design verabschiedet und verfolgen stattdessen den “Purpose-first”-Ansatz, bei dem der Zweck der Patterns im Vordergrund steht.
Lest mehr darüber im sipgate Blog: Warum unsere Pattern Library kein Atomic Design mehr benutzt
Es folgt der ursprüngliche Artikel.
Wir haben eine Pattern Library für all unsere Produktseiten gebaut. Hier sind unsere Take-aways:
(Der Erfahrungsbericht folgt weiter unten)
14 Dinge, die du tun solltest, wenn du eine Pattern Library baust:
- Gemeinsames Verständnis entwickeln
Für die Akzeptanz einer Pattern Library im Unternehmen ist es super wichtig, dass alle Beteiligten wissen, was du mit ihr erreichen willst und wie die konkrete Umsetzung aussehen soll. - Verschiedene Rollen einbeziehen
Die Pattern Library ist ein Tool für alle im Team, z. B. POs, Entwickler, UXer, Designer und Texter. Deshalb solltest du auch all diese Rollen so früh wie möglich einbeziehen. Das verbessert die Qualität und fördert die Nutzung der Pattern Library. - Den Einstieg einfach halten
Zum ersten Mal mit der Pattern Library zu arbeiten muss einfacher sein, als selber eine neue Seite ohne Library zu bauen. Gerade Nicht-Entwickler, wie Designer oder Texter, sollten auch mit der Library arbeiten können. - Jedes Pattern in die Library packen
Alle sollen von neuen Patterns profitieren können: Kunden und Kollegen. Es ist total kontraproduktiv, Verbesserungen für sich zu behalten und sein Wissen zu horten. - Patterns dokumentieren
Es macht total Sinn, Patterns in der Library zu dokumentieren. Dazu gehören z. B. auch Parameter, die an das Template übergeben werden können. Das hilft Leuten, die keinen Zugriff auf den Code haben, zu verstehen, was möglich ist. - Patterns mit optionalen Parametern erweitern
Manchmal wirst du vor der Frage stehen, ob du ein bestehendes Pattern erweitern oder besser eine neues Pattern anlegen sollst. Beide Optionen sind denkbar. Optionale Parameter im Template können helfen, Patterns zu erweitern, ohne dass sich diese Änderungen auf bestehende Implementierungen auswirken. Wenn’s zu komplex wird, bist du mit einem neuen Design Pattern oft besser dran. - Disruption zulassen
Design hat immer auch was mit Zeitgeist zu tun. Damit sich dein Design weiterentwickeln kann, ist es wichtig, dass jeder neue Patterns entwickeln kann und bei der individuellen Gestaltung nicht eingeschränkt ist. Neue, bessere Patterns können so ältere ersetzen. - Aktuelle Technologien verwenden
Deine Pattern Library sollte auch technisch so flexibel sein, dass du immer mit der Zeit gehen kannst. Sonst musst du in ein paar Jahren wieder von vorne anfangen. Falls du mit einem Framework wie Bootstrap arbeitest, achte darauf, dass Updates möglich sind und du regelmäßig welche machst. - Wissen, wo welches Pattern verwendet wird
Wir haben einen kleinen Crawler gebaut, der regelmäßig checkt, wo welches Pattern verwendet wird. Solltest du auch machen. So kannst du bei Änderungen an Patterns direkt checken, ob noch alles funktioniert. Außerdem kannst du nicht benutzte Patterns erkennen und ggf. verbessern oder aus der Library schmeißen. - Genug Platz für die Darstellung der Patterns einplanen
Wir haben in unserer Pattern Library eine Sidebar für die Navigation innerhalb der Library. Das ist deshalb ungünstig, weil wir Patterns, die über Vollbreite gehen, nicht sinnvoll darstellen können. Das kannst du besser — z. B. mit einem Off-Canvas-Menü oder einer horizontalen Navigation im Header. - Individuelles CSS für jedes Pattern vorsehen
Wenn du ein Pattern für mehrere Projekte verwenden willst, musst du darauf achten, dass du bei der Gestaltung flexibel bleibst. Wir haben für jedes Pattern ein Fallback-CSS, das das grundlegende Design festlegt. Bei der Implementierung im Projekt kann man dieses Design dann aber mit seinen eigenen Styles überschreiben. Solltest du definitiv auch machen. - Pattern Library als Wissensdatenbank nutzen
Neben den Design Patterns solltest du alles, was man braucht, um eine Webseite zu bauen, in der Pattern Library dokumentieren. Das können z.B. Brand Guidelines, Coding Conventions oder Anleitungen für die Einrichtung einer lokalen Entwicklungsumgebung sein. So hast du alles an einer Stelle. - Die Pattern Library öffentlich machen
Klingt vielleicht komisch, bringt aber total viel. Einerseits sorgt eine gute Sichtbarkeit für Motivation und damit bessere Qualität. Wer will schon mit etwas an die Öffentlichkeit gehen, von dem man nicht überzeugt ist? Andererseits ist so eine Pattern Library auch eine super Gelegenheit, neue, interessierte Kollegen zu finden. Willst du bei uns arbeiten? - Für eine gute User Experience sorgen
Genauso wichtig wie die Struktur ist auch die visuelle Gestaltung der Pattern Library. Ausreichend Whitespace, gute Lesbarkeit und die Verwendung von Illustrationen, Icons und Videos sorgen dafür, dass die Arbeit mit der Pattern Library Spaß macht.
4 Fehler, die du vermeiden solltest, wenn du eine Pattern Library baust:
- Für jedes Projekt eine eigene Pattern Library aufsetzen
Design Patterns sind nicht an ein bestimmtes Projekt oder eine Seite gebunden. Im Gegenteil: Der größte Wert einer Pattern Library liegt in der Wiederverwendbarkeit der Design Patterns. Deswegen macht es absolut keinen Sinn, für jedes Projekt eine eigene Library zu erstellen. - Die Pattern Library mit Patterns zumüllen, die niemand braucht
Halte Deine Pattern Library sauber. Schau regelmäßig drüber. Bestimme Paten, die die Verantwortung dafür übernehmen. Halte nicht an ungenutzten Patterns fest, nur weil es Zeit gekostet hat, sie zu bauen. Schmeiß sie raus oder verbessere sie, bis sie genutzt werden. Sonst findest du nachher nichts mehr wieder. - Design Patterns nach ihrem Zweck benennen
Du solltest deine Design Patterns nach ihrer Form benennen und nicht nach ihrem Zweck. Das mag erstmal verwirrend klingen, denn das ist das Gegenteil von dem, was man macht, wenn man CSS-Klassen benennt. Das macht aber deshalb Sinn, weil der Zweck durch das Design Pattern nicht vorgegeben wird. Ob ich z. B. ein Icon mit Headline und Text auf einer Webseite als USP oder als Testimonial verwende, gibt das Pattern nicht vor. “Icon mit Headline und Text” ist deshalb auf jeden Fall ein besserer Name als “Testimonial mit Bild”. - Patterns nur im eigenen Projekt testen
Wenn die Pattern Library von mehreren Teams für unterschiedliche Projekte benutzt wird, ist es wichtig, dass du Änderungen an Patterns auch überall testest. Jedes Team sollte jedes Pattern für jedes Projekt nutzen können, ohne erst Bugs fixen zu müssen.
Wie wir zu unserer Pattern Library gekommen sind.
Wir bauen Webseiten seit 1998 und waren eigentlich auch ganz gut darin. In den letzten Jahren haben wir es aber irgendwie versäumt, am Ball zu bleiben. Viele unserer Produktseiten waren veraltet: inhaltlich, optisch und technisch.
Wir wollten unser Mischmasch aus unterschiedlichen Layouts, Produkten, Marken und neuen Ideen wieder unter einen Hut bringen. Und zwar nachhaltig. Und vor allem: bald! Wir hatten einiges aufzuholen.
Design Sprint
Um uns diesem Problem zu nähern, haben wir mit ein paar Leuten aus der UX-Community einen Design-Sprint eingeschoben. Nachdem wir ein gemeinsames Verständnis entwickelt hatten, skizzierten wir Lösungen, bauten einen Prototypen und luden Tester zu uns ins Büro ein.
Das Ergebnis der User-Tests: Naja. Unser Prototyp hat nicht so gut funktioniert, aber die Erkenntnisse, die wir gewonnen haben, waren super. Also haben wir noch eine Woche drangehängt und unsere neuen Erkenntnisse in einen weiteren Prototypen gegossen. Der nächste Test war viiiieeel besser und so konnten wir aus dem Prototypen etwas Vorzeigbares bauen: einen neuen, einheitlichen Header und Footer für alle unsere Produktportale. Kernaufgabe neben dem üblichen Kram wie Produktlogo, Navigation und Login war, den Absender sipgate kenntlich zu machen, auch wenn die Produktmarke eine andere war. Außerdem sollte der Wechsel zwischen unseren Produktportalen einfach möglich sein.
Uns war relativ schnell klar, dass es schwierig wird, den neuen Header und Footer überall einzubauen. Zum einen, weil es kein einheitliches Seitenlayout gab, zum anderen, weil wir für unsere Portale zwei unterschiedliche Web-Frameworks im Einsatz hatten. Wir entschieden uns, die Produktseite von simquadrat als Ausgangspunkt zu nehmen. Responsive Design mit Bootstrap und Twig — das Aktuellste, was wir hatten.
Blieb das Problem, dass wir alle unsere Seiten redesignen mussten, um sie responsive zu machen und optisch an den neuen Header und Footer anzupassen. Und da kam einiges zusammen: 8 Portale mit durchschnittlich 10–20 Unterseiten standen auf dem Prüfstand. Heilige Scheiße. Das ist viel.
Wir brauchen eine Pattern Library
Um es kurz zu machen: Wir haben erkannt, dass wir nicht alle Portale gleichzeitig umbauen können — und wollen. Aber auch wenn wir schrittweise vorgehen und mit nur einem Portal anfangen, brauchen wir eine Lösung, die für alle Seiten funktioniert und wiederverwendbar ist. Wir brauchen eine Pattern Library, in der wir wiederkehrende Design Patterns definieren und zur Wiederverwendung für alle Produktseiten ablegen können.
Wir hatten zwar auch vorher schon Design Patterns, die waren allerdings nirgends dokumentiert. Das Wissen über diese Patterns wurde, wenn überhaupt, nur mündlich weitergegeben. Wir hatten auch nur für wenige Patterns Templates. Wenn wir also ein Pattern wiederverwenden wollten, haben wir es kopiert. Oder neu gebaut. Kein Scherz. Aber das sollte sich jetzt ändern. Also nahmen sich drei Entwickler aus unserer DEV-Community einen Tag Zeit, um unsere Webplattform vorzubereiten. Parallel dazu hat sich unsere UX-Community Inspiration bei anderen geholt, z. B. bei Mailchimp und Buffer.
Atomic Design
Uns gefiel Brad Frosts “Atomic Design”-Ansatz. Hierbei werden Design Patterns je nach Komplexität in Atome, Moleküle, Organismen und Templates aufgeteilt.
Atome
Atome sind Kleinstelemente, wie Buttons, Input-Felder oder Labels. Als Faustregel gilt: Atome lassen sich durch ein einzelnes HTML-Tag abbilden. Im konkreten Beispiel also durch <button>, <input> und <label>.
Moleküle
Moleküle sind Kombinationen aus mehreren Atomen, die zusammen einen gewissen Zweck erfüllen. Die drei Atome Label, Input-Feld und Button können z. B. zu einer Newsletter-Anmeldung kombiniert werden. Dieses Formular wäre dann ein Molekül in der Pattern Library.
Organismen
Organismen können sich aus mehreren Molekülen und Atomen zusammensetzen. Oft erfüllen Organismen mehrere Zwecke auf einmal. Ein typisches Beispiel ist unser neuer Standard-Header mit Logo, Navigation und Login-Formular.
Templates
Ganze Seiten-Vorlagen können als Template in der Pattern Library abgelegt werden. Das bietet sich vor allem für das grundlegende Seitenlayout an. Also z. B. eine Seite bestehend aus Header, Sidebar, Content-Bereich und Footer. Natürlich können auch einzelne Seitentypen, wie Startseite, Pricing-Page, Legals, etc. standardisiert und als Template definiert werden.
Der Vorteil von Atomic Design liegt für uns in der klaren Struktur der Library. Außerdem vereinfacht die Einteilung in Atome, Moleküle, Organismen und Templates das Wiederverwenden von kleinen Patterns innerhalb anderer, größerer Design Patterns. Brad Frost stellt mit Pattern Lab sogar eigene Tools zur Verfügung, die bei der Erstellung einer Pattern Library helfen können. Wir haben uns aber gegen Pattern Lab und für eine eigene Umsetzung mit Bootstrap, SASS und Twig entschieden. Wir wollten, dass sich unsere Pattern Library technisch und optisch nahtlos in unsere Web-Plattform einfügt.
Die Umsetzung
Nachdem also verschiedene Leute hier einen Tag in Vorbereitungen und Recherche investiert hatten, konnten wir uns an die Umsetzung machen. Wir haben das Thema mit einem unserer Scrum-Teams gegroomt und ein Backlog erstellt.
Der Plan: die Pattern Library erstellen - inklusive aller Design Patterns für das erste Produktportal. Wir haben uns für den Start unser Business-Produkt sipgate trunking ausgesucht. Zu dem Zeitpunkt basierte die Seite noch auf einer alten Version von Zend-Framework und hatte ein Fixed-Width-Layout. Höchste Zeit, das zu ändern und gut zum Lernen, denn der Umfang war relativ überschaubar, und viele der Patterns konnten wir für andere Produkte weiterverwenden.
Eigentlich wollten wir das neue Trunking-Portal erst bauen, wenn die Pattern Library “fertig” ist. Wir wollten so rausfinden, wie schnell wir mit vorgefertigten Patterns ein neues Produktportal an den Start bringen können.
Während wir im Team dann aber so an der Pattern Library arbeiteten, stellten wir fest, dass die ganze Sache doch länger dauerte, als uns lieb war. Wir waren mittlerweile 6 Wochen dran. Die Pattern Library nahm zwar Gestalt an, aber unsere Kunden hatten da bisher noch nichts von. Also änderten wir die Taktik. Statt zu warten, bis wir das komplette Portal in der Library abgebildet hatten, gingen wir ab jetzt seitenweise vor. Zwei Wochen später konnten wir dann mit der neue Startseite live gehen. Die anderen Unterseiten shippten wir in den folgenden Wochen. Bei jeder Seite wurden wir ein bisschen schneller und die Pattern Library ein bisschen besser.
Soll ick jetzt den Knaller zünden?
Auch intern sorgten die neuen Seiten für Aufmerksamkeit und machten unsere Product Owner und Entwickler neugierig. Erste Devs checkten das GIT-Repository aus und fingen an, mit der Pattern Library zu experimentieren. Kurz darauf begannen die ersten Produkt-Teams, ihre Webseiten mit der Pattern Library umzubauen. Auch komplett neue Projekte, wie voipschool.de, wurden mit der Pattern Library umgesetzt. Und das quasi von alleine. Innerhalb von zwei Wochen gingen vier neue Seiten an den Start. Dafür hätten wir vorher Monate gebraucht. Oder wir hätten weiteren Wildwuchs erzeugt.
Eigentlich wollten wir die Pattern Library mit einem großen Knall releasen und allen zeigen, wie man damit arbeitet. Das war aber überhaupt nicht mehr nötig. Aufkommende Fragen haben wir im persönlichen Gespräch oder im Yammer geklärt. Weiteren Austausch gab es über unsere DEV-Community, die sich regelmäßig trifft.
Läuft bei uns?
Auch wenn wir uns alle gut fühlten mit der Pattern Library, wollten wir qualifiziertes Feedback von außen. Wir laden oft ExpertInnen zu uns ein, von denen wir etwas lernen können. Meistens gibt es dann intern einen 1–2 tägigen Workshop und abends noch ein offenes Meetup für alle, die das Thema interessiert.
So war es auch mit Brad Frost. Wir haben ihn Ende Mai zu uns nach Düsseldorf eingeladen. Er sprach auf unserem Lean UX DUS Meetup über Atomic Design und gab uns in einem zweitägigen Workshop wertvolles Feedback zu unserer Library.
Sieht dann nicht irgendwann alles gleich aus?
Einige befürchteten, eine Pattern Library könnte die Kreativität einschränken und würde dafür sorgen, dass alles gleich aussieht. Diese Angst konnten wir mit unserem neuen sipgate basic Portal ausräumen.
Trotzdem haben wir die Bedenken ernst genommen, denn wir wollen, dass sich unser Design weiterentwickelt. Jedes Team darf jederzeit neue Patterns entwickeln. Einzige Voraussetzung: Sie müssen so gut sein, dass alle Teams sie ohne große Anpassungen für ihre Projekte verwenden können.
Für jedes Pattern muss deshalb zuerst ein neutrales Fallback-CSS gebaut werden, welches das grundlegende Design festlegt. Dieses Design kann dann aber von jedem Team und für jedes Produkt individuell überschrieben werden, ohne den HTML-Code zu ändern. Parameter im Twig-Template sorgen dafür, dass auch die Inhalte, z. B. Texte oder Bilder, beliebig ausgetauscht werden können.
Wie geht’s weiter?
Brad gab uns einige Verbesserungsvorschläge mit auf den Weg, von denen wir schon einige umgesetzt haben. Zum Beispiel ist der Einstieg in die Pattern Library und die Arbeit damit für Nicht-Entwickler noch relativ schwer.
Auch war die Library noch nicht besonders hübsch. Das hat sich mittlerweile geändert. Wir haben ein bisschen Design-Liebe reingesteckt und die Falten rausgebügelt.
Außerdem kann man jetzt sehen, wo und wie oft jedes Pattern verwendet wird. So können wir die Library sauberhalten und nicht benutzte Patterns aussortieren. Gleichzeitig kann man bei Änderungen an Patterns direkt sehen, welche Seiten man sich angucken muss, um sicherzustellen, dass nichts kaputtgegangen ist.
Wir haben die Library mittlerweile sogar um unsere Brand Guidelines erweitert. Nach und nach soll unter sipgate.de/design alles zu finden sein, was man braucht, um eine sipgate Webseite zu bauen.
Der nächste große Schritt wird eine Pattern Library für unsere Web-Apps. Auch hier gibt es einiges zu verbessern. Da wir viele Telefonie-Produkte betreiben, die grundlegende Funktionen gemein haben, liegt es nahe, auch das Web-Interface zu vereinheitlichen. Warum sollte die Anrufliste in dem einen Produkt anders aussehen als in dem anderen?
So fresh, so lean!
Wir versuchen generell so lean wie möglich zu arbeiten. Da kam die Pattern Library als Standardisierungs-Tool natürlich wie gerufen. Sie ermöglicht uns unsere Webseiten kontinuierlich und inkrementell zu verbessern. Sie sorgt dafür, dass Wissen über Patterns nicht verloren geht und dass Änderungen an unseren Webseiten schnell an unsere Kunden geshippt werden können.
Sie hilft sogar dabei, Bottlenecks zu reduzieren, denn durch das Baukasten-Prinzip können sowohl Designer als auch Entwickler Webseiten bauen, ohne aufeinander warten zu müssen.
Neugierig geworden?
Unsere Pattern Library findest du auf sipgate.de/design. Möchtest du dich mit uns über das Thema austauschen? Komm zum Essen bei uns im Büro vorbei oder schreib mir über Twitter.
Wer jetzt sofort und ganz unverbindlich schon mal einen Blick hinter unsere Kulissen werfen will — here you go:
