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

Wenn es um die Modernisierung großer CMS-Ökosysteme und ihre Erweiterungen geht, werden häufig Design-Systeme eingeführt. So beschloss auch die Schweizer Versicherungsgruppe Baloise, ihren groß angelegten Relaunch auf Basis eines gemeinsamen Design Systems zu starten. IBM iX unterstützte dabei mit der Entwicklung des Magnolia CMS für Baloise und deren großen globalen Web-Relaunch.

Ein Design System ist ein lebendiges System, bestehend aus Richtlinien, wiederverwendbarem Code sowie Design Assets und Tools, die dabei helfen, unternehmensweit konsistente und markengerechte Produkte zu entwickeln und zu skalieren. Ein gut durchdachtes Design System schafft eine gemeinsame Basis für jegliche Web-Anwendungen. Ob ein extern entwickeltes CMS, eine kleine Intranet-Seite oder eine App – alles erscheint aus einem Guss. Hierdurch können über die Jahre viel Entwicklungszeit und finanzielle Mittel gespart werden.

Zusammenfassend kann man sagen, dass ein Design System folgende Vorteile mit sich bringt:

Im Zuge des Relaunch-Projekts stellte die Baloise ein internes Team zur Entwicklung eines Design-Systems zusammen, das für einen einheitlichen Look aller zukünftigen Anwendungen sorgen sollte. Ausgehend von einem extern entwickelten Figma Design wurde ein Satz Basis-Komponenten angelegt, von einem Gridsystem über Headline bis hin zu Formelementen.

Die Entwicklung des Design Systems erfolgte auf Basis von StencilJS und erzeugte entsprechende Web Components mit eigenem Namespace, Events und offenen Properties, um Styles und Funktionalitäten der Komponenten zu steuern. Gehostet auf GitHub und Vercel Storybook, steht es inzwischen öffentlich zur Verfügung. Es existieren ebenfalls Builds mit Anleitungen für React, Angular und Vue.

Das Ergebnis ist sehr atomar, content- und funktionsagnostisch. Soll heißen: Beispielsweise das Input-Element validiert erstmal nicht selbst, bietet aber eine API für Fehlermeldungen, unterschiedliche States für bspw. den Erfolg oder Fehlerstatus und alles weitere, um das standardisierte Input-Element in jeglichem Formular oder Rechner zu verwenden. Auf ähnliche Weise ist das Overlay und seine verwandten Pop-Up, Toast, etc. nur ein Wrapper für prinzipiell jeglichen Content und Funktionalität.

Dieses Design System integrierte IBM iX als node Modul in das eigene StencilJS Projekt, dessen Output wiederum in einem Magnolia-Lightmodul landet – wieder mit separatem Namespacing. Hierdurch ist es dem Frontend-Team möglich, jegliches Design-Token und die vorgefertigten Komponenten des Design Systems ohne Weiteres zu verwenden. Separates Namespacing stellt dabei sicher, dass u.a. in der QA klar ist, welches Team für die Komponente verantwortlich ist.

Um die Komponenten mit Content aus Magnolia zu füllen, gibt es grundsätzlich mehrere Wege, bspw. JSON im Markup sowie als Property oder per Slots. Wir entschieden uns für Slots, da dies am ehesten „echtes“ Markup in den Freemarker-Templates erzeugt und damit leichter wartbar und für Frontender zugänglicher ist.

Dank vieler vorbereiteter Makros und konstantem Support durch das Backend-Team war es so den Frontendern möglich, ihre neu erstellten Komponenten direkt in Magnolia zu testen und anschließend einen Backender die Variablen erweitern zu lassen.

Natürlich bietet so ein veränderter Workflow auch Herausforderungen. Zum einen muss der Design System-Gedanke von der ersten Konzeptphase an vollumfänglich umgesetzt werden – das bedeutet, dass das Design einheitlich auf den gleichen Variablen für Schriftgrößen, Abstände und Farben basiert, die dann wiederum die Basis jeglicher Entwicklung sind. Zum anderen sind viele verschiedene Akteure beteiligt, so dass eine weitere Herausforderung in der Koordination und Kommunikation untereinander liegt.

Neben dem SCRUM-typischen Daily wurden beispielsweise Tech-Dailies etabliert, um einen stetigen Austausch zwischen dem Design System Team und denjenigen zu gewährleisten, die damit dann Projekte umsetzen. Die regelmäßige Kommunikation zwischen Design und Entwicklung dient dazu, die Anforderungen an die Komponenten zu überprüfen und trotz der Komplexität derartiger Unterfangen die Übersicht zu behalten, welche benötigten Features eventuell schon vom Design System abgedeckt werden oder diesem hinzugefügt werden sollten. Außerdem kann dadurch sichergestellt werden, dass das CMS-Team informiert ist, was in den nächsten Design System Releases zu erwarten ist.

Abschließend sollte noch ein Regelwerk für Abstände, Erfolg/Fehler Status oder Overlay und Formularverhalten etabliert werden, das helfen soll, die sogenannten „Edge Cases“ oder auch kombinierte Komponenten, die nicht separat im Design bedacht wurden, zu lösen – ohne immer wieder Extra-Schleifen durch Design oder Konzeption drehen zu müssen. Und zu guter Letzt lebt ein Design System – wie jedes andere solide Projekt auch – von einer gepflegten Dokumentation.

Für anspruchsvolle Web-Ökosysteme bietet ein Design System die Chance, Ressourcen (v.a. Zeit, Geld und Nerven) bei neuen Projekten zu sparen. Zwar erfordert dieses Vorgehen initial einen gewissen Invest, aber das Ergebnis eines gut durchdachten Design Systems bildet die unternehmensweite Basis für alle digitalen Vorhaben. Wenn dieses Fundament einmal steht, profitieren von den Konzepter*innen über die Entwickler*innen bis zu den Endkund*innen alle davon. Mit einem soliden Magnolia-Backend und sinnvollem Theming gelingt es, hochkomplexe Relaunches mit zahlreichen Unterseiten aus unterschiedlichsten Redaktionen effizient umzusetzen. Und all das, während auf derselben Design System Basis in anderen Teilen des Unternehmens parallel schon neue Projekte entstehen.