1,456 Components Down to 182 — One Scalable Design System
Transformed a redundant component graveyard into a documented, published single source of truth used across internal and partner product teams to build consistent experiences across multiple products.
My Role :
Design System Lead
Key Metrics :
Component Consolidation System Adoption
Team :
Product Design Frontend Engineering
Project Duration :
3 Months Continuous Evolution
Project Background
When I joined Cyberbay in 2024, the company had grown from an MVP into multiple digital products, while the design files had become cluttered and redundant along the way. Over the company’s first few years, several designers had contributed to building those products, but without a shared system. What designers and developers now had to work from wasn’t really a design system — it was an archive of everything anyone had ever created.
For cybersecurity products, consistency goes beyond visual polish — it shapes how reliable and trustworthy the experience feels across products. As Cyberbay began transitioning its products from dark mode to light mode and continued expanding its product ecosystem, establishing a consistent foundation became a priority.
Problem Overview
I knew the system was broken. The UI inventory showed me the scale of it.
I could already see the impact — inconsistent screens, duplicate components, and repeated back-and-forth with developers when the implemented UI didn’t match the designs. But before changing anything, I needed to understand where those inconsistencies were coming from and what was creating the most friction.
I ran a full UI inventory across the design files and product pages, auditing every component, variant, colour value and how much of the system was actually being used. What looked like general design debt became a clear, measurable list of what needed to be fixed.
The Component Graveyard
The existing system had 1,456 components, including 761 unused variants and 43 unused standalone components. They had been built and abandoned, but were still sitting in the assets panel competing for attention with the components designers actually needed.
50 Shades of Gray
The UI inventory found around 50 different shades of grey in use — far more than the product needed. Many were near-identical values, such as #e3e3e3 and #e2e2e2, adding unnecessary inconsistency across the interface.
Zero Documentation
None of the components had descriptions or usage guidance. Several component sets still used default names like Property 1 and Component 1, while others shared duplicate names. Designers couldn't tell what each component was for or how it should be used.
My Role
As Head of Product Design, I led the design system rebuild end-to-end — from the UI inventory and system architecture to rebuilding the component library and documenting the entire system.
Alongside the rebuild, I worked closely with front-end engineering to make the system easier to implement and reduce repeated back-and-forth during handoff. The published library became a shared foundation used across internal teams and our partner’s product team across multiple products.
Strategy & Approach
The UI inventory gave me a clear list of what was broken, but not what the new system should become. Fixing 1,456 components one by one would only create a tidier version of the same problem. I made the case for rebuilding from a clean foundation, using the old library only as an inventory of what the product actually needed.
That became the principle for the rebuild: build for real product use, not for what a design system is supposed to contain. A component only earned a place in the library once it appeared more than once across real screens, keeping one-offs from becoming unnecessary system components. The rebuild needed a structure that made the old failure modes impossible, rather than just cleaning up after them.
Atomic design as the structure
I structured the system using Atomic Design, organising components into atoms, molecules and organisms. This gave every component a defined place and made it easier to check what already existed before creating something new. It also gave the rebuild a clear order: atoms first, then molecules and organisms built from those finished parts. Changes to a base component could then carry through everywhere it was used instead of being repeated screen by screen.
Establishing a shared language and naming intentionally
Before defining the naming system, I conducted internal research and worked with the team to align on the language used across the product. The goal was to establish a consistent vocabulary for the system and remove ambiguity across teams.
That shared language guided how we named the system — by role rather than appearance. Headline Large instead of Heading 36 Bold, and text.secondary instead of grey-500.
Core Product Decisions
Rebuilding the system meant deciding what it would no longer allow, not just what it would contain. Most problems in the old library came from the same root: values, names and component decisions were being made locally instead of defined once and shared. Fifty greys, multiple button and icon sets, and zero documentation were different symptoms of the same problem.
The rebuild focused on removing the conditions that created them. Values were defined once and referenced, components were built to stay connected, documentation lived with the component, and the library was published from one dedicated source for products to use. What follows shows how those decisions shaped the finished system.
Building the foundations first
Before building a single component, I defined the system foundations as Figma Variables so components would reference shared values from the start rather than hardcoded ones. The architecture has two layers: primitives for colour, typography and dimensions, and semantic variables for colour, typography, border radius, border width and spacing. Semantic variables reference the primitive layer and are named by role, such as text.primary, border.muted and icon.secondary.
This structure replaced scattered values with one controlled foundation that can support theme or brand changes without rebuilding individual components. Colour combinations were also documented against WCAG 2.2 contrast requirements. From there, I built the core atoms on top of the same variables, giving every component a consistent foundation from the beginning.
No reason to detach
The old library pushed designers to detach components whenever the variant or property they needed was missing. I rebuilt each component with the states and controls needed for real use — text, icon, state, visibility and other instance-level changes — so adapting a component no longer meant breaking its connection to the library. The goal was simple: make the correct path the fastest one.
Everything was also rebuilt with auto layout. With 48% of the old library using fixed layouts, even reused components could break when real content changed. The new components resize with their content by default, making them more reliable across screens and products.
Removing guesswork through documentation
Every component is documented with its anatomy, variants, states, use cases and do/don’t guidance, with a description visible directly in the assets panel at the moment someone is choosing what to use. This makes the guidance part of the component itself rather than something written separately and forgotten.
Nothing enters the published library until it is documented. The goal is to answer the question at the point it matters most: which component should I use, and when?
Measurable Outcomes
The rebuild is easiest to judge by what disappeared. 1,456 components became 182 structured, documented component sets, while broken sets, duplicate names, scattered values and missing documentation were removed.
More importantly, designers began building from the library instead of around it. The same shift happened on the engineering side: the team refactored the frontend to align with the new library’s structure and naming.
1,456 components down to 182
The library went from 1,456 components to 182 structured component sets. This removed 761 unused variants and 43 unused standalone components, resolved broken and duplicate sets, and consolidated six fragmented icon libraries into one. What remained was documented, structured and built around what the product actually used.
From 32% in use to 100%
In the old library, only 361 of the audited variant components had ever been used — just 32%. The rest added dead weight and made the components designers actually needed harder to find. In the rebuilt system, every one of the 182 component sets exists because the product uses it, and nothing enters the library until it appears across real screens.
One library, multiple products
The design system now lives in its own file, published as a shared library that every product file connects to. Components are maintained in one place, so an update to the library carries across every product using it. The same library supports multiple internal products and our partner’s product team, extending the same source of truth beyond the internal team.
Ongoing Product Development
The refactor closed most of the visible gap between Figma and production, but keeping both aligned still depends on manual updates across design and engineering. The next phase is a coded component library with Storybook as the shared reference, reducing the risk of design and code drifting apart again.
The existing Figma documentation will gradually move into Storybook as coverage grows, while the Figma library remains the place designers build product experiences. I’m currently building the first stories directly in the codebase alongside engineering, continuing to close the gap between design and implementation.
Continue Exploring
1,456 Components Down to 182 — One Scalable Design System
Transformed a redundant component graveyard into a documented, published single source of truth used across internal and partner product teams to build consistent experiences across multiple products.
My Role :
Design System Lead
Key Metrics :
Component Consolidation System Adoption
Team :
Product Design Frontend Engineering
Project Duration :
3 Months Continuous Evolution
Project Background
When I joined Cyberbay in 2024, the company had grown from an MVP into multiple digital products, while the design files had become cluttered and redundant along the way. Over the company’s first few years, several designers had contributed to building those products, but without a shared system. What designers and developers now had to work from wasn’t really a design system — it was an archive of everything anyone had ever created.
For cybersecurity products, consistency goes beyond visual polish — it shapes how reliable and trustworthy the experience feels across products. As Cyberbay began transitioning its products from dark mode to light mode and continued expanding its product ecosystem, establishing a consistent foundation became a priority.
Problem Overview
I knew the system was broken. The UI inventory showed me the scale of it.
I could already see the impact — inconsistent screens, duplicate components, and repeated back-and-forth with developers when the implemented UI didn’t match the designs. But before changing anything, I needed to understand where those inconsistencies were coming from and what was creating the most friction.
I ran a full UI inventory across the design files and product pages, auditing every component, variant, colour value and how much of the system was actually being used. What looked like general design debt became a clear, measurable list of what needed to be fixed.
The Component Graveyard
The existing system had 1,456 components, including 761 unused variants and 43 unused standalone components. They had been built and abandoned, but were still sitting in the assets panel competing for attention with the components designers actually needed.
50 Shades of Gray
The UI inventory found around 50 different shades of grey in use — far more than the product needed. Many were near-identical values, such as #e3e3e3 and #e2e2e2, adding unnecessary inconsistency across the interface.
Zero Documentation
None of the components had descriptions or usage guidance. Several component sets still used default names like Property 1 and Component 1, while others shared duplicate names. Designers couldn't tell what each component was for or how it should be used.
My Role
As Head of Product Design, I led the design system rebuild end-to-end — from the UI inventory and system architecture to rebuilding the component library and documenting the entire system.
Alongside the rebuild, I worked closely with front-end engineering to make the system easier to implement and reduce repeated back-and-forth during handoff. The published library became a shared foundation used across internal teams and our partner’s product team across multiple products.
Strategy & Approach
The UI inventory gave me a clear list of what was broken, but not what the new system should become. Fixing 1,456 components one by one would only create a tidier version of the same problem. I made the case for rebuilding from a clean foundation, using the old library only as an inventory of what the product actually needed.
That became the principle for the rebuild: build for real product use, not for what a design system is supposed to contain. A component only earned a place in the library once it appeared more than once across real screens, keeping one-offs from becoming unnecessary system components. The rebuild needed a structure that made the old failure modes impossible, rather than just cleaning up after them.
Atomic design as the structure
I structured the system using Atomic Design, organising components into atoms, molecules and organisms. This gave every component a defined place and made it easier to check what already existed before creating something new. It also gave the rebuild a clear order: atoms first, then molecules and organisms built from those finished parts. Changes to a base component could then carry through everywhere it was used instead of being repeated screen by screen.
Establishing a shared language and naming intentionally
Before defining the naming system, I conducted internal research and worked with the team to align on the language used across the product. The goal was to establish a consistent vocabulary for the system and remove ambiguity across teams.
That shared language guided how we named the system — by role rather than appearance. Headline Large instead of Heading 36 Bold, and text.secondary instead of grey-500.
Core Product Decisions
Rebuilding the system meant deciding what it would no longer allow, not just what it would contain. Most problems in the old library came from the same root: values, names and component decisions were being made locally instead of defined once and shared. Fifty greys, multiple button and icon sets, and zero documentation were different symptoms of the same problem.
The rebuild focused on removing the conditions that created them. Values were defined once and referenced, components were built to stay connected, documentation lived with the component, and the library was published from one dedicated source for products to use. What follows shows how those decisions shaped the finished system.
Building the foundations first
Before building a single component, I defined the system foundations as Figma Variables so components would reference shared values from the start rather than hardcoded ones. The architecture has two layers: primitives for colour, typography and dimensions, and semantic variables for colour, typography, border radius, border width and spacing. Semantic variables reference the primitive layer and are named by role, such as text.primary, border.muted and icon.secondary.
This structure replaced scattered values with one controlled foundation that can support theme or brand changes without rebuilding individual components. Colour combinations were also documented against WCAG 2.2 contrast requirements. From there, I built the core atoms on top of the same variables, giving every component a consistent foundation from the beginning.
No reason to detach
The old library pushed designers to detach components whenever the variant or property they needed was missing. I rebuilt each component with the states and controls needed for real use — text, icon, state, visibility and other instance-level changes — so adapting a component no longer meant breaking its connection to the library. The goal was simple: make the correct path the fastest one.
Everything was also rebuilt with auto layout. With 48% of the old library using fixed layouts, even reused components could break when real content changed. The new components resize with their content by default, making them more reliable across screens and products.
Removing guesswork through documentation
Every component is documented with its anatomy, variants, states, use cases and do/don’t guidance, with a description visible directly in the assets panel at the moment someone is choosing what to use. This makes the guidance part of the component itself rather than something written separately and forgotten.
Nothing enters the published library until it is documented. The goal is to answer the question at the point it matters most: which component should I use, and when?
Measurable Outcomes
The rebuild is easiest to judge by what disappeared. 1,456 components became 182 structured, documented component sets, while broken sets, duplicate names, scattered values and missing documentation were removed.
More importantly, designers began building from the library instead of around it. The same shift happened on the engineering side: the team refactored the frontend to align with the new library’s structure and naming.
1,456 components down to 182
The library went from 1,456 components to 182 structured component sets. This removed 761 unused variants and 43 unused standalone components, resolved broken and duplicate sets, and consolidated six fragmented icon libraries into one. What remained was documented, structured and built around what the product actually used.
From 32% in use to 100%
In the old library, only 361 of the audited variant components had ever been used — just 32%. The rest added dead weight and made the components designers actually needed harder to find. In the rebuilt system, every one of the 182 component sets exists because the product uses it, and nothing enters the library until it appears across real screens.
One library, multiple products
The design system now lives in its own file, published as a shared library that every product file connects to. Components are maintained in one place, so an update to the library carries across every product using it. The same library supports multiple internal products and our partner’s product team, extending the same source of truth beyond the internal team.
Ongoing Product Development
The refactor closed most of the visible gap between Figma and production, but keeping both aligned still depends on manual updates across design and engineering. The next phase is a coded component library with Storybook as the shared reference, reducing the risk of design and code drifting apart again.
The existing Figma documentation will gradually move into Storybook as coverage grows, while the Figma library remains the place designers build product experiences. I’m currently building the first stories directly in the codebase alongside engineering, continuing to close the gap between design and implementation.
Continue Exploring
1,456 Components Down to 182 — One Scalable Design System
Transformed a redundant component graveyard into a documented, published single source of truth used across internal and partner product teams to build consistent experiences across multiple products.
My Role :
Design System Lead
Key Metrics :
Component Consolidation System Adoption
Team :
Product Design Frontend Engineering
Project Duration :
3 Months Continuous Evolution
Project Background
When I joined Cyberbay in 2024, the company had grown from an MVP into multiple digital products, while the design files had become cluttered and redundant along the way. Over the company’s first few years, several designers had contributed to building those products, but without a shared system. What designers and developers now had to work from wasn’t really a design system — it was an archive of everything anyone had ever created.
For cybersecurity products, consistency goes beyond visual polish — it shapes how reliable and trustworthy the experience feels across products. As Cyberbay began transitioning its products from dark mode to light mode and continued expanding its product ecosystem, establishing a consistent foundation became a priority.
Problem Overview
I knew the system was broken. The UI inventory showed me the scale of it.
I could already see the impact — inconsistent screens, duplicate components, and repeated back-and-forth with developers when the implemented UI didn’t match the designs. But before changing anything, I needed to understand where those inconsistencies were coming from and what was creating the most friction.
I ran a full UI inventory across the design files and product pages, auditing every component, variant, colour value and how much of the system was actually being used. What looked like general design debt became a clear, measurable list of what needed to be fixed.
The Component Graveyard
The existing system had 1,456 components, including 761 unused variants and 43 unused standalone components. They had been built and abandoned, but were still sitting in the assets panel competing for attention with the components designers actually needed.
50 Shades of Gray
The UI inventory found around 50 different shades of grey in use — far more than the product needed. Many were near-identical values, such as #e3e3e3 and #e2e2e2, adding unnecessary inconsistency across the interface.
Zero Documentation
None of the components had descriptions or usage guidance. Several component sets still used default names like Property 1 and Component 1, while others shared duplicate names. Designers couldn't tell what each component was for or how it should be used.
My Role
As Head of Product Design, I led the design system rebuild end-to-end — from the UI inventory and system architecture to rebuilding the component library and documenting the entire system.
Alongside the rebuild, I worked closely with front-end engineering to make the system easier to implement and reduce repeated back-and-forth during handoff. The published library became a shared foundation used across internal teams and our partner’s product team across multiple products.
Strategy & Approach
The UI inventory gave me a clear list of what was broken, but not what the new system should become. Fixing 1,456 components one by one would only create a tidier version of the same problem. I made the case for rebuilding from a clean foundation, using the old library only as an inventory of what the product actually needed.
That became the principle for the rebuild: build for real product use, not for what a design system is supposed to contain. A component only earned a place in the library once it appeared more than once across real screens, keeping one-offs from becoming unnecessary system components. The rebuild needed a structure that made the old failure modes impossible, rather than just cleaning up after them.
Atomic design as the structure
I structured the system using Atomic Design, organising components into atoms, molecules and organisms. This gave every component a defined place and made it easier to check what already existed before creating something new. It also gave the rebuild a clear order: atoms first, then molecules and organisms built from those finished parts. Changes to a base component could then carry through everywhere it was used instead of being repeated screen by screen.
Establishing a shared language and naming intentionally
Before defining the naming system, I conducted internal research and worked with the team to align on the language used across the product. The goal was to establish a consistent vocabulary for the system and remove ambiguity across teams.
That shared language guided how we named the system — by role rather than appearance. Headline Large instead of Heading 36 Bold, and text.secondary instead of grey-500.
Core Product Decisions
Rebuilding the system meant deciding what it would no longer allow, not just what it would contain. Most problems in the old library came from the same root: values, names and component decisions were being made locally instead of defined once and shared. Fifty greys, multiple button and icon sets, and zero documentation were different symptoms of the same problem.
The rebuild focused on removing the conditions that created them. Values were defined once and referenced, components were built to stay connected, documentation lived with the component, and the library was published from one dedicated source for products to use. What follows shows how those decisions shaped the finished system.
Building the foundations first
Before building a single component, I defined the system foundations as Figma Variables so components would reference shared values from the start rather than hardcoded ones. The architecture has two layers: primitives for colour, typography and dimensions, and semantic variables for colour, typography, border radius, border width and spacing. Semantic variables reference the primitive layer and are named by role, such as text.primary, border.muted and icon.secondary.
This structure replaced scattered values with one controlled foundation that can support theme or brand changes without rebuilding individual components. Colour combinations were also documented against WCAG 2.2 contrast requirements. From there, I built the core atoms on top of the same variables, giving every component a consistent foundation from the beginning.
No reason to detach
The old library pushed designers to detach components whenever the variant or property they needed was missing. I rebuilt each component with the states and controls needed for real use — text, icon, state, visibility and other instance-level changes — so adapting a component no longer meant breaking its connection to the library. The goal was simple: make the correct path the fastest one.
Everything was also rebuilt with auto layout. With 48% of the old library using fixed layouts, even reused components could break when real content changed. The new components resize with their content by default, making them more reliable across screens and products.
Removing guesswork through documentation
Every component is documented with its anatomy, variants, states, use cases and do/don’t guidance, with a description visible directly in the assets panel at the moment someone is choosing what to use. This makes the guidance part of the component itself rather than something written separately and forgotten.
Nothing enters the published library until it is documented. The goal is to answer the question at the point it matters most: which component should I use, and when?
Measurable Outcomes
The rebuild is easiest to judge by what disappeared. 1,456 components became 182 structured, documented component sets, while broken sets, duplicate names, scattered values and missing documentation were removed.
More importantly, designers began building from the library instead of around it. The same shift happened on the engineering side: the team refactored the frontend to align with the new library’s structure and naming.
1,456 components down to 182
The library went from 1,456 components to 182 structured component sets. This removed 761 unused variants and 43 unused standalone components, resolved broken and duplicate sets, and consolidated six fragmented icon libraries into one. What remained was documented, structured and built around what the product actually used.
From 32% in use to 100%
In the old library, only 361 of the audited variant components had ever been used — just 32%. The rest added dead weight and made the components designers actually needed harder to find. In the rebuilt system, every one of the 182 component sets exists because the product uses it, and nothing enters the library until it appears across real screens.
One library, multiple products
The design system now lives in its own file, published as a shared library that every product file connects to. Components are maintained in one place, so an update to the library carries across every product using it. The same library supports multiple internal products and our partner’s product team, extending the same source of truth beyond the internal team.
Ongoing Product Development
The refactor closed most of the visible gap between Figma and production, but keeping both aligned still depends on manual updates across design and engineering. The next phase is a coded component library with Storybook as the shared reference, reducing the risk of design and code drifting apart again.
The existing Figma documentation will gradually move into Storybook as coverage grows, while the Figma library remains the place designers build product experiences. I’m currently building the first stories directly in the codebase alongside engineering, continuing to close the gap between design and implementation.