Coupa Mobile: Approvals On the Go

Project Title:

Coupa Mobile: Approvals On the Go

Designing a consistent action pattern for a native mobile companion to Coupa's Business Spend Management suite

Outcome:

Designed the PTO approval flow for mobile from scratch, one of several desktop BSM features being brought over to the app feature by feature, and used it as the proving ground for a consistent "actions" interaction pattern the app had been missing. Extended that pattern across Expenses, Receiving, and Shop so users encountered the same approve/reject/hold and confirm/cancel logic no matter which part of the app they were in.

The Problem:

Coupa's mobile app was a native companion to the desktop BSM suite, and it was being built out feature by feature, porting over the highest-value desktop workflows one at a time rather than launching with full parity. PTO (and other) approvals hadn't existed on mobile yet. There was no earlier version to fix, which meant the job was deciding from scratch what this workflow should look like on a phone, not patching something that already existed.

That came with its own problem: the app had no shared interaction model yet either. Other features that had already made the jump from desktop to mobile had each solved "where do primary actions live" a little differently, so as PTO approvals got added, there was no established pattern to inherit. Whatever we built for approvals would either compound that inconsistency or be the thing that started fixing it.

Who I designed for:

  • Primary: Managers and approvers who needed to clear PTO requests, expense reports, and receiving tasks in short mobile sessions, often between meetings or away from their desk.

  • Secondary: Employees using the mobile app for lighter tasks like shopping the catalog, where the same action pattern needed to hold up.


They needed to open the app, understand what was being asked of them, and act on it in a handful of taps, without re-learning the interface from screen to screen.

My role:

I worked alongside the app's lead designer, who owned overall product direction and gave informal review on my work. My focus was twofold: owning the PTO approval flow end to end, and defining a reusable action pattern that could replace the inconsistent, one-off button placements scattered across the app. Once I had a direction working in the approval flow, I applied it to Expenses, Receiving, and Shop/Item Details to test whether it held up outside the flow it was designed for.

What I did:

  • Designed where the comment field should live relative to the decision

    • Tested a version where "Add a Comment" sat inline on the main request details screen, competing for space with the requester's notes and approval history and easy to skip entirely.

    • Moved to a version where tapping Approve, Reject, or Hold triggered a dedicated comment step, with the field required before the action could be committed.

  • Defined a consistent action bar pattern

    • Standardized on a persistent bottom action bar: two or three clearly weighted buttons, color-coded by intent (blue for neutral/hold, red for reject/cancel, green for approve/confirm).

    • Ran multiple icon and color variations through design review screen by screen, using the differences as decision points rather than settling early, until the team converged on one pattern that read clearly at a glance.

  • Applied the pattern across the app to stress-test it

    • Carried the finalized pattern into Expense list and detail views (Smarter Trip / Add Expense / Submit), Receiving (Select All / Receive), and Shop Item Details (Cancel / Add to Cart).

    • Adjusted button labels to stay meaningful in context without breaking the visual pattern, for example "Receive" becoming a count-based label like "Receive (2)" once items were selected.

Tradeoffs:

Inline comment vs. required comment after action. The early version placed the comment field inline on the main request screen, optional and easy to bypass. The direction we moved to instead required a comment as part of a dedicated step after tapping Approve, Reject, or Hold. This traded a small amount of added friction, an extra screen and a mandatory field, for a meaningful gain: comments stopped being an afterthought and became part of the decision record every time, which mattered more on mobile where approvers were moving fast and most likely to skip anything optional.

Multiple action-icon variations as a review tool, not indecision. The visible differences in icon weight, color treatment, and button styling across screens weren't accidental inconsistency, they were deliberate variations built to run through design review and converge on one final pattern. The tradeoff was time: rather than locking in one direction early, we kept two or three live variations in front of the team screen by screen until there was consensus on the version that held up clearly across Approvals, Expenses, Receiving, and Shop. Slower up front, but it's what let the final pattern hold together once applied everywhere.

Impact:

I was pulled onto another project at roughly 80% completion, so I don't have adoption or usage metrics to report on this one. This case study is framed around the design decisions and tradeoffs themselves rather than measured outcomes.

What this reinforced for me:

Consistency isn't just a visual system, it's a way of reducing the cognitive cost of "where do I act" every time someone opens the app. On mobile especially, when someone has ten seconds between meetings to clear a PTO request, a predictable action pattern does more for usability than any individual screen's polish.

More Visuals

Social: