REWE Design System

67% UI development acceleration by reducing code duplication by 54%

Success scenario

“REWE’s Product builders are investing their time building instead of arguing how to build. The frontend is unified in experience, style and performance, while still allowing fault isolation and technical freedom for the development teams.”

Methods used

1. Creating and selling the vision internally by presenting analyses on multiple dimensions and domains.
2. Setting up the business case to convince leadership of the business value of a design-driven initiative.
3. Building habits of synchronization and updates by facilitating frequent best-practice workshops.
4. Storytelling, engineering and visual craft to bring all aspects into existence and connect them into a coherent system.

Solving frustrations

After designing the recipes and offer section for rewe.de, it became clear to me that the larger design team wasted enormous resources trying to synchronize designs across all engineering teams by hand. It was a futile effort most of the time, since the results were inconsistent in style and function.

Work was constantly blocked by linear dependencies and opaque processes. Motivated colleagues fell into analysis paralysis, as every approach seemed to carry an unknown cost.

Context

Reusing components wasn’t an option. All teams ran their software as separate microservices, each with its own frontend. Many had no frontend engineer at all and were free to choose any tech stack, as long as the build output was HTML, CSS and JS.

This operating mode allowed teams to benefit from fault isolation, a service could go down without affecting the others. A sensible consideration for a grocery delivery business, used by millions of people every day.

This, however, meant designers couldn’t roll out UI and UX changes easily, since changes had to be consistent across the entire product landscape. Changing the smallest thing became a massive coordination effort to ensure a smooth rollout across all services. Someone had to watch over every duplicated part and make sure our quality criteria were met.

Persistence is everything

For a long time, the effort required to address this wasn’t seen as worth it. The prevailing opinion at REWE was to accept the complexity and do the best you could. Experience designers bore the brunt of it: users had no concern for the arbitrary separation of microservices and simply expected a consistent experience across all of them, unaware the complexity even existed.

That made it a design problem by default. Designers either solved it or lived with it. Since designers typically lack deep technical knowledge, no one took it upon themselves to fix it. Several attempts to establish a pattern library failed, the initiatives never gaining enough traction. The situation frustrated me enough that I taught myself the inner workings of our microservice architecture to understand the problem well enough to discuss solutions directly with developers.

The human element

At the start, the designers weren’t on board. Feedback from questionnaires and workshops showed they preferred to stay independent, free to deviate from shared UI standards. The downsides of inconsistent UI for end users and duplicated development effort did little to convince them. They also assumed it would require learning to code, so I built a solution that removed that concern entirely.

The power of direct control and responsibility

Setting up a token system was already part of the effort, so I thought about the workflows designers used to ship their work. I built a theme editor that let designers edit the style layer directly.

They could see in real time how a token change propagated through the interfaces they worked on every day. Change a color, see it ripple through every component. That was the moment it clicked. They understood what UI centralization could actually do.

The idea had landed. With people bought in, the next step was building habits around it. I ran a weekly workshop series where we tackled the top-voted issue for the design centralization effort and worked through it together. Over time this grew into a valuable teaching tool, walking others through how design decisions were made and what downstream impact they carried.

Convincing engineering managers and leadership

The designers were on board, but leadership and tech were not yet convinced. I ran a demonstration focused on the metrics they cared about most: time and cost. Management speaks in terms of ROI, quarters and resources, so I needed to tailor my story accordingly. I got a colleague to help build a business case and convince leadership to staff a team and get the implementation moving.

To show the workflow benefits of a centralized system, I gave a group of frontend developers a small task: build a simple interface twice, first without the system, then with it. I recorded and timed both sessions to show visually how much faster and cleaner the workflow becomes. A concrete argument for leaders far removed from day-to-day engineering.

After two years of pushing for it at REWE, I finally got a team together to build and release it to the wider organization. We rolled it out piece by piece to allow for gradual adoption and maintenance. Here is the individual steps visualized, from code, to preview, to new implementation using the system:

In my last year at REWE digital, the company merged with the sister company REWE systems, merging the design and engineering orgs into one. I handed off the system and effort to the new crop of designers and engineers to explore new challenges at Spotify, which took notice of me building this system from scratch.