Chase Bank

Claims, Disputes and Fraud Operations

UX Design

If you’ve ever reported fraud on your bank card, or had to dispute a charge and wait anxiously for the money to show back up in your account, chances are I’m familiar with the experience through my time working at Chase. In this case study, I’ll be looking at when I was tasked with designing the UX of a debit cardholder looking to provide supporting evidence for their disputed transaction. Think sending in a copy of your receipt or a picture of the faulty item in order to get your money back.

^That’s me (second from the top) running the affinity mapping session with Lori, our research lead, for the product team

It’s hard to complete a task when you don’t even know you have one...

After two rounds of moderated research, it became clear that users had the most difficulty in the upload flow before starting it. That is, customers don’t even expect to follow up on a claim unless the bank told them they had to.

It might be unthinkable to some in this day and age, but if a customer had an open claim on their debit account that required them to provide evidence, the existing system would notify them by mail or phone and request they mail or fax in the documents. The customer would then have to wait weeks for further notice from the bank about any actions taken on the disputed transaction. As such, my team was tasked with designing the digital upload experience from scratch.

To complicate things, the entry point on the homepage to view open claims was three clicks deep. When presented as-is, research participants reported an average ease of use rating of 1.2/5. When we showed them directions in the form of an email, the ease of use rating increased to 4/5.

🤔 Problem

The current analog flow of getting evidence from a customer to support their open claim can take weeks and lengthens the process to resolution while also causing users feelings of uncertainty and anxiety.

💡 Insights

Most friction occurs at beginning of the digital flow because 1) users don’t expect to follow up on a claim unless explicitly notified, and 2) homepage UI obscures the entry point into the upload function.

😎 Solution

Include wayfinding instructions in the “Action required” email and highlight the claim in question. Plans to work with engineering team on deep linking capability from the email as a fast-follow.

From the flow we tested, we realized it takes three clicks to get to the Claim Tracker, then the user has to open the claim details panel, and then from there get into the document upload flow.

There are many ways to a solution, but how much time do you have?

This project was a constant reminder that UX design never happens in a bubble. My first instinct after research was to think about reconfiguring the placement of the Claim Tracker entry point on the dashboard. Well, the dashboard was a separate product owned by a separate team and this solution would have taken a much larger, concerted effort that we just didn’t have time budgeted for.

We did work closely with the document upload team to ensure that our user would be able to land in their flow with some relevant information already entered— no one likes to have to enter their details again after thinking they already did on the previous page!

We made it clear to them that it was vital that the following were already reflected by the time the user reached the document upload center:

  • Type of account (which would have already been selected from the dashboard)

  • Reason for upload (user was previously asked to provide evidence for their claim)

  • Claim ID (research showed that users don’t record this when initially filing the claim; the bank also doesn’t send a copy of the claim ID with the claim confirmation email; the claim would also have been identified from the previous Claim Tracker page)

Time is also why we landed on the email instructions as our wayfinding solution for this release; although we had to speak to another team (within the same product group), it required less effort to convince them that it was important for our user to be able to quickly find our Claim Tracker page.

I would have liked to explore deep linking from the email directly into the document upload flow, to bypass the user having to read the instructions and click around on the dashboard, but that would have required more developer hours than this project was allotted. It also posed further security questions because of user authentication, so we shelved this idea for a future release.

One other thing that was within our immediate capability of improving was the Claim Tracker. My solution was to include additional statuses to the existing “In progress” and “Closed,” to describe the claim journey in more detail:

In progress > Additional documents required > Documents received > Closed

This added some extra hours to the project in terms of backend work, but we were able to convince our product partners that this would be valuable in saving our user time and maintaining their attention span. I also added the “Upload a document” link to the claim detail panel as a pertinent call to action for the user to take another step towards completing their claim journey.