01

Why this mattered

Finance admins at Fyle were drowning. They had to manually verify 500+ employee expense reports—even when verification wasn't necessary. Navigate through multiple tabs just to process payments. Deal with confusing interfaces that made simple tasks feel impossible.

The frustration was so intense, it was costing us major clients.

The Business Impact:

• Finance workflow issues accounted for ~1% of total product churn

• 5-8 support tickets per month from frustrated admins

• Major enterprise clients threatening to leave

• Negative sentiment affecting our reputation in the market

This wasn't just a UX problem—it was a business-critical crisis. If we couldn't fix this, we'd keep bleeding high-value customers.

Our Goals:

• Reduce churn from ~1% to <0.5% of total product churn

• Cut support tickets to near-zero

• Transform negative sentiment into positive reviews

02

Process overview

Discovery (Weeks 1-8):

• Multiple 2-3 hour problem-framing sessions with product, engineering, and stakeholders

• Analyzed support tickets and customer complaints

• Reviewed Smartlook session recordings to understand behavior patterns

• Leveraged existing customer interview data

Design & Testing:

• Explored multiple design solutions

• 5-7 rounds of usability testing with clients—often during off-hours

• Continuous iteration based on feedback

Implementation (6+ months):

• Close collaboration with engineering throughout the build cycle

• Phased rollout with beta testing

The response exceeded expectations. Even in beta, we hit 4.5★ ratings—something I never expected given how broken the experience had been.

03

Who I Was Solving For

In expense management, three personas keep the wheels turning:

The Spender → Incurs expenses and submits reports
The Approver → Ensures policy compliance
The Finance Admin → Reviews everything, processes reimbursements, closes reports

This initiative focused on finance admins—specifically their experience with the Expense Reports and Payments modules, which are critical to their daily workflow.

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.