Smart Budget

Turning monthly money stress into a calm, glanceable plan.

A mobile budgeting companion for people managing regular income for the first time, designed to show their monthly financial position through one overview of spending, budgets, savings, upcoming payments, transactions, and alerts.

Smart Budget rebuild home screen showing $765 left to spend this month, monthly allocation, and categories that need attention.

Solo rebuild · Coded prototype

Problem

Smart Budget was an academic capstone created by a six-person team for first-time budgeters moving from tips, freelance checks, or student life to a regular paycheck and the responsibility of making it last a month. Many budgeting tools require recurring categorization, reconciliation, and review, so these first-time budgeters needed a clearer way to understand their monthly financial position without maintaining a complex system.

Approach

The team designed a consistent mobile system that brings monthly spending, savings, budgets, transactions, upcoming payments, and alerts into a clearer financial overview.

Outcome

Formative testing led the team to put the dashboard first, reorganize it around savings, monthly allocation, spending progress, and upcoming payments, and rewrite alerts to be calm and actionable. After the capstone, I rebuilt Smart Budget solo as a coded prototype that resolves four findings the team left open.

02 · Understanding the problem

People needed guidance without financial homework.

I led a 10-question survey with 23 respondents and the competitive analysis. Follow-up interviews added context, and formative task-based sessions examined onboarding, the dashboard, budgets, transactions, and alerts.

Strongest survey findings

13 of 23 respondents named staying consistent as a leading budgeting challenge.
9 of 23 chose a simple dashboard as their single must-have feature.
9 of 23 tracked spending through notes or memory, and 7 of 23 didn't actively budget.

03 · Defining the direction

A calm monthly overview had to replace constant categorization.

The research pointed to a broader need: help first-time budgeters understand their monthly financial position across spending, budgets, savings, and upcoming payments without maintaining a complicated system. A composite proto-persona helped the team keep that need visible, but was not treated as fully validated.

How might we help first-time budgeters understand their monthly financial position without requiring constant categorization and review?

Design priorities

The overview had to reduce cognitive load: Group savings, allocation, spending progress, and upcoming obligations in one overview while keeping categorization deeper.
Anxiety lives in the unknowns: Bias the system toward proactive alerts (upcoming bills, category thresholds) over passive reporting.
Consistency is the hardest habit: Anchor the experience in goal progress and visual feedback rather than nagging notifications.
Plan vs. activity are different mental models: Hard separation between Transactions (history) and Budgets (planning); same vocabulary, different verbs.
Reuse the same categories everywhere: One canonical category set across Dashboard, Transactions, and Budgets. Filter once, see it everywhere.

04 · Designing the experience

One vocabulary connected planning, activity, alerts, and control.

The structure separated Budget from Transactions while reusing categories across both. Advanced alert, payment, and security controls stayed one level deeper so the primary navigation remained focused.

The core loop: overview, detail, action, confirmation, return.

Trust and control

Bank-account access remains inside Settings rather than competing with the monthly overview.
PIN, password, and login-history controls are grouped under Security with clear labels.

05 · Testing and iteration

Three failures reshaped setup, the overview, and alerts.

The team evaluated setup, the monthly overview, the distinction between budgets and transactions, category filtering, and alert comprehension.

V1 asked for a bank link and eight budgets before showing any value

Observation: The first prototype asked participants to link a bank, set eight category budgets, and create savings goals before seeing any value. Participants stalled at the budget step.
Design response: We put the dashboard first with smart defaults. Budgets became an optional “tune later” step after the first week of data.
Result: Onboarding is a value transaction. People will not pay setup costs before experiencing the product.

V1 setup · Team

Revised · Team

Reconstructed from the team's test notes: value moved from step four to step one.

The first dashboard fragmented the financial overview

Observation: The initial layout led with a monthly spend chart and savings progress ring. Participants glanced at it, then opened their account balance.
Design response: We reorganized the dashboard around a clearer overview of savings, monthly allocation, spending progress, and upcoming obligations, reducing the need to move between multiple financial views.
Result: People open a budgeting app to answer one question first: how much do I have? The overview has to answer that before anything else.

Dashboard progression

Early low-fidelity Smart Budget dashboard — **Early wireframe · Team**Charts and modules were present, but the monthly hierarchy was unclear.

Revised Smart Budget dashboard organized into monthly spending, budget, savings, and upcoming payment sections — **Capstone final · Team**The team grouped spending, budget progress, savings, and upcoming payments in one ordered view.

Alerts were either ignored or switched off

Observation: Early alerts were too generic (“Budget update”) or too sharp (“You’ve overspent!”). One participant said they would turn notifications off.
Design response: We made alerts calm and actionable: “Groceries is at 80% with 9 days left. Here’s what’s left to spend.” We added one-tap snooze and clear settings.
Result: Alert tone is part of the UX. Alarming copy reinforces the money worry the product should relieve.

06 · Final design

A clearer monthly financial overview.

The capstone's final screens carried the team's structure: planning separated from transaction history, with alerts, bill sharing, and security one level deeper. They also carried gaps our own testing had flagged, which the rebuild in section 07 picks up.

Budget screen showing Set Budget and Split Bills cards, a Spend vs Budget row, and a monthly bar chart comparing spend against budget

All Transactions screen listing rent, car payment, groceries and utilities with amounts, category labels, and a filter control

Capstone design · Team

Planning and tracking, deliberately separated

Budgets is for planning. Transactions is a ledger. The capstone Budget screen still carried placeholder values at handoff; the rebuild (section 07) replaces them with figures derived from one data source.

Overspend Alerts settings screen with a total overspent summary and per-category cards for Entertainment, Clothing & Self Care, and Hobbies showing budgeted versus overspent amounts

Capstone design · Team

