Project Hydrogen

Project Hydrogen began with a simple yet ambitious idea: to create a design system as adaptable as its namesake. I recommended the design system as a strategic solution to streamline product development and improve collaboration across teams. As the UX and Project Manager, I led over +35 people across 6 xFN teams to make this vision a reality.

The process started with a clear goal: “How might we bring engineering, product, and design together to deliver faster, better solutions for our partners and end-users?” I designed the Minimum Viable Product (MVP) and conducted a proof-of-concept to validate the system’s potential. This initial work demonstrated how a modular approach could meet diverse needs, including legal requirements, regional differences, and branding demands.

Once the foundation was proven, I expanded the system to teams across the organisation. This required fostering alignment, managing stakeholders, and ensuring the system could scale without losing flexibility.

The result was a design system that not only sped up product development but also allowed for seamless white-labelling and addressed the complex requirements of the insurance and reinsurance sectors. Project Hydrogen became a tool that empowered teams to work smarter and build better products.

Introduction

In the fast-paced world of white-labeling insurance and reinsurance products, we were constantly customizing solutions for each partner. This approach, while necessary, came at a cost—long development cycles, fragmented processes, and a growing complexity that threatened to overwhelm our teams.

The challenges were amplified by the international nature of our operations. Each region brought its own regulatory requirements and legal frameworks, further complicating the customization process. At the same time, we were managing multiple partner products simultaneously, creating a whirlwind of competing demands and compounding inefficiencies.

Amid this environment, it became clear to me that our way of working wasn’t sustainable. We needed a solution that could unify our efforts, reduce duplication, and simplify the development process without sacrificing the UX and adaptability required for diverse markets.

I asked myself the following question: “How might we fuse engineering, product, and design so that we can build faster and better products for us, our partners, and end-users?”

This question became the foundation for Project Hydrogen—a strategic initiative to streamline product development, introduce consistency, and empower our teams to work smarter, not harder.

What is white-labelling?

At its core, white-labeling is the process of creating a product and enabling other companies or partners to rebrand it as their own. For consumer goods, this is often straightforward—repackaging the product is usually sufficient.

In the world of insurance and reinsurance, however, white-labeling is a far more intricate undertaking. These products are deeply tied to regulatory frameworks, compliance requirements, and country-specific laws. Each jurisdiction brings its own challenges, demanding precision and adaptability.

Adding to this complexity are the branding expectations of business partners. Each partner arrives with their own set of rebranding guidelines, ranging from the meticulously detailed to the frustratingly vague. Yet, regardless of the clarity of their requirements, one expectation remains constant: excellence.

Tension and Challenges

The challenges we faced weren’t just technical—they were deeply rooted in competing priorities across teams, all operating within a fast-paced and demanding environment.

On one side, the product team demanded that each product be fully tailored to meet our partners’ specific needs: brand guidelines, jurisdictions, and unique expectations. For them, customization was non-negotiable.

On the other side, this level of customization placed immense strain on our engineering teams, whose workloads ballooned under the weight of complex requirements. Meeting demand often left little time for optimization, innovation, or future-proofing.

I found myself trapped in a frustrating position with limited opportunity to challenge assumptions or propose innovations. This problem was further compounded by communication silos across teams. Product, engineering, and design often operated with misaligned priorities, resulting in inefficiencies and, at times, conflicting outputs. These tensions fed into a larger issue: we weren’t building systems—we were reacting to demands.

Faced with this situation, I turned to first-principles thinking to strip away the noise and focus on the underlying truth:

1. What are we really trying to achieve?
   Our goal wasn’t just to build products faster but to create scalable, adaptable solutions that could support our partners while preserving our internal efficiency.
2. What constraints are we dealing with?
   The customization required by partners and jurisdictions was essential but needed to be balanced against the realities of engineering bandwidth and our ability to deliver consistent quality.
3. How can we align priorities across teams?
   Without a unified strategy, the tension between customization and scalability would continue to grow, slowing us down and diluting our efforts.

