THE PROBLEM
Decent was expanding the number of health insurance plans they offer, and needed a scalable solution that could work for any amount of plans they introduce in the future.
DESIGN QUESTION
How can we create a scalable, easy-to-use, solution that would allow for any amount of insurance plans to be added in the future?
STYLE GUIDE
Anders and I experimented with a few different color pallets, and landed on a mix of purple and blue. We wanted the colors to pop and contain an energy related to being outdoors.
WHAT NEXT?
My 9-month contract had come to a close once I prepared the second round of prototypes for testing. If I had more time, I would have analyzed the second round of user tests, refined the design, tested in color (using the style guide), and then create redlines for the dev team. If you'd like to see an example of this on another case study of mine, please see "Re-designing Decent's Broker/Partner templates."
THE SOLUTION
YES, it worked. The designs and changes introduced a scalable design that could work for any amount of plans. It also met the user needs to get a quote and sign up easily, understand how many plans decent has, and understand the major benefits of the plans.
Upgrading Decent's Quote Flow
RESEARCH
Study of previous usability studies & user feedback
Competitor Analysis
DEFINE
Design Goals
User Persona
IDEATE
Proposed features
Sketches
Userflows
PROTOTYPE
Mid-fidelity
High-fidelity
Interactive
VALIDATE
User Testing
Team Input
REFINE
Data Analysis
Document Findings
Apply changes
PROCESS
RESEARCH
The UX Researcher, Product Lead and I discussed issues with Decent's current flow and what previous case studies have shown. I then put together a 12 page competitor analysis that consisted what health insurance providers were currently doing in the market, and what those companies highlighted as important for their users. I was inspired by a couple company's layouts and compare/filter features, but for the sake of the contract agreement have been asked to keep them anonymous.
DEFINE
I designed a persona from incorporating the research and design goals, which summarized the basic goals, needs, thoughts, and pain points of our users. Meet Suzanne.
IDEATE
My team and I collaborated on a list of possible features. After sharing the features with the dev team, we agreed upon the following to fit into the scope of our project:
PROTOTYPE
SKETCHING
My first step is to always starting sketching mobile first. After multiple iterations, I moved on mid-fidelity screens, translating the designs on desktop as well.
MID-FIDELITY PROTOTYPE
Using the Sketch App, I started designing mid-fidelity screens that incorporated the new features. There were many versions our team discussed, and this process alone took about a month to pin down a mobile/desktop version we felt worked. We used Zeplin as a collaboration tool to leave comments and suggestions on screens, and also shared our progress with the dev team to get their input.
Steps Include:
-
Enter Zip Code
-
Add people
-
Tobacco Question
-
Quote Loader Screen
-
Quote Summary Screen (without Recommended, Comparison, Sort, Filter, Print, or Email features)
-
Glossary Modal (w/limited definitions)
-
Quote Details Screen
-
Enrollment Screen
FINDINGS
The UX Researcher took the bare bones prototype I created via InVision and tested it on 10 participants via UserTesting.com. Overall, the finding were quite positive.
-
Users loved the design layout and felt the entire flow made sense.
-
Participants did not open the definitions popup to learn more about what they had questions about.
-
Participants were confused about the difference between virtual primary care and in person primary care.
-
Participants wanted the ability to compare and filter plans, and noticed this was missing.
-
A couple participants wanted to ability to hide or collapse certain sections on plan details page so they didn't have to scroll. However, this page got positive comments being it provided transparency into each plan and allowed users to learn more.
REFLECTION
What challenges did I encounter?
Discovering the differences between "must have" features and recognizing "nice to have" features. Also, there were many screens involved in this project, and I needed to stay in close communication with my team plus the development team to make sure ideas were realistic and fit within the timeline of the sprint.
What did I learn?
I learned the importance of not getting attached to a design, to test small then big, and also how important over-communication is during ideation and design.
What did I try that didn’t work?
We found that introducing discounts were a bit out of scope, and they were more of a "like to have" feature than an immediate priority. Also, I pitched a ‘back to the top’ arrow for mobile, but it would have created ample work for the dev team to create a consistent experience amongst other devices/pages.
What did I accomplish?
I created a mobile and desktop framework for the new design. Though it needed another round of color testing, I'm confident I set my team up for success moving forward to complete the project.
CURRENT QUOTE PAGE (The Before)
PROPOSED DESIGN PAGES (The After)
The desktop version we decided upon for the three screens is below. On the mobile, I imagined what it would look like to incorporate discounts (for partners working with Decent), but in the end we decided it was out of scope for the project and labeled it as a "nice to have" feature for another project. This happened because if included, we'd have to test two different scenarios, one with discounts and one without, and that didn't seem like a good use of our time with the primary goal being to create a scalable solution for plans.
VALIDATE
I shared the final feature ideas with the dev team via Zeplin to get an idea for which feature to implement first, what would be the most difficult, etc. They recommended testing a ‘bare bones’ version first, and to add the other features once tested. This way they could start to build the main framework earlier in the process. After discussion with the team, we decided to only test the first prototype on desktop.
The ‘bare bones’ version included the main layout and primary CTA’s. It started with 'entering a zip code' and ending on 'signing up to enroll.' I assembled a prototype using InVision, which included 8 steps.
"How did the plans you see today compare to the plan you have now?"
"The plan I have now is more expensive."
"Very similar, with the exception virtual."
"What was the most frustrating aspect of the site you saw today?"
"The plan names seemed vague."
"I was not able to compare plans or sort."
"What would you do to improve the plans you saw today?"
"I would like to be able to filter the rows on the Plan Details page to hide the categories that I don't believe I would use."
"I would want to be able to compare them to make a quicker/easier decision."
"What was the best aspect of the site you saw today?"
"I like the layout of the site. It is easy to understand and navigate. I was not surprised by anything."
"The plan page gives me the impression that the company is transparent and does not try to hide anything about their plans from the customer."
POST - TEST QUESTIONNAIRE COMMON RESPONSES
REFINE
My team and I met to discuss the feedback. What feedback did we take, which did we ignore, and why?
PLAN NAMES
We decided to change the term 'Virtual' to 'Remote', since this is a term people are more familiar with.
DEFINITIONS
We discussed definition links would be easier to view in color and made no changes. Plus, other tests show definition links had an ample amount of engagement when in color.
FILTER & COMPARE
We brought in the filter and compare (as well as other added features), since we affirmed the importance of having them as part of the design.
PLAN DETAILS PAGE
We decided to not change the plan details page due to creating unnecessary additional clicks/steps for the user. Plus, scrolling is fast since the page isn’t too long.
PROTOTYPE 2.0 — ROBUST ITERATION
After discussing refinements with my team, I added all features into the next prototype which we called the 'Robust Version'. This flow was created to test users from 'entering their zip code' all the way to signing up and entering the 'member portal.'
STEPS INCLUDE:
-
Enter Zip Code
-
Add people
-
Tobacco Question
-
Quote Loader Screen
-
Quote Summary (All features: Recommended, Comparison, Sort, Filter, etc.)
-
Glossary Modal (w/all definitions)
-
Quote Details Page
-
Enrollment Page
-
Add owner to plan
-
Add spouse to plan / add payment method
-
Member Portal — Home
-
Member Portal — Partners
FINAL PROTOTYPE
Explore the desktop experience live to:
-
Follow prompts to get a quote
-
Check out the filter and compare features on the quote page
-
Finish signing up by clicking "Get Started" on the Lonestar Plan and see what it's like reaching the member portal which I also designed (this was a previous project).
View Interactive Prototype
COMPETITOR ANALYSIS
FINDINGS
-
Recommending a plan for users was not common, though it was a repeated need from our users
-
Compare and filter options were seen in almost all competitors
-
A plan summary or tagline was lacking, and from our user research we gathered this was an issue
-
Individual plan detail pages are common among competitors (this was something we were not doing because we had so little plans we could fit it all in one page)
-
Users needed help making informed decisions (it wasn't clear to them the difference between the plans, and healthcare jargon was hard to understand)
Documenting Current User Flow
I documented our complete current user flow to show where changes needed to be made, and what impact the new features would have on the flow (the impact type can be seen in the table above).
Design Goals
After synthesizing our insights, the Product Lead created a Design Spec including project timeline and design goals. After conversing with our team, we decided on the goals below as a framework for our design solution.
EASY-TO-USE
Our design should provide users the ability to get a quote and sign up easily.
TRANSPARENCY
Our design should allow the user to understand how many plans Decent has, the benefits they provide, and the difference between them.
EDUCATIONAL
Our design should provide the resources and information necessary to equip users to make informed decisions.
GUIDED
Our design should help guide the user to make the right decision for themselves or their family, as well as feel like they’re a part of something exclusive.
HIGH-FIDELITY PROTOTYPE (BLACK AND WHITE)
Decent prefers to test high fidelity designs in black and white first, so users are more focused on interactions than the overall aesthetic right away. Before and after screens are below.
MY ROLE
I worked collaboratively within a cross-functional team, and led the competitor analysis, user persona, ideation, design, prototyping, and refinements. I worked closely with the UX Researcher to gather data on previous usability studies and prepare her to implement usability testing, with the Product Lead and Visual Lead to define design goals and branding, and with the Engineering Team to define project scope, feasibility and restrictions.
QUICK CONTEXT
Decent is a health insurance startup. The company mission is to offer affordable and comprehensible health insurance to the self-employed in Austin, Texas. They were expanding quickly within the Texas area, and needed a scalable solution to introduce more plans.
DELIVERABLES
High Fidelity Prototype — Desktop (Black and White)
TOOLS
Sketch
Zeplin
InVision
DURATION
12 weeks
TEAM
UX Designer (Me!)
Design Lead
Product Lead
UX Researcher
Engineering Team