top of page
Improving Claim Experience
A redesign of the experience to file and track the claim at MakeSpace.
Check it out here:
https://makespace.com/account/claims/
.png)
NEW Claim experience
PROBLEM STATEMENT
-
Customers struggle to initiate and track their claims online. Lots of manual process.
-
Support agents spend tons of time dealing with inquiries about claims. We are wasting money.
-
Only a short window to make a significant impact to the business due to the seasonality of storage.
OBJECTIVES
-
Enable customers to easily and correctly file a claim on their own.
-
Reduce support tickets per claim. Save money on customer support costs.
-
Strategize and execute quickly to make a bigger impact on busy season.
IMPACT
-
31% decrease in support tickets per claim.
-
40% savings ($52,000/yr) on customer support cost.
-
New design QA process established.
-
Alternative user testing method introduced.
BACKGROUND
Storage and transportation industry faces a common issue that things may get damaged or lost in transport. When accidents happen, in addition to the existing frustration, customers still have to go through a complicated claim process—they need to find claim form at our Help Center, fill out the form, send photos to us via email, and then wait for 4 weeks to receive a resolution. Oftentimes, they need to reach out to support agents for assistance, or simply just for an update.
Current claim process
1 - find claim form at Help Center
7.png)
2 - fill out the form
3 - send photos through email and wait
Going into 2020, we expanded our business and the problem has become worse. For each claim started, the support team received over 5 tickets from customers on average.
RESEARCH
To better understand the problem, I started to look into more data. Quantitative data offers me a good overview of the problem scale and a wide range of problem categories. Meanwhile, qualitative data helps me understand the problems more deeply. I get to empathize with the customer on their needs, motivation and specific usability problems.
Total time spent by ticket type - Zendesk
File a new claim
Check on the status of an existing claim
Submit photos
Claims inquiry type - Zendesk
In the past 6 months, the support team spent 26% of their total time working on claims tickets. Within all those tickets, 56% is about filing a new claim; 30% is about submitting photos; 14% is about checking claim status.
To better understand the problem and specific customer needs, I further reviewed 50+ claims tickets and watched 30+ FullStory recordings. I found out many customers simply don’t know where to start and they get very anxious while waiting to receive an update from the support team. And sending photos through email is always a hassle—customers struggle with the image size and it also takes much time for the support team to reorganize the photos.
Review claims tickets
Watch FullStory recordings
Note: contents are blurred for confidentiality
Customer Lisa
“Some of the furnitures are broken. What should I do now? Is there any process where I can get compensated?”
Customer Maria
"I just submitted 2 claims. And I also sent you several emails with the photos (the photos are too large to be included in one email). Can you please let me know if you get everything??"
Customer John
"I don’t know if I ever got a follow up email. I just wanted a status update on my claim."
SYNTHESIS
In the past 4 years, the support team spent ~30% of their time dealing with claims tickets. It cost us $120,600/yr, which significantly exceeds all other categories.
BUSINESS
To file 1 claim and receive a resolution, customers needed to reach out to us 5 times to get answers.
CUSTOMERS
PROBLEM
Customers struggle to initiate and track their claims online.
Lots of manual process and not enough clarity.
The goal is to enable customers to easily and correctly file a claim on their own. The KPIs we want to impact include the number of support tickets per claim and savings in customer support cost.
PRODUCT & EXPERIENCE STRATEGY
Process strategy
To make sure the new claim experience can be seamlessly integrated into customers’ current journey. I started from a broader view of customers’ whole MS journey, then zoomed in to think of the claim experience. Lastly, I also looked into implementation details to make sure the ideal experience can be delivered.
01 MAKESPACE USER JOURNEY
Going through Customers’ MakeSpace journey, I found out Dashboard is the central hub for customers. They come here to book appointments, manage their inventory and basically do everything. To ensure a smooth experience, we decided that Dashboard will also be the place where customers initiate and track their claim.
02 END-TO-END CLAIM EXPERIENCE
Based on the support tickets data and our current workflow, the overall claim experience should consist of 3 steps: initiate, file and track. In the new experience, customers can easily initiate a claim on their dashboard, file the form and return to Dashboard to track the progress.
03 IMPLEMENTATION DETAILS
CHALLENGE
However, delivery season is coming! The claims are gonna be piling up.
Tight schedule. Big project.
In order to release it as soon as possible and stay agile, we made a 3-phase implementation plan based on the level of effort and impact. As a result, the team planned to implement “initiate” and “track” experience first, while I continued working on the form experience.
DESIGN
PHASE 1 INITIATE AND TRACK EXPERIENCE
Design principle for Initiate and Track experience
Harmony and Visibility
Initiate
Track
CHALLENGE
However, Claim is still an unpleasant and sensitive topic. How can we limit the potential impact on general customers?
For this challenge, our strategy is to target the right audience at the right time. I discussed with the development team to make sure we only show the claim feature to the customers who just finished their delivery appointment, the feature will also only appear for 2 weeks (which is also the eligible filing period).
PHASE 2 FORM EXPERIENCE
As the implementation started on those two features, I continued working on the design of the form experience. I briefly explored several options including multi-step form experience and single form experience. In the end, I moved forward with the single form experience because it offers more flexibility in making edits.
Multi-step form experience
Single form experience
Single form experience - wireframe
DESIGN CHALLENGE
With a complex and dynamic form like this, how might we make it clearer?
Discussed with another designer, I decided to use a white container at each section (over the grey background). This way the visual is more consistent with our design system, and it also delivers better visual grouping.
Visual grouping
4%201.png)
Before
After
DESIGN CHALLENGE
How might we make sure customers include all the items in one form?
During research, we found out a lot of customers submitted multiple forms with different items. This caused the support team’s extra time reorganizing the data and much confusion in communicating with customers.
I approached this challenge from different angles. First of all, from a usability perspective, I moved the “Add Item” button to somewhere more prominent and intuitive in the flow. As for content, instead of providing instructions only at the beginning where customers tend to skip, I moved instructions closer to the “Add Item” CTA so that it’s more relevant. When it comes to interaction, we used to have a complex and confusing way to add and edit items. In the new version, I simplified the interaction to accordion component. It’s more simple and intuitive.
Usability
Before
After
Content
Before
After
Interaction
Before
After
USER TESTING
I suggested doing user testing to collect customers’ feedback. However, this idea received push back from other stakeholders.
User testing was still in its early stage at MakeSpace. We only did a few moderated 1-1 user testing before and they can be pretty time-consuming. I evaluated the risks and project goals, in the end I decided to align with the team. The new experience will have instant impact anyway cause it provides additional and major functionalities like image-upload. And I also think that it’ll be much more beneficial if we can release it before the peak season.
To mitigate the risks, I suggested collecting feedback among cross-functional stakeholders, especially the ones who work very closely with customers. And we will collect user feedback after release by reviewing FullStory recordings and customer support tickets, and we can make follow-up design changes when necessary.
REVIEW WITH STAKEHOLDERS
The review with stakeholders was quite insightful. One problem brought up by Chalmers (Director of Claims) was “Customers often struggle with getting the item barcode. Now it’s the first question, it might put people off.”
The problem was just the tip of an iceberg. I started to rethink the overall order. The problem was that the order of the fields was not optimized for a natural mental journey. I reorganized the order of questions—starting off with simple and descriptive questions to ease people in, granular questions come in the middle, then we will end up with more complex questions that require interactions.
Designing a natural journey
Before
Simple
Granular
Complex
After
Another problem brought up by Sean (Senior Manager of Customer Enablement) was “Customers feel upset when they don’t receive the money they claimed for. How can we help them understand our policy?”
This problem was also discovered in the research. I think the problem here was not only that we didn’t effectively educate our customers on our evaluation policy, but also that we set the wrong expectation for them. In the iteration, I moved the evaluation policy closer to the end of the summary so that it’s more relevant and people are more likely to pay attention to it. I also suggested removing the value in the summary view so that we don’t emphasize and set the wrong expectation. It was a bold idea but I quickly got buy-in from stakeholders.
Setting the right expectation
Before
After
IMPLEMENTATION
During implementation. I worked closely with engineers on design QA. One area I worked on is to make sure the form is accessible. For example, making sure clicking on the radio button or the copy next to it will have the same expected behavior. (Same goes for the image-upload field)
Form accessibility
Design QA
POST-RELEASE
Despite a rocky design QA, the whole experience was shipped before the 2021 delivery season (July). And the results have been very positive.
-
31% decrease in support tickets per claim.
-
40% savings (~$52,000/yr) in customer support cost for the Claims team.
I also started watching FullStory recordings to see how customers interact with the new experience. Overall, I’m glad to see how easy it is now for customers to initiate their claims and track them on Dashboard. And the form is easy to use in general, but there are still some usability issues.
I’ve seen many people struggle to get past this value field. The problem is that we have very specific validation, but the field itself is very vague to customers. In the follow-up design, I used constraints to guide the behavior so that customers can avoid seeing error messages and get past this field easily.
Another bigger problem is that people still create multiple claims to include different items. Potential issues are - the copy is unclear, the CTA is not prominent enough, and we are not building the right mental model in general.
Value field usability
Struggle with the value field - FullStory session
Follow-up iteration
Item experience
-7%201.png)
Implemented version
Follow-up iteration
The follow-up designs are being implemented. We’ve heard positive feedback from stakeholders.
REFLECTIONS AND NEXT STEPS
USER TESTING - How might we conduct user testing in a timely manner?
The 1-1 moderated testing can be time-consuming, and that’s the major reason why we couldn’t test as often as we want. After this project, I discussed with the lead designer about adding another testing method. Now we’ve added usertesting.com to our research method, which significantly speeds up the testing process and can be a great tool for some projects.
DESIGN QA - How might we bring the implementation and design closer more efficiently?
I noticed that when doing design QA, sometimes it's too late or too much work to address all the small adjustments. I brought this problem up to get buy-in from stakeholders. And we agreed on involving design QA as soon as possible during implementation - ideally when they are still smaller components. I also talked to developers to understand their development process and discovered many engineers are not comfortable inspecting in Figma. To address this issue, I prepared and hosted a Figma Lunch & Learn to help developers get more comfortable with Figma and make use of its helpful functionalities. Besides that, I also become more mindful in creating design so that it’s easier to inspect and implement.
Most of all, I learned product design is a continuously learning and iterating process. Success is not only about metrics, but about the fact that we are learning something new and continuing to grow.
bottom of page