It became clear that what we needed wasn’t more tools or quicker fixes—it was a design system. A centralized, modular framework could bridge the gap between customization and efficiency, allowing us to meet the diverse demands of our partners while maintaining agility and quality.

But recommending a design system wasn’t without trade-offs.

• Customization vs. Scalability: A design system required partners to work within predefined frameworks, reducing the degree of tailoring for each product. However, this trade-off would enable faster delivery and more consistent quality.
• Upfront Investment vs. Long-Term Efficiency: Building the system would require significant upfront effort, but it promised to drastically reduce workloads and streamline processes over time.
• Autonomy vs. Alignment: Teams would need to adapt to a shared approach, sacrificing some autonomy in exchange for greater cohesion and clarity.

These trade-offs were worth it. The cost of maintaining the status quo—slow delivery, communication breakdowns, and an inability to innovate—was far greater than the effort required to implement a scalable solution.

With this realization, I crafted and presented my first recommendation for a design system to the wider leadership team. They acknowledged the problem and agreed with my proposal, setting the stage for change.

Laying the Foundation

In a leadership meeting, I presented a question that got straight to the heart of our challenges: “How might we fuse engineering, product, and design so that we can build faster and better products for us, our partners, and end-users?”

This question set the stage for a discussion about how we could work smarter and deliver value more effectively. To tackle these challenges, I proposed three straightforward recommendations (solutions):

1. Pilot and Build a Scalable Design System
   At the center of my proposal was the idea of creating a modular design system. This system would help us build products more efficiently while meeting the unique needs of our partners. It would be flexible enough to adapt to different legal requirements and branding needs, but consistent enough to reduce redundant work. I suggested starting with a pilot to test and refine the system before rolling it out across the company.
2. Standardise Communication and Hand-offs
   Miscommunication and inconsistent workflows between teams were causing delays and inefficiencies. I proposed creating a clear process for how teams collaborate and hand off work. This would ensure everyone was on the same page and working toward the same goals.
3. Adopt a User-Driven Design Process
   To make sure our products were meaningful and effective, I recommended integrating user research directly into the design process. This would keep the needs of the end-user at the center of our work and ensure we were solving the right problems.

The most critical part of my proposal was the scalable design system, which would address the biggest pain points in our workflow and serve as the foundation for everything else.

Leadership agreed with my recommendations, recognising the potential to improve how we worked and delivered products. But what I didn’t realise at the time was the skepticism within the product team. Some were concerned that the design system might limit flexibility or fail to meet the unique demands of our partners.

This doubt would later emerge as a key challenge—proving not only that the system could work but also that it could win over those who questioned its value.

The first attempt

As I mentioned earlier, the root of our problem lay in the tailoring and rebranding of our products. This rigid approach created a vicious cycle: strict demands for customisation placed increasing workloads on the engineering team, which in turn impacted the quality and consistency of our UX.

To address this challenge, I took my first action: I set up a meeting with representatives and leads from product, engineering, and design to present a potential solution.

I introduced the concept of Design Systems, explaining their benefits and demonstrating how strategic standardisation,  tokenisation and localisation of components could help us build faster and deliver more tailored products without sacrificing quality. My pitch highlighted how this approach could align with branding guidelines and legal requirements while significantly improving efficiency.

To my surprise, I was met with a resounding “No” from the product teams. Their response was clear:

The resistance caught me off guard because I had already secured leadership buy-in for the concept. However, I quickly realised that to make the design system a success, it wasn’t enough to have senior leadership support—I needed the trust and alignment of the teams who would be implementing it.

I later discovered a key reason for their skepticism: a previous attempt by the engineering team to standardise components had backfired. They had used a public component library across products, but one partner strongly disliked the look and feel, leading to complaints. This experience had cemented the product teams’ hardline stance on full customisation.

It became clear that introducing a design system wouldn’t just be about creating the system itself—it would be about changing perceptions, addressing past failures, and proving that standardisation could enhance, not hinder, customisation.

