Case study: Balancing design processes for multiple user groups

Lucy Lee
Lucy Lee
Oct 31 · 8 min read


I work as a UX designer for a company whose main product is classic car insurance. My goal was to redesign the online quoting experience for 4 user groups as we moved from a legacy policy management and quoting system to a cloud-based system. We had 9 months until product release, with each quoting experience having roughly one month to two months of design time for each user.


  • Average classic car enthusiast who wants to buy auto insurance
  • Agents that the company partners with in order to sell auto insurance
  • Internal licensed sales agents who work at our internal call center
  • Internal licensed sales agents who exclusively work with clients who have high-value car collections

How I approached the design process

Because some projects had a deadline of only a few weeks, while others had looser deadlines, I drew from a toolbox of UX methods and relied heavily on some and dropped others. The main toolkit included:

Competitive benchmarking


Gathering information about top competitors in the auto insurance space.


Not only is this stage helpful for getting inspiration for solutions to problems specific to the domain, having this stage helped in providing support for big design shifts. For example, when making the case for single-task flow (where a user can focus on a single task or question at time), I could supplement behavioral principles with examples of competitors as social proof.

landing pages of competitors

Stakeholder interviews


Interviews that preceded observations or usability testing


Get quickly at project goals, and hypothesize user needs, interactions with system, pain points


  • Remote meetings where we talked through a draft journey map of user workflows, which I used when I had around 2 weeks to get to a design.
draft user journey for understanding user actions, system actions, pain points, and opportunities
  • Remote meetings where we identified basic requirements, created ideal workflows, validated journey maps, and prioritized ideal features.
remote workshop to understand of ecosystem of users and tasks
  • For projects that had more time, I conducted in-person workshops…



In-person workshops with business stakeholders, design team, users, focusing on How-might-we’s, personas, and ideal user journeys.


To better understand the problem space and for blue-sky thinking. This helped me understand the wide variance of our external users in everything from their knowledge of classic cars (sometimes a spouse or an assistant will be filling out the quote) to their technical aptitude (users who fill out quotes for a living versus users who only come do an online quote once every couple of years).

Example of an expert persona
example of a high-level ideal quoting process



Observing users interact with existing designs


To understand what works and doesn’t work about current workflow. This step was especially integral when designing for internal power users.

Workflow in current system

Page flows


A page-by-page representation of the quote flow and the types of questions being asked on each page.


Helpful in communicating with stakeholders as we fleshed out requirements. For example, we could see clearly how the questions needed to be asked to make logical sense to the user, and could also use these diagrams to discuss where to run third-party reports that help us calculate the quote.

Example of a page flow

Interactive prototypes


Clickable prototypes that felt like an actual quoting system


To test the whole experience from start to finish. Essential because of complex requirements, and helpful for visualizing the product.

Quote for direct users (Average Joe)
Quote for agents (semi-power users)

Usability testing


Having actual users get a quote with the system. We emulated a real-life quoting experience as much as possible, for example by having team members phone in as clients.


To test the flows from a user perspective.

Based on the timeline of each project I adopted different usability testing schedules.

  • Direct: We invited classic car enthusiasts to our Ann Arbor office and had them get a quote with the prototype. We also invited stakeholders from actuarial, product and other teams to observe users and to partake in note-taking.
War room for an in-person usability test
  • Agents: We visited 3–4 agencies around Ann Arbor and observed agents get a quote with the prototype. This group had the most varying practices of quoting — ranging from agents who didn’t usually do the quote themselves and instead relied on data entry specialists, to agents who used our quoting system at least a couple times a month.
Raw notes for a remote usability test
  • Internal users: For 5 days, I ran 3 usability tests each morning, and in the afternoon and evening I updated the prototype. By day 5, I was fairly confident with our solution.
Example of a vehicle detail page from day 1 to day 5


I ended up designing four flows for each of the user groups. There was some initial pushback from the team on designing four experiences, but based on the evidence compiled from discovery and research, it was clear that creating a one-size-fits-all experience would result in a poor experience for all users.

I focused on interaction design rather than UI design, since we were using out-of-the-box styling on internal products, and external products would have a visual design pass.

Global principles for all flows

  • Polite— remember the user’s preferences and details
  • Customized — recommend the right coverage based on the user’s needs
  • Contextualized help — help the user with tasks the moment they need help

1. Average classic car enthusiast

  • Single task per page to reduce cognitive load, especially because some of the quote questions are difficult (ex. what kinds of modifications does your vehicle have)
  • Mobile-first, since mobile quotes accounted for more than 50% of this user group
  • Very clear, friendly language, with the tone and personality of the quote being that of an expert, warm call center agent who knows both insurance and cars extremely well.
example of personalization at beginning of flow

2. Partner agents

  • Help them sound like experts to their clients, even if they don’t know that much about classic cars or classic car insurance
  • Provide them with opportunities to promote special discounts and additional coverages
  • Help them provide their clients with truly customized insurance.
  • More information-dense than Average Joes, since they want to get scan information quickly during calls or get through questions with the least amount of clicks possible.

3. Call center agents

  • Similar to external agents, with a range of experience and knowledge of classic cars and classic car insurance
  • Need more flexibility rather than guidance on customizations
more flexibility with customizations

Call center agents who focus on high-value car collections

  • Designs need to support highly complex workflow, since their tasks overlap with underwriting
  • Clients can have hundreds of vehicles; designs needs to be highly compact
  • Need the most amount of flexibility in tailoring coverages and discounts
  • More time per client, but an extensive amount of documentation and communication for each client

Quote result page for all user groups


Development started with the internal call center agent experience first, and I supported the development process through documentation and communicating with business analysts and developers. I started to work on the Canada versions of these flows before being pulled onto other projects.


  • Deciphering complex auto insurance requirements that differed by state
  • Designing for users who range widely in comfort with classic cars and insurance.
  • Creating designs with the goal of meeting user needs, then retrofitting them to an out-of-the-box software system.
  • Balancing needs of multiple business units (underwriting, actuarial, insurance product, legal, strategic partners, etc.)
  • Sole designer working with 30+ internal and contractor developers and business analysts


Some things that helped the project:

  • Calendars :D.
  • A super organized product owner
  • A supportive research team
  • Relatively frequent touch points with other business units
  • Freedom to run the design process as I needed
  • Support from business for usability testing

What I would do differently:

  • I would not start with blue-sky thinking and move back to fitting to an existing out-of-the-box system. This proved especially difficult because the system was a new product and none of the developers on our team had experience with it, meaning that it was extremely challenging to understand what was feasible and to predict dev time.
  • I ended up taking on a lot of tasks that might not be traditionally a UX designer’s job — for example, identifying state-specific requirements for automotive discounts. Overall, it may have been helpful for a designer to be so engrained in the details, but this also meant I was spending less time on interaction design.


Design in a short timeframe can be rough, but is doable with appropriate planning, as well as flexibility in giving up some methods and steadfastness to others.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade