Project Hydrogen

Project Hydrogen emerged from a straightforward yet ambitious idea: to create a design system as adaptable as hydrogen itself. Leading a cross-functional team of over 80 people across 18 teams, I spearheaded the development of a scalable design system that revolutionised how our organisation approached product development within the highly complex insurance and reinsurance sectors.

Faced with the challenge of bridging the gap between engineering, product, and design teams, we asked a crucial question: “How might we fuse these disciplines to deliver faster, better products for our partners and end-users?” The solution required more than just technical expertise—it necessitated building trust, creating alignment, and managing stakeholders across diverse regions with varied legal frameworks.

Through Project Hydrogen, we developed a flexible, modular design system capable of adapting to different jurisdictions, legal requirements, and branding needs. This system not only accelerated product development but also enabled seamless white-labelling while addressing intricate backend and legal considerations.

Introduction

When tasked with creating a design system that could scale effortlessly across diverse insurance and reinsurance products, I knew we had to think bigger than a conventional approach. Enter Project Hydrogen, named after the element hydrogen, known for its ability to bond and adapt with other elements. Much like its namesake, the system we needed to build had to be highly adaptable—scaling not just in design, but in functionality, legal compliance, and branding.

At the core of this endeavour was a crucial question: “How might we fuse engineering, product, and design so that we can build faster and more effective solutions for our partners and end-users?” This wasn’t just a technical challenge—it was a people challenge, with the need to bridge gaps between product, UX, and engineering teams that had been working in silos. To succeed, we needed not only to create an efficient system but to foster collaboration and trust across the organisation.

My role as the UX Manager and Design Lead meant not only developing the technical aspects of the system but also managing over 80 people across 18 teams, ensuring alignment across the board. This challenge was further complicated by the legal and regulatory requirements unique to each insurance jurisdiction we served. Our solution had to accommodate these complexities while also being flexible enough to enable rapid white-labelling for our partners.

Project Hydrogen was, in essence, a bold step towards transforming our approach to product development. The stage was set for a solution that would not only scale our products but also our ability to innovate across teams and regions.

Understanding White-Labelling

White-labelling is the process where a product developed by one company is rebranded and sold by another. It’s like producing the same product, but allowing different companies to customise it with their own branding.

In the insurance industry, white-labelling is more complex. Each product must not only be rebranded but also comply with different legal, regulatory, and market requirements across various regions.

In Project Hydrogen, the goal was to create a flexible design system that allowed us to quickly adapt products to meet these diverse needs, while maintaining efficiency and scalability.

Tension and Challenges

At the heart of Project Hydrogen was a seemingly simple yet deeply complex challenge: “How do we fuse engineering, product, and design to deliver faster, more adaptable products?”

The core issue wasn’t just technical. We were operating in a highly regulated industry where each insurance product needed to meet the legal, compliance and underwriting requirements of different jurisdictions. White-labelling wasn’t as simple as changing a logo—it meant reconfiguring the product’s core architecture to meet diverse compliance standards.

Internally, there was a significant disconnect between teams. Engineering, product, and UX teams operated in silos, leading to misalignment, inefficiencies, and friction. Trust needed to be built across these groups before we could move forward. Without that, we couldn’t develop a system that truly integrated all of our needs.

Recognising this, I initiated the development of the design system as a solution. It became clear that in order to work collaboratively, we needed a framework that allowed us to create scalable, customisable products while maintaining UX integrity and excellence. This design system would provide the consistency required to bridge gaps between teams, all while addressing the legal and technical challenges that arose from the diverse insurance markets we served.

Laying the Foundation

From the outset, I knew that creating a scalable design system required a clear, structured strategy. To address the long-term goals of faster product development, better collaboration, and adaptability to diverse markets, I crafted a three-part approach:

