Shipped
Scaling a Design System
2023 - 2025
Design with technical awareness
Shipped
Scaling a Design System
2023 - 2025
Design with technical awareness
Shipped
Scaling a Design System
2023 - 2025
Design with technical awareness
Gemini II is the name I gave to our design system at Troop. Inspired by NASA’s Project Gemini, known as the “Bridge to the Moon”, our system acted as a bridge between our technology and end users. The project had two major parts to it: a high-fidelity Figma design system, and a StoryBook library, built with the close collaboration with our Front-End Leads.
Product
Figma design system
StoryBook library
Services
UI design
Design system building
My role
Product Design Lead
Timeline
2023 - 2025
Gemini II is the name I gave to our design system at Troop. Inspired by NASA’s Project Gemini, known as the “Bridge to the Moon”, our system acted as a bridge between our technology and end users. The project had two major parts to it: a high-fidelity Figma design system, and a StoryBook library, built with the close collaboration with our Front-End Leads.
Product
Figma design system
StoryBook library
Services
UI design
Design system building
My role
Product Design Lead
Timeline
2023 - 2025
Gemini II is the name I gave to our design system at Troop. Inspired by NASA’s Project Gemini, known as the “Bridge to the Moon”, our system acted as a bridge between our technology and end users. The project had two major parts to it: a high-fidelity Figma design system, and a StoryBook library, built with the close collaboration with our Front-End Leads.
Product
Figma design system
StoryBook library
Services
UI design
Design system building
My role
Product Design Lead
Timeline
2023 - 2025
The challenge
By this stage, the platform was already established, but it carried design and engineering debt. Different designers had contributed over time, creating some inconsistencies in the interface and interactions, while engineering had to maintain multiple environments and had a mix of custom code and libraries. On top of that, our focus had shifted in the search for product–market fit. This meant cleaning up the interface to cater to a new market and to ensure that it could easily scale.
Problem statement
Troop’s platform had grown quickly, but its design and engineering foundations were not keeping pace. Without a unified system, we risked the product becoming tedious to maintain and slow to scale.
The challenge
By this stage, the platform was already established, but it carried design and engineering debt. Different designers had contributed over time, creating some inconsistencies in the interface and interactions, while engineering had to maintain multiple environments and had a mix of custom code and libraries. On top of that, our focus had shifted in the search for product–market fit. This meant cleaning up the interface to cater to a new market and to ensure that it could easily scale.
Problem statement
Troop’s platform had grown quickly, but its design and engineering foundations were not keeping pace. Without a unified system, we risked the product becoming tedious to maintain and slow to scale.
The challenge
By this stage, the platform was already established, but it carried design and engineering debt. Different designers had contributed over time, creating some inconsistencies in the interface and interactions, while engineering had to maintain multiple environments and had a mix of custom code and libraries. On top of that, our focus had shifted in the search for product–market fit. This meant cleaning up the interface to cater to a new market and to ensure that it could easily scale.
Problem statement
Troop’s platform had grown quickly, but its design and engineering foundations were not keeping pace. Without a unified system, we risked the product becoming tedious to maintain and slow to scale.
From feature to product
We evolved from an enterprise platform where all functionality occurred on one screen overlaid with navigation, cards, and tables, to our latest version standardised using our design system. What started as a single-feature application grew into a modular, responsive product built to scale.
From feature to product
We evolved from an enterprise platform where all functionality occurred on one screen overlaid with navigation, cards, and tables, to our latest version standardised using our design system. What started as a single-feature application grew into a modular, responsive product built to scale.
From feature to product
We evolved from an enterprise platform where all functionality occurred on one screen overlaid with navigation, cards, and tables, to our latest version standardised using our design system. What started as a single-feature application grew into a modular, responsive product built to scale.
->
->
Part 1
Building in Figma
My team and I conducted a UI audit of the current platform and previous design system. We identified both the most frequently used and the most complex components, then ranked them by frequency and importance. We worked in alongside PrimeVue, as that was our front-end framework, and used this as our foundation. This ensured our designs were aligned with the development capabilities.
Due to the nature of startups, we always had something to do, so we couldn’t stop work in the middle of a sprint to work on the design system. We overcame this by building our components on demand for the projects we were working on. Thereafter, they were merged into the design system file, allowing us to keep shipping while steadily expanding the system. Regular communication within my team ensured that we were not replicating components.
The goal was to create alignment across designers and teams, eliminate custom designs, and decrease the number of detached components. With the new design system in place, the number of detached components was as low as 2.8%. This meant the design system was successful in being scalable, catering for all project requirements, and had been adopted by my design team.
Some stats
97.2%
Of components were not being detached
Part 1
Building in Figma
My team and I conducted a UI audit of the current platform and previous design system. We identified both the most frequently used and the most complex components, then ranked them by frequency and importance. We worked in alongside PrimeVue, as that was our front-end framework, and used this as our foundation. This ensured our designs were aligned with the development capabilities.
Due to the nature of startups, we always had something to do, so we couldn’t stop work in the middle of a sprint to work on the design system. We overcame this by building our components on demand for the projects we were working on. Thereafter, they were merged into the design system file, allowing us to keep shipping while steadily expanding the system. Regular communication within my team ensured that we were not replicating components.
The goal was to create alignment across designers and teams, eliminate custom designs, and decrease the number of detached components. With the new design system in place, the number of detached components was as low as 2.8%. This meant the design system was successful in being scalable, catering for all project requirements, and had been adopted by my design team.
Some stats
97.2%
Of components were not being detached
Part 1
Building in Figma
My team and I conducted a UI audit of the current platform and previous design system. We identified both the most frequently used and the most complex components, then ranked them by frequency and importance. We worked in alongside PrimeVue, as that was our front-end framework, and used this as our foundation. This ensured our designs were aligned with the development capabilities.
Due to the nature of startups, we always had something to do, so we couldn’t stop work in the middle of a sprint to work on the design system. We overcame this by building our components on demand for the projects we were working on. Thereafter, they were merged into the design system file, allowing us to keep shipping while steadily expanding the system. Regular communication within my team ensured that we were not replicating components.
The goal was to create alignment across designers and teams, eliminate custom designs, and decrease the number of detached components. With the new design system in place, the number of detached components was as low as 2.8%. This meant the design system was successful in being scalable, catering for all project requirements, and had been adopted by my design team.
Some stats
97.2%
Of components were not being detached
Part 2
Integrating with StoryBook
With a fully functioning design system in place and widely adopted across teams, we saw a major drop in design inconsistencies, but some were still present in the product.
This led us to the next phase: integrating with StoryBook, a front-end tool for building UI components and pages in code. Working closely with our Front-end Leads, we created a near one-to-one match between the designs and coded components.
From there, the Engineering team began replacing custom-built components with the Storybook versions and incrementally deprecated older legacy ones.
One of our most frequently used component in the product was our table. In the past, as work went on and through different people and product streams, variations of the table were created, all with slight differences. This was a big frustration for the Front-end team as they never knew which was the latest version. Thanks to the design system and StoryBook initiative, we were able to merge 5 different tables in to 1.
Some stats
80%
Reduction in the table component debt
Part 2
Integrating with StoryBook
With a fully functioning design system in place and widely adopted across teams, we saw a major drop in design inconsistencies, but some were still present in the product.
This led us to the next phase: integrating with StoryBook, a front-end tool for building UI components and pages in code. Working closely with our Front-end Leads, we created a near one-to-one match between the designs and coded components.
From there, the Engineering team began replacing custom-built components with the Storybook versions and incrementally deprecated older legacy ones.
One of our most frequently used component in the product was our table. In the past, as work went on and through different people and product streams, variations of the table were created, all with slight differences. This was a big frustration for the Front-end team as they never knew which was the latest version. Thanks to the design system and StoryBook initiative, we were able to merge 5 different tables in to 1.
Some stats
80%
Reduction in the table component debt
Part 2
Integrating with StoryBook
With a fully functioning design system in place and widely adopted across teams, we saw a major drop in design inconsistencies, but some were still present in the product.
This led us to the next phase: integrating with StoryBook, a front-end tool for building UI components and pages in code. Working closely with our Front-end Leads, we created a near one-to-one match between the designs and coded components.
From there, the Engineering team began replacing custom-built components with the Storybook versions and incrementally deprecated older legacy ones.
One of our most frequently used component in the product was our table. In the past, as work went on and through different people and product streams, variations of the table were created, all with slight differences. This was a big frustration for the Front-end team as they never knew which was the latest version. Thanks to the design system and StoryBook initiative, we were able to merge 5 different tables in to 1.
Some stats
80%
Reduction in the table component debt
Impact
One of the biggest benefits was that my team could rapidly produce designs and mockups. Changes were quicker, and feedback focused more on the customer experience than small UI issues. Together with well-documented designs and flows, our feedback loop with the Engineering team was quicker and both sides were able to work more efficiently.
We were now able to focus on the broader questions around the flows and behaviour. This meant I could dedicate more time towards building our Design team’s workflow and internal process. Design’s role moved from execution-focused work to customer-focused solutions.
Impact
One of the biggest benefits was that my team could rapidly produce designs and mockups. Changes were quicker, and feedback focused more on the customer experience than small UI issues. Together with well-documented designs and flows, our feedback loop with the Engineering team was quicker and both sides were able to work more efficiently.
We were now able to focus on the broader questions around the flows and behaviour. This meant I could dedicate more time towards building our Design team’s workflow and internal process. Design’s role moved from execution-focused work to customer-focused solutions.
Impact
One of the biggest benefits was that my team could rapidly produce designs and mockups. Changes were quicker, and feedback focused more on the customer experience than small UI issues. Together with well-documented designs and flows, our feedback loop with the Engineering team was quicker and both sides were able to work more efficiently.
We were now able to focus on the broader questions around the flows and behaviour. This meant I could dedicate more time towards building our Design team’s workflow and internal process. Design’s role moved from execution-focused work to customer-focused solutions.
Reflection
A strong, scalable design system is non-negotiable for any stage in a company’s growth. While the first version was built relatively early on, I’d advocate even more strongly for this in an early-stage company. An investment like this has a large impact on the future of a company as is scales.
I’d lay the groundwork early on so I can focus on larger things such as understanding the product vision, agreeing upon a platform behaviour and interactions, and forming a good working relationship with the Engineering team.
Sharpening my skills
In my free time, I build design systems to teach myself and refine my process. I built a ChatGPT-4o design system clone that I launched for free to the Figma Community to put theory into practise.
Reflection
A strong, scalable design system is non-negotiable for any stage in a company’s growth. While the first version was built relatively early on, I’d advocate even more strongly for this in an early-stage company. An investment like this has a large impact on the future of a company as is scales.
I’d lay the groundwork early on so I can focus on larger things such as understanding the product vision, agreeing upon a platform behaviour and interactions, and forming a good working relationship with the Engineering team.
Sharpening my skills
In my free time, I build design systems to teach myself and refine my process. I built a ChatGPT-4o design system clone that I launched for free to the Figma Community to put theory into practise.
Reflection
A strong, scalable design system is non-negotiable for any stage in a company’s growth. While the first version was built relatively early on, I’d advocate even more strongly for this in an early-stage company. An investment like this has a large impact on the future of a company as is scales.
I’d lay the groundwork early on so I can focus on larger things such as understanding the product vision, agreeing upon a platform behaviour and interactions, and forming a good working relationship with the Engineering team.
Sharpening my skills
In my free time, I build design systems to teach myself and refine my process. I built a ChatGPT-4o design system clone that I launched for free to the Figma Community to put theory into practise.
Time in Cape Town, ZA
00:00
© 2025 Josh York Mc Donald
Time in Cape Town, ZA
00:00
© 2025 Josh York Mc Donald
Time in Cape Town, ZA
00:00
© 2025 Josh York Mc Donald