A Personal Finance Manager for TD's mobile app: budgeting, automated savings, and transaction clarity. Built by a small team, validated through multiple rounds of user research.
What increment do you want to round up?
Jay Frank · Principal Product Designer / Strategist
A new way to round up. Control the amounts you save with spare change on purchases
What increment do you want to round up?
See what is coming before it happens.
Next 2 weeks
There is a line people put in Einstein’s mouth: given an hour to solve a problem, spend fifty-five minutes on the problem and five on the solution. I cannot source it to him. I went looking and it is not there. I use the ratio anyway, and honestly the fact that I checked is the more useful half of the story.
Who the customer was, what the bank believed, and what the research actually found. The person every budgeting tool on the market broke on. The two decisions where we tested a real alternative.
The product itself, every decision inside one control, the measured results, the honest ending: it was defunded before launch, and how the work reads from the seat you are hiring for. The final four are an appendix, and I will tell you when it starts.
A problem well stated is a problem half solved.Charles Kettering, head of research at General Motors. That one is attributable.
TD's Payments organization set out to build personal financial management into the bank itself: one place where budgeting, savings, and spending clarity live next to the money instead of in a third-party app. Our team owned the experience from discovery through validated design. Through open banking, the picture is not limited to TD: customers connect accounts held anywhere, so the snapshot, budgets, and spending insights cover all of their money, not just the part that sits with us.
Spend insights · all accounts, TD and connected
About 14 months, discovery through validated design and patent filing.
Two product designers, an HCD research lead with two researchers, product, engineering, content strategy.
Inside TD's existing mobile app, iOS and Android, on the bank's design system.
Research was a shared resource. The design system had gaps. Every number on screen went through review. Then the program was defunded.
The HCD team I led co-created the product end to end with our business partners and other lines of business: shared flows, daily critique, one system with all of our fingerprints on every screen. Alongside that shared design work, four lanes sat with me.
Research at a bank is a shared resource, so our HCD research lead and I made the case together and got dedicated researchers. We also did not start from zero: Payments already held prior study reports and running customer research diaries. We mined those first, so our own discovery began where the bank's existing knowledge ran out.
Every idea stayed on the board · Tested: recommended budget, built from 6 months of transactions
Publicly published TD research on both sides of the border, stories.td.com and td.mediaroom.com, plus one cross-border study, Gallup with Edward Jones, Money and Meaning, 2026. Our own discovery, two years earlier, found the same shape.
Do people want it? Proven in discovery, then re-proven in every testing round.
Can we build it? The lead engineer sat in every scoping session.
Should the bank fund it? The activation metric and the business case.
Overdrafts were the fear, and budgeting was the only tool on offer. Budgets died at setup: the effort wall killed them before any value showed up, so the anxiety stayed.
People wanted effortless saving, but not surrendered control. Automation alone was not the answer. RoundUp+ was: every purchase saves, at an increment they set.
Money lived across too many accounts and apps. No single surface answered "am I okay?"
The three quotes above came out of our own interview rounds, nearly word for word. They became the product's job description.Discovery interviews and surveys
Week-one activation as the leading indicator, with budget setup completion, savings opt-in rate, and return visits per month underneath it. The business case behind them: deposit growth and retention. Every number later in this deck maps back to one of these.
29 · shift lead at a regional grocer, plus weekend delivery work · TD chequing, TD credit card, one outside savings account
"Every app wants me to say what I spend in a month. I don't know what I make in a month."
Click a card for what sits behind it
A composite built from the interview and survey base, not a single participant. Gig and shift workers were the group our concepts had to earn.
The research and the persona came into the room with us. Same gauntlet for every candidate: open questions, ideas, concerns, competitor evidence, then MVP questions and a committed feature list. If it did not work for someone paid like Dana, it did not survive.
Click any column to see where it landed in the product
The gauntlet, left to right. Click a column to focus it. Only what reached Committed went into design.
The alternative on the table: the industry default, round every purchase to the nearest dollar. Simple to build, simple to explain, and already proven elsewhere in the market.
What I proposed instead: the customer sets the increment, anywhere from $1 to $20, with a custom value underneath that.
The alternative on the table: the spec as written, a single enrollment form of fifty to sixty questions. Cheap, one screen, uses components that already existed.
What I proposed instead: ten conversational steps, one decision each, encouragement between them. New components, more build cost.
Agreed before either test ran: opt-in rate under a control condition, completion of setup, and build cost against enrollment return. Naming the criteria first is what stops a preference test from becoming an opinion contest.
One product partner on the enrollment flow, in those words: “nobody is ever going to use that.” I brought drop-off data and competitor patterns. When the argument stalled, I stopped arguing and called the test.
The increment picker. It cost new components and a longer build. Every round said the same thing, so I held it and framed the cost as investment against enrollment, which is the language that funded it.
Customization was my instinct. I never asked the team to take it on faith. We put it in front of users every round, and the evidence is what carried it, not my argument.The rule I work by when the idea is mine
Every candidate had to answer one of the three jobs from our interviews. Anything that did not was cut.
The lead engineer sat in every scoping session, so build cost was named in the room, not after commitment.
Nine MVP milestones sequenced against the Payments roadmap, with several patents filed from the work.
The five we committed to first: MVP 1 across all three pillars, plus the one-tap starter budget and savings goals pulled forward from MVP 2 because testing proved they mattered.
Every screen in these flows is rebuilt from the concept evaluation file. Click a pillar to slide the real flow in.
Nothing carried by color alone: every over-limit state pairs the red with a label and a value. Type held to the bank's minimum sizes, targets at 44px, and the whole loop tested against WCAG 2.1 AA contrast before it went into a round.
What happens when income is irregular, a goal is missed, a connected account drops, a round-up would overdraw the chequing account. Every one of those got a screen, because the participants who broke the flow found them first.
TD's design system where it served us, new patterns where it had gaps: the budget-to-savings recalculation, the increment picker, and the goal pace control were built and contributed back.
You already touched this one. It is the real component, not a picture of it. Three decisions sit inside a control most people would have shipped as a toggle.
What increment do you want to round up?
Live · the real control, same as the cover · try an increment or a custom amount
The interface never offers a move the system cannot honor. That rule is why the overdraw case has a screen instead of an error.The constraint we designed against, in a domain where the money is real
A slider at money granularity is a precision problem solved with a thumb on a moving train. Four discrete increments answer almost everyone in one tap.
Custom is the fifth option, and the stepper does not exist until it is chosen. The few who want $14 get $14; the rest never read past it.
The worked example and the yearly projection recalculate the instant the increment changes. Nobody commits to an automated money rule on faith; the outcome stays on screen while the decision is still reversible.
One snapshot aggregates every account. Spend insights layer category breakdowns, month and year comparisons, and custom ranges beneath it. Same screens, two depths: glanceable defaults for set-and-forget users, drill-downs for fine-tuners.
To avoid going over and remain on your budget we have noticed that in the last three months, you average $300 less than what you budgeted for lifestyle. However, you also go over $300 in your housing. We have offset the differences to help you maintain your budget.
Goal setup was specced as one long enrollment form, fifty to sixty fields of paperwork. I rebuilt it as ten supportive steps: one decision per modal, encouragement between steps, and a finish line you can see. People organizing their money are already stressed. The interface should cheer, not interrogate.
"Nobody is ever going to use that." One product partner held the line for the form, so I called the test: twenty participants, A/B, and twenty of twenty chose this flow. It won its place in the validated build. PFM never launched, but the pattern is tested and specified, so when this rolls out again, onboarding starts finished.The real screens from the Figma file, shown here
Four findings kept proving true across every round, and each one became a design change we could measure. One user model sat underneath all of them: set-and-forget people and fine-tuners, and nothing could punish either. Click a card for the evidence.
A draft budget generated from the user's own spending history, editable from there.
median time to finish budget setup in the first tested build
after the one-tap starter budget, built from real transaction history
setup was named as the reason to quit, in every testing round we ran
My concept: fixed nearest-dollar round-ups tested against increments the customer sets, from $1 to $20.
participants who could set the increment turned it on; those given a fixed rule refused it
my design, and the basis of one of the patents filed from this work
Customization was my instinct, but I never asked the team to take it on faith. We put it in front of users every round, and the evidence is what carried it, not my argument.
Merchant logos plus plain labels, like turning "WF Mortgage" into "Home Loan."
the single most common source of confusion in transaction review
our content strategist rewrote transaction copy off the back of this finding
people who could not read a charge stopped trusting the whole balance
Notifications rewritten as gentle nudges, data requests explained in plain language.
red overspend warnings made people close the app rather than open the budget
saying why we needed a data connection raised willingness to link outside accounts
the softer tone brought people back more often, which is the whole activation game
What comes next is what we could prove, not what we hoped. Measured outcomes are what make a project like this hold its value: the product did not ship, but the evidence did, and it is already paying for whatever comes next.
Click a number for how we measured it. The gold line is what each result is worth, modeled on slide 19.
Activation metric we defined: connect one outside account and set one savings rule within the first week. In follow-ups the ones who did showed nearly three times the intent to keep going, the signal we would have proven at launch.The would-be north star
Read it as: uptake is slow for the first six months, steepest between months 6 and 14, and flattens once the interested customers have signed up. The shaded area is the gap between the two cases, which is the range we would actually be arguing for.
Activated means they linked one outside account and set one savings rule. Same product, same customers: doing that in the first seven days makes a customer three times as likely to still be here six months later. That is why week-one activation, not sign-ups, became the metric we defined.
Two scales, both modeled and labeled that way in the room. Bank scale: Visa's assessment and the committee model, built for TD. Cohort scale: our research signals on public benchmarks, 1 million offered, 318,000 enrolled. The committee model builds on Visa's savings automation line, so the $3.4 to 4.0B cover total is an upper bound. Every formula and source: the last page of this deck.
User-set round-up increments, and the budget-to-savings reallocation loop with the goal recalculation that follows it. Several of the six patents I have filed to date came from this work. The reallocation loop became the filing modeled for TD's IP committee at $835M to $1.5B over three years against a $10 to 20M build.
Three things, and they are all the same mistake: I proved the design worked long before I proved it paid.
The business case slide you just saw is the argument I should have made a year earlier. I now treat the business narrative as a design deliverable.Honest hindsight
Three problems took most of this runway: hard rules the interface can never break, trust in automation that has to be earned one control at a time, and a first week designed on purpose. Every product I have worked on since has had all three, inside banking and well outside it. The next slide reads the same work from the seat you are hiring for.
Your budget change will affect your end date. If you want to cut cost, you can view our recommendations so you can keep your goal on track.
Patent-pending · edit any input and the goal recalculates live, then the product recommends the budget moves to recover the date
The seat changes what you look at. The work does not. Here is what to pull from this case study depending on the role you are hiring for, and where in the deck it lives.
One control taken three levels down, edge cases that each got a screen, WCAG 2.1 AA before any round went out, and every tested build through my file.
Clear lanes inside one team, a research muscle built before the product, criteria agreed before either test ran, and a stakeholder fight settled by evidence rather than rank.
The bank's system where it served us, new patterns contributed back where it had gaps. In the appendix, a system I own end to end: tokens aliased in Figma and consumed by the code.
Automation people actually turn on: control before automation, the consequence shown before the commit, and a recommend-then-recalculate loop that keeps the person deciding. Then a product built by 19 agents I direct.
PFM lived inside a brand set before I arrived. Hello Court is a brand authored from nothing, and this deck is itself an interactive build with the real components embedded in it.
Three lenses held from discovery to the business case, a week-one activation metric the research produced, and a modeled case I now treat as a design deliverable.
The same three problems: hard rules the interface can never break, trust in automation that has to be earned, and a first week designed on purpose. Regulated or not, consumer or enterprise, that is the work.
PFM is the case study. What follows is not a second one. It is evidence for two things PFM structurally cannot show, however recent it is. One, a brand I authored from nothing: at TD I designed a great deal from scratch, but always inside a palette, type and principles set before I arrived. Two, a whole product I built and run end to end: the systems, the security, the agents and a working app, not just the screens.
The honest part first, before you ask. Neither of these has launched. Hello Court is fully built and functionally tested and it is the one I am carrying forward. Quorum I paused deliberately to make that possible. I am showing you craft and systems, not adoption numbers.
Hello Court’s planning room is not a deck about the work. It is a live site I designed and built, generated from the work itself: 65 pages across 13 sections, behind an access code I share with employers, collaborators and investors.
A Python pipeline I wrote renders every page from one style source. The data pages read sprint status, the time log and git history at build time, so the site cannot drift from the work it describes.
Planning, case study, team, design system, data, SEO, security, prototype, journeys and a change log. Each one is the real working artifact, not a summary written after the fact.
Where something is unfinished, the page says so. Showing the room mid flight is the point: decisions get revisited and the counters refresh on every rebuild.
8 independent reviews, 6 tools run against the code. Every finding is published with its impact and status, never the exploit path.
Secret scanning, SAST, dependency and supply-chain, recon and vuln scanning, OWASP Top 10 and access-control review, plus an edit-time tripwire on risky patterns. The full kit stays private by design.
One day in June took the site from one indexable article to a 49 page library. Three weeks later: 50 pages indexed, 272 queries, and the first clicks, including a searcher who looked up a Georgia statute and landed on the Georgia guide from page one.
The product is built by 19 agents I direct across desirability, viability and feasibility, over a research bench of 411 AI personas across all 50 states. The page says it in bold: AI personas, not lawyers, and none of it is legal advice.
Published as a living section of the site and mirrored into Figma variables: foundations, 15 components and 3 interaction patterns, documented with the same tokens the code consumes.
The Figma file carries 67 Color variables plus Radius and Spacing collections. A component consumes a semantic name, accent, surface, danger, and that name aliases to a primitive, so one edit moves the whole system. Design file and running product cannot drift.
An ADA AA audit sits in the foundations beside type and color. Every pairing is verified for WCAG AA in both modes, and sage text on light is pinned darker to clear 4.5 to 1.
Every app screen is built from component instances, zero detached copies. Anything with a hover, a load or a transition has a live preview: if you cannot watch it move, it is not specified.
The first entry in the color changelog reverses a decision I had defended: danger moved from amber to red, so danger reads as danger. A system that can overrule my taste is the proof that it is a system.
One decision per screen. Save and exit always there. English and Spanish from the first tap. A ten step intake that meets a frightened person in plain language, then a case home that always answers: what do I do next.
Quorum is an AI deliberation tool for boards and executive teams. Next.js 16, React 19, Prisma, real auth, Playwright end-to-end tests, and a design-system route that lives inside the application rather than in a separate file that drifts away from it.
The second production-grade build, and it shows the pattern I work in: the system is not a document about the product, it is a route in the product. Design and code are the same artifact.
Two products, one person, and both getting a fraction of what they needed. I picked the one with the larger problem and the clearer user, and I stopped the other. It was the right call and it was not a comfortable one.
I have spent years at senior and director level, in the rooms where roadmaps get funded: executives, partners, vendors, and the tradeoffs between them. That is unusual for a designer, and it travels to any seat. It does not make me a better designer than the people already on your team. It makes me an easier partner for them, because I can carry the stakeholder conversation without anyone having to translate the work first.
The seat can be an individual contributor or a lead, and the loop is the same. Give the team a direction on Monday and there is a testable prototype by Thursday: UI, interaction, edge cases, accessibility, and evidence in the room. Leading, I run that loop through the team, set the criteria before the test, and clear the stakeholder path. When the business case is what is missing, I will write it, and the credit stays with the people who built the work.
Jay Frank · Principal Product Designer / Strategist · Thank you
Two models built for TD, added together. Both are modeled, not booked; PFM was defunded before launch.
| Component | Low | High |
|---|---|---|
| A. PFM MVP revenue lift (Visa, 2022) | $2,518M | $2,518M |
| B. Patent filing 1, three years (committee, 2025) | $835M | $1,500M |
| Total | $3,353M | $4,018M |
Caveat: the committee model cites Visa's savings automation line as evidence for its deposit growth, so A and B overlap in part. Treat the total as an upper bound. Visa's horizon is not stated on its slide; the committee figure is three-year cumulative.
Built for TD to rank the MVP features across credit, debit, checking and savings. Slide 12, 2022, Visa Confidential. Reviewed with the team Jan 31, 2023 (source file timeline).
| Capability | Checking | Savings | Total |
|---|---|---|---|
| 1.0 Holistic financial summary | $349.8M | $219.2M | $669.8M |
| 1.1 Account aggregation and visualization | $306.5M | $195.3M | $542.6M |
| 1.2 Customizable visualization | $23.4M | $12.6M | $68.1M |
| 1.3 Upcoming transactions | $19.9M | $11.3M | $59.2M |
| 2.0 Budgeting | $464.3M | $289.9M | $868.8M |
| 2.1 Budget creation and monitoring | $219.1M | $148.4M | $415.9M |
| 2.2 Budget customization | $25.6M | $13.0M | $72.1M |
| 2.3 Forecasted spend insights | $219.6M | $128.5M | $380.7M |
| 3.0 Savings | $534.6M | $333.7M | $979.5M |
| 3.1 Savings customization | $167.5M | $96.6M | $290.5M |
| 3.2 Savings automation (round-ups) | $346.1M | $225.5M | $620.8M |
| 3.3 Savings optimization | $21.0M | $11.6M | $68.2M |
| All three capabilities | $1,348.7M | $842.8M | $2,518.1M |
Totals include credit and debit columns not shown here (credit $117.2M, debit $209.4M). Visa's caveats, quoted: checking and savings portfolio size factors heavily; revenue impact does not factor in costs or time to implement; a feature's impact may double count another's.
Automated Adjustment of Visual Elements in a Personal Financial Management System. Filed through TD Invent; 2025 Visionary of the Year finalist, one of three bank-wide. Modeled for the Intellectual Property and Ideation Committee, Nov 2025. Not audited results.
| Component, three years | Low | High |
|---|---|---|
| Deposit and investment growth | $420M | $850M |
| Cross-sell revenue | $180M | $360M |
| Service-cost savings | $35M | $70M |
| Retention and lifetime value | $150M | $300M |
| Total | $835M | $1,500M |
| Build cost, once | $10M | $20M |
| Operating cost a year | $5M | $7M |
| Value to build | 42× | 150× |
Inputs as submitted: managed deposit uplift +5 to 10%; digital cross-sell conversion +15 to 25% (JD Power, BCG, BAI benchmarks: satisfaction up 20% lifts cross-sell 15 to 25%); digital interaction about $0.10 against $4.00 in a branch or call centre; digital transformations lifting bank revenue about 31%; Visa's savings automation line as the deposit evidence, discounted. Adoption ramp 20 to 30% to 50 to 60% over three years.
1,000,000 customers offered; 318,000 enrolled at month 24 expected, 174,000 conservative (slide 19 curve).