Design System hoch 4 – ein neues Design System für LOTTO24

Ein gutes und funktionierendes Design System hat für die Produktentwicklung viele Vorteile. Zum Einen kann der Nutzer das Produkt besser bedienen, da das Design konsistent und durchdacht ist. Zum Anderen arbeiten die Produkt-Teams effizienter, da es eine gemeinsame Grundlage und Sprache gibt. Die Etablierung eines Design Systems ist aber vor Allem bei bestehenden Produkten nicht einfach, da das Design über die Jahre gewachsen und nicht mehr einheitlich sind. Eine gute Gelegenheit ist es das neue Design System im Zuge größerer Umbau-Arbeiten am Produkt einzuführen.  Bei LOTTO24 haben wir im UX-Team genau diesen Moment genutzt und innerhalb eines Jahres ein Design System für vier Lotto-Webshops entwickelt. Das Design System musste daher flexibel genug sein, um vier unterschiedliche Design Sprachen abbilden zu können. In diesem Artikel geben wir euch einen kurzen Einblick in die Herausforderungen, das Vorgehen und unsere wichtigsten Erkenntnisse.

Unsere Design System-Challenge

Zu LOTTO24 gehören vier verschiedene Lotto-Webshops (LOTTO24, Tipp24, WEB.DE Lotto, GMX Lotto). Mit diesen vier Webshops kann jeder Zielgruppe ein unterschiedliches Lotto-Erlebnis in einer anderen Markenwelt geboten werden.  Viele Funktionalitäten sind ähnlich, da die Anwendungsfälle dieselben sind (Lottoschein ausfüllen, Lottoschein kaufen etc.). 

Der Pflegeaufwand beim Betrieb von vier Lotto-Webshops ist natürlich groß. Ganz zu schweigen von der Komplexität für die Produkt-Teams diese weiterzuentwickeln und für die Kunden zu optimieren. Ohne das entsprechende “Gerüst” im Hintergrund ist das quasi nicht machbar. Deswegen wurde das Projekt “UNITY” initiiert. Hierbei ging es u.a. um eine Vereinheitlichung des technischen “Gerüstes” in Form einer Component Library, die von allen Webshops genutzt werden kann. Parallel zu dieser Component Library sollte ein neues Design System entwickelt werden.

Hier unsere Startvoraussetzungen für das Design System auf einen Blick:

• Ein Design System für vier unterschiedliche Lotto-Shops
• Möglichst viel vereinheitlichen, so dass eine Komponente (z.B. Login) bei allen vier Shops gleich funktioniert, aber anders aussieht
• Die Designsprache für alle vier Marken modernisieren
• Der Kunde soll dabei möglichst wenig große Änderungen mitbekommen, die sein gewohntes Nutzungsverhalten zu stark beeinträchtigen

Um bei so viel Komplexität nicht den Überblick und den Nutzerfokus zu verlieren, haben wir anfangs das Projekt in verdauliche Häppchen aufgeteilt. In diese Aufteilung haben vor Allem die Produktmanager viel Energie und Nerven gesteckt und das UX Team hat sich auf den Nutzer und das Design konzentriert. Das UX Team hat sich auf den Workflow im Design Team fokussiert und auf das Thema “Design-Entscheidungen”. So haben wir uns zu Beginn gemeinsam auf ein passendes Design Management-Vorgehen geeinigt.

Das Vorgehen

Bei so einem großen und teamübergreifenden Projekt sind von Anfang an viele Beteiligte einzubinden und zusammenhängende Arbeitspakete zu bearbeiten. Unser Vorgehen hat sich im Rückblick wirklich bewährt, deswegen hier die einzelnen Bestandteile im Überblick.

• UX Matrix und eigenes UX Board
  Zu Beginn haben wir erstmal eine “UX Matrix” in Excel erstellt. Das natürlich in der Online Version, damit alle darauf zugreifen konnten. Diese Matrix bildete alle Module ab, die wir für das Design System beachten müssen, den Status (z.B. Offen, Analyse, Mockup), das verantwortliche Team und die Seiten, auf denen die Module auftauchen.  In Jira haben wir dann alle UX Tasks in ein Backlog überführt. Im wöchentlichen Grooming haben wir die Tasks besprochen und uns im Daily dann täglich ausgetauscht. Das alles lief parallel zur Arbeit und den Dailys  in den dedizierten Produkt-Teams.
   
