Making finances approachable for the 65% who avoid them
Financial literacy has a high barrier to entry, and we found it comes with a large emotional response
Opening a banking app can produce a spike of dread before a single number is read. Anxiety arrives before the comprehension does, and the response is avoidance, leading to balances going unchecked and goals quietly lapsing.
Design Interactive challenged our team to design for personal finance. With a prompt that broad, we chose an audience first and let their experience decide what we’d build.
- Formed the user flow for the Profile and Goals pages.
- Built the milestones system that made progress feel tangible.
- Designed shareable goals, including the QR code model for sharing in person and the privacy model for who sees what.
Nobody had a finance app they actually liked
We ran 42 surveys and 12 interviews with college students and recent grads. Here are some insights:
Confidence is low
65% of the respondents rated their financial confidence ≤3/5.
Tracking is manual
2/3’s of respondents track their finances by hand.
Checking doesn’t help
The heaviest checkers still overspent at a high rate.
We analyzed the finance platforms young adults already reach for.
YNAB (You Need A Budget)
Well structured, steep learning curve, but heavily subscription based.
Monarch
Strong all-in-one dashboard, but no free tier and inconsistent syncing.
Rocket Money
Automated tracking, but takes a cut of savings and buries cancellation.
Spreadsheets
Flexible and free, but manual entry with no automation.
Every app in this space assumes that showing people their money helps. We found that the problem isn’t the numbers. It’s looking at them.
There’s a lot of information, and it’s not always clear what I should focus on. I also wish it felt more personalized instead of just showing generic charts.
3rd year, Design
How might we help young adults transform financial anxiety into confident financial decisions through engaging goal-setting and budgeting tools?
The more a page holds, the less people want to use it
The Profile page carries the heaviest load in the app: saved, milestones, goals, shared goals, banks, privacy. Every one is necessary.
Splitting and reimbursements came up unprompted in the surveys — group money was already happening, just not in anyone’s budgeting tool.
So the question was never what to cut. It’s that nothing stands out from anything else. When everything looks equally important, the page reads as a wall. And for someone already primed to avoid their finances, a wall is a reason to close the app.
Five streamlined decisions
The Goals page, where a goal gets made, checked on, and shared. Setting one up takes five decisions. I streamlined the flow so each screen asks for one thing, because overload is where avoidance starts.
Where your progress, milestones, and preferences coexist
Shared goals sit near the top, with members and progress visible on the card, so money feels like something you work on together, not something you face alone.
Managing your preferences
Connected banks, milestones earned, and privacy settings, kept below the fold and never in the way, so nothing heavy is the first thing you see.
The judges wanted to know where it went next
We closed the quarter by presenting Mellow at Design Interactive’s showcase. The designs landed well, and the judges spent most of their questions on where the app could go next rather than on what it already did.
Timeline shifts cut testing short
I thought I was on schedule. However, the timeline moved partway through, and the days it took were the days I’d left for testing the pages.
I got one session in on the Profile page. Enough to raise questions, but nowhere near enough to confidently answer them. Revising would’ve been guessing, so the page shipped based on the team’s research and my own judgement. The goals page never got that far, coming too late into my hands during the project that there was no room to prepare and perform any user tests.
What I’d do differently is move testing earlier in the process and book the sessions well before I need them, far enough inside the deadline that a shift can’t reach them. Even if a page is only partially finished by the time user testing comes around, testing something unfinished is better than not getting any tests in at all.