The fairy tail about complexity in Designsystems, Styleguides and Component Libraries…
… or how to give extended governance on corporate level with white label elements while integrating changing CIs.
While working for MediaMarktSaturn Technology I integrated a new design experience and took over the responsibility to prepare this for the implementation on the technical level.
UI, UX, Testing
MediaMarktSaturn built in parallel to the existing monolithic online shop a new microservice-based shop system in the cloud from scratch. They eventually prepared for every technical incident e.g. to handle several million page-requests on black friday.
While the technical development was already in progress, the design development and UX consistency were lacking behind. That was about the time they hired me. I started with the challenge to implement a complete redesigned component system in an already running development process.
Building a design system is challenging and complex if you start in the middle. With my systematic approach to narrow down elements and build components with an atomic-design driven approach, I can solve this task for a complete webshop in less than two months.
Building the system
Always stick to real user scenarios! Just do it, because it is simple and efficient.
So I create Experience Templates to rebuild main example pages with existing products, texts, and images. Analyzing the elements in this process with the principle of Occam’s razor is key to deliver a robust and efficient system, which developers, editors, marketing and designers can work with. Additionally, I use the system of atomic design.
The result: the design system contains patterns where no more elements should be made than are necessary.
Make the vision tagible through Experience Templates of the flows. Just a design system and templates to work with are not enough in a corporate environment
Usually, you are relying on several teams within the company and different agencies, with many different touchpoints. What we see when we browse through a design system is just the outcome of endless discussions and compromises to fit this to the need of the company.
If you look closely you can find evidence of inconsistency everywhere in the experience for the end-user.
To fight this and to support the people working for MediaMarktSaturn to provide consistent products and assets „on brand“, the creation of a guided design system was mandatory.
The results are definitions of elements in a shared working file for the team. On the one hand, there are structured logic groups of elements as components and symbols to reuse in the whole creative team are inside the file. On the other hand, the Experience Templates are within the file to provide the vision for further development within the team.
Detailed description of every instance of the same element are provided to keep the questions of the team to a minimum.
As the job of UX is evolving, I think it is necessary to team up with developers. Understanding their pain points in the design hand-over and try to explain systems also from their perspective. A close relationship with the dev-department is the key to success within the implementation.
But there is more… Testing, testing, and testing.
The need for iterating designs and optimizing for the specific user need is not only the concern of the business perspective from the product owners but also for the development as a brand and to lead to success.
Therefore the varieties of elements are developed in four steps:
First I analyze the requirements of data elements, then I design a possible solution. Next, it is necessary to talk to the UX department and PO to verify the fit of the design and finalize it. The fourth step is to design possible variants and iterations for the vision of the system and to create material for testing scenarios.
Getting people to love it.
Digital transformation should lead to the enablement of employees to use assets to create brand-related experiences.
When new systems are evolved and disrupt complex approval processes, the refusal of the new process is likely, because:
We always did it that way!
To avoid confusion regarding the topic I created company presentations on big review sessions, introduced the project and provided FAQ sessions.
I learned, that this eases the introduction and reduces the fear of a new system. Additionally, people can get motivated with the visionary story, it is telling.
An inspiring spot that I created for a company wide presentation.
When everybody was on-board, I created roadmaps and guides on how to implement the system. We had to decide if a step by step introduction of the components is the way to go or if we should bring them to live in one big bang.
I prepared the versioning of the component system, checking out the development as soon as possible in the git and doing QA with a review of local built branches so as to not lose track of the development process.
It is super important to work with developers hand in hand and never see the design as a final product.
Changes on the go are necessary and ensure an effective development process. I also learned that leaving definitions in the design open and up to the experience of the developer makes sense in a lot of cases.
Developing and evolving
What I did not cover until now: you can find the governance-system which is an additional outcome of the project here. This not only covers the digital, but also the print, POS, and marketing side as well as its describes the brand principles in total.
The introduced of versioning for the initial development helps to test specific elements inside capsuled PWAs. The development inside frameworks like ’storybook‘ aims to have a full configurable component system which can be edited by almost everybody, so that ideas and formats can be tested easily, without spending money on development or prototyping.
Designing a design system is not as fast as many people belive that it is. The creation of the system itself and uniting the people that work with it takes lots of time an effort. My key learning was that at first not everything should be overdefined, because the rules create themselves by using the elements in real-world-scenarios. Especially during the development, there are going to be lots of changes and optimizations to the design – and that’s ok.