Snapsheet VICE

Virtual Insurance Claim Engine

Snapsheet, a leader in automotive insurance virtual claim processing, wanted to reduce time spent by a Negotiator to resolve a Supplement (repairs and labor not identified in the initial estimate required to restore a vehicle to pre-loss condition).

The Problem

The Supplements process was a bottleneck in the lifecycle of a Claim— often increasing the duration of an open Claim by a week or more. Snapsheet's revenue model depended on resolving a high volume of Claims in a fast pace; any truncation of the Supplement process strengthened the company's financial outlook.

Simplified Claim Process

While many variables causing the timeline bloat were external (and therefore largely out of our control), my team's goal was to reduce the amount of time Snapsheet employees spent resolving a Supplement.

Users and Audience

Initially the sole audience was Snapsheet’s Negotiators who had extensive knowledge of vehicle repairs, repair facilities, and Snapsheet’s existing claims software called “CORE”. The audience eventually grew to all of Snapsheet’s customer and partner support. More on that in Process.

Negotiators would review photos of a damaged vehicle (sent by the vehicle owner and/or the repair facility) and compare the Supplemental Estimate from the repair facility against the Insurance Carrier’s guidelines to negotiate with the repair facility for the best, fastest, most economical to-guidelines repair of the vehicle.

Roles and Responsibilities

A single Designer was charged with leading the project under my supervision. We developed a research plan that she implemented with support from myself and one other Sr. Designer. The Lead Designer and I developed prototypes and vetted them through Users, Engineering, and Management stakeholders. The Lead Designer oversaw the handoff of UI to the Engineering Lead for final implementation

Scope & Constraints

Initially, the project was scoped by the CTO for 3-weeks.

Because improving the Supplements process would make the business more efficient, we were given leeway to provide the best solution rather than adhere to a strict timeline. After our team identified the addressable causes of inefficiencies, the timeline was extended to two months for the UX/UI overhaul and four additional months for production.

Process

The project spanned six overlapping phases of development.

Process Diagram

1. Research

Research Plan

First the Lead Designer and I shadowed Snapsheet’s local Negotiators observing and noting how they used CORE and other tools to do their work. They were asked to speak through what they were doing and why so that we could gain a better understanding not only of their tasks, but their goals.

Having gained some understanding of their process, we interviewed the local Negotiators to uncover frustrations they had with the existing software and to gather their opinions on what could be improved, what features would be helpful, as well as their main frustrations.

We simultaneously developed a questionnaire that could be sent to top-performers from Snapsheet’s Negotiators throughout the country and combined the results with our in-person findings.

After gathering requirements through our software audit (later in the process), we would lead card sorting exercises to determine how to best organize the information the system would need to present.

Findings

During our research, we learned that our users needed to navigate three separate internal web-based software systems as well as multiple other tools in order to complete their tasks for each Supplement:

Photos from the vehicle owner and initial estimate were in one location (VICE), photos from the repair facility were in another (CORE), and communications to and from the Adjuster at the Insurance Carrier were in a third (Adjuster Portal), and vehicle repair schematics were only available in a third-party system (CCC).

Further complicating things, several crucial pieces of the Supplements workflow required their own browser window to view.

The result of the above meant Negotiators needed approximately eight open browser tabs spanning four software systems to view & process a single Supplement. I became abundantly clear that we needed to simplify their workflow in order to increase their efficiency.

2. Requirements Gathering

We then set out on the task of auditing each of the internal systems for the important bits of information the Negotiators needed to process a Supplement.

Printouts of Legacy UI with Annotations

We created a spreadsheet capturing the information displayed in each system, eliminated duplicates, and grouped like items. We then had several Negotiator team leads review our groupings. Finally, we had Negotiators complete a card sorting exercise to inform us on how to best group the outlying information.

Example of Card Sorting Results

The data gleaned from the card sorting exercises were then converted into an information architecture of the unified assignment view.

Information Architecture Based on Card Sorting Exercises

3. Prototyping

In the early stages of prototyping we pursued two solutions: revising the current CORE system to better serve the Negotiator workflow, and re-inventing the VICE system to serve Negotiators and Customer Success Specialists (CSSs; Snapsheet employees dealing primarily with Vehicle Owners).

It was immediately clear to the Design team that reinventing VICE was the better solution— not only would it improve the Negotiator workflows, it would also improve the CSS workflows. We were quickly able to convince leadership that the broader scope provided better value.

With the broader scope we had to repeat some of our research with CSS. We found that, with a few exceptions, the CSS workflows confirmed our research findings from the Negotiators.

We then iterated low-fidelity mockups of a few UIs ultimately landing on what we would eventually call VICE 2.0— rather than the information regarding Claim (also referred to as an Assignment) to be spread across two main systems we would distill the most relevant information into a single unified assignment view.

Low fidelity sketches capturing UI concepts

Mockups were first vetted by the Design team, then Engineering Stakeholders (for feasibility), and finally with Negotiator and C-Suite Stakeholders. Fidelity increased with each iteration.

4. Implementation

The Lead Designer and I worked with Engineering Leads to ensure a smooth transition from Design to Engineering simultaneously adding new components to our fledgling UI library (called SnapKit) so that they could be easily repurposed in future Development efforts.

A mockup of final UI for the Supplement tab of an Assignment

5. User Acceptance Testing

As Engineering completed the development of our designs, we ran a pilot program beta testing the software with a small group of Negotiators on Claims from select Insurance Carriers. VICE 2.0 was unanimously preferred for its ease of use over the previous systems and it was green-lighted to rollout to Production in a phased approach.

6. Training

The Lead Designer provided annotated UI mockups detailing the intent behind and use of various sections of the UI. Snapsheet’s internal Learning & Development department then provided training for Negotiators and CSS on how to use the new software.

Annotated wireframes provided to Learning & Development showing the Inspector tab of an Assignment

Learnings

The process provided not only insight into how to improve Snapsheet’s internal operations, but also the foundation of the product that Snapsheet now sells as SaaS for their international clients.

It improved the efficiency of Negotiators handling Supplements by 15% meaning they spent less time learning and navigating software and more time focused on their work.

By observing our users, analyzing their tasks, listening to their input, and being willing to question the initial ask, we uncovered a solution with far greater potency than that envisioned by leadership at the outset.