🚀 Launching the Marshmallow app: a UX case study

In 2021, Marshmallow launched its first app on both iOS and Android to help make insurance easier and faster for its customers!

My role

My job was to facilitate the discovery and design of the MVP (minimal viable product) solution to have it ready for launch within 6 months.

We kicked off the project with a small team, even before we’d hired our now iOS and Android engineers. Over the next 6 months, our team grew to be fully cross-functional.

Discovery

We split the project into 3 sections.

1. Understanding the features that our customers would want.
2. Defining the right information architecture of the app — it needed to encompass everything from our current customer account as well as facilitating the future growth of the business.
3. Promoting the features of the app to encourage downloads.

We had a web app that was being used by our customers to manage their own policies and make changes within the account. We started by speaking to customers to understand what they would want in an app and how it could bring more value.

After exploring this we had early signals around what could be improved;

• A more streamlined login
  To log into the web account, customers signed in with their email and a magic link. For the app, we could make logging in a one-time task, and a more streamlined process by using a phone number.
• Support in an accident
  A big selling point for the app was that customers could have all their information on them in the event of an accident. The app could give guidance on the steps to follow and help them collate information about the incident. These features were seen as strong reasons for downloading and keeping the app.
• The ability to start a chat with the team on the go
  There was a lot of uncertainty surrounding webchats. Customers weren’t sure if they needed to keep the webchat window open, or whether it was ok to change tabs or log out. Customers trusted that the app would take away this uncertainty, notifying them when someone had replied.

Based on this research, and previous learnings, we started ideating around the structure of the app.

Defining the app’s structure

We started by looking into patterns for up-selling and cross-selling products as well as how to switch between multiple policies.

Insurance has low engagement. You sign up for a policy and don’t really check it until renewal, or if you need to claim. Knowing this, we decided it wasn’t worth risking some newfangled interaction to switch between policies or to default to a policy as you see in some banking apps.

We opted for a more traditional navigation so our customers wouldn’t need to learn a new behaviour to use a low engagement product.

As we pride ourselves on our customer support, we also decided to prioritise the help functions. We put help into the bottom navigation so that it was easy for customers to engage with our support team. We combined this with FAQ articles and popular help topics to allow customers to self serve ahead of chatting with the team.

Help in an emergency

Next, we started looking into how to support customers when they had an accident. For the purpose of an MVP, we reused some existing content giving customers immediate access to a step-through guide and a number to call.

We tried placing this feature in a few different areas of the app — in ‘Account overview’, ‘Help’ and also in ‘Claims’. Through testing we learnt that:

• When an emergency happens, people don’t think about making a claim, they just want to get help as soon as possible. With that in mind, users didn’t expect to find a number for emergency support by clicking ‘Claims’.
• In our task completion testing, no participants clicked on ‘Claims’ to get emergency roadside assistance as they expected to see past or current claims here.
• There are different factors that determine whether an incident is an ‘emergency’ or not. This would affect how the user would approach getting help in the app.
• There are different opinions on what being ‘roadside’ means – for some, it meant literally ‘on the road’ others assumed it would include breaking down at home.

We ended up placing “Emergency assistance”, as we eventually coined it, on a level 1 in the IA as it is the biggest need for our customers and a big differentiator between the app and the current customer account.

Policy overview

Thankfully, we already had some insider knowledge in this area!

The Growth Team had been busy understanding what “peace of mind” looks like for our customers at the point of purchase. We leaned on that knowledge to help inform the policy information.

The customer account, shown below, currently doesn’t allow people to make changes in line. You view your policy in one place and edit in another — this makes for extra friction to the customer if they want to see and edit existing details.

The approach that we wanted to test was splitting the account into three sections:

Overview – a place for customers to understand their cover at a glance
Manage – to allow customers to make changes to their policy information.
Documents – to give customers total peace of mind.

We took this into task-based testing to make sure that the information was structured in a way that met customers’ expectations.

We did 2 rounds of testing with a couple of different prototypes and found that most of the app met expectations. The main point of difficulty was understanding if Breakdown Cover was included in the policy or not.

Two variations of the same page for testing

Promoting the app

As a lot of the functionality already existed in the customer account, the largest part of the project was actually getting the customer to download the app.

We had a stretched target of getting 86% of new customers to use the app.

To reach this target, we could have taken a forced or optional approach to get users to download the app.

We tested a couple of prototypes with the objectives of:

• Identifying how we can drive adoption of the app from the sign-up flow
• Understanding people’s feelings towards downloading an app in the purchase flow
• Understanding what messaging will persuade customers to download an app
• Understanding user behaviour after purchasing a policy so we can create a seamless transition into the app.

Through this, we found out that:

1. Participants didn’t expect to have to switch devices partway through signing up for their insurance and would prefer to stay on one device to complete their purchase — to get the job done.

“I’ve done 90% already. I’d prefer to stay here instead of switching it up.”

2. Customers want to know the steps to get cover upfront so they don’t hit any unexpected barriers and can complete their purchase in one sitting.

“I’ve spent 15–20 minutes on this. I don’t know if I would have the energy to come back”

3. Apps are just the norm now, so customers were inclined to download the app after seeing its benefits, lucky us!

“Personally, I would download the app straight away with no hesitation. For me it shows how tech-forward Marshmallow is”

We felt that forcing customers to download the app without strong motivation would have an impact on conversion. So, we decided to present it as optional but leverage the benefits.

When customers onboard, the first thing that they want to do is get their policy documents to be reassured that they are successfully covered by us. We use this fact to promote the app, highlighting how you can easily check your documents there.

We also looked across other touchpoints to promote the app, including the Marshmallow website, welcome emails and the customer account. But I’ll save those for another time!

Launch

Manage your policy at your fingertips

We actually descoped this for MVP. Having a functioning web app meant that we could quite easily bring in web views to get the release out the door faster. We made sure that interactions were seamless to ensure it felt like an in-app experience.

“I’m not expecting this app to change my life. I don’t expect to be using every day but I like to know that it’s just there until I need it”

From web chat to support on the go

By leveraging Intercom’s APIs (application programming interface), customers could start a chat or leave us a message.

“This is what I mean about an app being better — it’s just so much more instant”

Get help in an emergency

We broke up emergency help into different categories and gave the customers all they would need to help them in that situation.

“I think it’s good to see the policy and reference and number plate etc, otherwise, I would have to go back to my contract and it makes thing a bit less scary to me.”

Results

Our target for the quarter was to get the app out to 86% of new business. Other numbers we tracked were app store ratings and crash-free session — we’re smashing both of those too!

Numbers 2 months after launch

What’s next?

Improving feedback loops
We’re planning to introduce some simple functionality to let customers rate us, report a bug and leave feedback.

Bringing in more native functionality
We’re aiming to lean less on web views and have policy information viewable in the app.

Promoting the app to existing customers
We’ll be looking at new touchpoints to promote the app — the Marshmallow website, the current web customer account and emails too.

Exploring and building out the claims space
We’re kicking off a design sprint to better understand how the app can support the claims experience.

This was a very collaborative project, so I want to give a massive shout out to the fantastic team behind it:

Daniele Bottillo, Ben Gilroy and João Cana Verde for making our app super slick and scalable. Ellie, Eve and Gwen for working on their first product projects and running with it. Lexie Titterington for getting up to speed so quickly and bringing it back to metrics 👏

We're hiring! If you want to be part of these sorts of processes and a growing design team, check out our open roles here.