A Fintech UX Case Study Example, Torn Down (Pilo)
Heads up: Pilo is a fictional neobank — an example portfolio built with Folioverse. The metrics below are illustrative sample figures from that fictional project, not real product results.
A fintech ux case study lives or dies on trust. In money flows, one scary moment kills confidence, so the thinking behind each decision matters more than the polish. This teardown walks through Pilo — a fictional neobank — to show how a financial product case study can prove judgment, defend a trade-off with evidence, and stay honest about results.
Pilo is a consumer banking app. The designer redesigned the Send Money flow because users were abandoning at confirmation and support kept getting “I sent money to the wrong person” tickets. It is an example portfolio built with Folioverse, so the project is realistic but fictional, and the figures are illustrative.
Recruiter 30-second scan: What was breaking in the flow? What did the designer personally own? Which decisions were backed by evidence? And are the results stated with appropriate caveats?
Case context
- Project type: mobile redesign (trust-critical flow)
- Role: sole product designer, partnered with one PM and two engineers
- Duration: 6 weeks, UI and flow only (no backend changes for v1)
The boundary is clear, which matters in fintech where teams are cross-functional.
Weak version:
“We improved the banking app’s transfer feature.”
Strong version:
“I was the sole product designer on a 6-week redesign of the Send Money flow, scoped to UI and flow changes only, working with a PM and two engineers.”
The problem this case proves
A strong fintech problem statement points to a specific, trust-damaging failure.
Weak version:
“The transfer flow had bad UX.”
Strong version:
“Users abandoned at the amount and recipient confirmation step, and support saw repeated wrong-person and wrong-amount tickets. In banking, one scary moment kills confidence — so this was a trust problem, not just a friction problem.”
What the designer did — research that fits the domain
The case shows evidence-led work: three months of support tickets tagged by failure point, plus five usability sessions on the old flow. Synthesis grouped failures into three root causes — recipient ambiguity, amount-entry friction, and no clear “review before send” moment.
This is the part many fintech case studies skip. Tying design decisions to tagged support data is exactly the kind of evidence a hiring reviewer trusts.
Key decision 1: a non-skippable review screen
Evidence: support tickets showed the real cost was wrong sends, not slow sends.
Alternative considered: keep the flow fast with no extra step.
Weak version:
“I added a confirmation screen.”
Strong version:
“I added a non-skippable review screen even though it adds a tap. I chose safety and trust over raw speed, and I defended that trade-off with the support-ticket data.”
This is the strongest signal in the case: a designer knowingly adding friction, and justifying it with evidence.
Key decision 2: recipient verification
Evidence: “wrong person” was a recurring, expensive error.
Alternative considered: a plain recipient name field.
Weak version:
“I made the recipient clearer.”
Strong version:
“I added recipient verification — avatar, masked account number, and a last-sent badge — to kill the ‘wrong person’ error class before the money moves.”
Key decision 3: amount-entry redesign
Evidence: mis-entry of amounts was a distinct root cause.
Alternative considered: keep the existing small input.
Weak version:
“I redesigned the amount input.”
Strong version:
“I rebuilt amount entry with a big numeric display, inline balance, and clear currency, because the data showed mis-entry was its own failure mode, separate from recipient errors.”
Outcome and evidence
This case includes metrics, but treats them as what they are: illustrative figures from a fictional project.
Weak version:
“The redesign was a huge success.”
Strong version:
“In the example project, task completion rose from 68% to 91% and wrong-send support tickets dropped by roughly 40%, while time-to-send stayed about flat — the extra confirm tap didn’t slow people, because there were fewer corrections. These are illustrative figures for a fictional product, not a real launch.”
The honesty about the figures’ nature is part of what makes the case credible.
What makes this teardown worth studying
- The problem is framed as a trust failure, with a concrete cost (support tickets).
- The headline decision adds friction on purpose — and defends it with data.
- The “extra tap didn’t slow people” insight shows the designer thinks in systems, not single screens.
- Even with metrics available, the case labels them honestly as illustrative.
For the full structure behind a case like this, use the UX case study guide. Browse more UX case study examples, including an e-commerce PDP teardown. If this is your first portfolio piece, start with how to write a UX case study with no experience.