B2B2C SaaS platform
Life insurance. It’s boring.
But my team shipped features
which were used and appreciated.
Anorak was a financial services startup selling life insurance and income protection, acquired by CLARK Group.
Selling insurance is a complex process behind the scenes, regulated by the Financial Conduct Authority (FCA).
Leading the design of this product enabled me to appreciate the challenges of helping advisers sell insurance to their clients, and discover the stories of our customers around what prompted them to buy.
Business KPI
Increase productivity
85%
Reduction from weeks to days for high-value cases
Role
At an early stage startup, you get to wear many hats

Leader
Anorak’s culture empowered me to take the lead on the product strategy, working closely with the product manager and engineering lead to shape the product.

Designer
Our small design team meant I could move faster, testing new interaction patterns and components to enhance workflows, and contributing to the design system.

Researcher
My preferred framework is Clay Christensen’s version of Jobs to Be Done (JTBD) to interpret the data into goals and needs of financial advisers and the clients they serve.
Product strategy
What does it mean to help advisers to be more productive?
We identified key opportunities to frame the direction of the platform's evolution.
Low product adoption
Clients wanted to customise their cover, which meant advisers having to go ‘off-platform’ to manually create cover.
Limited operational efficiency
Each financial adviser had their own way of working, which led to inefficiencies and lost opportunities. Sales managers had limited oversight of the team’s performance.
Low case progression
Clients with health conditions converted better, but were overlooked by advisers due to the amount of manual work involved. Also, advisers typically stuck to the products they were familiar with.
Product discovery
Sitting with and observing advisers to see how they work in the field
Contextual observation enabled me to see how advisers used (or didn't use) the platform.
Phone call analysis between the adviser and their client enabled me to understand how advisers used the platform to serve their clients in real-time.

Mapping the adviser's workflow from making a recommendation to finalising the policy contract to ensure we designed for not just the most common use case, but also key edge cases.

Mapping goals and tasks advisers needed to achieve those goals helped the team to make sure we were building the things which mattered most.
Systems design
Shaping the new platform architecture and defining business rules with the lead engineer
At the start, there's no point in jumping into wireframes because we don't even know what features the new platform is going to have.
My Computer Science degree came in handy here, as I was able to have conversations with the lead engineer about the new platform architecture.
Being able to shape the system's design from the beginning was vital to the success of the product as it allowed me to set better foundations for the product's design.

How the B2B product fit into the platform ecosystem.

I created an Entity Relationship Diagram in order to have a common reference point during early conversations with the lead engineer prior to designing or building anything.

I co-designed the lead management and case management business rules with the head of sales and lead engineer.
I looked to other industries and products which used cases to manage workflows, such as Salesforce and HubSpot.
Even though we were starting from scratch, I felt we didn't need to reinvent the wheel, so adopted patterns from these industries.
User journeys
Prototyping the experience to walk stakeholders through the changes

Mapping key user journeys through the product help to audit the existing experience and identify issues, as well see how and where new elements could be introduced.
These would be repurposed to create interactive prototypes to rapidly test ideas internally and with our target users.
Product design
Making the ‘Schedule’ feature work harder as it was most-used in the product

The 'Schedule' was the most frequently used feature of the platform. Advisers would check it at the start of their day, during appointments, in-between appointments, and at the end of the day.
This needed to work much harder than any other feature. Based on contextual research observing and asking about how advisers work, I identified key functionality that would save advisers time and be more effective at servicing their clients.
I tested the Schedule component in Storybook, as well as in our staging and production environments with advisers to ensure it performed as intended.
Product retrospective
Did we help advisers to be more productive? Yes!
Product adoption
9/10
cases
We drastically reduced the number of cases where advisers went ‘off-platform’, only doing so for the most complex cases.
Operational efficiency
133%
cases per day
Advisers were able to work on more cases each day, spend less time on admin and more time with clients. In addition, sales managers were now able to real-time have oversight of the team’s performance.
Case progression
100%
non-standard cases
All clients with health conditions were able get a quote. In addition, advisers were able to research the whole of the market, rather than just the products they were familiar with.

Next steps
Let's chat
Think I might be a good fit for your team?
Need temporary support for a project?