Magnolia meets Design System: How to implement a global web relaunch efficiently

Design systems are often introduced when modernizing large CMS ecosystems and their extensions. This is also how the Swiss insurance group Baloise decided to approach its large-scale relaunch based on a common design system. IBM iX assisted with the development of Magnolia for Baloise and their major global web relaunch.

A design system is a living system consisting of guidelines, reusable code, and design assets and tools that help develop and scale consistent and on-brand products across the enterprise. A well-designed design system creates a common foundation for any web application. Whether it's an externally developed CMS, a small intranet site, or an app, everything appears to come from the same mold. This can save a lot of development time and financial resources over the years.

In summary, a design system brings the following advantages:

As part of the relaunch project, Baloise assembled an internal team to develop a design system to ensure a consistent look across all future applications. Starting from an externally developed Figma design, a set of basic components was created, from a grid system to headline and form elements.

The design system was developed based on StencilJS and created corresponding web components with their own namespace, events, and open properties to control the styles and functionalities of the components. Hosted on GitHub and Vercel Storybook, it is now publicly available. Builds with instructions for React, Angular, and Vue also exist.

The result is very atomic while also being content and function agnostic. For example, the input element does not validate itself but provides an API for error messages, different states, and everything else to use the standardized input element in any form or calculator. Similarly, the overlay and its related pop-up, toast, etc., is just a wrapper for basically any content and functionality.

BM iX integrated this design system as a node module in its own StencilJS project, the output of which, in turn, ends up in a Magnolia Light module - again with separate namespacing. This enables the frontend team to use any design token and the prefabricated components of the design system. Separate namespacing ensures that, among other things, it is clear in QA which team is responsible for the component.

To fill the components with Magnolia content, there are several ways, e.g., JSON in the markup and as property or via slots. We decided to use slots because this is the most likely way to create "real" markup in the Freemarker templates and is, therefore, easier to maintain and more accessible for frontenders.

Thanks to many prepared macros and constant support from the backend team, it was possible for frontenders to test their newly created components directly in Magnolia and then have a backender extend the variables.

Of course, such a changed workflow also offers challenges. For one thing, the design system idea must be fully implemented from the very first concept phase - this means that the design is uniformly based on the same variables for font sizes, spacing, and colors, which in turn form the basis of any development. On the other hand, many different players are involved, so another challenge lies in their coordination and communication.

In addition to the SCRUM-typical daily, tech dailies were established to ensure a constant exchange between the design system team and those who then use it to implement projects. Regular communication between design and development serves to review the requirements for the components and, despite the complexity of such undertakings, to maintain an overview of which required features may already be covered by the design system or should be added to it. It also helps ensure that the CMS team is informed about what to expect in future design system releases.

Finally, a set of rules for spacing, success/error status or overlay and form behavior should be established, which should help to solve the so-called "edge cases" or combined components that were not considered separately in the design - without having to turn extra loops through design or conception repeatedly. And last but not least, a design system - like any other solid project - lives from well-maintained documentation.

For sophisticated web ecosystems, a design system can save resources (especially time, money, and nerves) for new projects. Although this approach initially requires a certain investment, the result of a well-thought-out design system forms the company-wide basis for all digital projects. Once this foundation is in place, everyone benefits from it, from the conceptual designers to the developers to the end customers. With a solid Magnolia backend and sensible theming, it is possible to efficiently implement highly complex relaunches with numerous subpages from a wide range of editorial departments. And all this while new projects are already being developed in parallel on the same design system basis in other parts of the company.