The feedback from the product leads didn’t deter me. Instead, I returned to first principles, asking: ‘Where do our partners draw the line in their corporate design expectations?’ I knew the solution lay in striking a balance—preserving brand integrity while streamlining development.

This insight drove me to explore how we could introduce a level of standardisation without compromising the fully tailored approach demanded by management and partners. Understanding each partner’s non-negotiables became the focal point for refining our solution. It was clear that success would depend on aligning standardisation with the boundaries of their brand expectations.

Addressing expectations

To determine which brand elements truly mattered for our partners, I designed a systematic A/B/n test around our most widely used page: the quote calculator. The goal was twofold:

1. Identify which components (e.g., typography, color scheme) most affected perceived brand integrity.
2. Validate whether a standardized approach could still respect the “must-have” elements of each partner’s brand.

I started by isolating one variable per design variation (for instance, typography in one version, iconography in another) to clearly see the impact of each change. This approach reduced confounding factors and made it simpler to pinpoint what exactly triggered a preference.

To minimize bias, I randomized the order in which participants saw each version. This prevented any single version from becoming the default or “first impression” for all participants, ensuring more balanced results.

Participants were then asked the core question:
“Which design best represents your brand guidelines?”
They could choose among:

• Design A
• Design B
• “No difference”

When a participant selected one of the designs, I asked a follow-up question:
“Why do you prefer this version?”

This second question was critical. It encouraged respondents to articulate which specific brand elements (e.g., color palette, typography, iconography) influenced their choice. By focusing on the “why,” I could separate surface-level preferences (like a casual dislike of a certain font) from more fundamental branding concerns (such as legibility or brand consistency).

Providing a “No difference” option gave insight into whether certain changes were too subtle—or simply not central enough—to matter for brand identity. This feedback helped me see which elements might be prime candidates for standardization, since participants didn’t perceive them as make-or-break for brand integrity.

I made sure to involve partners across the spectrum, from those with lax brand guidelines to those known for strict rules. This broad participant base helped me gather robust data on which elements truly defined brand identity across different branding philosophies.

The insights from these tests helped me prioritise the elements of a brand’s digital identity into three categories:

P0: Non-Negotiable (Highest Priority)

• Logos
• Typography
• Colour Scheme
• Imagery

These were the essential drivers of brand recognition and the foundation of a strong web presence.

P1: Important (Secondary Priority)

• Shapes
• Iconography

These elements supported the user interface and contributed to the overall brand experience.

P2: Aesthetic (Lower Priority)

• Layout
• Grids and Proportions
• Animations and Motion
• Shadows

While enhancing aesthetics, these elements were less critical for maintaining brand integrity.

Turning point

This discovery was pivotal. It revealed that a brand’s digital identity could be distilled into four P0 elements—Logos, Typography, Colour Scheme, and Imagery. These were the true drivers of brand recognition, while other elements like layouts, shadows, and animations played a far less critical role.

The insight was clear: our strict stance on rebranding had been unjustified. There was far more room for standardizationthan we had initially believed. By focusing on these high-priority components, we could maintain brand integrity while simplifying development, paving the way for a scalable approach.

This realization didn’t just shape the design system—it transformed my ability to gain stakeholder support. Armed with data, I could confidently show that we didn’t have to choose between customization and efficiency. The evidence opened the door for Project Hydrogen and the design system pilot.

I still remember the head of engineering saying, “Please work with us to implement it.” This was more than just encouragement—it was the validation needed to move forward with a bold, strategic vision for how we built and delivered our products.

The Design System MVP

With a clear understanding of how to prioritise branding guidelines, I set out to build the Minimum Viable Product (MVP) for the design system. It was structured around three key layers:

• Core Brand UI – Foundational brand identity
• Component Structure – UI components and library
• Tokenisation – Bridging design and engineering

Each layer addressed the balance between customisation and efficiency, ensuring we could meet our partners’ expectations while streamlining development.

1. Core brand UI layer

The Core Brand UI Layer focused on the most critical elements of a partner’s brand—those identified as P0 perceived brand identity items during earlier research: Logos, Typography, Colour Scheme, Imagery, Shapes, and Icons. These elements formed the foundation of brand recognition and were non-negotiable for maintaining identity across products.

I then consolidated all guideline parameters into a comprehensive Figma template library. More than just a static collection, this library was designed as a dynamic instance. Each instance could be tailored to reflect the unique brand guidelines of individual partners.

This layer served as the core pillar and control center of the entire design system, dynamically linking to the layers above it—Component Structure, Tokenisation, and the final white-labeled product. For each partner, branding guidelines and updates flowed seamlessly through the system, ensuring fast and consistent brand management.

What It Solved:

The Core Brand UI Layer addressed several critical challenges:

1. Preserved brand integrity: By focusing on the P0 elements, it guaranteed that each product retained the unique look and feel required by partners while simplifying lower-priority design elements.
2. Streamlined rebranding: With the Figma template library instance, we could rebrand components and update designs with just a few clicks, drastically reducing the time and effort needed for customisation.
3. Enabled scalability: This layer acted as the backbone for the entire design system, ensuring that customisation could scale across partners and products without compromising quality or efficiency.
4. Unified the system: By tying this layer to the Component Structure and Tokenisation, changes could propagate automatically, ensuring alignment across all aspects of the design system and reducing errors.

2. Component Structure

The second layer was built using atomic design principles—a method that breaks down a design components into small, reusable pieces:

• Atoms: Basic elements like buttons or icons.
• Molecules: Groups of atoms working together, like a search bar.
• Organisms: Larger structures, such as a header.
• Templates: Page-level layouts without content.
• Pages: Final designs with real content, ready for use.

This structure made our designs:

• Reusable: Components could be used across different products, saving time.
• Consistent: Shared components ensured a unified look and feel.
• Scalable: New components could be added without disrupting the system.

What It Solved:

The modular structure allowed us to deliver products faster while keeping the design consistent and adaptable.

It also introduced flexibility, enabling further customisation of components in extreme cases where specific needs arose. However, its primary role was to act as a framework for standardisation.

These components served as skeletons, dynamically updated by the Core Brand UI Layer. This integration ensured that any changes to the core layer automatically cascaded to all connected components, maintaining consistency across products.

The modular structure also enhanced quality control. Instead of manually updating components for each partner, we could update the component layer with the latest trends or improvements and push these changes to all partners simultaneously.

Additionally, it allowed us to create country- and jurisdiction-specific components or variants, ensuring compliance with regional requirements without disrupting the overall design system.

This approach balanced standardisation with adaptability, empowering us to scale efficiently while meeting diverse partner and market needs.”

3. Tokenisation

The final layer of our system was Tokenisation, which played a critical role in operational efficiency and quality control. Tokens are named variables that store design decisions—such as colour values, spacing, typography, and even copy—allowing changes made in Figma to flow directly into the codebase.

I used a mix of alias tokens and component-specific tokens instead of relying on global tokens:

• Alias Tokens: Represented values like primary or secondary colours, linked to specific brand elements. This made it easy to adapt components for different partners without extensive rework.
• Component-Specific Tokens: Gave us precise control at the component level, preserving brand integrity while still allowing fine-tuned customisation.

Why This Matters

• Greater Flexibility: We could adapt designs on a granular level, rather than applying uniform changes everywhere.
• Efficiency: Because design updates in Figma pushed directly to the front-end, development was faster and less error-prone.
• Brand Integrity: Crucial brand elements were locked in, while non-essentials remained adaptable.

Drawbacks of Global Tokens

• Limited Customisation: Changing a global token affects the entire system, making it difficult to fine-tune specific components.
• Reduced Precision: Small adjustments for a single brand can inadvertently affect every product.

By adopting this layered token approach, we ensured that design and development stayed closely aligned. The result was high-quality, customised products delivered quickly and at scale—further reinforcing the balance between flexibility, efficiency, and brand consistency.

4. Bringing it all together

The design system MVP unified everything we had built.

