UX Case Study 5
Submitting Claims
Native mobile apps (iOS, Android)
Context
Caregivers on the Homage platform would often incur expenses in the course of their caregiving, which were either billed back to the customer or absorbed by Homage. Caregivers were submitting their expense claims via WhatsApp to the Operations team. This worked at low volumes, but was inefficient and risky at a large scale as the number of caregivers submitting claims grew.
For the best customer experience, we needed caregivers to submit claims promptly with sufficient documentation so that we could bill the claims back to customers within the same billing cycle, and reimburse caregivers quickly.
We wanted to design an end-to-end flow where caregivers could submit claims through the Care Pro app, and the Operations team could manage them on the internal web app.
This feature was the first phase of the Payments epic which would later on also include a rule-based pricing engine and in-app payout breakdowns.
My Role
I was the product manager and UX designer on this end-to-end feature, and I worked with one other designer on the flow. While I took care of the mobile flows for caregivers to submit claims, she took care of the desktop web flows for internal users to approve and edit claims.
We worked in a team with 2 mobile engineers and 2 backend engineers.
Design Rationale & Thought Process
Entry points into the flow for 100% adoption
This new feature was aimed at preventing caregivers from missing out their claims, and having more timely claim submissions (within 24h of the visit end time).
All caregivers on the platform would use the app to compose and submit a visit summary after each visit. I added a claims declaration within the existing mandatory flow to submit a visit summary. It was couched as a simple yes/no question, which was consistent with the rest of the visit summary flow, and included validation so that the summary could not be submitted without declaring the presence or nil result of claims.
The main drawback of placing the claims flow on the visit summary flow was that it made an already long page even longer. However, due to the importance and time sensitivity of the claims, we went with this approach since it would not be missed.
In addition to the visit summary, I also designed other touchpoints within the app so that users would see a consistent and clear message that they should submit their claims ASAP, if they had any. These included other contextual in-app buttons, alerts, and also push notifications.
Help and documentation
To help first-time users, the design also included a hint box which would take users to an article containing documentation
Reducing to the minimum number of steps
To enable caregivers to submit their claims as quickly as possible, I designed the form in a very space-saving way with the maximum amount of information visible at a glance. Only 4 pieces of information were required: Item Type, Amount, Description and Photo Receipt. The amount of space allotted for each field indicated the expected (desired) amount of data.
I also made use of smart defaults here by looking into the data of existing claims. Typically, since caregivers would submit one or two claims, the default empty state of the page contained two items so the user could even omit a step of having to add a second item.
Users could of course add more items or delete unneeded items. One path we also handled was a blank submission, so that if users only wanted to submit one item but the default was two, then they could just leave the second item untouched and blank.
End-to-end design
In order to carve out a smaller Minimum Viable Product, we deliberately limited the scope of the app feature to only the submission portion of the claims flow. After the caregiver submits her claims, there was no way to edit nor view the status of those claims within the app.
To provide users with feedback on the claims they submitted, we included an email in the feature scope instead.
As always, the email design catered for all the mutually exclusive and collectively exhaustive scenarios. Namely:
when all the items were approved (good news)
when only some of the items were approved but others were rejected
when all of the items were rejected.
Outcome
The end-to-end feature comprising mobile and backend was launched in just under a month.
Caregivers were able to submit their claims through the app in a timely and standardised manner, which directly improved the accuracy of customer billing and payments.
This built confidence in the ongoing Payments epic and was a crucial first step for the Product team to tackle larger and even more extensive features.