From Fragmented Components to a Unified System - UX Case Study

Impact Summary

80% component adoption across active projects
15+ projects using the React library within two years
Zero frontend specialists required for quality implementation
Unified modal patterns replaced dozens of inconsistent variations

The Fragmentation Problem

When I started working with this client, their design system existed in theory but not in practice. Teams across the company were still building their own isolated component libraries, with each project reinventing buttons, cards, and modal components in slightly different ways.

The core issue wasn't lack of design documentation. It was that most projects used React, but no shared React implementation existed. Backend developers (the client had no frontend specialists) were left interpreting Figma files and building components from scratch. As designs evolved, these isolated implementations fell further out of sync.

I saw teams duplicating the same work over and over while the central design system remained underused.

Seizing the Opportunity

One summer, during a quiet period of work, I saw a chance to partner with two senior developers to kickstart a React component library. In just two weeks, we pulled components from various projects into a unified structure using Storybook.

This wasn't about building everything from scratch. It was about gathering what already worked, standardising it, and making it accessible.

But getting it built was only half the battle. We needed teams to actually adopt it.

Making the Case to Teams

I co-led the evangelisation effort with the developers. We ran demos for the project teams in our office, showing how the library would save them time and improve quality. We gathered testimonials from early adopters who'd already experienced the benefits.

The pitch was simple: backend developers without frontend expertise could now implement designs that matched the Figma components with 99% accuracy. No more guessing at sizing, colours, or interaction patterns.

This resonated because the client's reality was that designers rarely had capacity to QA every implementation detail. The library meant quality by default rather than quality by constant oversight.

All core components in Figma were recreated as React components in Storybook.

Solving Real Problems

One clear example: modal components.

When I arrived, I counted dozens of different modal implementations across projects—buttons positioned differently, varied styles, inconsistent interactions for opening and closing.

I proposed consolidating these into two core patterns:

Dialog modals for messages, feedback, and instructions
Content modals for displaying tables, images, and file previews

These two patterns covered 90% of use cases whilst eliminating the inconsistency that confused users moving between products. Teams stopped building custom modals and started using the library versions.

This became the template for how we expanded the system: identify the pattern needed across projects, design one flexible solution, implement it in React, and make it easy to adopt.

Building for Longevity

As the system grew, I took responsibility for quality control. I QA'd every component that entered the library, created and prioritised tasks for improvements, and wrote guidelines that even junior designers could follow.

I also added technical documentation that developers needed—like z-index elevation rules and ARIA labels for accessibility. The system wasn't just visual specs; it was a complete implementation guide.

Elevation index diagram showing consistent z-index hierarchy. — Visualisation of the z-index elevation system included in developer documentation.

Over time, we expanded from basic components to cover the everyday needs of nearly every project. The library became stable enough to work across different contexts and device sizes, which built trust with teams.

The Reality of Adoption

Not every team came on board. The main website—running a 20-year-old legacy platform—couldn't migrate to React. Their codebase was patched together from multiple technologies, and modernisation wasn't feasible in the short term.

One team reported challenges with customisation and contribution processes. As one senior developer noted: "We had some small issues related to not being able to customise certain components and not finding an easy way to contribute to the library ourselves."

But the fundamental value was clear. A tech lead from a long-term adopter project put it simply: "We have been using the UI library for years now with great success. We feel the solution is mature and well supported and changing implementation would be prohibitively expensive."

The fact that switching away became "prohibitively expensive" showed the library had become essential infrastructure—exactly what a design system should be.

What made this work

Speed to value.
We didn't wait for perfect conditions or complete buy-in. We built something useful quickly and let the results speak for themselves.

Solving real pain.
Every component we added addressed actual problems teams were facing, like the modal inconsistency.

Making implementation easy.
Backend developers could ship quality frontend work without specialised skills.

Quality by default.
The library maintained 99% accuracy to Figma, which built designer trust and reduced QA overhead.

Ongoing evangelisation.
Adoption didn't happen automatically. We continuously demonstrated value and gathered advocates.

Within two years, the library became the foundation for 15+ active projects. Teams that adopted it shipped faster and more consistently. The design system went from "nice to have" to essential infrastructure.