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, Component Structure, and Tokenisation. 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: Logos, Typography, Colour Scheme, Imagery, Shapes, and Icons.

Based on earlier research, I identified these as the elements that defined brand identity. This layer ensured that each product retained its unique look and feel while allowing other components to be standardised.

To simplify the process, I consolidated these guidelines into a single Figma library, making it possible to rebrand components with just a few clicks.

What It Solved:
The Core Brand UI Layer allowed us to maintain brand integrity while cutting down the time and effort required for rebranding. It was the foundation that made customisation scalable.

2. Component Structure: Atomic Design Principles

The second layer was built using Atomic Design Principles—a method that breaks down a design system 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.

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.

The design system MVP brought everything together. The Core Brand UI Layer protected each partner’s unique identity. The Component Structure ensured reusability and consistency. The Tokenisation Layer streamlined customisation, allowing us to adapt designs quickly while maintaining quality.

This layered approach wasn’t just about saving time—it aligned design, product, and engineering teams around a shared system that balanced flexibility, efficiency, and brand identity. It was the first step toward transforming how we developed products, setting a new standard for scalability and collaboration.

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.