1. Pilot and Build a Scalable Design System: The cornerstone of my strategy was to develop a modular design system that would allow us to build products more efficiently. By piloting the system in a controlled environment, we could refine the approach before scaling it. This system would need to be adaptable to different jurisdictions, legal frameworks, and branding requirements, ensuring both flexibility and consistency.
2. Establish a New Communication Protocol and Hand-off Standardisation: To ensure seamless collaboration between teams, I introduced a standardised communication and hand-off process. This would streamline how design, product, and engineering teams worked together, eliminating misunderstandings and improving efficiency.
3. Create a User-Driven Design, Research, and Innovation Process: To keep the end-user at the heart of our development, I implemented a user-driven design process. This involved integrating user research and feedback directly into the design cycle, ensuring that our products were informed by real-world insights and aligned with user needs.

While all three components were essential for long-term success, the primary focus of this case study will be the pilot and development of the scalable design system. This solution was the foundation upon which the entire strategy was built, enabling us to achieve faster product development while maintaining UX integrity and regulatory compliance.

The First Attempt: Tailoring the Solution

In the early stages of Project Hydrogen, our team faced a significant challenge: how to efficiently adapt and rebrand our design system for each partner, especially across various legal territories. Each partner came with its own strict brand guidelines, adding complexity to the process of creating a unified yet customisable design system.

During my first pitch to management, I proposed a solution aimed at balancing consistency and flexibility. My idea was to standardise all core components—the foundational building blocks of the system—while allowing major brand elements, like logos and colour schemes, to be customised for each partner. This approach would enable faster scaling and ease of rebranding.

However, this proposal didn’t land as expected. Management pushed back hard: “Fully tailored solutions only. We must follow each partner’s brand guidelines and legal requirements. No exceptions!” The message was clear: no standardisation at the core level would be acceptable, as each partner required a bespoke solution that adhered to their brand identity and jurisdictional demands.

The feedback from management and partners didn’t dismay me. Instead, I went back to first principles, asking myself: “Where do our partners draw the line in their corporate design expectations?” I knew there had to be a balance between maintaining brand integrity and streamlining development. This insight led me to explore how we could still introduce some level of standardisation without compromising the fully tailored approach management and partners insisted on. It was clear that understanding the non-negotiables of each partner’s brand would be the key to refining our solution moving forward.

Addressing Corporate Design Expectations

After the pushback, I reframed my approach by focusing on a key question: “Where do our partners draw the line in their corporate design expectations?” This question became central to developing a scalable design system that could still meet the individual needs of each partner.

I began by breaking down a partner’s brand and UI guidelines into core components: Logo, Colour Scheme, Imagery, Grids and Proportions, Iconography, Shapes, Shadows, Animations and Motion, Typography, and Layout. These elements represented the building blocks of a product like a quote calculator website, but I needed to determine which of them were truly non-negotiable for maintaining brand identity.

To uncover this, I conducted UXR (user experience research) sessions not only with our management and partners but also with end-users. The feedback from these sessions provided a wealth of insight, helping me prioritise the importance of each guideline:

• P0: The highest priority elements—Logos, Typography, Colour Scheme, and Imagery—were essential for brand recognition. These were the key drivers in creating a strong web presence.
• P1: Shapes and Iconography followed, playing a secondary role in defining the user interface and overall experience.
• P2: Finally, Layout, Grids and Proportions, Animations and Motion, and Shadows were deemed lower priority, contributing more to aesthetics than to brand integrity.

This discovery proved to be a turning point. It revealed that the essence of a brand’s digital identity could be distilled into the four P0 elements: Logos, Typography, Colour Scheme, and Imagery. These components were not only non-negotiable but also the true drivers of brand recognition and user trust. Armed with concrete data from users, customers, and partners, I was able to refine our design system to focus on customising these critical elements while allowing the rest to remain standardised.

This insight didn’t just shape the design system—it made it significantly easier to convince leadership and all stakeholders of the approach. With evidence-backed priorities, I could demonstrate that focusing on these high-priority components would deliver a truly tailored experience for each partner while maintaining the scalability and efficiency necessary for rapid product development. The data-driven argument helped bridge the gap between the need for customisation and the realities of operational efficiency.

Structuring the Design System

The design system for Project Hydrogen was structured around three key layers, each designed to ensure the system could handle customisation, scalability, and efficiency across various partners, products and regions.

1. Core Brand UI Layer

The Core Brand UI Layer was the foundational pillar of the system, encompassing the most critical elements: Logos, Typography, Colour Scheme, Imagery, Shapes, and Icons. Based on later research, I added Shapes and Icons to this layer, recognising their importance in maintaining the brand’s identity. This layer was essential for ensuring that each product could be fully white-labeled to match the unique look and feel of each partner’s brand. It defined the visual identity and formed the backbone of every product we developed.

By focusing on these elements, we could guarantee that the core of each partner’s brand remained consistent, even as other parts of the product were standardised or customised.

2. Component Structure: Atomic Design Principles

The second layer of the system was the Component Structure, which followed the principles of atomic design. This methodology breaks down a system into small, reusable components that combine to form larger, more complex structures. Atomic design is organised into five stages:

• Atoms: The basic building blocks, such as buttons, icons, and input fields.
• Molecules: Groups of atoms working together, like a search bar (input field + button).
• Organisms: Collections of molecules that form distinct sections of a page, such as a header.
• Templates: Page-level layouts that contain groups of organisms, defining the structure but not the content.
• Pages: Final implementations of templates with real content, ready for deployment.

Advantages of Atomic Design:

• Reusability: Components can be reused across multiple products, making development faster and more efficient.
• Consistency: By using the same components across different products, we ensured a uniform user experience.
• Scalability: The system could grow organically, adding new components without disrupting existing structures.

This modular structure allowed us to create products faster while maintaining a high level of consistency and customisation.

3. Tokenisation: Streamlining Customisation and Quality Control

The final layer was Tokenisation, which played a critical role in maintaining operational efficiency and quality control. Tokens are named variables that store design decisions, such as colour values, spacing, or typography settings. This allowed us to quickly customise components directly in the codebase based on design changes made in Figma.

I employed a strategy using alias tokens and component-specific tokens, rather than relying on global tokens. Here’s why this decision was key:

• Alias Tokens: These tokens represented values like primary or secondary colours and could be linked to specific brand elements, allowing us to adapt components easily for different partners.
• Component-Specific Tokens: Instead of using global tokens that applied universally, component-specific tokens gave us the flexibility to make fine-tuned adjustments at the component level. This was especially important for maintaining brand integrity while allowing for flexibility in customisation.

Pros of This Approach:

• Greater Flexibility: By using alias and component-specific tokens, we could adapt designs on a granular level without affecting the entire system.
• Efficiency: Changes made in Figma could be reflected directly in the codebase, streamlining the handoff process and reducing errors.
• Brand Integrity: This approach ensured that key brand elements were preserved while allowing for quick customisation.

Cons of Global Tokens:

• Limited Customisation: Global tokens, while simpler, could apply uniform changes across the system, making it harder to fine-tune elements for specific brand needs.
• Reduced Precision: With global tokens, there’s less room to tweak individual components without affecting the entire design, which could compromise brand-specific requirements.

By adopting this layered approach, we struck a balance between flexibility, operational efficiency, and quality control. The tokenisation layer in particular ensured that design and development could remain closely aligned, enabling us to deliver high-quality, customised products quickly and consistently.

By adopting this layered approach, we struck a balance between flexibility, operational efficiency, and quality control. The tokenisation layer in particular ensured that design and development could remain closely aligned, enabling us to deliver high-quality, customised products quickly and consistently.

Though the design system was a monumental first step, there was still work to be done in optimising it for configuration and localisation. Each jurisdiction presented its own compliance and legal challenges, and the system had to be flexible enough to adapt to country-specific requirements such as localisation, language support, and payment processing regulations. These elements were crucial for ensuring the system could be deployed smoothly across multiple regions without compromising on legal or operational standards.

That being said, the first iteration of the design system worked exceptionally well as a proof of concept for four different projects. The structured approach, combined with a communication protocol I established, improved collaboration between product teams, engineering, and UX. This streamlined communication and handoff process helped break down silos, ensuring that all teams worked more efficiently and with greater alignment. The groundwork was laid for even greater optimisation as the system evolved to meet the specific needs of each jurisdiction.

A Flawed Approach

During the development of the design system, one of the biggest mistakes we made was our initial approach to creating components. We started by following a checklist of components, aiming to design and build each one based on all known components across the web. At first, this seemed like a comprehensive strategy—ensuring we had a component for every possible scenario.

