Bionic Insurance E2E

Taking ownership of the insurance journey

Bionic's property insurance journey was powered by a third-party platform, which meant we had very little control over the customer experience. We couldn't properly track behaviour, run experiments or systematically improve areas where customers were struggling.

The ambition was to bring the entire journey into Bionic.

I led the UX design of a new end-to-end property insurance journey that Bionic would own and could continuously measure, test and improve.

The challenge was that we couldn't simply redesign the experience from scratch. The journey still had to capture the risk information required by Acturis, the platform underpinning the insurance and underwriting process.

And initially, I didn't even have access to the Acturis API.

Understanding what we actually needed to ask

My first challenge was therefore to understand the existing insurance journey.

I reverse engineered the complete set of risk questions from an internal tool used by Bionic's insurance agents, documenting the questions, their dependencies and the logic determining when each one appeared.

This quickly exposed another problem.

The questions had been written for experienced insurance brokers, not customers. They contained industry terminology, assumptions and complex wording that made sense in an assisted sales environment but were much harder for someone buying insurance themselves.

I couldn't simply rewrite them, however. The answers ultimately formed part of the insurers' statement of facts, so changing the meaning of a question could have legal and underwriting consequences.

I worked closely with Bionic's insurance specialists to find a balance: make each question as easy as possible for a customer to understand without changing what insurers needed to know.

That became a core design principle for the journey.

Turning insurance logic into a coherent journey

Once I understood the question set, I mapped the complete information architecture.

This was considerably more complex than arranging questions into pages. Insurance journeys contain extensive conditional logic: one answer can reveal several additional questions, which can themselves trigger further questions.

I mapped these relationships and dependencies so that we could see the journey as a system rather than a collection of individual screens.

Alongside this, I reviewed the journeys of 10 business insurance providers. I wanted to understand both the conventions customers were likely to encounter elsewhere and where competitors were creating unnecessary friction.

This helped me make decisions about how questions should be grouped, when additional information should be revealed and how we could reduce the cognitive load of completing a potentially long insurance journey.

The result was a structure that satisfied the underlying insurance requirements while presenting them to customers in a much more manageable way.

Designing for lots of questions without making it feel like a form

The new journey required a large number of structured inputs, but our existing design system wasn't designed for a form-heavy experience of this complexity.

Rather than designing each screen independently, I created a set of reusable, form-optimised components in Figma.

These covered radio selections, checklists, dropdowns, tabs, address lookup, text inputs and progress tracking, with responsive behaviour across desktop and mobile.

I also designed the states that are easy to overlook when looking at a happy-path journey: validation, errors, helper text, tooltips, hover and focus states.

This gave us consistent interaction patterns throughout the journey and created reusable components that could support future insurance products rather than solving only the immediate design problem.

Making the complexity tangible

Static screens couldn't adequately communicate how the experience would actually behave.

To solve this, I built a fully interactive Figma prototype using Boolean variables to recreate the journey's conditional logic.

Different answers dynamically revealed different questions, allowing someone to experience a realistic journey rather than clicking through a predetermined happy path.

This proved particularly useful with stakeholders.

It made the true cognitive load of the journey visible and allowed us to identify points where customers could become confused or overwhelmed. It also gave our insurance specialists and insurer partners the context they needed when reviewing changes to question wording.

One issue that emerged was a simple but important one: if customers couldn't tell how far through the journey they were, how would they know what they were committing to?

That led me to introduce and explore a progress indicator, which became something we could investigate further through user testing.

Putting the journey in front of customers

With the interactive prototype in place, we could test the experience before committing it to development.

I focused testing on the areas where I felt the design carried the greatest risk: whether customers understood the insurance terminology, whether they could answer the questions confidently, and how much effort the journey appeared to require.

The progress indicator raised an interesting design question.

Showing progress could reassure customers that they were moving towards completion. But explicitly showing the length of the journey could also make it feel more daunting.

Rather than assuming which was better, we explored both the progress indicator and ways of setting expectations about completion time.

The testing gave us evidence to refine the journey before launch and highlighted areas that could subsequently be validated with behavioural data.

From a fixed journey to an optimisable product

The most important outcome wasn't simply a redesigned insurance form.

By bringing the journey into Bionic, we moved from an experience we had limited visibility or control over to one we could actually learn from.

The new journey gives Bionic the ability to capture behavioural analytics, identify where customers struggle and run controlled experiments across areas such as question wording, grouping, information hierarchy and progress indicators.

That creates a very different product model.

Instead of making changes based primarily on assumptions, the team can now form hypotheses, measure their impact and progressively improve the experience.

For me, that was the real value of the project: turning a complex, externally controlled insurance process into a Bionic product that could evolve through evidence.