UBS Mobile Payments

CONTEXT

A product that existed, but not adopted by users

UBS Mobile Payments carried a 2.8 App Store rating and near zero mobile adoption in 2020, when I joined the team. The product existed on paper: complex journeys, thirty plus payment types, and heavily detailed sections built for compliance review, not human confidence. No analytics, no researcher, no design system. We had to build everything from scratch, with no data to guide the solutions.

I was part of a very small mobile team, desktop was the main focus at the time, when I was asked to take over Mobile Payments. Payments is one of banking’s most used products, part of daily routine, yet deeply emotional. When it doesn’t work, the backlash is immediate and significant.

The backend was old and rigid, and the app ran on Cordova, which ruled out a natural, native experience. It took four years of relentless iteration to turn a compliance heavy system that once felt like a chore into something people trusted enough to call effortless. One piece of user feedback said it best: banking now ran like butter.

Four years later: 4.2 rating. CSAT 4.4 sustained across that period. A component library adopted firm-wide.
A UX feedback process adopted across the organisation. The CEO cited the redesign publicly in the NZZ after the first release.

Mobile Payments transformation to Native.

Ralph Hamers, then CEO of UBS, quoted in the NZZ, November 2021.

MY ROLE

Sole designer on the bank’s largest squad

Sole product designer for the bank’s largest cross-functional squad: twelve developers across iOS and Android, three testers, one PO, one BA. I owned design for the mobile payments product end to end, delivering every feature the roadmap called for and resolving design debt. Many of the patterns I created, including list views, filtering, sorting, and summary screens, fed directly into the bank’s design system. I worked especially closely with my BA and PO, translating feature requests into design solutions that balanced business needs with technical constraints.

We went beyond simply executing on requests. I helped bridge design and IT by shaping the agile processes we ran as a team, ensuring design was embedded in how priorities and decisions were made. That process became a standard adopted across teams in the Bank. My involvement extended to co-running grooming ceremonies as Scrum Master with the BA for a year, and running all qualitative user testing myself in the first year, when the team had no UX researcher, validating every major concept before it moved forward. I also mentored a junior designer who was promoted to Senior during this period.

THE PROBLEM

The backend dictated the experience, not the user

Every screen depended on multiple backend service calls just to load, leaving real time data and account information buried under heavy, cluttered loading states. Even after the native release, legacy screens built on Cordova lingered in the product, still holding back the experience. Where backend changes were possible, we requested them. Where they weren’t, design and IT teamed up on front end changes to work around the backend’s limitations, delivering the most seamless and quality experience we could. Over time, the volume of requests we pushed eventually forced backend changes once thought impossible.

Complexity ruled where clarity should have

Thirty plus payment types, color coded with complex logic, buried in heavy banking jargon. No informational hierarchy, no distinction between what needed attention now and what had already been executed. Business and security teams treated dense, detailed pages as a requirement, and the result was navigation that confused rather than guided.

Friction replaced confidence at nearly every step; forms asked for information in the wrong order. Field validation was unclear and punishing. Labels used internal bank terminology instead of language users understood. Empty states were blank. The payment summary, the critical moment before money moves, was a data dump of backend parameters. Trust was absent at exactly the moment it mattered most.

Introducing the summary screen as concrete example of one of the simplification cases, with before and after screens.

Non-essential details moved into a separate, downloadable view. Actions simplified and rebuilt per payment type, replacing a single generic ‘more’ button.

Designed for iOS, retrofitted for Android

No real native Android patterns existed, no components built for the platform, just iOS design retrofitted to fit. Android users made up a significant share of the bank’s mobile base, not a minority to overlook, yet I was the only Android user on the design team, and the only one pushing for change. Android developers had long felt the same gap and wanted it fixed. Once design and engineering aligned, we pushed together for a true native experience, leaning on Material Design to finally build the components and patterns the product had never had. Years of mounting technical debt were, at last, being paid down.

Native Android components and interaction patterns, built with Material Design, replacing iOS patterns that had simply been adapted rather than designed for the platform.

THE DESIGN WORK

We didn’t inherit a process. We built one.

Every significant milestone went through real user testing, from early concept and scoping through to what we were about to ship, making sure we were building the right thing from the start. With no data to guide us, we built a Feedback Form under Mobile Payments to collect that missing signal directly from users. It’s now used across every UBS mobile product to gather user voice.

Every piece of feedback, app store reviews, support tickets, was monitored and fed into a process we built with the PO and BA to turn it into actionable items, not just data, with UX findings feeding directly into sprint planning.

Business, management, IT, and design reviewed every proposal together before it ever reached build, not as a formality, but because each side had something to challenge. That discipline is why every release went out with confidence, not hope. It wasn’t just a new process, it was a culture change, one that other teams across the bank went on to adopt.

A process built to enhance the product quality and experience.

OUTCOMES

What changed

Total of 11’306 feedbacks collected over one year.

IN THEIR WORDS

Users put it directly

RECOGNITION

Presented as a success story