The Problem

Our bank was onboarding a new commercial segment: a mortgage group moving large sums, with no prior relationship with us and no branch anywhere nearby. For them, depositing checks remotely was the only practical way to fund their new accounts.

We did offer remote deposit, but it sat behind a third-party web login and needed a $600 scanner for every user. Their previous bank already offered it natively on mobile, and a competitive scan showed we were one of only three banks in the market still without it. Missing the onboarding deadline meant losing the entire incoming group and roughly $2M in forecasted first-year revenue.

Scope

The project kicked off in a single meeting with a single ask: ship in 4 months. For a feature moving real money through a third-party service, that was too tight. I led a timeline negotiation with my product partners and we landed on 6 months.

Even with the extra time, we had to stay lean. Ideally, depositing a check and seeing its status would ship together. We split them: in phase 1, users deposited on mobile and checked history on web, with phase 2 closing that gap.

Phase 1 of a 3-phase initiative

We also dropped "daisy chaining," the web pattern that lets users submit several checks in one session. Mobile launched with one check at a time.

Users

Our users were staff at a mortgage group handling high-value transactions. They were new to our bank, had no branch nearby, and were coming from a competitor that already let them deposit checks from their phone. That set the bar. Anything slower, clunkier, or more expensive than what they'd left behind would feel like a step backward on day one.

My Role

As UX Lead, I set up the working sessions that defined the timeline, cross-functional impacts, and project plans. I created the project brief and discovery documentation, and put together a deck to bring the wider UX team up to speed on the six months ahead.

And as the Interaction designer, I owned the experience end to end: competitive research, flow models, sketches, mapping service calls with architecture and engineering, and the final UI.

Constraints

Every constraint on this project showed up somewhere in the user's experience, so I treated them as design inputs from the start.

Here's where those guardrails showed up across the flow, from the moment users tapped in to the final review.

Entry Point Entitlement service fails to confirm access RDC disabled bank-wide due to integration issues

Location Access Device found outside US/Canada (hard block)

Image capture User denies camera permission (hard block)

Post Capture Review Entered amount doesn't match the check image Check image unclear, illegible, or not endorsed correctly Duplicate or unexpected check structure Check appears drawn from outside US/Canada

Process

I started by mapping high-level flows and scanning the competitive landscape. One catch: commercial banking RDC examples weren't available, so I looked at retail banking apps instead.

Patterns from the competitive scan

Clear camera guidance helps users capture checks with confidence

Simple workflows reduce cognitive load

Helpful error messages improve recovery

Transparent confirmations build trust

Consistent patterns made complex tasks feel familiar

Several viable flow patterns emerged from that competitive research, all with similar core components. I built out multiple flow models from those patterns and evaluated the tradeoffs of each. None of the options were wrong but one aligned much more naturally with the design patterns already established elsewhere in our app, so that became our direction.

With the flow set, the next question was where users would find it.

The entry point was placed within the existing bottom navigation, deliberately avoiding a drastic structural change. Since phase 1 was rolling out to a small user subset, we chose the minimal-disruption option and left the door open to reconsider entry point placement based on usage data over the following year

Arch Collaboration

Most of the Fraud and Information Security risk lived outside the happy path. I set up working sessions with architecture and engineering to map the vendor's full call pipeline: what it returned, in what order, and where it could break. My computer engineering background helped here too. I spotted where service calls could run in parallel instead of one after another, which cut how long users waited after hitting submit.

Those sessions also became the foundation for defining all 13 error states users could run into. Designing 13 one-off screens wasn't realistic on our timeline, so I built a single error template with dynamic content. It meant engineering built one reusable UI template instead of 13 variants.

UI template reused across different error states

Midway through, we found out the vendor documentation we'd designed against was outdated, and parts of the design had to be reworked before launch. The same working sessions also surfaced a long tail of edge cases. Not all of them could make phase 1, so I worked with business and product partners to prioritize them into a fast-follow release instead of letting them stretch the launch date.

Outcome

On time Phase 1 shipped in 6 months

$2M+ Forecasted first-year revenue protected

2 acquisitions Supported 2 acquisitions in 2026

Users adopted it quickly, which made sense for a group with no branch access that had been waiting for exactly this. We watched closely for three to four months after launch for usability issues or integration errors, and no design changes were needed.

Reflection

What worked:

Strong cross-functional collaboration, a clearly defined goal and timeline from day one.

What I'd do differently:

I'd validate vendor documentation before it becomes load-bearing for the design. Going into phase 2, the lesson was to surface and validate third-party documentation and service architecture risk much earlier.

And I'd push for at least one round of testing with real users. We skipped it on purpose since the pattern is common across banking apps and time was short, but it's the piece I'd fight harder for next time.