Warum unsere Pattern Library kein Atomic Design mehr benutzt

tl;dr Wenn ihr eine Pattern Library bauen wollt, guckt euch Alla Kholmatovas Design Systems an

Seit 2015 bauen wir unsere Webseiten mit einer Pattern Library (PL). Eine Pattern Library kann man sich wie einen Homepage-Baukasten vorstellen: Wenn wir eine neue Webseite erstellen, brauchen wir nicht mehr über deren Design nachzudenken. Wir wählen aus vorgefertigten Elemente, die wir „nur noch“ mit Texten und Bildern befüllen brauchen.

Das hat folgende Vorteile für uns:

1. Es geht unglaublich schnell. Wir brauchen eher 2 Stunden für eine neue Webseite statt 3 Tage.
2. Die neue Seite sieht trotzdem gut und „sipgate-ig“ aus.
3. Es gibt einen einheitlichen Style – über verschiedene Produkt-Webseiten hinweg.

Hier möchten wir euch erzählen, warum unsere neue Pattern Lib, inspiriert von Alla Kholmatovas Design Systems, für uns besser funktioniert als die alte, basierend auf Brad Frosts Atomic Design.

Aber gehen wir kurz nochmal einen Schritt zurück.

Was ist Atomic Design?

Ich zitiere mal aus einem Artikel meines Kollegen Wolf aus der Anfangszeit unserer Pattern Library:

[Bei Atomic Design] 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. Faustregel: Atome lassen sich durch ein einzelnes HTML-Tag abbilden. Beispiel: <button>, <input>, …

Moleküle

Moleküle sind Kombinationen aus mehreren Atomen, die zusammen einen gewissen Zweck erfüllen. Beispiel: Die drei Atome Label, Input-Feld und Button kombiniert zu einer Newsletter-Anmeldung.

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. Beispiel: Standard-Header mit Logo, Navigation und Login-Formular.

Templates

Ganze Seiten-Vorlagen können als Template in der Pattern Library abgelegt werden. Beispiel: Grundlegende Seitenlayouts mit Header, Sidebar, Content-Bereich und Footer; Seitentypen, wie Startseite, Preise-Seite, …

So weit so gut. Klingt schön strukturiert oder? Dachten wir auch. Darum haben wir Brad Frost für einen Workshop angeheuert und unsere Pattern Library nach Atomic Design Prinzipien aufgebaut. Wir dachten, dass die Baukasten-Elemente uns erlauben würden schnell neue Seiten zu bauen und Änderungen an Elementen einfach auf unsere verschiedenen Produkt-Webseiten auszurollen. Das ist leider in und an der Realität gescheitert.

Update: Mein Kollege Michael hat damals Brad Frost zu Atomic Design interviewt.

Warum hat Atomic Design für uns nicht funktioniert?

Wir waren ein bisschen zu strikt mit der Trennung der Elemente und hatten den falschen Fokus. Anstatt, dass unsere Designer sich eine visuelle Hierarchie überlegen, haben unsere Entwickler eine Elemente-Hierarchie im Source-Code abgebildet:

Wir haben Twig als Template Engine benutzt. Darin haben Moleküle Atome referenziert, Organismen Moleküle und so weiter. Am Ende hatten wir eine riesige Kette von Abhängigkeiten. In manchen Fällen ist das sogar gewünscht: Wenn Du den grundlegenden Style eines Button änderst, soll sich das Aussehen aller dieser Buttons verändern. In anderen Fällen ist das furchtbar: Wenn Du etwas an einem Date-Picker veränderst, willst Du keine Nebenwirkungen auf andere Elemente. Doch bei unserer Hierarchie war nicht mehr nachvollziehbar wo ein Pattern referenziert wurde. Für Atome hat es super funktioniert. Für alles darüber nicht.

Mit der Zeit wurde die Hierarchie in Twig so komplex, dass UX Designer nichts mehr daran gemacht haben. Nur noch Entwickler trauten sich, etwas an den Patterns zu ändern. Es wurde zu einem Tool von Entwicklern für Entwickler, anstatt mehr Leute einzubinden. Wer nicht gewohnt war, in OOP-Konzepten zu denken, der hatte Pech gehabt.

Letztlich wurde der Pattern Lib ihr eigener Erfolg zum Verhängnis: Mehrere Teams fingen an damit zu arbeiten und plötzlich wurden die existierenden Patterns immer komplizierter. Refactoring war kaum möglich, zu groß war die Angst etwas ganz woanders kaputt zu machen. Also haben wir das vermieden und haben nur neue Optionen in vorhandene Patterns eingebaut. Überraschung, dadurch wurde Refactoring noch schwerer. Am Ende konnte die man die Patterns nicht nur nicht mehr weiterentwicklern, sondern auch als Endanwender, sprich Webseiten-Bauer, kaum noch verwenden, weil man bei den Optionen nicht mehr durchblickte.

Die UXer dachten wenig in Patterns. Die Entwickler versuchten, Photoshop-Designs in Patterns zu pressen. Und im Zweifelsfall baute man einfach ein neues Pattern.

Am Ende sah man den Wald vor lauter Bäumen nicht mehr. Die sogenannte Übersichtsseite war sau-unübersichtlich. Und weil man das passende Pattern im Wust nicht finden konnte, hat man kurzerhand ein neues gebaut. #truestory

Im Nachhinein ist unsere erste Pattern Lib an folgenden Punkten gescheitert:

• Es gab keinen Style Guide, der alle Produkte verbunden hätte.
• Es war eine Abhängigkeitshölle.
• Nur Entwickler konnten bauen und deployen.
• Der Fokus lag auf dem Aussehen der Patterns.

