A design system

The problem was a hiring plan

When I joined Megapolis-IT as a senior designer, the company had around 20 products (over 40 by the time I left), from Android apps for maintenance crews and traffic inspectors to iPadOS dashboards for the mayor's office, and about 60% of them were web systems: equipment registries, inventory, repair requests, traffic light control, a dynamic city model. There was no design lead. All designers reported to the CTO, who was not responsible for design and had no way to judge it. An earlier attempt at a design system had failed.

The CTO's plan was to hire two more senior designers: projects were coming in faster than the team could draw them, and only seniors could work without documentation or shared patterns. He asked me to help with the hiring. I told him: “I can spend three months on hiring with no guarantee. Give me the same three months, and I will build a system that makes the hiring unnecessary.” We discussed it over a few meetings, and he agreed.

I was confident because I had done it before, at my previous job, where I built a multi-brand, cross-platform design system for iOS, Android and web. Design systems are my favorite part of the job.

What the fragmentation cost

Five new products were being designed from scratch by independent teams, and the older ones looked ten years apart. That cost the company in three places:

• Inefficient syncs: Designers tried to stay aligned, wasting an hour every day discussing each other's projects and debating minor color tweaks.
• Only seniors could ship: Junior and mid-level designers had no documentation or established patterns to rely on, so every new project needed a senior, and seniors are always in short supply.
• High documentation costs: Government contracts require strict sales protocols. Every system shipped with a thick stack of paper documentation detailing every feature. This meant a large budget for technical writers and constant updates.

The harder part was not technical. Some designers feared a system would kill their creativity, so the work needed as much team management as component design.

Phase 1: Getting the team on board

The process began by syncing with the design department. During our calls, I started pitching the benefits of a design system at opportune moments. Eventually, everyone agreed it would be a huge plus, except for one designer. The discussions with him were difficult, and he firmly insisted on the opposite.

I couldn't resolve this conflict immediately, so what was the solution? First and foremost: don't stop operations. I began working on the kit, while he continued working in isolation on his specific project.

Phase 2: Building without stopping the work

After aligning with the rest of the team, I started developing the UI kit. The designers continued working on their projects as before, but during our joint calls, we made sure their current decisions didn't contradict the future architecture of the design system. This ensured their work could be easily swapped out later without having to rewrite documentation.

Sometimes this meant negotiating with product managers: they agreed with the shared pattern, or I accepted that their product genuinely needed a custom one. I did not come in and break processes; the system had to fit into how the teams already shipped.

Phase 3: The MVP

With the prior experience, setting up primitives, semantic tokens, typography, light/dark themes and the basic components was straightforward. Once that was done, the daily sync meeting went from an hour to 15 minutes and then to 1-on-1s, so the rest of the team could work. I kept the documentation in Figma; it was a bit messy, but it worked.

One lesson I took from it: design tools change faster than UI patterns. Every new Figma feature meant reworking the library, and that is what eventually pushed me to maintain systems in code and to teach the designers React prototyping.

The first product: the traffic management system

The first product to adopt the system was the Traffic management system, a complex platform used to manage traffic lights, bridges, and city infrastructure. It dictates the timing of every traffic light, managing not just single intersections but entire streets to create "green waves" (so cars don't get stuck at every light).

It was the company's most technically demanding product. In a way, this complexity made my job easier: if the design system patterns held up under the stress of TMS, scaling them to the rest of the company’s products would be straightforward.

Reorganizing the design department

After the heavy product work on TMS, with the components tested under load, it was time to reorganize before scaling. At this point I was formally promoted to lead designer and design system owner.

I aligned the changes with the CTO. We set up a dedicated project in Azure for the design system and invited the developers. Technically, the design system code used to be coupled with TMS; now, it was extracted into its own independent entity.

Designers started logging tasks there. The UI kit in Figma was split into "approved files" (for developers) and "WIP (Work In Progress) files." Every designer could contribute to the WIP files. This solved two major issues: it alleviated my personal bottleneck and gave the team the creative outlet and personal growth they needed.

I kept my promise to the CTO. The two senior hires were never made. The number of projects doubled and their complexity grew, and the team handled it at the same headcount.

Scaling and delegation

All new systems were now built on the UI kit, which the senior designers handled on their own. To redesign the legacy systems, which had no new functional requirements, I needed the junior designers to be able to do it.

The challenge was my bandwidth: I was leading two flagship products while managing the design system. I needed to delegate.

I focused on mentoring one specific designer who showed the strongest aptitude for product design. He became my deputy: he helped guide the other designers, approved mockups, and covered for me when I was overloaded or on PTO.

By the time the company resumed expanding, our processes were so solid that we were fully prepared to hire and onboard juniors, and the search for senior designers stopped.

Examples of projects built on the design system: