UI / UX       NOV 2017

Kaus is a class project DesignLab UX Academy Kaus is a fictitious insurance company with more than 30 years of experience. It is transitioning from a brick-and-mortar insurance shop with a network of local agents to a direct-sale business model. Specifically, Kaus wants to tap into the young and digitally savvy sector by selling through a user-centered ecommerce platform. 

To fulfill this project goal, I used a design-thinking process to understand user needs and experiences and to leverage these insights in an iterative process to deliver the final product – a responsive ecommerce site. 

The words behind the words

The user research aspect was the most challenging for me. As a person who tends to think every little detail is important, I can easily get lost in the weeds, often jotting down every user utterance as an observation. More often than not, I end up staring at a wall of post-its, feeling overwhelmed by the information and underwhelmed by my insights. 

After going through the design-thinking process, I realize it is not so much the words uttered as the thoughts and feelings behind those words that bring value to the design process and end product. It’s a hard-earned skill – to understand the words behind the words – and one that I have not quite mastered. 



For this project, I had 3 main research goals:

  1. Understand the insurance industry landscape
  2. Gain insight into consumer understanding and perception of the insurance industry
  3. Understand how consumers obtain and pay for insurance


Through cursory research:


With a competitive feature matrix, I was able to get a quick bird’s-eye view of current industry capabilities and standards as well as what sets the disruptor apart.

Geico and Esurance have a similar business model to Kaus - a focus on direct sales online. Both emphasize online account access and customer-centered claim service. Both have invested heavily in mobile applications and online account management.

Lemonade is an insurance industry disruptor. It is a peer-to-peer company. 20% of all premiums are taken to pay for Lemonade’s overhead. The rest are spent on claim payouts. Claim processing is done by artificial intelligence and machine learning. It will be interesting to see how the lack of human agents and reps can benefit or harm the customer service experience.


To understand users more, I interviewed 5 people, conducted 1 contextual inquiry, and had a quick Q&A with a Statefarm agent.

I wanted to uncover unknowns, such as how users typically search for and procure insurance and whether users prefer dealing with local insurance agents or through an online platform that is geographically agnostic.

I also focused on disproving or proving certain assumptions such as

1) user have a hard time understanding technical insurance language

2) users view search for, evaluating, and buying insurance to be an onerous process

3) users find it hard to compare insurance packages

A few user quotes:

"Best kind of insurance is the kind you don’t need."

"Being able to ask questions freely is super important to me."

"Annoying, convoluted, non-clear process. I will NEVER switch to X insurer, regardless of price!"


After conducting the user interviews and contextual inquiry, I used an empathy map to distill the responses and gain a deeper understanding of each user's distinct experience with insurance. The empathy map consisted of 4 quadrants – say, do, think, and feel. 

Because I was so focused on not missing out on any details, I jotted down nearly every utterance and the empathy map became rather overwhelming at a certain point. 

Even super sticky post-its fall off walls; I eventually transferred every single post-it into a digital version.

The empathy map process generated a few key insights, which became the basis of user needs:

Insurance has emotional value. It provides peace of mind and control over the uncontrollable. 

Learn it. Get it. Have it. Forget it...until you need to use it. And when you have to use it...it’s a stressful time. 

Users want apples-to-apples comparison, but its especially challenging to have this as insurances coverage varies so drastically across different insurers.

Users typically start their search online but it’s always after dialogue with an agent, whether over the phone or in person, that they make the decision to buy.

Regardless of education level or time spent on research, insurance terms are always challenging to understand.

Claim processing is stressful, but when the service is lacking, it almost always leads to switching.


The empathy map exercise derived a lot of great insights. However, it was still a challenge for me to derive a persona from the findings. I needed a more holistic view of all the observations from the user interviews. I decided to do a variable mapping exercise. Mapping interviewee answers against a series of variables allow behavioral patterns to surface. These patterns became the foundation of the user persona.


From the variable mapping, I was able to get a clearer idea of what the persona’s various characteristics. Jeremy represents the goals and behavior patterns that I witnessed from the user interviews.


Creating a storyboard allowed me to inject some context into the user personal and story. Jeremy’s past experience with insurance companies wasn’t pleasant, so he was looking to switch. Good customer experience with ample time for him to make his decision convinced him Kaus was the right choice. 

It was interesting to hypothesize a situation wherein a user might possibly want to switch insurance providers. There is often a backstory that can uncover a lot of unmet user needs, which can help improve the product or service. 

I thought about how a deliberative buyer such as Jeremy would want to proceed in the process. He probably won’t just sign up right away. He would need some artifacts to keep Kaus in his mind. That’s where the quick quote came in. A user I had interviewed was really turned off by long quote forms, so I thought maybe a short one that only estimated coverage could be enticing. 

After getting the simple quote, Jeremy will most likely want to talk to someone. So, I thought an option to call or chat with a Kaus representative, at the user’s selected date/time, would be most appealing. I also considered how Jeremy might look at other insurers during his deliberation and happen upon lower prices. How would the agent address that? Because Kaus doesn’t really offer tailored packages, the agent has to do a good enough job justifying the higher price. 

The storyboard exercise presented a lot of opportunities for designing a good experience, both on and off screen. 


From the market, industry, and user research, I was able to discover that users struggle with insurance terms, comparing different insurance packages, and they view the claim process as stressful.

I also learned that users typically start their insurance search with referrals or online. However, it always require direct interaction with an agent before making the purchase decision. There was no consensus on whether users preferred local agents or a platform that is geographically agnostic.

From the research, I also decided that Kaus should place emphasis on vehicle, property, and life insurance products because these were more easily understood by users, because Millennials are increasingly buying life insurance, and because these types of insurance tend to be more universal (less differentiation through state regulations).


After conducting research, it's time to define the problem and examine solutions. I started by deriving business goals from the Kaus project brief. After this, I used Jeremy - the persona - to define user goals. 

The common goals between business and user goals became the foundation of the first iteration. 


  • Sell directly to consumers through user-centered e-commerce site
  • Transition away from brick and mortar insurance resellers
  • Manage customer relationship directly, without insurance reseller agent
  • Promote low cost optimized packages 
    (no àla carte selections and limited customizable options)
  • Obtain and maintain a net promoter score of 6 to 10
  • Increase customer acquisition of customers ages 27-45 by X percent in 1 year
  • Increase sale of auto, homeowners/renters, and life insurance by X percent in 1 year


Obtain coverage that best aligns with needs

  • Understand insurance terms
  • Ability to clarify coverage options/ questions quickly and easily with insurer during purchase decision
  • Easily compare different insurance packages by various insurers

Be able to rely on insurance coverage whenever needed

  • Smooth and quick claim process
  • Be apprised of status updates without playing phone tag with X different agents
  • Be able to ask insurer questions and get answers quickly, whenever needed


  • Interactive and user-friendly e-commerce site to sell, purchase, and maintain insurance
  • Streamline communication between insurer and customer
  • Simplify insurance terms (coverage categories, coverage limits, etc.) into human terms, understood by customers, not insurers
  • Streamlined claim processing so all parties are kept apprised of current status

Technical consideration 1:

Updated and searchable database of providers (doctors, hospitals, body shops, etc.) 

Technical consideration 2:

Record keeping of phone calls that happen offline and incorporating the content of these calls within one customer profile (integration with CRM?)


From the common goals, I formulated features that were most pertinent to these goals, as well as features that would be great additions for future iterations.


Ability to view, compare, and ultimately purchase insurance through the Kaus website.


Once users file a claim, the claim appears within the claim tab on customer portal. This tab hold info about claim, filing date, next steps, contact info, and message/chaat function. It acts as a record of the claim as well, so users and rep are seeing the same info at the same time.


Young and digitally savvy customers (Kaus' target audience) expect info to be readily acessible anytime and anywhere. The online customer portal is a central hub that holds all the important customer info, insurance cards, renewal dates, invoices, contact channels, etc.


A simple breakdown of different coverage options available to Kaus customers in their initial search.


A chat function for prospective customers to easily ask questions.


Prospective customers can schedule a call and have Kaus rep call them at specified date/time.


To come up with a site map and site hierarchy that made sense to users, I conducted a quick open card sort using Optimal sort. The card sort had 3 terms and were fully completed by 7 participants.

After looking at the results, I felt like the results didn’t really provide any insights. It would have been much more useful to conduct an in-person manual cart sort so I can witness what the users’ thought process.

But life isn’t perfect and I had to deal with the cards I was dealt. I did a manual analysis of the card sort results.

  • 4 out of 7 participants grouped auto and vehicle insurance together.
  • Most technical terminiology were grouped together even though they technically were offerings under different types of insurance.
  • Most users recognize FAQ, claim, payment, contact as separate from insurance categories.


This final site map reflects the emphasis placed on vehicle, property, and life insurance. Each of these insurance categories would have a landing page that would direct users to specific insurance types within each category. Items like search, account, bag, and footer are global elements accessible from any page on the website.

Following the site map, I did some quick iterations of the homepage. I was considering whether the home page would only concentrate on the most popular types of insurance or list out all product offerings. 

3.1 Flow it out

I mapped out a high-level user flow of the ideal purchase flow. I made certain assumptions like the user would purchase without having to talk to an agent. This was to ensure that website was optimized for purchase.

In the following user flow, Jeremy visits the Kaus site and purchases insurance without talking to an agent. 

In reality, the user’s purchase decision is never straightforward, especially when the product is insurance. Therefore, I mapped a more detailed task flow that took into account typical user needs such as talking to agent before purchasing. I thought about how to ensure that the process is seamless across various mediums of business/user interaction.

I made an assumption that users search by insurance type first. Thus, the task flow starts with the user landing on the car insurance page of the Kaus website after an initial Google search.


After working on some initial UI requirements, I began wireframing a few pages, taking into account how the design needs to respond to various breakpoints.  After this, I prototyped the wireframes to ensure the flow made sense.

Because the end product is a responsive web site, I also worked on how the home page would respond down to tablet and mobile breakpoints. For mobile breakpoints, I opted to condense the 4 insurance modules into a carousel, so as to cut down on scrolling. 

I always find navigation to be the most challenging and interesting to design responsively. I took inspiration from Wired's mobile navigation solution. This solution allows me to utilize icons for each of the insurance categories. It's especially appealing to me when graphic treatments appear on distinct breakpoints. It's like an exclusive graphic treat. 

To examine how the site would work on mobile, I quickly prototyped wth pen, paper, and the Marvel app. I focused on making sure the transitions were intuitive and followed expected design patterns. 


Before starting high-fidelity mocks, I needed to come up with a cohesive brand identity. I wanted to stay away from stock photography and color palettes typically associated with insurance. Insurers such as Lemonade and Oscar Health really inspired me to do something different. 

I focused on picking colors, type, and graphics that corresponded to these adjectives: whimsical, easy, happy, human, dependable and earnest.

3.4 UI KIT

With the UI kit, I focused on building upon the brand identity with interactive UI elements such as hover and active states, form fields, and search. After building the UI kit, I utilized it to stylize the responsive wireframes from earlier. 


Before I could conduct any usability testing, I had to have a working prototype. Because of time constraints, I included both high-fidelity mockups and low-fi wireframes in the prototype. 


Usability testing is key to ensuring assumptions made during the designing phase are correct, and if not correct, why not. For the usability test, I enlisted 4 participants. I recorded each session so that I may go back and review in detail later. 

Here are some of the goals of the usability testing: 

  • Determine if the user interface is usable
  • See whether the decision-making and purchase decision can be made easier with a quick quote 
  • See if users understand and can utilize the navigation
  • Understand whether users’ perception of the Kaus brand aligns with the adjectives I was striving for in designing the brand style.


For each task the particpants performed, I marked it as pass or fail. The overall test completion rate and error-free rate is 76%. Any task tht wasn't completed was counted as an error. 

After the usability test, to surface common design successes and failures, I conducted an affinity map. I wrote down observations for each usability test on a post-it and after filling an entire wall with post-its, I started to see patterns and categories. 

After a few days of finding random post-it notes on the stairwell, I finally transferred the affinity map into a digital version using Trello. 

Affinity MappingAffinity Mapping


All 4 participants found the site to be aesthetically pleasing, clean, and enticing.

Overall, it seems that the navigation and interaction patterns were understood and usable.

All 4 participants found the quick quote and call scheduler function to be useful and usable.


There was some confusion about the differences between quick quote and full quote. Some users wanted to go directly to the full quote.

Although users found the quick quote to be easy to use, most were skeptical over the results. They wanted more explanation over how the rates were calculated and the average coverage used to generate the quote price. 


After the usability test, I realized that certain assumptions I had made were incorrect and addressed the urgent ones.

For example, users did not differentiate between quick quote and full quote buttons. My conceptual model did not match the users' mental model. To address this issue, I decided to make the quick quote and full quote CTAs default to quick quote forms, with the option to switch over to full quote more apparent. 

Per user suggestions, I also added a "add to calendar" feature to the call scheduler confirmation page. 

Because certain start quote CTAs were not specific to any type of insurance, I also worked on an interstitial screen that asked users to select the type of insurance for which they want a quote. 

Interstitial - pick insurance typeInterstitial - pick insurance type
[unex_ce_button id="content_tlu0h76f3,column_content_u3crrqe86" button_text_color="#000000" button_font="light" button_font_size="12px" button_width="full_width" button_alignment="center" button_text_spacing="2px" button_bg_color="#ffffff" button_padding="10px" button_border_width="1px" button_border_color="#ed5650" button_border_radius="0px" button_text_hover_color="#ffffff" button_text_spacing_hover="2px" button_bg_hover_color="#ed5650" button_border_hover_color="#ed5650" button_link="/bon-voyage/" button_link_type="url" button_link_target="_self" has_container="" in_column="1"]PREVIOUS[/ce_button]
[unex_ce_button id="content_tlu0h76f3,column_content_2zkscy89k" button_text_color="#000000" button_font="light" button_font_size="12px" button_width="full_width" button_alignment="center" button_text_spacing="2px" button_bg_color="#ffffff" button_padding="10px" button_border_width="1px" button_border_color="#ed5650" button_border_radius="0px" button_text_hover_color="#ffffff" button_text_spacing_hover="2px" button_bg_hover_color="#ed5650" button_border_hover_color="#ed5650" button_link="/project-banana/" button_link_type="url" button_link_target="_self" has_container="" in_column="1"]NEXT[/ce_button]