Case study – Fraud & Claims Bot

Fraud and Claims case study
Problem
The current process for filing a fraud claim at our financial institution is known to be a painful experience for our customers.  The process normally starts with an IVR call for transaction verification and then can span across two to three different customer service departments via phone call.  The movement from one department to the next are often cold transfers which forces the user to repeat the same information multiple times adding frustration to an already troubling experience.
My Role
When I first joined the project team we had another designer who was working on the concepts.  She was rolling off as I rolled on.  We already had some initial wireframes and concepts.  My job was to continue with our initial concepts while also adding new features.  I was responsible for creating wireframes, visual design and prototypes.
How Might we
How might we create a more streamlined experience for identifying fraudulent charges and filing a claim if necessary?
Context
By the time I had joined the team it had been decided that we would develop a chatbot that would assist a customer with the fraud claim filing process.  We would create a standalone iOS application that would serve as a proof of concept that would simulate how the experience would work.  The long term goal being that if the POC was successful we would later integrate what we had done into our main consumer mobile application.  The POC would also serve as a way to get user feedback during testing.
Team
Our team consisted of the following members
  • 1 Designer
  • 1 Front end developer
  • 2 Back end developers
  • 1 Project manager
  • 1 QA tester
  • 1 Tech manager
Initial Research
I linked up with one of our user researchers shortly after I joined the team.  The user researchers we work with are not traditionally part of the project team.  They usually work as consultants on as needed basis.  During our first meeting together we made I discovered, purely by chance, that the researcher that had been assigned to our project just completed a 3 month research study on our current fraud process.  While some of her focus was adjacent to our area, we were able to get in-depth knowledge of the current fraud claim process which ended up defining our problem space and made a considerable impact on our eventual solution.
Customer Journey maps
Based on the findings from our user researcher, I created some customer journey maps comparing the existing experience and what we proposing for the new flow for filing a fraud claim.
current process

Current fraud & claims process

to be

Proposed customer journey

Design
Based on our journey maps we outlined the features and I began creating wireframes and then later visual design assets that would be exported to the development team
use cases

Main features

design

Wireframes

1 design

Responding to a push notification from the system

2 design

Verifying recent transactions

3 design

Transaction verification complete & adding comments to the claim

4 design

Reviewing summary and submitting the case

Prototype
In parallel of creating wireframes and design assets, I also created a clickable prototype using principle to help explain to developers how the transitions and animations would work inside our mobile application
prototype
User testing
Once we had a working proof of concept completed, we took our mobile application into user testing sessions with 5 different users to get some initial reactions to what we had built.  I worked with the research team to develop an interview script and helped screen candidates who met our criteria.  Our main criteria was customers who had experienced fraud in the last 6 months and filed a fraud claim based on the unauthorized charge.
Findings
Some quotes from our sessions:

“When I come to a chat screen, I don’t expect it to read the text out loud.”

“I like this and prefer to interact with a bot for something like this. It’s much easier than calling over and over again and having to repeat myself.”
Some general take-aways:
  • Liked interacting with a bot but were surprised by the voice and did not care for it.
  • Concerned about financial information being broadcasted and using voice in a public place to discuss financial information
  • Worried about security – would like conversation to be encrypted and stored safely because it’s sensitive information
  • Redundancy: Bot saying information has been saved after each transaction that is selected as fraudulent.
  • Ability to pull and view transactions by location/ date and select fraudulent transactions in a single view vs. one at a time.
  • Would like to receive notification for status update in 2-3 days vs. a quick reply to check for updates
Next Steps
Since we received a warm reception from both end users and our financial crimes line of business the proof of concept has been considered for the consumer mobile application roadmap.
I was rolled off the project, but made suggestions to the next designer and project team based on our usability sessions.  One key point was removing the sounds by default.  Our users felt startled when they started our app and it immediately started talking to them.  We suspected this would be the case as we were developing it.
We also implemented an easier method for verifying transactions that reduced some of the redundancy of seeing just one transaction at a time as seen below
updats

Updated transaction verification flow