Kaus Insurance
A DesignLab Concept Project
BRIEF
A large insurance company wants to start selling products directly to consumers. Design a website and a new logo for this project.
SOLUTION OVERVIEW
Research showed that lack of consumer trust is the biggest issue for insurance. I focused on earning users’ trust in every aspect of the project.
LESSONS LEARNED
- Explain why you need each bit of personal information.
- Simple language > complicated legalese.
- Show information in multiple places, i.e. both a “Learn” section and contextually to the user’s task.
USER INTERVIEWS
3
users
CUSTOM ICON SET
6
icons
PROTOTYPE
45
screens
USABILITY TESTING
5
tests
PRIORITY REVISIONS
4
improvements done
NEXT STEPS
3
improvements to do
01. INTRODUCTION
Project Overview
Kaus is a large insurance company that offers every type of insurance under the sun: property, personal, health, business – you name it, they sell it. They are switching from selling through their agent network to selling directly to consumer through the website I get to design.
From this description, my working assumption was that the main foci of the project will be
- Information architecture to wrangle the massive amount of content and
- E-commerce – a clean, simple way for users to make their decisions and purchase the products.
However, I was open to the possibility of having to adjust the direction as I learned more.
Spoiler alert: that’s exactly what happened.
My Role
I was the sole designer on this project, with invaluable feedback from my mentor. That, and the time constraint, required the project to be tightly defined and limited in scope.
02. RESEARCH
Industry Research
I read industry publications, consumer-facing articles about insurance, and users’ stories about their experiences with insurance companies.
The biggest thing that stood out was a profound lack of trust toward the insurance industry from prospective customers and the society as a whole. There are two main causes of this distrust:
1. Past bad behavior such as:
- Fraud
- Price gouging in catastrophes
- Discrimination
- Delaying claims payments
- Denying legitimate claims
- Lowball reimbursement offers
2. Lack of transparency:
- Hard to find essential information
- Overwhelming complexity and confusing presentation
- One sided information flow: companies require a lot of information from the consumers before providing any information back
Competitive Research
Most insurance companies cover either Life and Health or Property. Since Kaus covers both, the competitive research had to be broad, but shallow due to the project time constraints. This resulted in a brief overview of a few representative competitors.
User Interviews
Demographics
- 3 participants
- 2 male, 1 female
- 30-45 years old
- Urban, college educated, professional
Key Insights
- Lack of trust is the #1 issue
- Users shop around for insurance and get quotes from several companies before they commit
- Users feel uncomfortable with the amount of information they have to provide to get a quote
- Users are intimidated by insurance because they don’t feel they understand it enough
- Insurance is important to people
- Ratings and testimonials are important for decision making
- Modern-looking websites help people trust the company more
Persona
James recognizes the need for the security provided by insurance products, but is skeptical that any company is going to uphold their end of the bargain.
My goal is to convince James that Kaus is an exception to that rule.
Empathy Map
The empathy map helped me understand the experiences, frustrations, and motivations of my persona, and guided me through the rest of the process.
03. DEFINE
Project Focus: Lack of Trust
The lack of trust came up consistently throughout the research phase, so it became the main issue I would try to address in this project.
For the rest of the process, every time I had a decision to make, I had to answer this question:
What would help earn James’ trust?
The main decisions were:
1. Estimated Quotes
A lot of insurance companies do not provide estimated quotes because there are too many factors that could affect the final quote.
However, every user interview indicated that they
a) Shop around for insurance to get the best quote, and
b) Feel very uncomfortable with the amount of sensitive personal information they have to provide to the company before they get any information back from them.
I decided that providing a quote range would help with both of those issues. Yes, they will shop around after they get a Kaus estimated quote, but they will remember that Kaus gave them some information without making them feel uncomfortable.
2. Insurance Education
Users often put off getting insurance because they are preemptively overwhelmed by the process. They expect a lot of jargon and obfuscating legalese.
Kaus would provide information about insurance in normal language. Kaus would also provide contextual explanations about every bit of information they request from the users. People are far more likely to be comfortable with providing the information if they understand why it is necessary in order for them to get what they seek.
3. Minimal, Friendly Design
Users indicated that modern, clean design helped them feel more comfortable with the company. It indicated that the company is not stuck with business-as-usual and was more likely to be flexible and innovative.
This was especially important for the younger users.
User Flow
Obtaining a quote is the critical task of the website, so I identified several paths a user might take through the site in order to complete that task.
In a real world project I would have a lot more content to work with, so the user flow would be more nuanced and complex.
This deliverable is a snapshot of my thinking at the time, which has evolved and simplified through the iterative design process.
Task flow
Next I picked one possible path and listed the main pages necessary to complete the task. The plan was to use this list in building the prototype to be tested later, but I got carried away and ended up making a prototype with several different paths instead. But I’m getting ahead of myself.
04. UI DESIGN
Tone
If I had to describe Kaus as a person, he would be a lovably geeky guy who gets really excited to tell you all about some complicated aspect of your insurance policy at a cocktail party.
He and James, my persona, would definitely get along.
Logo Design
I thought that a simple word mark would appeal to my persona. I explored several options, which I narrowed down to the final result. Connecting the A to the letters around it conveys interdependence, while the blocky letterforms create a sense of stability and dependability.
Icons
I created a set of custom icons to reinforce a sense of cohesive brand identity throughout the site.
Color Palette
I kept the palette neutral with a few pops of brand color. I chose a vibrant green because it feels fresh and optimistic, and has not been overused in financial applications, as blue has been by now.
In retrospect, I think it would have been better to avoid stark black and white to reduce eye strain for the users. I learned my lesson with this project, and reduced the contrast a bit in future projects.
Typography
I decided to stick with one font for both body and headings to help keep the interface clean and cohesive. I chose Open Sans for its simplicity, friendliness, and excellent legibility.
Images
I chose to use illustrations instead of photography to reinforce the geeky-friendly feel of the website.
I used stock images due to time constraints. If I had more time, I think custom illustrations would have helped to create a more unique and cohesive voice for the brand.
05. KEY PAGES
Home
A user coming to the home page could have one of several goals.
- Find out how much a particular product would cost them.
- See if this company even provides the product they’re looking for.
- Learn about the company to decide if they’re the right fit for them.
- Find out what existing customers think about this company.
- Learn more about insurance so they can figure out what product they need.
- An existing user would need to log into their account.
I explored layout ideas in quick sketches to start.
I refined the best layout in the wireframe stage, and worked out the mobile layouts.
I kept iterating as I increased fidelity, until I had a final result I believed would accomplish the end goals of the company, and work well for James.
Learn
I followed the same process for the other pages. I’ll spare you the step-by-step and skip straight to the finished result.
The Learn section is a series of articles about insurance, designed to convey the information the users would want to learn, in normal English.
I scoured insurance websites for copy, and rewrote it to fit the Kaus voice.
Obtaining a Quote
The copy was the most important aspect of these pages. Of course, if I was doing this for a real insurance project, the questions would be decided in collaboration with every aspect of the business, from marketing to legal. Since I was on my own, I used the competition to get a sense of which data points were essential for an estimated quote.
There was less consensus out there than i expected. Some, like Geico, asked for very few items before providing a number, and put the rest into the Assumptions that I could review and change after I got the initial number.
I think my skeptical target user would appreciate a similar approach, but some of the questions in the assumptions turned out to be pretty critical. For example, if you answered YES to the “Do you have a vicious pet?” question, you could no longer purchase insurance through the website. Asking questions like that upfront would save the user a lot of time and hassle.
Other companies, like Progressive, asked users for their social security number on the very first screen. I did not continue with the process far enough to find out what else they asked. The cost of providing something this sensitive simply wasn’t worth it.
These pages remained in mid-fi. Given the time constraints, creating higher fidelity screens would have meant less time I could spend on doing more competitor research, writing the right questions, and creating extra screens for a more interactive prototype.
I chose to prioritize copywriting and interactivity over visual fidelity, because that allowed me to do better testing.
06. TEST
Testing Process
I made roughly 30 screens to create my Figma prototype. I could have used fewer screens, but then the experience would have been less realistic for the user, and I thought I might miss some frustration points. Creating a new screen for each question allowed me to pinpoint problems that would’ve been too subtle if I didn’t make people click on each item like they would on a real site.
I recruited 5 participants and conducted the testing remotely via screen sharing. Each test took about 20 minutes.
Demographics
- 5 participants
- 2 male, 3 female
- 28-44 years old
- Urban, college educated, professional
Primary Test Goals
- How easy is it to find information about a specific insurance product (renter’s insurance).
- How easy is it to obtain an estimated quote for that product.
- Whether the design succeeded in establishing trust with potential users.
Secondary Test Goals
- Which of the data entry options the users would choose for entering their address.
- Which quote button they prefer to use to start the process of obtaining a quote.
Testing Outcome
People had no problems finding the information article about renter’s insurance and browsing through all the subsections, so that gave me confidence the IA and design pattern choices I made work well for that task.
People were able to complete the estimated quote process as well, although they had a number of questions about the information requested of them. I added the contextual information buttons to each question, but did not have the time to create the screens for them before the testing. This would be the first priority addition for the next iteration of the test.
Most importantly, I received feedback such as
“I was surprised that nothing felt sinister.”
“I really appreciate having the option to get an estimate first, and that I didn’t have to provide a lot of personal information to get it.”
“The questions were easy to understand, this was a lot less complicated than I expected.”
“I’ve learned something about insurance despite myself.”
The testing validated the overall direction of the project and demonstrated achievement of the main goal of the project.
That said, it also revealed several problem areas and immediate improvements to be made in the next iteration of the project.
07. ITERATE
Priority Revisions
Testing unearthed a multitude of problems and areas for improvement, big and small. Most of the iterations were out of scope for the project, but there were some where a little bit of investment would make the final result significantly better.
I prioritized action items that accomplished one of two goals:
- Made the primary task of obtaining an estimated quote easier for the user.
- Increased user’s comfort level, and therefore trust.
1. Clarify Quote Start
Users did not realize they are getting an estimated quote until they completed the process. They really liked how little information they had to provide, but then had an “oh…right” moment at the end.
The fix: reword the copy so the users’ expectations will be more accurate.
2. Simplify Starting a Quote from a Learn Page
I added a CTA button to the bottom of every Learn page because I wanted to see if users prefer it to the one in the header.
I found out that they overwhelmingly did prefer it, and that they were then annoyed at having to choose the product from the dropdown.
“I was already on a page about Renters insurance, why do I have to select it again?”
Fair enough, users. Fair enough.
I added a zip code box above the CTA button on each Learn page. That way the users would then navigate directly to the beginning of the quote process, bypassing several unnecessary steps.
3. Simplify Topnav
Originally I had a Tasks option in the main navigation bar. It was meant for existing users who would need to do things like start a claim, or check on a status of an existing claim, or adjust their coverage – generally all chores that come with having insurance.
However, the Tasks option confused and distracted my testers, which made them feel uneasy.
I realized that an existing user would have to log into their account in order to do any of it, and there was already an account icon in the navbar. So I simply removed the Tasks option altogether.
4. Reword a Thorny Question
Some of the testers had concerns about some of the questions.
- “Why do you need my name?”
- “Why do you need my address? Shouldn’t my zip code be enough?”
- “What counts as a room?”
In a real project with real stakeholders, I would address this feedback with said stakeholders because I am not an insurance expert, and don’t know what is required like the experts would.
However, there was ONE question that raised every tester’s hackles.
“Do you have a vicious pet?”
I copied that question from Geico’s quote process. They buried it in the Assumptions tab, and if you answered Yes to it, you could not purchase insurance through their website. I decided that made it important enough to put in the main quote taskflow.
Turns out, that wording makes people extremely uncomfortable. I went back to Geico to figure out what they meant by it, and the explanation was, “do you have a pet that ever bit anyone?”
Well, let’s just say that and spare pet parents everywhere the defensiveness and discomfort.
All these small changes added up to a smoother, cleaner experience for the users.
Next Version Iteration
With more time to devote to this project, I would prioritize the following items:
1. Add the information popups for the quote questions.
In the first version testing, I gave the additional information to the testers verbally, and kept track of which questions prompted the most concern. That was fine for the mid-fi prototype test, but would definitely not cut it for anything more developed.
2. Redesign privacy information presentation.
In the current iteration I have Privacy Policy and Data Protection Policy on the estimated quote result page, before the user is asked to submit more personal information needed for an exact quote. Testers said that this made them feel more comfortable, but that they would be hesitant to click on them because they would expect a wall of dense legalese, and nobody wants to experience that.
A better solution would be to present a quick summary on the page itself, with a link to more information if needed. However, to do this I would need more domain knowledge (or access to a lawyer!) to know what information would have to be there in the first place.
3. Complete the task flow to get an exact quote.
This would be a big project because I lack the domain knowledge and would need to do a lot of research to know what information is required, so that then I could work out the copy and organize the information into a simple task flow with a reasonable number of pages.
08. CONCLUSION
Project Limitations
Every project has its own unique set of limitations and challenges. You’d think that a student project for a fictional company would not have any of that, but of course that’s not true.
One, I was limited in the amount of time I could spend on each section before I had to move on to the next deliverable. I would have especially liked to spend more time on research at the beginning, and then on user testing and iteration at the end.
Two, there wasn’t much content to work with, like there would be with a real life project. Knowing the full scope of content would be obviously most important at the information architecture stage, but it would also be a helpful guide in even the smallest design decisions. Is the “get a quote” button in the header necessary? Based on the content and the pages I had the time to create and test, no. But since I don’t know what the rest of the site would be like, I can’t be certain.
Most importantly, I did not have a team. I had my mentor for guidance and feedback at every step, which was invaluable, but I did not have other designers to collaborate with, and developers to check on the feasibility of certain things with, etc. To me, good design happens through ongoing interactions between people, and this project would be better with more opportunity for collaboration.
Lessons Learned
1. Trust can be earned
I started the project hearing things like “[insurance companies are] a bunch of money sucking leeches” during the research phase, and by the testing phase people were saying “wow, nothing felt sinister!”
2. Domain knowledge helps
There were so many points where I wished I could fire off some stupid questions to an insurance professional, or three. And also a lawyer. And an insurance salesperson. I had to make a lot of guesses and assumptions to complete this project, and actual information would have made it much better.
3. Components are awesome
Nothing beats the satisfaction of adjusting a component and seeing it instantly update on 30 screens.
Each subsequent project reinforced this lesson in new and occasionally painful ways.