Was wir heute anders machen würden:

• Mehr Kommunikation mit allen Teams
• Festlegen, wer die PL „owned“ und bei Entscheidungen hilft.
• Mehr Selbstverantwortung, damit alle ihre eigene Kreativität zähmen, wenn das dem Gesamtdesign der PL dient.
• Viel weniger Abhängigkeiten einbauen

Auf halbem Weg zur neuen PL ist uns aufgefallen, dass man nicht nur eine PL will, sondern auch eine Content Strategie, um die Elemente mit guten Inhalten zu füllen.

Und jetzt? Design Systems!

Im April 2016 wurde Mathias auf die Arbeit von Alla Kholmatova aufmerksam.

“A design system is not only about the elements –
it’s the purpose and connections that hold it together.”
~ Alla Kholmatova

Auch mit Alla Kholmatova haben wir einen Workshop gemacht und seitdem konzentrieren wir uns bei jedem Pattern auf seinen Zweck. Dadurch denken wir automatisch auch über den Zweck einer Seite und ihren Mehrwert für Leser / Kunden nach. Wenn wir den Zweck einer Seite klar haben, ist es leicht die Patterns auszuwählen, die diesen Zweck unterstützen.

Wenn wir bis ins Jahr 2010 zurückblicken, sieht unsere Entwicklung im Web-Design in etwa aus: Desktop first -> Mobile first -> Content first -> Purpose first. Also von “Sieht das gut aus?” hin zu “Erfüllt das Pattern seinen Zweck?” Dadurch verschiebt sich die Diskussion von „Welches Blau sollen wir nehmen?“ über „Ist dieses Pattern ein Molekül oder ein Organismus?“ zu „Was trägt dieses Element zur Seite bei? Schafft das Wert?“

Um mal Beispiele zu geben, wir haben Patterns für folgende Zwecke: USPs aufzählen, Vertrauen erhöhen, Navigation, Content anteasern und viele andere.

Es gibt keine Pattern-Hierarchie mehr. Sie sind alle auf der Ebene von Atomic Design „Organismen“. Sie nehmen alle die ganze Seitenbreite ein und kein Pattern kann mehr ein anderes enthalten. Dadurch gibt es keine unübersichtlichen Abhängigkeiten mehr.

Es gibt ein paar wenige Core-Atome wie Buttons, die schön gestylt sind, damit man über das Aussehen von Buttons oder simplen Tabellen nie mehr nachdenken muss. Benutz sie und sie sehen gut aus. Fertig.

Auch unsere Dokumentation ist besser geworden. Weg von „Wie binde ich das in Twig / PHP ein?“ zu „Was ist der Zweck dieses Patterns? Was muss ich beachten, z. B. maximale Textlänge, Bildgröße, ..?“. Wie es aussieht, ist nachrangig, weil darüber ja schon die Leute nachgedacht haben, die das Pattern erstellt haben.

Wir bauen bewusst nur wenige Optionen in Pattern aus. Wir wollen keine großen visuellen Variationen innerhalb eines Patterns, damit es berechenbar und testbar bleibt. Konkret ist z. B. eine Überschrift oft optional, aber Padding und Farben sind fix.

Durch stärker getrennte Patterns ist transparent, was wo benutzt wird. So können wir refactoren, weiterentwickeln und einstampfen.

Am Coolsten wäre natürlich jeweils ein Pattern pro Zweck zu haben. Das klappt nicht immer, weil wir manchmal den gleichen Zweck unterschiedlich prominent / intensiv erreichen wollen. Manchmal muss der Teaser „ballern“, weil es der Hauptzweck der Seite ist, dass jemand den Teaser klickt. Manchmal ist der Teaser unter „ferner liefen“ und muss dezenter sein.

Dezenter Teaser für weiteren Content

Großer Teaser, der eine Entscheidung erzwingt

Wenn es ein Pattern noch nicht gibt, meldet man sich bei Team Krk. Meistens findet man dann doch ein passendes Pattern. Wenn nicht, baut Team Krk es.

Wie bauen wir Webseiten mit der neuen Pattern Lib?

Wir zeigen die Patterns an einer Wand, für jeden sichtbar. Zuerst ausgedruckt auf je einem Din A4-Zettel, inzwischen haben wir für jedes Pattern einen Magneten. Mit diesen Tools machen wir Wireframing-Sessions und fragen uns für jede Seite: Was ist der Zweck? Welche Informationen müssen drauf, damit die Seite diesen Zweck erfüllt? Jedes Pattern, dass ich verwenden will, muss auf diesen Zweck einzahlen.

Sobald wir uns auf ein Grundgerüst geeinigt haben, checken wir noch:

• Gibt es einen roten Faden? Ist der Gesamtzusammenhang klar?
• Beantworten wir die W-Fragen? Die W-Fragen sind je nach Seite unterschiedlich:
  • Portierung -> Wie mach ich das denn jetzt?
  • Preise -> Was kostet der Spaß für mich?
  • Startseite -> Worum geht’s? Was ist das Produkt? Warum will ich das?

Zusammen mit der neuen Pattern Library sind wir weg von Twig und hin zu WordPress. Dadurch kann jeder bei sipgate die Patterns verwenden und schnell Webseiten bauen. Ein Riesenfortschritt!

Unsere neue Pattern Library findet ihr hier: https://design.sipgateteam.de/

Update 27.6.2018:
Mein Kollege Mathias (von dem auch der Input zu diesem Artikel stammt) hat einen Vortrag bei den WebWorkern NRW zu diesem Thema gehalten: