Gov Claim Management System
Getting Payments Out the Door Faster
This government organization pays out hundreds of thousands to millions of dollars to individuals and families who were losing time due to a manual fragmented process. Authorizers were juggling external tools such as Word, Excel, and email to piece together information to make a final decision. I led the research and design for a unified Salesforce record page that consolidated all the information an authorizer needs to make a confident decision, reducing expected payment processing time by 50%.
COMPANY
IBM
MY ROLE
UX Researcher and Designer
TIMELINE
September 2022 - April 2024
What’s the problem?
Payments are taking too long to get out the door
Family members are in need of the funds and the organization wants to get them out as soon as a payment is decided and approved.
Discovery
In order to design a better payment authorizing process for users, I talked with current payment authorizers to understand the payment lifecycle. Starting from when a payment is approved by a claim manager, to OPBE review, Treasury processing, and final disbursement to the claimant. The flow chart illustrated the multiple handoffs, decision points, and opportunities for payments to stall.
Discovery
What was slowing down the process?
Through talking with payment authorizers, I discovered that there were two main challenges that slowed them down in authorizing a payment.
Problem 1:
Information is scattered.
Currently, users are utilizing multiple tools such as Microsoft Word, Excel, and email to communicate critical information to different parties of the process.
Problem 2:
Lack of trust in the data.
Because users were using different channels to communicate, many users felt that it took longer to see the full picture of a claim and needed to triple check the information.
Problem Statement
How might we improve decision-making speed for payment authorizers by integrating all necessary tools and data into a unified record page?
*** while utilizing strictly out of the box salesforce capabilities?
Understanding the Data
Mapping out the data and understanding Salesforce data structures
The payment process is a culmination of all the events in that claim, I needed to pull in all the relevant data that a payment authorizer may need so that everything is in one place. To do this, I worked with a business analyst to inventory every relevant data field and the Salesforce objects they lived in. The data mapping exercise became the foundation for every layout decision that followed. While the volume if data is significant, the goal was to structure it so that the information flows and pushes toward a faster approval.
The actual data is protected under an NDA.
Design
A page layout built around the decision
Given the components available in Salesforce, I designed a two-column page layout with a highlight panel at the top. This structure mirror show an authorizer thinks thorugh a claim. Starting with high-level information at the top with, a summary panel to get an overview of the claim, and the payment section to dive deeper into the events of a claim.
The highlight panel sits at the stop of the page and houses the top level information as well as navigation links to related records. It also holds any actions that user may perform on the record.
This acts as an extension of the highlight panel. The payment summary gives the user a quick look at the stage of the payment and basic characteristics.
Payment details section is where the bulk of the information sits. It included related lists and links to other related records.
Putting it all together
The final payment authorization page now holds all the information an authorizer may need to see when making a decision. The users can also directly disposition the record and perform necessary actions such as submitting the decision so the record can move along its process.
Challenges
Designing within constraints
This project’s main challenge was working within the native Salesforce functionality. In particular, understanding how Salesforce structures its data and how that interacts with the out-of-the-box component was essential to designing something that was actually buildable. I sat in peer coding sessions with developers to watch how page layouts were configured and eventually simple pages myself to validate ideas faster. This understanding changed how I approached the design and communicated design decisions to the client.
Impact
With the new system and pages, payment processing times are expected to be reduced by about 50%
By consolidating all claim information into a single record page, authorizers no longer need to piece together data from external sources such as Word, Excel, and email. This new process is expected to reduce processing times by 50%. In addition, other built in features like change tracking and historical data, will support provide authorizers with confidence in their decision making.
Takeaways and Learnings
Constraints are a design input, not a limitation
Salesforce comes with its own set of constraints but working within them often produces a better solution that going custom. Custom code introduces maintenance risk, particularly every Salesforce update can become a potential breaking point. Staying native was the most sustainable path, and part of my role was making that case to the client, even when it felt more restrictive to do so.
Machine Learning App Builder
Next Case Study: