Rebuilding the account experience.

The Problem

GoCompare has recently stopped creating a duplicate account with the same email; little did they know that this has caused a detrimental impact to customers being able to get a quote with our service. 

The validation error stopping users from creating a duplicate account was our most prominent error in a matter of days releasing. We identified via our customer feedback tool and user session recordings that customers were attempting to create quotes for others under their email.

"My wife and I use the same email address. As she has set up an account in her name for  house insurance I cannot do the same for car insurance. She cannot set up for car insurance as all details regarding the car and no claims discount are all in my name."

Stopping duplicate accounts have now stopped customers from fulfilling the need to get a quote for friends & family. 

Understand phase

At the start of the project, I set up a questions & assumptions workshop with everyone assigned. This gives the team a chance to note everything down and prioritise the questions & assumptions we need to get the answers for to be able to understand the problem entirely.

After that, it was time to get those questions answered and assumptions validated. We did a vast amount of desk research gathering all the customer data to get deep into the problem at hand. 

We did the following :

• We looked through previous research sessions from other projects relating to account management. 
• We reviewed what our customers were saying in our customer feedback platform.
• Watched user session's using quantum metric and identifying common user behaviours around quoting and account creation. 
• We had our customer services team tag any conversations they had relating to getting a quote for others. 
• We talked with Engineering to understand how the database handles customers and why it's an issue. 
• Create a DACI (driver, approver, contributor, informed) framework to understand who we need to keep a regular cadence with.
• A service blueprint was created to understand the journey customers take while getting a quote at GoCompare and how the accounts affect the experience.
• We ran a job stories workshop to identify what jobs needed to be done to provide the best experience and a checklist for our concepts.
  

After all this, we created a document that would act as our source of truth for the project; we called it the GoUnderstand Doc. This would involve the context, the problem statement, the job stories and the measure's success, and any links to any project resources. The doc would act as a point of reference when we get lost within the problem.

Key Findings 

• A lot of couples share an email between them so that they can manage bills and insurance together. 
• Duplicate accounts originated from customer's getting quote for others.
• Customer's don't remember they have an account with us.
• We penalise our returning customers forcing them to sign in at the start of a quote, which causes significant churn
• Due to customers only using the service around once a year, using the forgotten password flow is more common than entering the password. 
• Customer's don't want to be forced to create an account to get a quote; they want the freedom to do so.
  

This was the first time we've implemented this understand phase, and it's proven super valuable to the business and has prevented us from thinking of the solution too soon.

Ideation Phase

I conducted a workshop with the product team and leadership team to explore multiple product ideas to address the problem.

• How might we help customer's manage quotes for others?
• How might we stop penalising customers for having an account with us?
• How might we help our customers sign in easily?
• How might we make creating an account less forceful?

This was a great session, and people were very passionate about solving this problem.

‍

Designing the system.

Working with the product manager on the product to define the current system and then utilising the ideation session to create a proposed system architecture to see the experience working on a high level. 

Designing the system at a high level allows us to -

• Understand what parts of the system we could launch in an incremental fashion
• Understand how the frontend system interacts with the customer database.
• Help engineering understands our thoughts and start investigating the technical feasibility
• See where the data points are utilised across the service. 

‍

Interaction Design

Now we've established the different aspects of the system, the other designer and I have now split the sections up and started exploring visual concepts and experimenting with different interactions. 

This is all we're up to right now, so watch this space for more.