Case Study
Finvault
A personal finance dashboard built to answer one question hiring teams keep asking designers and developers: can you actually ship the thing you designed? Every account, transfer, and goal on screen is real, not a static frame pretending to be a product.
Role
Product Design + Build
Scope
Banking Dashboard
Timeline
Solo, single build cycle
Devices
Mobile · Tablet · Desktop
THEBRIEF
Open ten portfolio finance dashboards and you'll find the same thing: a beautiful balance screen that does nothing the moment you click anything on it. The numbers are static, the buttons are decorative, and the "transfer money" flow is a single frame with no second screen behind it. It looks like a product. It isn't one.
So I gave myself one rule before drawing a single pixel: if a button exists, it has to do something. Not "log to the console" actually open a flow, accept input, validate it, and show a result a real person would recognize as a confirmation. No exceptions, no "coming soon." If I couldn't make a feature real, it didn't make the cut.
That constraint mattered because of who's actually looking at a portfolio like this. It's not a casual visitor it's someone deciding whether to trust their product, their timeline, and their budget to the person who built it. The people who get burned by a portfolio that falls apart on the second click are exactly the people I'm trying to convince not to walk away.
My Role
Solo product design and frontend build, start to finish.
Visual Direction
Deep navy and mint-green fintech palette, built for trust over noise.
Core Challenge
Make a demo dataset feel like real money balances and transfers that actually respond.
What Was Tested
Every screen, on phone, tablet, and desktop in both dark and light mode.
The Walkthrough
Each one shaped how the rest of the product got built.
Decision 01
Card Design
I replaced the usual "balance inside a flat panel" pattern with cards built to resemble the physical bank cards already in everyone's wallet, a metallic chip, a masked card number, a network mark, and a gradient unique to that account. I did this because people extend more trust to something that looks like a card than to a number sitting in a generic box. The visual language was already familiar. I just had to borrow it honestly instead of inventing a new one nobody recognizes. The payoff for the person using it: they know which account they're looking at before they've read a single label. Checking is blue, savings is green, credit is violet, color does the identifying, so their eyes don't have to work for it.
Checking Account
$24,389.50
•••• •••• •••• 9065
VISA
High-Yield Savings
$18,750.00
•••• •••• •••• 1876
MASTERCARD
Decision 02
Privacy First
Total Net Worth
••••••••
👁 Show balance
I built a single toggle that masks the net worth figure, every account card balance, and every income/expense number on screen at once, instead of a "hide" button scoped to whatever card it sits on. Finance apps get opened in public more than almost any other app category, on a train, in a meeting, in line at a coffee shop. A privacy control that only hides one number while three others stay visible isn't really privacy. It's a gesture. For the person holding the phone, it means a glance over their shoulder reveals nothing, full stop. It's one small interaction, but it's the difference between an app that performs safety and one that actually delivers it.
Decision 03
Real Functionality
Pay Bill, Top Up, Loan, Gift, Travel, Insurance each one of the eight quick actions on the homepage opens its own form, takes real input, validates it, and ends in a confirmation a person would actually recognize, the same way their banking app already works. I made this trade deliberately: I'd rather ship eight flows that genuinely work than twenty buttons that look impressive and lead nowhere. A dead-end button costs more trust than a missing feature ever does it tells the person the rest of the product might be hollow too. The result for the end user is simple: nothing on this dashboard is a trap door. If they tap it, something happens. That's the bar every banking app they've ever used has already set, so this one had to clear it too.
💳
Pay Bill
Pay utilities, subscriptions & more
Select biller
Comcast Xfinity — Internet
Amount (USD)
$79.99
Pay Bill
Decision 04
Built for the Pocket
☰
Finvault
🏠
📊
↔️
🎯
Desktop got a fixed sidebar. Phones got a hamburger menu paired with a bottom tab bar for the actions people reach for most. I designed them as two separate systems rather than squeezing the desktop sidebar into a 6-inch screen and calling it responsive. Most people open a finance app on their phone first, often one-handed, often in a hurry. A sidebar that technically fits but forces a thumb stretch across the screen is a worse experience than navigation built for that context from the start. What this means in practice: whichever device someone reaches for, the things they need most transfer, pay, check a balance stay one thumb-reach away, never three taps deep in a menu they have to go hunting for.
Every screen in this case study is a real, working build open it, click through the same flows shown above, and they'll behave exactly the way they're described.
Before: actions cut off on small screens
→
After: layout adapts per device, nothing hidden
What Shipped
Three account types, nine working financial flows. Pay Bill, Transfer, Top Up, Loan, Gifts, Insurance, Travel, Mortgage, and Invest are all built, wired, and clickable not wireframed placeholders waiting on a "v2."
Two full navigation systems, three breakpoints. A dedicated sidebar for desktop and a hamburger-plus-tab-bar pairing for mobile, tested down to a 320px-wide screen not one layout awkwardly resized.
Designed and built solo, end to end. From the first color token to a shareable, deployed link, in a single continuous build no handoffs, no gaps between the design file and what actually shipped.
No slide decks standing in for a product. No "imagine if this button worked." Just something you can open and click through right now.
Get In Touch