Magnolia trifft Design System: Wie man einen globalen Web-Relaunch effizient umsetzt

Bei der Modernisierung großer CMS-Ökosysteme und deren Erweiterungen werden häufig Designsysteme eingeführt. So entschied sich auch der Schweizer Versicherungskonzern Baloise, seinen groß angelegten Relaunch auf Basis eines gemeinsamen Designsystems anzugehen. IBM iX unterstützte die Baloise bei der Entwicklung von Magnolia für ihren großen globalen Web-Relaunch.

Ein Designsystem ist ein lebendiges System, das aus Richtlinien, wiederverwendbarem Code sowie Design-Assets und -Tools besteht, die die Entwicklung und Skalierung konsistenter und markengerechter Produkte im gesamten Unternehmen unterstützen. Ein gut durchdachtes Designsystem schafft eine gemeinsame Grundlage für jede Webanwendung. Egal, ob es sich um ein extern entwickeltes CMS, eine kleine Intranetseite oder eine App handelt, alles scheint aus einem Guss zu sein. Das kann im Laufe der Jahre eine Menge Entwicklungszeit und finanzielle Ressourcen sparen.

Zusammenfassend lässt sich sagen, dass ein Entwurfssystem die folgenden Vorteile bietet:

Im Rahmen des Relaunch-Projekts stellte die Baloise ein internes Team zusammen, um ein Designsystem zu entwickeln, das ein einheitliches Erscheinungsbild für alle künftigen Anwendungen gewährleistet. Ausgehend von einem extern entwickelten Figma-Design wurde eine Reihe von Basiskomponenten erstellt, von einem Rastersystem bis hin zu Überschriften- und Formularelementen.

Das Designsystem wurde auf der Grundlage von StencilJS entwickelt und erstellte entsprechende Webkomponenten mit eigenem Namespace, Ereignissen und offenen Eigenschaften zur Steuerung der Stile und Funktionen der Komponenten. Gehostet auf GitHub und Vercel Storybook, ist es nun öffentlich verfügbar. Es gibt auch Builds mit Anleitungen für React, Angular und Vue.

Das Ergebnis ist sehr atomar und gleichzeitig inhalts- und funktionsunabhängig. Das Eingabeelement validiert sich beispielsweise nicht selbst, sondern bietet eine API für Fehlermeldungen, verschiedene Zustände und alles andere, um das standardisierte Eingabeelement in einem beliebigen Formular oder Taschenrechner zu verwenden. In ähnlicher Weise ist das Overlay und das zugehörige Pop-up, Toast usw. nur ein Wrapper für praktisch jeden Inhalt und jede Funktionalität.

BM iX hat dieses Designsystem als Node-Modul in sein eigenes StencilJS-Projekt integriert, dessen Output wiederum in einem Magnolia Light-Modul landet - wiederum mit separatem Namespacing. Dies ermöglicht dem Frontend-Team, beliebige Design-Token und die vorgefertigten Komponenten des Design-Systems zu verwenden. Das separate Namespacing stellt unter anderem sicher, dass in der QA klar ist, welches Team für die Komponente verantwortlich ist.

Um die Komponenten mit Magnolia-Inhalten zu füllen, gibt es mehrere Möglichkeiten, z.B. JSON im Markup und als Property oder über Slots. Wir haben uns für die Verwendung von Slots entschieden, da dies der wahrscheinlichste Weg ist, um "echtes" Markup in den Freemarker-Vorlagen zu erstellen, und daher einfacher zu pflegen und für Frontender zugänglicher ist.

Dank vieler vorbereiteter Makros und ständiger Unterstützung durch das Backend-Team war es möglich, dass Frontender ihre neu erstellten Komponenten direkt in Magnolia testen und dann von einem Backender die Variablen erweitern lassen konnten.

Natürlich bietet ein solcher veränderter Workflow auch Herausforderungen. Zum einen muss die Idee des Designsystems bereits in der ersten Konzeptphase vollständig umgesetzt werden - das bedeutet, dass das Design einheitlich auf den gleichen Variablen für Schriftgrößen, Abstände und Farben basiert, die wiederum die Grundlage für jede Entwicklung bilden. Zum anderen sind viele verschiedene Akteure beteiligt, so dass eine weitere Herausforderung in deren Koordination und Kommunikation liegt.

Neben dem SCRUM-typischen Daily wurden Tech-Dailies etabliert, um einen ständigen Austausch zwischen dem Designsystem-Team und denjenigen zu gewährleisten, die es für die Umsetzung von Projekten nutzen. Die regelmäßige Kommunikation zwischen Design und Entwicklung dient dazu, die Anforderungen an die Komponenten zu überprüfen und trotz der Komplexität eines solchen Vorhabens den Überblick darüber zu behalten, welche benötigten Features möglicherweise bereits durch das Designsystem abgedeckt sind oder noch ergänzt werden sollten. Sie trägt auch dazu bei, dass das CMS-Team darüber informiert ist, was in zukünftigen Versionen des Designsystems zu erwarten ist.

Schließlich sollte ein Regelwerk für Abstände, Erfolgs-/Fehlerstatus oder Überlagerungs- und Formularverhalten etabliert werden, das helfen soll, die so genannten "Edge Cases" oder kombinierte Komponenten, die im Entwurf nicht gesondert berücksichtigt wurden, zu lösen - ohne extra Schleifen durch Entwurf oder Konzeption mehrfach drehen zu müssen. Und nicht zuletzt lebt ein Designsystem - wie jedes andere solide Projekt auch - von einer gut gepflegten Dokumentation.

Für anspruchsvolle Web-Ökosysteme kann ein Designsystem Ressourcen (vor allem Zeit, Geld und Nerven) für neue Projekte einsparen. Obwohl dieser Ansatz zunächst eine gewisse Investition erfordert, bildet das Ergebnis eines durchdachten Designsystems die unternehmensweite Basis für alle digitalen Projekte. Ist dieses Fundament erst einmal gelegt, profitieren alle davon, von den Konzeptern über die Entwickler bis hin zu den Endkunden. Mit einem soliden Magnolia-Backend und einer sinnvollen Thematisierung lassen sich hochkomplexe Relaunches mit zahlreichen Unterseiten aus den unterschiedlichsten Redaktionen effizient umsetzen. Und das, während parallel in anderen Unternehmensbereichen bereits neue Projekte auf der gleichen Designsystembasis entwickelt werden.