ZenBudget

Concept project · Product designer and researcher · 2025–2026

A budgeting app for people paid partly in cash tips. I took it from an open bootcamp brief through research, testing, a change of direction, and a working coded prototype.

Three ZenBudget screens: logging tonight's tips, the home screen, and tip history by week.
Three ZenBudget screens: logging tonight's tips, the home screen, and tip history by week.

01 / Overview

Designing a budget for income that arrives in cash

Traditional budgeting assumes income arrives as a paycheck. It doesn't account for cash tips.

I researched how people manage money, designed and tested a first version with six people, and changed direction when testing exposed a problem with cash. I then designed and built a working prototype for hospitality workers.

My role: research, interaction and visual design, a design system, and the coded prototype. Status: the cash-tip flow is built but not yet usability tested - that's the next step.

02 / Starting point

A bootcamp brief that became a product

ZenBudget started in my CareerFoundry UX bootcamp as an open brief: design a personal-finance app from scratch, end to end: ideation, survey, interviews, user journeys, affinity mapping, a design system and usability testing.

Competitive analysis of Bank of America, Cash App and Venmo showed AI guidance and subscription tracking together were uncommon, so my first versions explored that. What ZenBudget is today came later, from what testing showed me.

03 / Research

What 20 people told me, and 4 explained

A survey of 20 people, interviews with 4, and a card sort with 5.

65%

didn't track a budget at all

60%

didn't track subscriptions, but wanted to

5.8/10

average comfort with AI, only if it explains itself

4 of 4

interviewees had dropped a tool that asked more than it gave them

04 / Design and design system

Turning findings into structure

The card sort showed people treat subscriptions, reminders, and alerts as one job, so they became one place. Because effort decided everything, I designed for the fewest steps per task.

The visual system was built around calm: soft blues, red kept for alerts only (red around money causes stress), and a tone closer to a coach than a bank.

05 / Usability testing

Six people, one prototype, what changed

Moderated think-aloud sessions with six people: three on mobile, three on desktop. Everyone completed the tasks; the struggles were about meaning. Numbers needed explaining, people expected a confirmation after any change, and AI should be something you switch on, not something that pops up.

So I made AI an explicit opt-in with its own tab, and made every add or cancel confirm what happened. One theme came up with five of the six people: cash.

Screens changed after testing: an AI opt-in question, a dedicated AI Assistant tab, and a transaction confirmation.

06 / The pivot

Why I changed direction

In testing, cash broke the numbers. One participant explained that with $100 in cash, the app would only ever show his bank balance, so any cash he spent made the total wrong. Once the numbers didn't add up, people stopped trusting the rest.

I'd already designed a way to log cash spending, but that was only half the picture: for many people, cash is also income. From about eight years in hospitality, I knew tips can be a large part of a worker's real earnings and rarely make it into any app.

No participant asked for tip logging. Refocusing on tipped workers was my judgment, built on a real finding, and the next round of testing is designed to check it.

From research to design: cash broke the numbers in testing; my judgment: cash is also income, for hospitality workers that income is tips, they think in shifts.

07 / Design decisions

Key decisions, and what I chose not to do

Shift picker with Dinner selected and the note: set automatically from the time, tap to change.
Shift picker with Dinner selected and the note: set automatically from the time, tap to change.

Shifts, not dates

Workers remember earnings by shift, like "Saturday dinner". The shift is pre-set from the time of day, and always visible, because testing showed people distrust things an app decides silently.

Amount entry labelled Cash you took home, showing $85.
Amount entry labelled Cash you took home, showing $85.

Log what you took home

Tips are often pooled before a worker leaves. I log only the cash they actually took home and keep pooling out of the app, it happens before the money reaches them, and would add steps at the end of a shift.

Update cash screen: count the cash in your wallet; ZenBudget expected $311 and records any difference as a correction.
Update cash screen: count the cash in your wallet; ZenBudget expected $311 and records any difference as a correction.

Say what's in your wallet

Cash on hand is calculated from what you log. When it drifts, you count your wallet and ZenBudget works out the difference, people know what they're holding, not what the app is missing.

Income card: paycheck and cash tips, with a green upward change labelled versus last month.

Colour means good or bad for you

"$20 up, but it's green" confused testers. Now the arrow shows direction, colour shows meaning, red appears only when something needs attention, and colour never works alone.

Onboarding question: How do you get paid? Options: a paycheck, a paycheck plus cash tips, mostly cash tips.

Ask how people get paid

A reviewer pointed out that asking every new user about cash tips doesn't fit people who don't earn them. One question after sign-up now sets things up: paycheck-only users skip the tip features, and people paid mostly in tips start with cash. Nothing is pre-selected, so a default can't nudge the answer. It's untested, and part of my next round.

Home: the Log cash tips card with an amber edge and amber icon, above recent activity with category dots instead of outlined tags.

Make the main action stand out

The Log cash tips card was fading into the background, so I kept its warm amber and gave it a defined edge and a solid icon. Category tags became dots: as outlined pills they looked like buttons, and testers had mistaken status labels for controls.

What I left out: a proposed "spendable" figure. A new number on the main screen needs a clear definition and a reason to be there; that one had neither.

08 / The prototype

A working prototype, not just screens

I built ZenBudget as a coded prototype from my Figma designs, with AI as a build partner, so the flows can be used, not just viewed. The walkthrough follows the core job: logging tonight's tips, and names the design decision behind each step.

Try it yourself

One task: log $85 of tips for your shift. Look for:

  • the shift is already set from the time of day - tap to change it

  • a numpad instead of a keyboard

  • the comparison with your previous shift of the same kind after you save

Everything is simulated; nothing you type is sent anywhere.

09 / How I used AI

AI as a collaborator, not the designer

Analyse

AI checked my research, Figma and early screens against each other and flagged where claims went further than the evidence, including claims from earlier versions of this case study.

Challenge

Every suggestion came as a proposal I accepted, changed or rejected, and every decision is on record. When AI's cleanup made the screens consistent but generic, I rejected it and kept the original visual character.

Build

The Figma file and a coded prototype kept in step, built with AI and deployed so people can use it.

10 / Reflection and next steps

What I'd do differently, and what I'm testing next

I'd screen for income type from the start. My survey never asked about cash or tips, so when I changed direction there was no survey data behind it.

I'd measure, not only observe. I planned task times and success rates but ran the sessions as qualitative only.

Next is a second round of testing with hospitality workers: can someone log a shift correctly without help, how long does it take, and do shifts match how they remember their earnings?