• Design Decision Meeting
  Es sind meist die Design-Entscheidungen, die den Projektfortschritt behindern oder im Nachhinein zu zeitraubenden Änderungen führen. Oft sind Stakeholder nicht ausreichend abgeholt worden oder die Designs funktionieren einfach nicht gut genug. Die Perspektive des Nutzers geht im hektischen Projektalltag leider auch verloren.. Um diesen Problemen von vornherein aus dem Weg zu gehen, haben wir gleich zum Start ein regelmäßiges “Design Decision Meeting” aufgesetzt. Die Runde bestand dabei nur aus den wichtigsten Beteiligten und wir haben sehr darauf geachtet, dass sie nicht zu groß wird.
  
  Im Meeting haben wir den Status Quo der Shops mit den möglichen neuen Varianten verglichen. Die Entscheidungskriterien waren die folgenden:
  • Vereinheitlichung: Sind die Komponenten ausreichend vereinheitlicht, so dass das Ganze nicht zu komplex wird und wartbar bleibt?
  • Nutzerakzeptanz: Ist die Änderung zu groß für den Nutzer und wird ihn vielleicht negativ beeinflussen?
  • Design-Qualität: Sind wir wirklich überzeugt von der Lösung als den besten Ansatz, den wir den Nutzer bieten können?
  • Daten: Gibt es Daten z.B. aus UX tests oder A/B Tests, die für eine der Varianten sprechen?
• Flexibler Axure Prototyp für das Testing
  Regelmäßige Tests waren bei diesem Projekt unabdingbar. Das wussten wir und haben frühzeitig einen Axure Prototyp für alle Viewports von Mobile bis Desktop aufgesetzt. Dieser Prototyp hat anfangs nur die Seitenstruktur und die Navigation abgebildet. Wir konnten dann vor den jeweiligen Tests schnell und einfach die passenden Inhalte im Prototypen ergänzen. Für komplexere Inhalte (z.B. die Lotto Spielscheine) haben wir richtigen Code von den Entwicklern eingebunden, damit der Test so real wie möglich ist.
   
• Design Libraries und Guidelines
  Wir haben von Anfang an die Design Guidelines und die entsprechenden Libraries gepflegt. Dabei waren die Grundelemente wie Farben, Buttons, Formulare, neue Seiten-Layouts etc. bereits angelegt. Das hatten wir im Zuge eines UX-Projektes zum Thema neue Designsprache und Navigation bereits erarbeitet. Ohne diese Vorarbeit wäre das Projekt in diesem Zeitrahmen schwierig umsetzbar gewesen. Die bestehenden Designs und Guidelines konnten wir einfach nutzen und für das neue Design System anwenden.

Die Arbeit des  UX-Teams fand während des gesamten Projektes sowohl in den dedizierten Produkt-Teams als auch mit den anderen UXlern an übergreifenden Themen wie der Vereinheitlichung statt. Diese parallelen Workstreams zu koordinieren und Verständnis dafür zu schaffen war nicht immer einfach. Umso wichtiger war es, dass wir uns ein gemeinsames Vorgehen für dieses Projekt gleich zum Start überlegt hatten.

Der Workflow im Design Team

Die Zusammenarbeit im UX Team war sehr intensiv und gut. Wir haben alle mit Sketch gearbeitet und dabei immer die aktuellsten übergreifenden Sketch Libraries genutzt. Dabei gab es für jede Marke bzw. jeden Shop eine eigene Library, aber mit der gleichen Struktur. Jeder UXler hat seinen aktuellen Stand in Abstract hochgeladen und so war der neueste Arbeitsstand für alle immer sichtbar und nutzbar.

Viel Arbeit ist natürlich in die Pflege und den Aufbau der Libraries geflossen. Aber so konnten neue Designs (Beispiel: Kundenkonto) schnell aus den hinterlegten Komponenten erstellt werden und dann im nächsten Schritt schnell für die anderen Marken adaptiert werden.

Zeplin haben wir zur Doku und für die finale Übergabe der Designs an die Entwickler genutzt. Das Bereitstellen von Komponenten und Page-Layouts via Zeplin hat es uns ermöglicht pixelgenaue Hand-overs zu erstellen in denen alle Spezifikationen wie Farbe, Schriftgröße, Line-height, Abstände usw. enthalten sind. Zudem bietet Zeplin die Möglichkeit  Icons, Piktogramme und Logos mit einem Klick als SVG, PNG oder JPG zu exportieren. Das hat viel Arbeit beim Hin- und Herschicken von Dateien erspart. Auch Farben und Text-Styles lassen sich mit Namen versehen, so dass Design und Entwicklung eine Sprache sprechen konnten. 

Die Entwickler haben dann aus den Designs in die neue theme-bare Component Library aufgesetzt. Diese Library wurde mit Storybook und auf Basis von Angular gebaut. Der Austausch mit den Entwicklern war über das ganze Projekt sehr eng.

Hier nochmal unser Toolset auf einen Blick:

• Mockups und finale Designs erstellen mit Sketch
• Vorbereitung von Design Decision Meetings und den Varianten mit Marvel
• Zusammenarbeit/Ablage an den Designs über Abstract und entsprechende Libraries
• Dokumentation und Übergabe mit Zeplin
• Prototypen für UX Tests mit Axure

Das Design System im kurzen Überblick

Das Design System wurde “Carrera” getauft. Die dazugehörige Component Library auf Basis von Angular nennt sich “ng-carrera”. Carrera steht für die schnellere und leistungsfähigere Version der bisherigen technischen Basis und die Anspielung auf ein bekanntes Spielzeug und eine bekannte Automobilmarke war uns sehr bewusst.