Overspend alerts, as the team shipped them

This view still led with after-the-fact totals in warning color, the tone our own testing warned against. The rebuild moved the first alert ahead of the problem (section 07).

Split Bills, custom thresholds, and security settings sat one level deeper to keep the main navigation focused.

07 · Beyond the capstone · Solo

The capstone left questions open. I rebuilt it to answer them.

The team shipped a strong concept, but our own testing left issues unresolved. Participants still went looking for their balance, and the final screens didn't fully follow the principles we'd set. After the capstone, I rebuilt Smart Budget on my own as a working prototype in Lovable, directing the build and making every design decision. Then I audited it the way I'd review a teammate's work, against usability heuristics, WCAG 2.2 AA, and internal consistency, over three rounds.

Smart Budget first build home screen showing total savings, monthly allocation, and budget progress — First build · Solo

Smart Budget home screen showing $765 left to spend this month, spending by category, and categories that need attention. — Rebuild after three audit rounds · Solo

Where the capstone left off

1. People wanted to know what they could still spend

Observation: In testing, participants glanced at the dashboard, then opened their account balance. The team's final dashboard still led with total savings, which answers a different question.
Design response: Home now opens on one number: Left to spend: $765 of $3,500, with the percentage used beneath it. Savings moved below the fold.
Why it matters: For someone on their first regular paycheck, "Can I afford this?" comes before "How am I saving?" The overview should answer the question people brought to it.

2. The interface was judging people it was meant to calm

Observation: We rewrote alerts to sound calm, but the dashboard still labeled progress "Budget Discipline" and filled overspent bars in warning orange.
Design response: "Budget Discipline" became Needs attention, and it shows only the categories near or over their limit. Everything on track stays out of the way.
Why it matters: Tone is part of every label, not only the alerts. Each one either eases money anxiety or adds to it.

3. One vocabulary on paper, several on screen

Observation: Our principle was one canonical category set, but the final screens used "Transportation" in one place and "Vehicle Expenses" in another, and three screens showed three different totals for the same month.
Design response: I rebuilt the data from a single source. There are five categories, each with one name and one color everywhere, and every figure is derived rather than typed in. Budget, Activity, and Home now agree to the dollar.
Why it matters: In a finance app, trust breaks on the first number that doesn't match.

4. Proactive alerts need proactive defaults

Observation: We prioritized warnings before problems, but the capstone's alert screens still led with overspent totals after the fact.
Design response: Each alert in Settings now explains when it fires. Upcoming Bills (3 days before) and Category Alerts (at 90%) are on by default, so the first notice comes before money runs short.
Why it matters: Most people never change a default, so the default is the strategy.

What the audits caught

Numbers that didn't agree

Three screens showed three totals for the same month. A single data source now drives every figure.

Color doing too many jobs

One orange meant 'primary action', 'warning', and 'sign out'. Now each category has one color everywhere, and warning color appears only when something needs attention.

Accessibility and layout

Zoom was disabled, toggles and legend dots fell below contrast minimums, and labels overflowed their containers. I re-enabled zoom, raised contrast above the minimums, enlarged touch targets to 44px, and labeled every icon-only button.

Across three rounds, I logged and resolved issues in data, color, accessibility, and layout.

Simplifying the structure

The capstone used five top-level tabs, including Support. I moved help into Settings, which leaves four tabs that map to four questions:

Home: What can I still spend?
Budget: What did I plan?
Activity: What happened?
Settings: How should the app reach me?

I renamed Transactions to Activity because the screen holds more than purchases. It shows income, like paychecks, alongside spending, and "Transactions" read as bank-statement language for people new to budgeting. "Activity" also pairs naturally with "Budget": one tab is the plan, the other is what happened. The planning-versus-history split from the capstone stayed intact.

Upcoming bills now appear on Home under "Upcoming this week," with a warning when a bill would push a category over its limit, so the capstone's goal of advance notice is the first thing people see.

Home: opens on what's left to spend and what's due this week, so bills are flagged before they push a category over.
Budget: every category shows spent, limit, remaining, and status in the same layout.
Activity: grouped by recency. Expense amounts are neutral, and income is green.
Settings: every alert explains when it fires; Upcoming Bills and Category Alerts are on by default.

Live prototype

Try the Smart Budget prototype

The coded prototype described above, built solo after the capstone. Tap through Home, Budget, Activity, and Settings.

Try the live prototype

08 · Reflection

Leading the research taught me to listen. Rebuilding it taught me to follow through.

On the team, my job was to turn survey and testing evidence into shared priorities. On my own, my job was to check whether the design kept those promises. Most of what I'd do differently sits in the gap between the two.

Lead with the decision the research supports: The survey made a simple dashboard the priority, and testing showed where its hierarchy still failed. On the team, those two forms of evidence stayed in separate slides. The rebuild's "Left to spend" came from connecting them, and next time I'd make that connection before the first wireframe.
Audit principles against the final screens, not only the plan: We wrote "one canonical category set" and "calm, actionable alerts," then shipped screens that broke both. Reviewing my own rebuild like a teammate's work is what caught it. I now treat design principles as a checklist to test against.
Settle vocabulary before anyone draws: Participants treated a budget and a completed transaction as different tasks. Agreeing on Budget vs. Activity before collaborative wireframing would have saved the team a round of rework.
Test the alert, the threshold, and the default together: Tone, timing, and whether an alert is on at all shape the same moment. I'd test them as one unit rather than reviewing copy separately.

Limitations

Smart Budget began as an academic capstone. The research shaped its direction, and the rebuild has passed my own heuristic and accessibility audits, but neither has been tested with users at scale.

Next steps

Test the rebuild with 5 first-time budgeters, focused on one question: does "Left to spend" replace the habit of checking the account balance that we observed in capstone testing?