How I led discovery and prototyping for a mobile card management experience at C. Hoare & Co — a 350-year-old institution with 15,500 customers and no self-service card controls. The design shipped and is live in the App Store today.
C. Hoare & Co is the UK’s oldest privately owned bank, founded in 1672. It serves around 15,500 customers — predominantly high-net-worth families, entrepreneurs, and professionals — with a relationship-led model where each client has a dedicated account manager.
The bank’s existing mobile app offered basic account viewing, but customers had no way to manage their cards. Freezing a card, reporting it lost, or checking a PIN all required a phone call to the relationship manager. With 20,000 cards across personal, business, and corporate accounts, this created a daily bottleneck — especially when fraud was involved.
The bank needed to bring card management into its iOS app — but first, it needed evidence that this was the right investment. My role was to lead UX discovery and prototyping: prove the demand through relationship manager research, define what customers actually needed, and deliver a validated design ready for implementation.
This wasn’t a project where the client was waiting for UX with open arms. The bank was pushing toward a predetermined solution rather than understanding the problem first. There were no existing personas, no user research history, and no design system for the mobile app.
On top of that, we were navigating a shifting technology landscape — an ongoing AWS migration, evolving platform constraints, and two parallel project tracks where priority levels weren’t immediately clear.
My first job was to demonstrate that a structured discovery process would produce a better outcome than jumping straight to screens.
We ran two intensive days of lift-off workshops with the bank’s product, technology, and business stakeholders. The goal was to define the problem space, align on competing constraints, and agree on a discovery plan.
Using a Miro board, I facilitated sessions that mapped the existing customer journeys, surfaced competing priorities from different parts of the business, and identified the core question: what do high-net-worth customers actually need from card management — and what can the bank deliver within its existing technology stack?
The lift-off produced three outputs: a shared project vision, a prioritised backlog of discovery activities, and — critically — buy-in from the bank’s leadership that discovery was worth the investment before committing to development.
Direct customer research wasn’t available to us — the bank’s relationship managers are the primary interface with clients, and the institution was cautious about introducing external researchers to their customer base. So I designed a research plan that used RMs as expert proxies.
I wrote a structured interview guide with open-ended scenarios — questions about card fraud situations, Apple Pay requests, mobile app frustrations, and feature requests. We interviewed four relationship managers across different client segments: high-value personal clients, business customers, corporate family offices, and the call centre team.
The interviews produced rich qualitative data. I synthesised responses into an affinity map, grouping patterns across customer segments. Three findings reshaped the entire project direction:
I conducted a competitive review across retail and private banking apps, examining card management patterns from Revolut, Monzo, and traditional banking apps. The goal wasn’t to copy fintech — it was to identify baseline expectations that C. Hoare’s customers would carry from their other banking relationships.
The analysis confirmed that freeze/unfreeze, card state visibility, and PIN management were table-stakes features. But the private banking context meant we needed to handle multiple card types — personal debit, corporate credit, third-party holder cards — with different permission models and visual distinctions.
The most important design decision was the card state system. Unlike retail banking where a customer typically has one or two cards, C. Hoare’s customers could have personal debit, personal credit, corporate cards, and third-party holder cards — each with different states and available actions.
I designed a visual language where the card itself communicates its state: active cards appear in the bank’s signature teal, frozen cards shift to grey with a snowflake icon, blocked cards darken further with a lock, and unactivated cards show in a warm tone with a prominent “Activate” CTA. Each state change triggers contextual actions — a frozen card offers “Unfreeze,” a blocked card offers “Unblock.”
I also designed the UI iteration through four versions of the main “My Cards” screen — evolving the information hierarchy, action bar placement, and card detail visibility based on stakeholder feedback and technical constraints. Each iteration tightened the balance between the bank’s brand identity and modern usability patterns.
Based on the research findings, I recommended a two-phase approach that prioritised the actions causing the most RM overhead:
I built a high-fidelity Figma prototype covering the complete Phase 1 flows: viewing cards, the freeze/unfreeze journey with confirmation dialogs, and the report-card flow with location and time capture. The prototype used the bank’s brand colours and followed the existing app’s navigation patterns to feel like a natural extension rather than a bolt-on.
Key interaction decisions included confirmation dialogs for all destructive actions (freeze, block, report), clear state transitions with visual feedback, and a help CTA on every screen linking back to the relationship manager — preserving the bank’s personal service ethos even within a self-service feature.
Given the bank’s intergenerational customer base — from 70-year-olds to their grandchildren — accessibility was a first-class concern. I ran contrast checks using Stark and A11y against the bank’s brand palette during the design phase, not after handoff.
The results were mixed: the primary card-on-background combination passed AA at 6.68:1, and the report card flow achieved full AAA compliance. However, the action bar icons on light backgrounds fell short at 3.7:1 — I flagged this as a design system issue that needed resolution before development, proposing darker icon fills that maintained the brand aesthetic.
The project delivered a complete discovery package: a validated prototype, a phased product roadmap, and research insights that changed how the bank thought about its digital offering.
The most significant outcome wasn’t the prototype itself — it was the strategic appetite we uncovered. During the discovery process, stakeholders realised that card management was just the starting point. The research had surfaced demand for a complementary web platform, corporate card controls, and deeper self-service capabilities. Our recommendations reshaped the product roadmap beyond the original brief.
The card management features I designed — view cards, freeze/unfreeze, report lost or stolen, view PIN — were implemented and are live in the C. Hoare & Co iOS app today. The frozen card state, confirmation dialogs, and card status visual system I prototyped during discovery carried through to the production release.
Discovery isn’t always welcomed. Pre-discovery is not always seen as a valuable step by clients — it takes persuasion to bring the needed audience to the meetings. I learned to show the value of each workshop by delivering a tangible output at the end of every session, not just at the end of the project.
Workshop fatigue is real. Too many workshops result in disengagement. I adjusted by reducing session length, tailoring the audience for each workshop rather than inviting everyone, and sharing outcomes with non-participants separately. Showing benefits for each session — not just asking for time — kept momentum alive.
Relationship managers are the real experts. In a private bank, the RM knows the customer better than any analytics dashboard. Designing the research around their expertise — rather than trying to access customers directly — produced richer insights than a standard user interview would have.
What I’d do differently: I’d push for a design system conversation much earlier. Without an existing component library, every UI element was designed from scratch, and the lack of reusable patterns created inefficiency in the later prototype iterations. Starting with even a lightweight token system — colours, spacing, type scale — would have saved significant time and given the bank a lasting asset beyond the project.