01

Context

In an expense management system, once an expense is submitted by the spender, it moves through an approval process and reaches the finance admin, who rechecks the expenses and settles payments wherever necessary. Several customers at Fyle, complained about the inefficiency, unnecessary steps, confusing information and lack of visibility of important information which subsequently resulted into dissatisfaction, more customer tickets and churn costing big clients.

With the following primary goals, We picked up this initiative.

1. Reduce churn that accounted for ~1% of total product churn

2. Reduce customer complaints from 5–8 support tickets per month to nearly zero

3. Change the negative sentiment into positive one

02

The initial 7-8 weeks & beyond!

While the product team conducted multiple 2–3 hour problem-framing sessions with design and other stakeholders, as the solo designer, I

• Explored several early design solutions

• Ran designs with product, eng and other stakeholders

• Conducted 5–7 rounds of usability testing with clients even in off hours

• Collaborated closely with engineering throughout a 6+ month implementation cycle

When the project went live, I was delighted to see the overwhelming response from customers. I never expected we would achieve such high positive reviews in our initial beta phase! From an empathetic viewpoint, you could truly sense the emotional weight of the journey the customers had been through before this improvement.

03

Whom did I solve for - Personas

In the world of expense management, 3 personas keep the wheels turning: the spender, the approver, and the finance person.

• The spender incurs expenses and submits them in the form of reports.

• The approver ensures policy compliance.

• And finally, the finance person reviews everything, reimburses when needed, and closes the loop by updating the accounting system.

This initiative was designed to tackle long-standing issues faced by finance person —especially around the reviewing/approving Expense reports and Payments module, a critical part of their workflow.

What is an Expense Report?

Expense Report contains a list of expenses, submitted by the spender. Payment Module deals with the payment settlement process post expense report approval or verification.

04

Problems & How did I solve those!

A finance person's workflow, typically revolves around three core actions:

1. Handling the approval process, when required

2. Initiating reimbursements, wherever applicable

3. Closing reports to finalize the expense cycle

Hence, we examined the problems through these lenses, also dived deep into customer complaints and Smartlook session recordings to understanding user behavior and pain points. We already had access to previously conducted customer interviews.

Below are a few selected problems we addressed—ranging from small to significant. I strongly believe that both minor and major changes play a critical role in shaping the overall user experience. Even the smallest improvements deserve their place in this case study, as they often have an outsized impact on usability and perception.

4.1

Striping away the user control

🚨 Problem:

Finance admins were forced to perform additional "Verification" step even if it wasn't required. For example, if an expense report contained 10 individual expenses, the admin had to manually verify each one just to mark the report as verified.

Now imagine the magnitude of frustration when an admin has to do this across expense reports for 500+ employees!

As per Data, In organizations that exclusively use corporate cards, approximately 78% of them wanted to disable the verification settings. But there was no way to control it through the interface leading to frustration.

✅ Solution:

Giving Control Back to the User - Introduced Verification Settings

It was a simple roll-out, but brought a massive impact in closing reports faster. Finance admins were empowered to turn this ON whenever they need it otherwise not.

We deprioritized the verification flow improvement in favor of another initiative.

4.2

Ambiguous UX copy

I deeply value the power of good UX copy. It’s the voice of the product—the bridge between design and user understanding. Great content isn't just about words; it's about delivering clarity and simplicity in both tone and experience.

🚨 Problem:

When a report was submitted, it moved through several stages—Submitted, Approved, Processing, and finally, Archived. Instead of using two-word labels for each stage, we aimed to align with the user's mental model by simplifying them into clear, intuitive one-word labels.

✅ Solution:

🚫 failed attempt

We initially planned to use one-word, action-oriented terminology—such as

1. Approve

2. Settle

3. Reimburse if applicable

4. History

But, It didn't make a cut in internal usability testing. We observed that users more frequently relied on familiar, standard terms like Submitted and Approved, which better aligned with their mental models.

🎯 What worked

1. Approval Pending -> Submitted

2. Verification Pending -> Removed, Kept it as data grid column

3. Payment Pending -> Approved

4. History -> Closed (Used accounting language)

4.3

Employees Without Bank Details Not Clearly Identified

🚨 Problem:

There was no clear signifier for employees who hadn’t updated their bank details in payment settlement page, leading to multiple payment failures—resulting in confusion, unexpected delays, and user dissatisfaction

✅ Solution:

To indicate missing bank details, I introduced a bank icon next to the employee’s name. Though it was an unconventional choice, it resonated with users during internal usability testing and proved effective enough to be adopted.

4.4

Losing the context in the Payment stage : The major challenge

🚨 Problem:

01. The finance admin had to navigate to the Payments section to initiate reimbursements, and then go through two additional tabs to complete the payment process. Many finance admins dropped off midway, assuming the payments had already been processed.

02. The page layout was inconsistent with the rest of the product, affecting the overall user experience and visual consistency.

03. Settling the advance amount was confusing. The page displayed the same employee twice in a row—once representing the report balance and once representing the advance balance, along with the net liability.
When the liability was negative, it forced the admin to collect money from employees offline, which felt unnecessarily harsh to the employees. This negative balance could have been easily adjusted in the next reimbursement cycle.

✅ Solutions:

To address the series of challenges, we made different changes.

🚫 failed attempt

• Primarily, a report can contain two types of expenses: expenses incurred via company card and expenses made using a personal card. While a part of the report requires reimbursement, the card expenses journey should ideally end as soon as the report is approved.

• Our initial solution aimed to end the card expense journey on the report approval page and directly send it to accounting, whereas the rest of the report would move to the payment page for reimbursement. We didn't aim to solve the context problem intentionally.

However, this process didn’t work as expected due to two major challenges: technical constraints and high cognitive load. It was difficult to clearly communicate to users that part of the journey had already ended.

🚫 another failed attempt

• Our second attempt was to bring payment within the context of the report module removing cognitive load and addressing the technical constraint.

• The difference was taking user to a different tab within the same page instead of a separate page.

• But we actually didn't solve for cognitive load as we expected. Users were confused with the 2 step process here.

🎯 What worked

We decided to enable user initiating payment for the entire report instead of doing it partially, for reimbursable expenses to eliminate the cognitive load.

The newer problems we faced

• Communicating the non eligible expenses

• Communicating the non eligible employees for the reimbursements

Variation 01:

✅ Variation 02:

4.5

Missing Signifier in Processing Queue

🚨 Problem:

There was no way for the finance admin to understand which payment had failed.

✅ Solution:

I introduced an additional "failed" status after engineering green.

Also, introduced a task on the admin dashboard for easy discovery of failed payments.

4.6

Confusing -ve liability settlement

🚨 Problem:

Sometimes, the organization issued advances to employees, which needed to be settled during reimbursements. However, the existing interface was extremely confusing.

✅ Solution:

Providing In context advance UI in report module

To allow users to apply for advances, we placed the call-to-action button near the reimbursement amount for easy discoverability. Upon interaction, we prompt users to select the advanced account they want to settle against. The interface keeps the user informed about the consequences of applying advances.

It could have designed better, but the % of users using advances were less.

05

Wrapping up,

The problem list is not over yet, but I am making a hard stop here now.

We conducted usability testing with at least 7 to 10 organizations, often during off-hours, to gather validation for our solution. I am very grateful to Gayathiri. She lifted my spirit throughout this initiative by offering feedback, participating in brainstorming sessions, or with a shoutout message like this.