Business Online, Gauravi Linjara

the payment

A supplier is waiting. The deadline is today.

AED 2,400,000, ready to go. The Authorizer is boarding a flight.

the old way

Three roles, and the last one is chained to a desk.

makerCreates the payment. Done by 9am.

checkerVerifies every detail. Done by 10.

authorizerCan only release it from the desktop, at the office.

payment waits · supplier waits · deadline slips

business online

The same release, from seat 14A.

Pending approvalAuthorizer

BeneficiaryGulf Steel Works

AmountAED 2,400,000

Checked byR. Menon ✓

Hold to approve

reviewed · approved · released

shipped · emirates nbd · mena

1.0×

faster approvals and key journeys, from wherever the Authorizer is.

Case snapshot

Role

Sr. Product Designer · Business Online, mobile

Team

1 design lead + 3 senior designers (I led UX/UI with 2 others), plus product, iOS & Android eng & business

Timeline

2024 · Emirates NBD, Dubai

Tools

Figma · user research via user testing

What I did

Owned the role-based experience (Maker, Checker, Authorizer) and the full device-activation onboarding, end-to-end. Co-built the mobile component anatomy handed to iOS & Android.

Impact

70% faster delivery and 3× faster task completion in key journeys, across 500+ screens and 12 end-to-end journeys.

Constraints

A small screen carrying high-value payments, multiple user roles, security controls, authorization limits, and dense financial data.

The redesign

legacy → redesign.

Basic, functional layout with limited visual hierarchy
No distinction between user types
Limited contextual insights

before

after

drag ⇆ to reveal the redesign

Modernized layout with clear segmentation of actions, balances, and insights
Role-based cards (e.g. "Pending Approvals" for Authorizers only) keep focus
Added Payment Tracker, Recent Transactions, and Carbon Footprint widgets

02 · The roles

one payment, three roles.

First, the people. A corporate payment isn't one person's job: a Maker creates it, a Checker verifies it, an Authorizer releases it, each with a focused view and a clear approve-or-reject fork.

Maker

Creates

Checker

Verifies

Authorizer

Decides

biometric check

✓ released

✕ back to maker

maker and checker do the work; the Authorizer decides. Approve releases it, reject returns it to the Maker.

03 · Problem

high stakes on a small screen.

Approvals stuck at the desk

Authorizers had to wait until they were at a desktop to release payments.

"Did it go through?"

Unclear status after authorizing, no confident confirmation on mobile.

Dense for a phone

Desktop-grade data crammed onto a small screen, hard to scan.

Multi-role complexity

Makers, checkers and authorizers each need a different view.

“

the signal · user + heatmap research

I just need to approve it and know it's done.

Business ownersFinance teamsAuthorizers

Confidence and clarity, not more features, was what authorizers asked for.

04 · Research

the data backed the complaints.

We started with daily users. The same frustrations kept surfacing, so before redrawing a screen we validated them with attention heatmaps on the legacy app.

in their own words

“If I'm out of the office, a payment just waits, I can't release anything until I'm back at my desk.”

Imran K.Finance Authorizer

“After I tap approve I'm never quite sure it actually went through.”

Priya N.Business Owner

“There's so much packed onto one screen, I scan for the one number I need and ignore the rest.”

Tariq M.Finance Team · Daily user

attention heatmaps · legacy app · validating what users told us

Fig.01 · Authorizer · approvalsapprovals lost in the noise

Attention heatmap across the legacy Authorizer approval flow

ObservedAcross the approval journey, attention spread evenly over headers, balances and dense request tables, the pending-authorization items never pulled the eye.
ValidatesConfirms what authorizers described: the one action they open the app for was buried in everything else on screen.
DecisionLed with a task-based home and a focused approval queue, so pending approvals are the first thing an Authorizer sees.

Fig.02 · Maker · beneficiary managementno clear path to the action

Attention heatmap across the legacy Maker add-beneficiary flow

ObservedThrough the add-beneficiary flow, attention scattered down long, undifferentiated lists and form fields, no step made its primary action obvious.
ValidatesMatches the "I scan for the one thing I need and ignore the rest" feedback, the flow read as a wall to scan, not a path to follow.
DecisionSimplified navigation and surfaced the primary action at each step, turning beneficiary management into a guided, faster path.

05 · The shift

from desk-bound to on the go.

Approving a pending payment, the core task. Before vs. after the mobile redesign.

The bet behind it. The obvious move is the whole portal on a phone. But a finance lead on the go needs one thing: authorize a pending payment, fast, and know it released. I scoped to that moment, not feature parity. Saying no to everything else is what made it quick.

approvals tethered to a desk→

released in seconds, from anywhere.

What needed a desktop and a wait is now a pending-first home screen, authorizers see and clear tasks the moment they land.

06 · Process

designed for the thumb zone.

Research how authorizers really work on mobile, prototype the flows, and validate with heatmaps and testing.

the bet

Cramming the full desktop dashboard onto a phone would keep the very density that made approvals slow. Instead I led with a pending-first home, what needs action, at the top.

map the roles

Makers create, checkers verify, authorizers release. Each needed a focused mobile view, not one crowded screen.

prototype the flows

Designed a pending-first home, a clear authorize action, and a frictionless device-activation journey.

validate with heatmaps

Ran heatmap + usability testing on the new screens, attention landed exactly where the key actions live.

ship across iOS & Android

Delivered a documented component anatomy so the app stayed consistent across both platforms and future releases.

07 · Solution

the app, in hand.

A Maker and a Checker don't need the same screen. Each home is tuned to what that role actually does, here are the key decisions, on the live build.

Checker

Pending Approvals, upfrontTask-based prioritisation, the approval queue leads the dashboard instead of sitting in a menu.
Approve / Reject in contextRole-aware CTAs replace the one generic button.
Workflow tabEvery step of a transaction is visible, for full transparency.

Maker

Create New, front and centreThe Maker's primary action leads, in place of a generic CTA.
Role-relevant quick linksAction cards for the Maker's common tasks replace the generic shortcut.
Workflow tabSee exactly where a submitted payment sits in the approval chain.

09 · Onboarding

secure setup, no branch visit.

Before touching a file, a corporate user has to prove who they are. I designed the full device-activation journey, subscriber ID, OTP, password, Smart Pass PIN, so first-time users sign in without visiting a branch.

Activate your device, enter subscriber and user ID

Verify your number, six-digit OTP with live countdown

Set up your password with live rule validation

Device activated, quick login with Touch ID or MPIN

01 · identify

prove who you are

Subscriber and user ID from the welcome email. The bank already knows the corporate, so there's nothing to invent, just confirm.

02 · verify

a one-time code

A six-digit OTP to the registered number, with a live countdown and a resend path. Verify the channel before any credential is set.

decisionCountdown and Resend are visible from second one, so no one's left guessing whether the code is stuck.

03 · secure

set a password it can trust

Rules validate live and turn green as you type, then a four-digit Smart Pass PIN for fast re-entry. No guessing what "strong enough" means.

decisionRules check as you type, not on submit, so a weak password gets fixed in the moment instead of bounced after.

04 · activated

in, and ready

Device activated, with Touch ID and MPIN offered for faster, safer access next time, all without a branch visit.

10 · Impact

3× faster, off the desk.

For the user

3×↑faster task completion

Role-specific UI and simplified navigation cut the steps in key journeys like approvals and beneficiary management, so the work that mattered got done three times faster.

For the business

70%↑faster delivery

Aligning design sprints with engineering readiness cut delivery time, so the redesign shipped faster without stalling on handoff.

For the org

500+↑screens, one system

A documented mobile component anatomy keeps iOS and Android consistent and lets every future release build on a real system, not one-off screens.

measured across approvals and beneficiary-management journeys

11 · Reflection

We built something better than polished.

This wasn't just a redesign. It was a re-alignment of roles, priorities, and how we want business users to feel when they interact with BOX Mobile.

Every decision was rooted in real user insight and built to scale. We simplified complexity without removing depth.

Working on this project wasn't linear, and that's what made it real. It involved sketching, unlearning, reworking, and lots of back-and-forth.

And as always, the process continues. Because great design isn't ever done, it just keeps getting sharper with every scroll, tap, and insight.

12 · Beyond the Figma file

I shipped a mobile system, not just screens.

A documented component anatomy handed to iOS and Android, so the experience stayed consistent and every release built on a real system.

Accessible by default: large touch targets, AA-contrast tokens, and clear focus states for every authorizer.

corporate banking, in your pocket.

four designers, one redesign.