Liability Analysis Tool
Tools Used: Sketch, Zeplin, InVision, Mural
Client: Allstate Insurance
Research Methods: Contextual Inquiry, Concept Testing, Card Sorting, Usability Testing, In-depth Interviewing
Role: Product Designer
Background & Context
Why it was built
The tool had three significant goals upon release:
#1 Reduce the number of days to investigate a claim
#2 Create more consistency in the Adjusters’ liability decisions
#3 Start on a journey to create system-guided liability decisions
What it is
The Liability Analysis Tool is a web application used by Allstate Claims Adjusters to assist them in making an auto liability decision.
Prior to the tool, Adjusters did much of the work in their heads or outside of Allstate software. The tool launched as a way to keep Adjusters accountable for their work and to provide documentation for every aspect of the decision.
Our Users
A few words to describe our users:
Busy: Our users are expert multitaskers: working in multiple systems, taking calls, helping co-workers, making calls, and documenting everything along the way so nothing gets lost in translation.
Critical Thinker: Liability Determination employees need to build a case, thinking critically about all the information presented to them, asking questions along the way to submit a fair and robust fault decision.
Communicator: Our users need to be able to communicate effectively, even in heighten conversations. Sometimes participants will be angry or frustrated; a Liability employee needs to be able to stay calm, answering questions quickly and efficiently. They may need to understand what’s happening in a claim in a matter of seconds if a participant calls with questions.
When I Joined The Team
When I started on the Liability Analysis Tool, the product had just launched as an MVP. I was coming from a team (Accident Scene Sketch) that’s product lived within the Liability Analysis Tool, so I was able to hit the ground running. Post-release, I traveled to two offices to conduct Contextual Inquiries and see the tool in our users’ environments. On my first trip, my research pair and I were able to sit with 24 claim employees for 2-hour sessions, each observing everything from notes on their desks to their work in the tool.
Major Finding From The Field
Being out in the field, I was able to observe something that hadn't come up in remote sessions or our monthly survey: our users weren't using photos as evidence to help support their fault decisions. Up to this point, I had heard about how great photos were as objective evidence. When I asked employees about their use of photos, I heard that photos appeared small in the tool and that it was difficult to see the essential details. I also learned photos didn't always make it into the Liability Analysis Tool. When I started to dig into this, it became clear that many of the users didn't understand how to see other participants' photos. This issue was a pretty cut and dry usability problem.
first things first
While I knew I needed to redesign the gallery component for our users, we were also redoing the look and feel of the tool to be Allstate branded and on a shared front-end pattern library. Nevertheless, as a product team, we wanted the Liability Analysis Tool to share components, including the front-end code with the other claims products at Allstate. We felt the consistency would help our users as well, as they often toggle between different company systems and tools.
I worked closely with my Product Manager, design partner, back-end, and front-end engineers to update the code and visual design. We convinced our stakeholders that should we sell the product to other companies, we could keep the components the same and apply a theme in the form of new colors and fonts. Everyone was on board, so I put my head down and got to work, testing along the way.
Shared Gallery Component
When working through the redesign, I set up weekly pairing sessions with the pattern library developers to go over designs and provide feedback on the builds. During one of our weekly meetings, we were talking about the reskin of the Asset Damages section, and the library team mentioned other product teams had been asking the pattern library to build a gallery component.
Having multiple needs was a perfect opportunity to move our Asset Damages section work up to the top of our backlog. I worked closely with the pattern library and partnered with the other product team to design the gallery component to fit both of our use cases and then took the design into usability testing.
Use the carousel above to read my findings and additional details on the testing objectives.
Launching The New Gallery
There were some items I wanted to iterate on post-testing, including the indication that a user added evidence. Still, for the most part, I was ready to add the wireframes to Zeplin for the developers to start building. The gallery component was added to the pattern library and used by the other team for their MVP. We released the new Asset Damages section with the release of our new look and feel. There was a lot of excitement about the new design overall; Adjusters were happy to see photos enlarged, available without additional clicks, and the added ability to zoom in and out.
“I love the new updates, much easier to read without having to scroll all over the page. ”
“It doesn’t look like a piece of hardware; people are meant to use it easily.””
Benefits & Learnings
Launching the new brand on a pattern library certainly was a team effort. I had to lean into collaborating across disciplines, even outside of my product team. I had to make an effort to pair with designers on other products, the pattern library, and evangelize the benefits of sharing a library to my various stakeholders in different business areas. Plus, I accomplished my original goal of fixing our gallery component and released it earlier than expected.
Designing with the library and front-end engineers resulted in more thoughtful components that were accessible, brand-compliant, and scalable. As a product team, we were able to release new features and improvements to the field much faster, and I was able to spend time on more valuable things than pixel-perfect specs for the developers. I was able to focus on our next epics and problem statements, getting on a better cadence for our sprint cycle by always staying one problem statement ahead of development.