From a scattered UI to a design system: the story of five admin panels

I recently joined a company as a frontend team lead, and it had five separate admin panels: an OMS, a CMS, a PIM, a back office and more. They all did similar work and shared the same structure. Yet each one had been built from scratch, with no idea the others existed.

This post is about how we brought those five panels under one design language.

The problem

As different developers came and went, the codebases drifted further apart every day. Each panel had its own buttons, its own dropdowns, its own colors. Whenever a feature or a design change came in, someone had to fix hundreds of buttons, menus and dropdowns one by one, across five separate projects. Even a small revision turned into a heavy workload.

Analysis first

My first job after joining wasn't writing code; it was analyzing the mess. Which components repeat? Which colors are really just shades of the same color? Which spacing values were picked at random? That analysis showed what a shared foundation needed to cover.

Laying the foundation

I set up two things:

• Design tokens: Color, borders, spacing, typography and border radius all came from fixed variables. In the CMS, for example, we defined a brand color variable, and every primary button started using it.
• Shared components: The dropdowns looked different from project to project. I took an off-the-shelf dropdown, adapted it to what the panels needed and turned it into a single dropdown component. Buttons and menus went through the same process.

I covered token layers and naming in detail in Design token architecture.

Button hierarchy

The inconsistency wasn't only about styling. Some pages had two or three primary buttons side by side, and users couldn't tell which one was the main action. When everything on a page stands out, nothing does.

On each page, I found the main action and made only that one primary. The rest became secondary or tertiary, in order of importance. That way the shared button component made not just the look consistent, but the priorities on each page too.

Handing it off to the team

I led a team of 10 frontend developers, and I ran this work with two of them. I laid the foundation, then handed the repetitive work to those two: rolling the new components out page by page and replacing old styles with tokens. At every step, I explained what we were doing and why. They trusted me, so things moved quickly.

The order was the same in every project:

1. Components first: scattered buttons and dropdowns moved to the shared components.
2. Then variables: hard-coded colors and sizes became tokens.
3. A final pass: we went through every page and fixed spacing and alignment.

The result

From then on, changing a single variable changed every color or border in a panel at once. Since the components lived in one place, revisions shipped much faster. Even though there were five separate projects, they all looked like the work of a single hand.

Looking back

I worked there for four months, and in that time I improved each project on its own; the shared components lived inside each project. With a bit more time, the next step would have been a monorepo: I would have pulled the components and tokens into one place. That way all five projects would use the same source, and a single fix would reach every one of them.

Summary

• Analyze first: you can't build a shared foundation without seeing what repeats.
• Tokens keep the decisions in one place; shared components keep the usage in one place.
• Each page gets one primary button; the rest are ranked as secondary and tertiary.
• Lay the foundation, then hand off the repetitive work and explain the reasons behind it.
• Order matters: components, then variables, then a page-by-page pass.
• If several projects need to speak the same language, plan a shared source from the start.