Backstory

A typical UK consumer doesn't have one bank; they have a financial life spread across several. Salary lands in one current account, everyday spending runs through another, savings sit somewhere else, and around that sit credit cards, a loan, an ISA, perhaps a pension. Every one of those institutions offers a well-designed app, but each app is optimised around its own slice of the picture.

That creates a quiet but real problem. A question as ordinary as "Can I afford this £1,500 laptop?" can't be answered reliably by looking at one current-account balance. The balance might look healthy while a credit card bill, a direct debit and a savings goal all sit just out of view in other apps. The user is left to do the reconciliation in their head.

BACI started from a different premise: treat the user's financial life as one connected system, and give them an agent that can reason across all of it. As Product Designer, I was responsible for defining the product strategy and experience end to end from onboarding, consent and account connection through to the insight engine and the AI agent, and for specifying it to a level engineering could build from, captured in a PRD, a functional requirements document and a high-fidelity Figma file.

The central discipline on this project was refusing to design a dashboard. A consolidated balance screen would have been the obvious output, and it would have missed the point: the value isn't in seeing all the numbers, it's in understanding them well enough to make a decision.

I structured the work as Problem → Fragmented landscape → Assumptions → Product strategy → Information architecture → Connection model → Trust model → First insight → AI agent → Affordability scenario → Edge cases, so that every screen could be traced back to a specific user job rather than a feature list.

I framed the central design question as a How Might We: How might we turn fragmented banking data into explainable, conversational decision support that users can actually trust.

Measuring success

The design was specified alongside nine QA acceptance scenarios that double as a validation plan — from connecting one bank, to aggregating three institutions, to confirming credit-card debt is never treated as cash, to checking that a disconnected account can't be used by the agent, and that duplicate subscriptions across accounts are detected without double-counting. The recommended next step is moderated testing of the "Can I afford this?" flow, comparing answers with and without coverage and freshness disclosures, to confirm that transparency increases trust rather than adding friction.

The Problem

Research plan

The Process

Six hypotheses shaped what the product needed to prove:

Coverage drives accuracy; answers grounded in all of a user's accounts will be materially more useful than single-account answers, and users will value that difference once it's shown to them.

Granular consent builds trust; explaining each data category individually, with control to switch each off, will increase connection rates rather than reduce them.

Immediate value earns the next account; a genuinely useful first insight straight after connection will motivate users to connect further accounts.

Explainability beats confidence; users will trust a hedged, well-explained answer over a confident yes/no they can't verify.

Conversation lowers the barrier; people would rather ask a question in their own words than learn a dashboard's taxonomy.

Scenarios beat verdicts; for large purchases, showing the impact on cash buffer and goals is more helpful than a simple "yes, you can afford it.

Working through the problem surfaced a statement that shaped everything that followed: people can't make confident everyday financial decisions because their financial information is fragmented across institutions, and no single product both sees the whole picture and explains what it means for the choice in front of them.

But the more interesting problem was the one hiding underneath it. Financial intelligence is only as good as the data coverage behind it. If a user connects two of their five accounts, any answer BACI gives is based on partial information, and presenting a partial picture as a complete one is worse than giving no answer at all.

That turned the brief into an unusual UX challenge: the interface had to communicate uncertainty, which accounts were analysed, how fresh the data was, and what BACI had assumed, without turning a friendly consumer product into a technical banking console.

I mapped the full journey; Introduction → Consent → Financial profile → Connect account → Add another account → Sync → First insight → Dashboard → Ask the agent → Discover missing coverage → Connect another account → Recalculate and identified that account connection was not an onboarding step at all. It is a persistent loop at the heart of the product.

Initial UX hypotheses

Solution exploration

To move from assumption to evidence, I scoped a four-part research plan:

Jobs-to-be-done mapping;  distilling the everyday questions people actually ask about money ("How much do I really have?", "What bills are coming up?", "Can I afford this?", "Why does my balance feel lower than expected?") into core user jobs that the agent had to answer.

Usability testing of the consent and connection flow; recruiting people who hold accounts across two or more institutions, and observing whether they understood what data was being requested, why, and how to add a second or third account after onboarding.

Trust and comprehension testing of agent answers;  showing participants affordability answers with and without source, freshness and assumption disclosures, and measuring which ones they found believable and actionable.

Competitive review;  studying bank apps, aggregators and AI assistants for patterns in consent, multi-account management and financial explanation, used to inform interaction patterns rather than visual style.

Validating the direction

Success was defined across four lenses.

Activation: completing consent, connecting at least one account, and the metric most specific to BACI  connecting two or more, alongside time to first sync and reaching a first insight.

Engagement: agent conversations per active user, insight open and action rates.

Trust: connection completion, consent abandonment, disconnection rate, user-reported accuracy and the share of agent answers with visible supporting data.

Financial utility: recurring savings and avoidable fees identified, goal-impact scenarios generated, and insights users confirm as useful. Trust metrics were deliberately treated as guardrails, so a rise in engagement couldn't be counted as success if it came with rising disconnections or accuracy complaints. 

Key learnings

The most important shift on this project was realising that the hardest design problem wasn't the AI, it was honesty about data. A financial agent that sounds confident but reasons over half the picture would erode trust the first time it got something wrong.

Designing BACI meant treating uncertainty as a feature: showing coverage, freshness and assumptions in a way that feels reassuring rather than technical. That reframed the whole brief from "design a finance dashboard" to "design a multi-account financial intelligence system that turns fragmented banking data into explainable, conversational decision support."

The direction moved BACI away from a finance dashboard and toward a financial intelligence system: a consolidated data model with a conversational agent as its primary interface, and trust signals designed into every answer.

Onboarding that earns permission: The introduction presents the Finance Intelligence Agent as a large, friendly visual and immediately answers the questions users bring to any finance app: where is my data kept (Secure Vault), what will you do with it (Smart Alerts), and who is in charge (user control). A five-stage progress indicator keeps the journey short and legible.

Granular, revocable consent; Instead of one "allow access" screen, permissions are broken into nine understandable categories; transaction history, spending categories, bills and direct debits, savings and ISAs, credit cards, loans and mortgages, overdraft usage, investments and pensions, and income signals, each explained in plain language and each revocable later.

A profile that complements, not competes: Profile setup captures take-home income, current status, primary financial goal, risk approach and insight frequency. Crucially, declared income and account-derived income are kept side by side and labelled by source, so live data never silently overwrites what the user told us.

Connection as a loop, not a step; Users can add a first account, add another immediately, and come back to add more at any time. Every account shows its institution, masked identifier, status and last successful sync, and I designed ten distinct connection states; from Connecting and Awaiting authorisation through Healthy and Stale to Re-authentication required and Disconnected, so the interface is never ambiguous about what BACI can see.

A first insight that proves the point; Straight after connection, BACI surfaces one explainable insight, in the design, duplicate streaming subscriptions spread across accounts, framed around the annual saving. Each insight shows what was detected, which accounts and transactions it came from, the period analysed, the estimated impact, and a clear action or dismiss path. It's the moment the multi-account model pays for itself.

"Can I afford this?" as the signature interaction; When a user asks "Do you think I can buy this £1,500 laptop?", the agent never simply compares the price to one balance. Behind the answer sits a fourteen-step pipeline: parse the price, check one-off vs. recurring, retrieve connected accounts, check their freshness, aggregate liquid balances, identify expected income, essential spend, debt repayments and upcoming bills, check savings goals, then project the cash position and goal impact, before offering alternatives where they help.

Trust designed into every answer; Each response makes six things visible: which accounts were analysed, when they last synced, whether coverage was complete, what was assumed, how the figure was calculated, and how to change accounts or permissions. Where only some accounts are connected, the agent says so directly, "your analysis is based on 3 of your accounts", and offers to connect another when it could change the answer.

I also restructured the information architecture around the user's financial life rather than any single bank's structure: User → Profile → Consent → Accounts (across institutions) → Financial data model → Intelligence → Agent.

Trust designed into every answer; Each response makes six things visible: which accounts were analysed, when they last synced, whether coverage was complete, what was assumed, how the figure was calculated, and how to change accounts or permissions. Where only some accounts are connected, the agent says so directly, "your analysis is based on 3 of your accounts", and offers to connect another when it could change the answer.

I also restructured the information architecture around the user's financial life rather than any single bank's structure: User → Profile → Consent → Accounts (across institutions) → Financial data model → Intelligence → Agent.

Developed Screens