• The Core Brand UI Layer protected each partner’s unique identity, ensuring their branding was at the forefront.
• The Component Structure provided reusable and consistent building blocks.
• The Tokenisation Layer streamlined customisation, allowing us to adapt designs quickly without sacrificing quality.

This layered approach wasn’t just about saving time—it created a shared system that aligned design, product, and engineering teams. By balancing flexibility, efficiency, and brand identity, it transformed how we developed products.

In the example below, you can see how everything came together. We were able to quickly deliver standardised yet brand-unique white-label experiences, significantly reducing development times while maintaining quality and consistency. This was the first step toward setting a new standard for scalability and collaboration.

The design system MVP was a strong first step, but it was far from the final product. Each jurisdiction brought its own compliance and legal challenges, meaning the system still needed to adapt to country-specific requirements like localisation, language support, and payment processing rules. These factors were crucial to ensure the system could be deployed effectively across multiple regions without complications.

Even in its early stage, the design system MVP proved its value. It successfully supported four different projects as a proof of concept, demonstrating how a structured approach and clear communication protocols could streamline workflows. By breaking down silos between product teams, engineering, and UX, we created better alignment and improved efficiency.

While there was still work to do, the MVP laid a solid foundation for future iterations. It showed that with the right structure and collaboration, we could build a scalable system capable of meeting the diverse needs of different markets.

A Flawed Approach

In the early stages of building the design system, we made a critical mistake. Our initial approach to creating components seemed thorough, even ambitious: we aimed to design and build every conceivable component based on a comprehensive checklist of all known components across the web. At first glance, it appeared to be a solid strategy, ensuring we would be prepared for any scenario.

But as we delved deeper, the flaws in this approach became glaring. Each time we completed a component, new requirements or variations would surface, making our work obsolete almost as soon as it was finished. The process was slow, resource-intensive, and lacked strategic focus. Instead of progressing steadily, we found ourselves in a frustrating loop—building components that would either need constant updates or, worse, become entirely unnecessary.

This inefficiency created a ripple effect: valuable resources were wasted, timelines were jeopardized, and the design system became increasingly difficult to maintain. Updating components with new variations—what we called forward-propagation—was tedious and chaotic, pulling us further from our goal of a scalable, streamlined system.

Faced with this setback, I asked myself a critical question: “How can I make this approach more effective?” The answer wasn’t in building everything upfront. Instead, we needed a process that could adapt dynamically to immediate needs while leaving room for future expansion.

The goal shifted. It was no longer about designing a comprehensive system from the start, but about creating a flexible framework—one that could respond to evolving requirements without wasting time or resources. By changing my strategy, I moved from building for every possibility to building for what was essential, with the ability to grow as needed.

This pivot marked a turning point, transforming the design system into a living entity that could evolve and scale, rather than a rigid structure doomed to constant revision. It was a hard lesson but a valuable one: in design, as in strategy, adaptability often trumps exhaustive preparation.

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

After reflecting on our progress, I thought, “We’ve developed incredible UX artifacts and products in the past so why not use them as our foundation?” This realization led to a pivotal decision: to focus on a single product category that could serve as the foundation for our design system pilot.

To make the choice, I set clear criteria:

1. Jurisdiction coverage: The product needed to operate across multiple regions, ensuring we could address localisation and compliance challenges.
2. User insights: We needed deep knowledge about the end-users to create a product that truly resonated with their needs.
3. Business impact: The redesign had to drive significant value for both our partners and our organisation.

Using these criteria, I created an evaluation table to score each product category. With input from the business strategy team and stakeholders from the product team, we refined the evaluation process to ensure we selected the category with the highest potential for impact.

2. The Reference Product

The result was a new Reference Product, embedding all our best practices and UX learnings. This product became the foundation for the design system pilot, as well as the template for all future white-labeling efforts in its category.

By starting with a Reference Product, we ensured that the design system pilot wasn’t just a collection of components—it was grounded in real-world applications, aligned with business goals, and built for scalability.

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.