In der Designsprache und im Aufbau der Library haben wir uns sehr an den Google Material Design Standards orientiert und diese natürlich ergänzt und erweitert. Für die Basis-Metriken haben wir uns an Google’s Material Design bzw. dem 8×8 und 4×4 Pixel Grid orientiert. Bei vorherigen Projekten hat sich dieses System mehr als bewährt. Es schafft ein solides Fundament für alle UI Objekte, welches sich letztendlich wie Legobausteine benutzen lässt. Einzelne Elemente lassen sich leicht miteinander kombinieren und das gesamte Layout aller Webshops baut auf dem gleichen Rastersystem auf. 

Aus visueller Sicht hat sich das neue Design System für die einzelnen Marken/Webshops nicht stark verändert, da die bestehende Markensprache aus Farben und Schriften nur leicht aufgefrischt wurde. So wurden z.B. bei Tipp24 neue H1-Headlines mit Montserrat als Schrift eingeführt und der Condensed Schnitt der Roboto wurde gestrichen. Strukturell mussten wir am Design System natürlich auf Grund der Vereinheitlichung der vier Webshops mehr anpassen. Navigation und Seiten-Layout waren bei den Shops natürlich stark verschieden und es war knifflig, da gute gemeinsame Lösungen zu finden. Alle größeren Anpassungen haben wir aber mit den Nutzern intensiv getestet und uns wirklich immer genau überlegt, ob diese Änderung sinnvoll ist oder nicht.

Unsere Herausforderungen

Damit es in diesem Artikel nicht nur um die positiven Seiten des Projektes geht, hier noch ein kurzer Überblick über die größten Herausforderungen aus UX-Sicht:

• Loslösen von bisherigen UX Workflows: das schnelle Umschwenken auf den “Großprojekt”-Modus war nicht einfach, da wir innerhalb von einigen Wochen das Thema “Wie arbeiten wir in UX zusammen” neu denken mussten.

• Komplexität: Den Status Quo der vier Webshops mit den möglichen neuen und vereinheitlichten Design-Varianten im Überblick zu behalten war eine große Herausforderung. Zum Glück hatten die Produktmanager den Fokus hier zunächst auf den LOTTO24 und Tipp24-Webshop gelegt. Schon das Denken und Designen für zwei Webshops am Anfang war intensiv, vor Allem bei Themen wie z.B. der Spielschein-Historie.

• Kommunikation: Die Kommunikation hat einfach viel Zeit in Anspruch genommen, da es viele Beteiligte abzuholen und zu involvieren gab.

• Design-Dokumentation aktuell halten: Bei der Übergabe der Designs an die Entwickler in den haben sich oft Änderungen ergeben. Durch den engen Zeitrahmen haben wir es dann oft nicht geschafft die Designs in Zeplin zu aktualisieren. Das hat dann wiederum zu Mißverständnisse in der QA-Phase vor dem Launch geführt.

Von den Herausforderungen haben wir die meisten, aber nicht alle gelöst. Das Thema “Design-Dokumentation” auf dem aktuellen Stand halten hat uns z.B. bis zum Projektende begleitet.

Das Fazit

Insgesamt lief das Projekt sehr gut und wir haben auch viel positives Nutzerfeedback bekommen. Wir haben mit dem UX-Team innerhalb eines knappen Jahres vier Webshops auf das neue Design System umgezogen. Und das mit einem recht kleinen Team. Der eng verzahnte gemeinsame Workflow mit den passenden Design Tools hat dabei sehr geholfen. Und auch die enge und gute Kommunikation im Team per Slack & Co.. Trotz der Remote-Situation hat das wirklich gut geklappt.

Auch das Thema Design-Entscheidungen hat gut funktioniert. Die Design Decision Meeting waren zwar teilweise zeitintensiv in der Vorbereitung, aber haben sich auf lange Sicht bezahlt gemacht. Die Entscheidungen wurden in dieser Runde immer begründet (UX Tests, Daten, …) getroffen und mit Hinblick auf die Auswirkungen für den Nutzer. 

Natürlich sind auf Grund der Zeitknappheit und auch der Teamstärke in UX einige Punkte zu kurz gekommen. Zum Beispiel die Benennungen der Komponenten in Sketch und in Storybook (dem Tool der Entwickler) von Anfang an einheitlich zu halten. Teilweise wurden in Storybook in der Umsetzung andere Namen benutzt als in der Design Library. Die Kommunikation mit den Entwickler war zwar eng, hätte aber rückblickend noch intensiver sein müssen.

Und last but not least – die Dokumentation der Design Guidelines in Zeplin ist aufwändig zu pflegen und vor allem für “Nicht-UXler” schwierig zu verstehen. Deswegen arbeiten wir derzeit an dem Aufsetzen einer separaten Design-Doku, die einen einfachen Einstieg in das neue Design System bietet. Aber insgesamt haben sich unser Vorgehen und unsere Tools als schlanke und effiziente Lösung erwiesen, deswegen wollten wir unsere Erfahrungen gerne mit euch teilen.