Multi-Asset Wallet

01 Context

Brief

The client is a multi-asset trading platform backed by a large investment banking group. Their wallet — deposits, transfers, cards — had been built by a previous vendor. It worked, but adoption was low and nobody could say why: the product had never been through user research, and the team was making decisions on assumptions.

Our squad was brought in to change that. The mandate was to audit the existing wallet, run discovery, and bring the product to a level where it could compete with Revolut and Wise on experience — not just on trading features. Two feature tracks were prioritized from the start: recurring payments (Direct Debits) and multi-currency accounts.

Team & my role

Three of us: a UX Researcher, a Product Manager, and me as the sole designer. I worked in two streams at once — Discovery (researching the next feature) and Delivery (shipping the current one, supporting engineers, visual QA). This case covers both, so the sections below are marked by who owned what.

Scope, honestly

Mine: the UI concept the client bought the engagement on, competitor analysis, the annotated UI audit and prioritization, the Direct Debits feature from research to production, transaction icon set, visual QA, and Apple Pay provisioning wireframes.

02 Concept

The pitch

Before the engagement was signed, the client needed to see what "competitive" could look like. I designed a set of mobile screens for a wallet that treated crypto, fiat and cards as one system: a portfolio view with live asset cards, a transaction history that reads like a bank statement rather than a ledger, a digital card with Apple Wallet provisioning, and a quick-trade flow reduced to preset amounts and one confirmation.

The concept did its job — the client bought the engagement on it.

What it did and didn't do

The concept set the bar and defined the direction: dark theme, dense but calm information hierarchy, cards as first-class objects. That direction survived into the roadmap and into the client's expectations.

What it didn't do is become the product. The shipped wallet ran on the client's existing design system, owned by another team, and I had no permission to change it. Every screen I delivered later — Direct Debits, transaction icons, provisioning flows — was built inside that system. The gap between these screens and the delivered UI is real, and it's the normal gap between a pitch and a production constraint. The rest of this case is about the production side.

03 Discovery

Competitor landscape

I benchmarked 13 products across four groups: wallet apps (Revolut, Wise, Monese), challenger banks (Monzo, Starling), investment platforms (eToro, Trading 212, CMC Markets, City Index) and card-first products (Curve, Zilch). Methods were deliberately cheap — product walkthroughs, app store and Trustpilot sentiment, a feature comparison table and a SWOT per product.

On a trust-versus-flexibility map the platform sat in the middle of the field: more capable than the pure trading apps, less trusted and less flexible than Wise or Starling. That gap became the framing for everything that followed — the Wallet had to earn trust first and add flexibility second.

User research

The researcher ran 14 sessions of 1.5–2 hours, mixing contextual interviews with usability tests on the live Wallet. Participants were UK and EU investors already using Trading 212, eToro, Revolut, Wise or Monzo. My part was analysis, not fieldwork: I went through the Direct Debit findings in detail and turned the usability issues into design feedback.

Five themes came out of synthesis: people want one place for investing, budgeting and everyday money; trust has to be earned before anyone moves real funds; multi-currency needs are underserved and fee transparency is the pain; the transaction history was hard to read; and card activation was routinely missed.

UI audit

I took the research findings back to the screens. Every issue was placed on the actual UI with a severity level — severe (user couldn't complete the task), mild (user struggled), nice-to-have (user suggested) — and paired with a proposed change. Two areas carried most of the weight: transaction history, where users couldn't tell direction or status of a payment, and transfers, where scheduled payments and direct debits were hidden under the wrong menu.

Prioritization

To turn the list into a sequence, the team ran the issues through three lenses: severity, importance to the business, and ease of fix. Where all three lined up — transaction history and deposit scheduling — became quick wins and went straight into delivery. Feature ideas from research were grouped by theme and roughly sized by effort before entering the backlog.

04 Direct Debits

Problem

Recurring payments were the first gap the discovery made unavoidable. The Wallet had scheduled transfers, but no Direct Debits — and in the UK that means no rent, no utilities, no subscriptions paid from the account. Research made the second half of the problem visible: even the scheduled payments that existed were hidden under Transfers, and users expected all recurring money in one place. So the brief was two things at once — add a feature, and fix where recurring payments live.

Research

I started with how competitors handle it. Revolut, Wise, Monzo, Starling and Monese all had Direct Debits; Zilch, Curve, Trading 212, CMC and City Index didn't. Mapping the five that did gave a common shape — a payments area with scheduled and completed items, notifications on upcoming and failed payments, and cancel from the payment details. Then I built a user story map around what people actually need to do: set one up, see it, cancel it, know when it's due, know when it failed, change the date, dispute a charge, get a refund.

Flows

The open question was the entry point. I designed three variants — Direct Debits as a tab inside Transfers, as a section on the Accounts screen, and as a standalone item in the main menu — and took them to a Design Critique with the PM, researcher and client-side product owner. The Transfers variant won, but with a change: scheduled payments and Direct Debits merged into one "Recurring" list. In research, users didn't distinguish between the two — to them it was all money leaving on a schedule — so separating them was our taxonomy, not theirs.

Validation

The researcher tested the prototype with participants matching the target profile. Subscription management landed well — people liked seeing how much they'd paid so far and the timeline of a mandate. Finding the details didn't: users knew to go to Payments but didn't click through, and got stuck. Three critical gaps, five improvements and three quick wins went back into the design; the main one was surfacing Direct Debit details as soon as the user lands on Payments, rather than one tap deeper.

"Subscriptions are one of those things that are quite hard to get a grip on. It is a good thing to be able to dig into those."

— usability test participant

Delivery

The feature shipped inside the existing design system. Alongside it I delivered the pieces the system was missing: a transaction icon set covering every transaction type in the Wallet — POS and online purchases, transfers in and out, exchange, withdrawal, deposit, scheduled, direct debit, cashback, refund — which fixed the audit finding that users couldn't tell payment direction at a glance; wireframes for in-app card provisioning on iPhone and Apple Watch; and visual QA on the built screens against the mockups.