Case study · 2026

A bank built around the couple, not the account.

Role

Product Designer

Type

Concept project

Platform

Web app

Skills

UX/UI · Research

The couples banking app running on a laptop, held up against a blue sky

Shared setup — deciding how a couple's money works, together.

01 — Overview

A shared bank for couples.

This is a concept project: a bank for couples who share their finances. I didn't design the whole application — I designed one flow, the shared setup: the couple decides what each partner contributes, which bills the shared pot covers, how spending is split into cards, and what they're saving for. It's the flow where all the real decisions live, so it's where the design problem is.

The process, briefly: desk research first, distilled into five constraints that guided the design decisions. Then flow explorations and lo-fi wireframes, a coded prototype, and a moderated usability test. Only after that came the visual identity and the final coded UI — which is embedded further down, live.

02 — Research

Five constraints I designed against.

I started by writing research questions to organise the research, aiming to cover every aspect of the product: how do couples actually organise their money — what's shared, what's kept separate? What happens when incomes are unequal? Why do money fights start, and what are they really about? What makes saving together work?

With those questions set, I did a round of desk research — existing studies on couples and money, plus the behavioural economics behind spending and saving. From the findings I distilled five constraints. Not hard rules, but things I kept with me throughout the project — they guided the product decisions from here on.

01Boundary. Couples want partial transparency, not full. What's shared is visible to both; what's personal stays private. So nothing is ever defaulted into the shared layer — every shared item is an active choice.
02Fairness. The harm from unequal income isn't the gap, it's the unspoken meaning. Contribution has to be explicit, agreed, and proportional to income — never an assumed 50/50. This is the product's sharpest differentiator: the Icelandic incumbent only offers 50/50.
03Mental load. The partner who manages the money carries stress nobody consciously handed them. Automate the execution, and surface decisions as shared, so the admin is distributed rather than dumped on one person.
04Goals. Shared goals motivate more than private ones, and visible progress sustains them. Saving has to feel motivating, not like filling in a form — named pots, a picture of what you're saving toward, progress both partners can see.
05Couple-first. Every existing tool treats a couple as two individuals. Here the shared pot is the primary concept and setup is a joint act — neither partner's experience is the secondary one.

03 — Finding the flow

Finding the flow.

In this phase I needed to finalise the base task flow first, then move on to the detail — what belongs on each screen. For this I used Claude Code and Paper design. It was a really enjoyable workflow: I could brainstorm different ideas with Claude Code and easily see them laid out in Paper design.

Three flow directions came and went — one partner setting up and the other just approving, a turn-based version, and the one I committed to: both partners set their own contribution, then move through bills, spending, and savings together, before a final review. The outcome was both that flow and a first take on what each screen should hold.

The Paper canvas with the wireframe explorations — three flow directions and many screen variants side by side — Every wireframe explored, on one Paper canvas.

What to share screen — The final screens from this phase.

Set contribution, share of pay — The final screens from this phase.

04 — Prototype and testing

Making it real, then testing it.

With the flow and screens resolved, I built them into a working prototype — the whole setup, clickable end to end. Clicking through it for real surfaced things the static wireframes had hidden, so I refined each screen as I went.

I also mapped the flow as a user flow diagram to catch the edge cases and added them to the prototype.

Then I put it in front of people: a moderated, think-aloud usability test, real tasks, watching without stepping in. Below is each screen that was tested, and where people got stuck.

The setup flow mapped as a diagram — screens, decisions, and undesigned edge states — The flow mapped out — main path left to right, edge cases and undesigned states branching off.

05 — Building the identity

Now the colour and brand.

With the flow tested and settled, I added colour and brand. The goal was trust: a product you hand your salary to has to feel calm and solid, not like a spreadsheet. I used Mobbin to study how established banking and finance apps build that trust, and pulled the direction from there.

For the build, I set up a simple two-step design system — raw values (the palette, type, spacing) feeding semantic tokens (background, accent, savings) — so the whole UI stays consistent from one source. I moved the design between Claude Code and Figma, using Figma wherever I needed finer control, then bringing it back into the coded product.

06 — Final design

The final design.

Everything below is the real, coded product — not screenshots. The whole setup flow is embedded here, playable start to finish; the screens after it are that same live UI, each held on the moment that carries the most design thinking.

Try it yourself.

Walk the full flow below — set a contribution, choose bills, split spending, name a savings goal. Or open it full screen.

Screen 1: Contribution — proportional, and private.

Testing showed people expected to set what they put in, not what stays — so contribution is now the deliberate number, a share of pay or a fixed amount (the Fairness constraint). The privacy reassurance testers found over-said is one calm line now: salaries stay private, only amounts show (Boundary).

Screen 2: What's coming — orienting before deciding.

The loudest signal from testing was that people decided without knowing what was coming, then opened each screen unsure where they were. So setup now opens with a short intro — bills, then spending, then savings — orienting the couple before a single decision is asked. Page through its three cards below.

Screen 3: Bills — which ones the pot covers.

Testing caught the old headline — "How should bills be paid?" — misreading as which card pays, not which bills the pot covers. It's reworded to name the real task, with every bill (and its auto-pay) opt-in, so nothing about a couple's money is assumed (Couple-first).

Screen 4: Spending — but savings first.

This screen tested worst: the linked sliders were opaque and savings-as-leftover never read as a decision. So it's rebuilt savings-first — you lock savings before anything else — with named virtual cards rather than abstract "pots" (testers didn't link a pot to their wallet), keeping the Mental-load constraint honest.

Screen 5: Savings — a base account, and goals worth picturing.

Testers didn't realise they'd reached savings, and a "catch-all" account baffled them — so it's gone, replaced by a plain base account that simply holds what isn't assigned. Goal accounts keep what testing liked: a target, a time-to-reach line and an interest breakdown — the Goals constraint, made motivating.

Screen 6: Review — the whole picture, agreed.

Testers said the shared-pot picture was there but easy to miss, and the side panel just repeated the middle. Now the whole picture is the focus, with nothing new to decide — only the choices you already made together, ready to send (Couple-first).

Dark mode.

Dark mode was part of the system from the start — a dedicated night photograph behind the glass and a deeper accent, rather than a mechanical invert. Here's the whole flow again, clickable from the top, at night.