I realised that this approach was highly inefficient. It was slow, expensive, and lacked any real strategic focus. The problem was that by the time we finished building one component, a new requirement or variation would emerge, rendering the previous component obsolete. This not only caused us to waste valuable resources but also put our launch timelines at risk. We were in a constant cycle of building components that were either outdated or unnecessary.

“How can I make this approach more effective?” I asked myself at the time of the setback. It became clear that we needed a more flexible and strategic process that could adapt to changing requirements without draining resources or slowing down the process.

The goal was no longer to build everything upfront but to create a structure that could respond to immediate needs while maintaining the flexibility to expand as necessary.

A Flawed Approach: The Path to a Better Solution

After recognising the inefficiencies in our initial component development strategy, I realised we needed a new approach—one that was both strategic and adaptable. To resolve these issues, I implemented two key initiatives: the Design System Pilot and the Reference Product System.

1. The Design System Pilot and Evolution Metric

Rather than continuing to build an exhaustive list of components, I introduced the concept of a design system pilot. This approach shifted our focus from building every possible component to strategically selecting the most impactful ones based on real project needs. We evaluated all existing projects and products on a partner-to-project basis, using the following criteria and combination of metrics:

• High-Value Elements: We prioritised projects that contained components critical to the product’s core functionality and brand representation.
• UXR Insights: User research and feedback helped us determine which components had the most significant impact on the user experience.
• Business Impact: We focused on projects with components that would generate the highest return on investment for both us and our partners.

Using this evaluation method, we ensured that the design system pilot was built around the most strategically relevant components. After selecting a project, we expanded our core component catalogue as needed, ensuring the system remained flexible and adaptable. This allowed us to efficiently scale the system for other white-label products and solutions, always focusing on what truly mattered for each partner.

2. The Reference Product System

The second key initiative was the creation of the Reference Product System—a collection of white-labeled skeletons for key component areas. Each skeleton served as a flexible foundation that could be quickly customised and configured for different jurisdictions, addressing localisation and product-specific legal requirements.

These skeletons provided adaptable templates that streamlined the white-labeling process. Each skeleton could be configured to meet the legal, compliance, and localisation needs of each market, solving one of the biggest challenges in delivering products that met both brand and regulatory demands for our partners.

The system was designed to be extremely flexible, leveraging Storybook to allow for seamless customisation. Each component could be configured with a single click to meet the specific requirements of different jurisdictions, territories, brand and legal compliance needs. This high level of configurability ensured that our design system could quickly adapt to any market, making it both scalable and efficient for product development across diverse legal frameworks.

The Resolution: Outcome and Impact

By refining our approach and implementing key strategies, Project Hydrogen delivered impressive results that fundamentally transformed our product development process. The combination of the Design System Pilot, the Reference Product System, and the use of Storybook for flexible component configuration proved to be a game-changer.

Key Outcomes:

• 55% Increase in Partner Onboarding Speed: The ability to quickly configure components for different jurisdictions and territories dramatically accelerated the onboarding process for insurance and reinsurance partners.
• 23% Conversion Rate Boost: By focusing on the most critical, user-driven components (P0 elements) and streamlining the user experience, we saw a significant improvement in conversion rates.
• 36% Reduction in Error Tickets: The introduction of tokenisation, paired with the communication protocol I established, ensured tighter integration between design, development, and product teams. This led to a marked reduction in errors and miscommunication during the development process.

The design system’s extreme flexibility, facilitated by Storybook, allowed us to configure components with ease for specific legal, territorial, and branding needs. This adaptability made our products more scalable and efficient, ensuring compliance without compromising on speed or quality.

Beyond these measurable results, the impact of Project Hydrogen extended to the culture within the organisation. The system became a shared framework for collaboration, bringing previously siloed teams—engineering, product, and UX—into alignment. The communication protocol we established strengthened this cross-team collaboration, fostering transparency and shared ownership of the design system’s success.

Ultimately, Project Hydrogen was not just a technical achievement but a strategic one, driving both operational efficiency and a new level of agility in product development. It empowered us to meet the diverse needs of our partners while positioning the business for future growth and innovation.