Logging expenses shouldn't wait for a desk

Attached to that travel product was an expense module. It was the part nobody wanted to use.

Before getting to what users hated about it, it is worth understanding why the company cared enough to rebuild it, because that shaped every decision that followed.

Quest2Travel earns the overwhelming majority of its revenue from travel fulfillment. Commissions and fees on flights, hotels and ground transport. The expense module is not sold standalone and does not carry a meaningful price of its own. It is bundled into the platform as the lock in that keeps a client's entire travel spend booking through Quest2Travel.

That lock was broken. Not every enterprise that bought travel went on to adopt expense, and any client running their expenses on a competitor's tool had effectively handed that competitor a foothold inside the account. A foothold a full travel and expense suite could widen until it took the travel business too.

So this was never about selling better expense software. It was about defending travel revenue and completing a bundle the sales team could lead with.

The user side of the problem was just as structural.

The platform was report first. Before an employee could log a single expense, a report had to exist to put it in. That one architectural choice is what made everything else difficult, because it meant expense logging could only ever happen in a sitting, at a desk, with time to set things up.

Four failures compounded it.

Put together, the brief that emerged was harder than a visual refresh.

Then I went through the competition, each for a specific reason rather than a general survey.

Every platform offered broadly the same features. None had solved presenting them inside an ecosystem users already knew, because none of them were embedded in a travel platform. That gap was the opportunity.

None of that research produced the feature that ended up mattering most. That came later, in a live prototype session with enterprise clients, when the same concern surfaced independently from more than one contact.

That reframed rejections entirely. They were not a compliance problem to police. They were an information problem to solve, and solving it meant telling people the rules at the moment they were spending rather than weeks later. That single sentence created the Tips panel, which I come back to in the design.

Manohar, 37, corporate professional, Mumbai. A composite drawn from those calls and conversations. High travel frequency, limited time, no patience for desktop only tools. He needs to log expenses in motion, know his limits before spending rather than after a rejection, and see where his claim has reached once it is submitted.

But he is only one of four roles, and that turned out to matter more than any single persona. Employee, Approver, Financial Auditor and Admin all share one reimbursement pipeline, and a decision that helps one can easily obstruct another.

So before the redesign work began, I shipped a hygiene pass on the legacy platform. Targeted fixes across all three roles, Requester, Approver and Accountant, on desktop and mobile, chosen specifically because they could go live without structural or backend change.

None of it touched the architecture. That was the point. Keep the current experience workable while the real fix is built. It also forced me deep into every corner of the legacy product early, which paid off for the rest of the project.

With the old system stabilised, I started the redesign properly. My first version was clean and well executed. OCR first capture, standalone creation, modelled closely on Navan. By the standards of expense platforms, it worked.

My PM's feedback was short and it stopped me.

He was right, and the reason was that I had benchmarked against the wrong thing. I had been comparing my work to other expense tools when the product users would actually compare it to was sitting one tab away.

So I went and studied the travel platform instead of the competition.

It had a three step mental model that existing users already knew instinctively, because they used it every time they booked a trip. I applied that same structure directly to expense reports.

The borrowing is visible screen for screen. The landing page keeps the travel platform's split of work raised by you and work waiting on you, under the same My Approvals heading. Creation keeps its three steps, with the detail accordion collapsing to a summary line once a step is done. An employee who had raised a trip request was not learning a new product; they were using the one they knew, against a different noun.

Same pattern, two products. An employee who had ever raised a travel request already knew how to file an expense report, which meant no training rollout across enterprise clients and effectively no learning curve.

Not every decision I made survived contact with review, and one correction improved the product significantly.

My initial proposal surfaced warnings during expense creation but held critical issues back until submission. My PM pushed back, and the final architecture surfaces both tiers during creation, with the same deviations reappearing at review and in the report screens.

He was right for a reason worth stating: a user who only learns about a critical problem at submission has already made all their decisions on bad information. Surfacing everything early costs nothing and prevents the unpleasant surprise.

Alongside the design work ran a set of hard limits. Each one pushed toward a cleaner solution than the default would have been.

The library is named in Tailwind, not translated into it. Colour styles sit on Tailwind's numeric scale: a primary of Blue 700, with tints from Blue 900 down to Blue 50. Text styles are its type scale, text-xs through text-3xl, each carrying regular, medium and semibold with the size and line height set on it.

So a developer opening the Figma inspect panel reads a class name rather than a value to look up and convert. Nothing is lost in the handover, because there is no translation step in it.

Expenses can now be logged the moment they happen, with no report required. Reports are compiled later, at a desk, when there is time to review what has accumulated.

Corporate cards feed the same surface. Card transactions sync in as Incomplete Expenses on both desktop and mobile. Rather than re entering what the bank already knows, the user reviews, edits and links them to a report. Capture by camera and capture by card end up in the same place.

Responsive where the work moves, desktop where the work sits. The employee and approver experiences are fully responsive, so an expense can be captured, built into a report and submitted from a phone. Two roles stay desktop only by design. Financial Auditors work across dense data tables and aging claim queues, and Admins configure policies where one wrong toggle affects an entire organisation. Compressing either onto a phone would add risk without adding value.

Because the report flow borrows the travel platform's structure, enterprise employees needed no onboarding to submit their first report.

Solves the travel to expense disconnect. Continuity is a feature, not a cosmetic choice.

Step two is where the two products actually meet rather than merely resemble each other. Every travel request automatically generates its expense report, so the employee never creates one and never links anything. By the time they get back from a trip, the report already exists, already tied to the approved travel plan. What is left in step two is the work only they can do: attaching the expenses from the trip, and reconciling advances, linking approved ones, adding manual entries, or surrendering funds they did not end up spending.

The three step pattern borrowed the travel platform's shape. Auto generation borrowed its data. An employee who books a trip has already started their expense report without doing anything, which is the difference between two products sharing a login and one product.

This was the decision I spent longest on, because both positions were defensible.

The tension. If you block saving when an expense breaks policy, your data stays clean and finance never sees nonsense. But you also destroy the on the go use case, which was the entire point of the redesign, because a person in a taxi cannot resolve a policy violation.

The resolution came from noticing that creation and submission happen in completely different environments. Creation happens in motion, in airports and between meetings. Submission happens at a desk, with time and context. Applying the same enforcement to both moments necessarily destroys one of them.

The decision. Save freely during travel. Block report submission until every critical issue is resolved. Nothing reaches finance until submission anyway, so the data is only ever messy inside the user's own drafts.

That decision only works if the system can tell the difference between a real violation and a judgment call, which is what the two tiers do.

Critical. Surfaced at creation, hard blocked at submission. Over limit amounts, missing documentation, out of policy categories. These are errors finance genuinely cannot process.

Warning. Surfaced at creation, never blocked. Near limit spends, receipts that look altered, categories that need a note. The user is informed and the responsibility shifts to them.

Enforcement severity matches issue severity, and every flag appears at the moment it can be acted on rather than weeks later.

This is the feature that came out of the client session, and it began life as something much smaller.

It was originally a static prompt nudging users to try OCR. The insight about employees not knowing the rules turned it into a dynamic, category aware policy guide. The moment OCR identifies a receipt as a client meal, the panel surfaces the reimbursable limit for that category, the exclusions, and what documentation is required, all before the user hits save.

Solves the absence of policy guidance. Policy awareness moved from reactive, a rejection three weeks later, to proactive, guidance at the moment of decision.

Hierarchy in an enterprise is recursive. An employee can be an approver for the people who report to them, and every approver is an employee to the approver above them. The same person switches roles depending on whose report they are looking at.

So Employee and Approver do not get separate products. They share one dashboard, and approvers simply gain an additional My Approvals section.

Capabilities layer onto a single interface instead of forking it, which is what keeps the system scalable as enterprises reshape their approval chains.

The dashboard makes that literal. It splits into Raised by You and To Be Approved by You, so a manager sees both halves of their working life on one screen rather than switching modes or accounts.

Beyond the core flows, the redesign covered mileage logging with map based route entry and a visible reimbursement calculation, advance requests as a guided two step flow with their own listing and detail views, category driven field defaults the user can override, duplicate expense detection, approval chain visibility showing who has approved and who is next, and a full audit trail with comments on every report.

Finance teams needed something different again. Not a queue of tasks but an answer to a question.

The Organisation view is built around one thing: what does a finance lead need to know within 30 seconds of opening it. Net Booking Value, Policy Deviations, and Savings versus Missed Savings own the first row. Everything else lives behind tabs and filters.

The approval queue beneath it carries the actions a finance team actually needs, including assign to self and release assignment, because in a shared queue the first problem is not deciding, it is knowing who owns what.

By the time I left, standalone expense creation was developed and the Reports dashboard was fully developed, with the remaining modules in active development against a complete documented handoff. Every flow, edge case and screen state was walked through with the dev team in person, supported by flow diagrams for each module.

Validated in prototype reviews by contacts at Adani, Toyota and Dr. Reddy's, the same clients who had flagged the legacy system as a blocker in the first place.

Accessibility. I ran the primary colours, CTAs, flag indicators and body text through Adobe's Color Contrast Analyzer against WCAG 2.1 AA and AAA thresholds and adjusted the palette where they fell short. It matters more than usual here, because the enterprise user base skews senior in age. I also pushed for dark mode, though it never got past discussion.

Recognition. Employee of the Quarter, twice.

I left before launch metrics could accrue, so I cannot claim outcomes. What I can say is which four numbers I designed toward and would pull first, because defining them was part of the design work rather than an afterthought.

That timing is the specific thing I would change. Because I did not own the research process from the start, a feature that changed how employees understand reimbursement policy was retrofitted onto a form that already existed rather than shaping the information architecture from the beginning. The panel works. Had the insight surfaced in month one, it would have shaped how the entire expense form was structured.

The pace played a part. There was no formal deadline, but the culture was ship as soon as possible, and I inherited the research rather than owning it. My conversations with colleagues were an attempt to close that gap within the constraints I had. Real input, honestly gathered, but not the structured research this product deserved.

If I ran this again, I would conduct user interviews personally before any design work begins, with actual travelling employees rather than only the buyers who administer their expenses. And I would include the support team, who hold the most unfiltered picture of where a product fails, because they hear about it first.