Increasing designer efficiency through a living design system. How a fragmented component library evolved into a versioned design system that improved consistency, accelerated collaboration, and reshaped how our team worked across web and mobile.
When I joined NCB in 2018, there was no true design system in place. The organisation was in the middle of shifting from waterfall to agile delivery, and much of the bank's digital product design had historically been handled by external agencies. As a result, the internal team inherited a fragmented set of files, inconsistent interface patterns, and very little shared structure across products.
What existed were fragments: a few repeated UI elements, some recurring visual decisions, and isolated attempts at consistency. But there was no unified system, no shared logic, and no strong foundation that could help designers move quickly and confidently across products.
What followed was not a single launch moment, but a gradual evolution. Over time, that fragmented starting point became a shared library, then a broader component framework, and eventually a versioned, living design system that supported web and mobile work across the team. The system improved more than visual consistency. It changed how we collaborated, how designers approached problem-solving, and how quickly new work could move from concept to stakeholder-ready design.
No system. Just fragments.
The earliest challenge was not refining an existing system. It was creating shared structure where very little existed. Because design work had been spread across products, teams, and external partners, there was no dependable source of truth. Common UI patterns appeared in different forms. Similar problems were solved multiple ways.
Design quality varied depending on who created the work, when it was created, and which product area it belonged to. This created friction in a few important ways.
A shared library, not yet a system.
The first meaningful step toward consistency happened in Adobe XD. What we built there was not yet a mature design system — it was closer to a shared component library: colours, buttons, cards, headers, footers, and the beginnings of reusable layout pieces. Still, it mattered. It gave the team a common base to work from and started introducing the habit of reuse.
Adobe XD did not support the kind of design logic, scalable variables, or token architecture that later became central to the system. That meant the library could improve consistency, but it could not yet become the flexible, intelligent foundation we needed long term. Even so, this phase shifted the team's mindset toward patterns that should be reused, improved, and shared.
Four versions. One living system.
Adobe XD
Raw components
Focused on the basics: a shared library of foundational UI elements — colours, buttons, and cards. Introduced consistency, but structure was still limited and the system was not yet deeply documented.
Adobe XD
Research and guidelines
The library expanded and became more intentional. Clearer design thinking, stronger visual logic, and early documentation. A more serious attempt at building repeatable standards rather than just collecting reusable assets.
Figma
Move to Figma
Rebuilt with broader ambition. A more scalable structure, expanded scope beyond atomic components, and shaped around real product needs across web and mobile. Figma made it easier to support collaboration, reuse, and pattern maturity.
Figma
Variables and maturity
Variables, stronger component relationships, better theming support, and fuller pattern coverage. No longer just a reusable library — a real operational foundation for the team.
What changed for the team.
The biggest outcome was not just cleaner files or more components. It was a change in how the team worked. As the system matured, designers were able to move faster because they no longer had to solve the same foundational problems repeatedly. They could start from proven patterns, spend less time rebuilding common UI, and focus more of their energy on experience design, content structure, and solving the specific problem in front of them.
One of the less obvious but most important impacts was confidence. When a designer is working from a system that has already been used, reviewed, and improved by the team, they are not starting from zero. They are starting from a foundation. The system did not replace design thinking. It made design thinking more efficient.
What I learned from building it.
Documentation is important, but examples are often what unlock adoption. Designers work more effectively when they can see how a real problem has already been solved. Even an imperfect starting point can dramatically reduce friction.
A good design system does not limit exploration. It removes unnecessary effort so designers can spend more time on the parts of the work that actually need fresh thinking. The system handled the repeatable parts, which made it easier to explore the non-repeatable parts.
A design system is not mature because it looks polished. It is mature when people understand it, trust it, and use it in real work. Adoption, flexibility, and relevance matter more than visual neatness alone.
This project taught me that design systems are not really about components alone. They are about creating shared confidence.
What started as a fragmented collection of assets gradually became a living, versioned system that improved consistency, accelerated collaboration, and gave the team a stronger foundation for product design across web and mobile. Its real value was not just in what it contained, but in how it changed the way people worked. It did not simply standardise design. It increased designer efficiency by making good decisions easier to repeat.
Explore the Oasis design system
Browse design tokens, typography scale, spacing system, and adoption metrics — the full living documentation for the NCB design system.