Cover Price Delivery

Cover 2018 • Mobile App

Delivering insurance quotes within the app experience.

Role & Responsibilities

My contribution to the project

As the lead designer on the app team, I worked with developers, QA and our product manager to design the iOS and Android experience of the insurance quote delivery. Responsibilities consisted of breaking down the business challenge, documenting major decisions, questions brainstorm and analysis, concept ideation and prototype, finalizing designs and developer hand-off for views and interactions, designing phased approach for testing/releasing.

Background & Context

The business problem behind it all

As an early product, Cover was built as a mechanism to capture information from leads and funnel them to our sales agent, who would manually engage with each customer to deliver a quote and convert it to a sale. Naturally, the app was very bare-bones and the experience required the user to only answer a handful of information and then be directed to text with our agents to get their price. A slight bait and switch, but a necessary one as a starting company. Of course, this lead to many issues especially scalability, and we wanted to see how we could solve this manual text message delivery of price. The natural step was to work towards a delivery of the price inside the Cover app.

Design Problem

Our problem statement to guide direction

How can we automate the delivery of a price inside the app in a simplified experience for our customers?


Evaluating problems from key stakeholders

It was clear that price accuracy was something we wanted to solve and ensure we were able to delivery with this automated price delivery feature.

I worked with our sales agents to find out common questions they would ask customers in their conversations to ensure the best rate would return. One goal was to see if we could add these common questions to the intake flow if they were simple enough that users didn't have to reference a document or seek the answer.

The second part was to validate how users felt about the current length of questions and figure out how many questions we could add to the intake before users would drop off. We set up 10 calls with our customers - 5 who have purchased a policy and 5 who decided not to. The goal was to gather anecdotal feedback on their experience getting a quote, specifically fishing for two things:

How they felt about the current length of the whole intake. We found that generally, the customers seemed content with having more questions as long as they could be ensured to get a good price. They saw it as a balance of effort and reward.

Their experience texting with an agent to get their policy bound. Majority of the users agreed that the texting experience was initially unexpected but enjoyed it over the traditional ways of jumping on a call and the nuances of that process. They felt it was less of a hassle and accommodated to their personal time a lot better. This meant that we would have to deliver the price via text as a supplement, since agents would continue texting with our customers, so having the price in the conversation history was key.

The Design Process

Working through the problem

Along with the team, I explore different options for the delivery of the price. There were technical limitations that guided some of the exploration and options. We wanted to focus on making sure we exhausted exploring price treatments inside of the app. Both on a visual level but also on a co intent level. From a visual perspective, I tried some layouts and UIs where we could display multiple packages and how we’d handle showing more information. In terms of content, our best source of information was our internal sales agents to understand customer behaviour or concerns and how we could translate that into the app.

We landed a solution of delivering an accurate and competitive price inside the app, which would then direct interested customers to talk to our sales agents to bind.

MVP Solution

Redefining the experinece

We solved for accurate price delivery through introducing more questions that were key influencers in determining price but also weren't challenging to answer without referencing another resouce.

Through user testing, we were able to stress test the difficulty of questions, how many questions became too many (equating to a tedious user experience) and at what point was there any drop-off in the flow. Since we’ve design this version of the app with the ability to easily make edits, we were able to test questions and dynamic flows at a granular level.

We designed an in-app experience that included a loading animation for any delays in calculating the price, as well as the UI for the price being delivered to the customer

The loading animation we designed was based on estimates on time to calculate a price. One of the technical challenges was that it took roughly 30 seconds to calculate so we had to design around the expectation. What we created was an animation that created trust with the customer by breaking down what our systems was doing to calculate the price.

The price view highlighted the monthly rate, and key coverages. Our choice to list out all of the coverages was meant to create a feeling of comprehensiveness, regardless if users actually understood what each coverage meant. Additionally, we designed to solve a business issue of gathering intent from the user. This was mainly for our sales team to be able to add users to a Salesforce queue and prioritize selling to those customers. If a user was ready to purchase a policy inside the app, we added a clear action, but if not, we created a feedback loop where we asked the customer why they didn’t want the quote. It created a second opportunity for us to educate them on how the insurance process works and reassure them on how we can service them - e.g. If a user believes the price is too high, we can reassure them how our agents can massage the quote and look for discounts to lower it. From an analytics side, this allowed us to see where and why users were dropping off between a quote completion and policy sold, and then allowing the growth team to create appropriate re-engagement strategies.

After the customer receives the price, one aspect we wanted to add to this project was the post-intent experience. With the previous experience with and agent talking to the customer directly, they could fish out why a customer may not want a price. To mirror that experience inside the app, we create 2 additional workflows.

If a customer says they want to proceed with the price, we display this view where we show the next steps

If a customer says they don’t want to proceed with the price, we’ll have this intermediate view that asks why they weren’t interested and we list out 3 options that cover about 95% of the reasons someone would say no. This new view acts as a 2nd chance to re-engage. Ultimately if that fails, this information could be used for our growth team to create drip campaigns or re-engagement emails at a later date

Quote Start to Quote Complete.
Because we introduced a lot more questions for price accuracy
92% previously → 87% which is a reasonable drop-off

Customer Response Rate
Saw a lift from about 3% - 5%
Customers answering initial text vs. responding to interest in a price

Lead to Conversion rate
Improved from 1.5% to 2.4%
Customers interested in their price. Sales agent more focused on selling to interested customers

Post Iterations

Continuous learning from user feedback

After our launch of our MVP solution, we monitored user feedback on the App Store, sales funnel analytics, and ran user testing to smoke check any issues we may have missed.

We essentialy boiled up the feedback into 2 key issues to optimize against. There was way too much copy - no one is reading it. We also made it too easy to decline the price, both location on the sticky footer and the wording was too encouraging. We used these key problems to redesign the UI to help drive better conversion.

What I learned

Lessons and best practices

Involving engineers early in the discussion. We ran into some technical issues which we eventually overcame, but we didn’t account for any engineer discovery period to see how long a price calculation would take so we could design against it. Having a technical lead or something to work with design during a discovery period, allows us to easy validate ideas and see how something could be implemented. We have since added this to our process, which has allowed us to define limitations early and design against it before the sprint planning.

Browse more work