Spending, saving and delegating
Three ways people relate to the money in a BSV product, why each screen should serve one of them, and the bridges to build between them.
Design each screen for one state of mind. Paying for lunch, putting money aside and letting software pay for an API are three different ways the same person relates to their money. A screen that tries to serve all three at once serves none of them well.
Three states of mind
| Spending | Saving | Delegating | |
|---|---|---|---|
| What they are doing | Paying a person, a shop or an app | Holding money for later, or for somebody else | Letting software pay on their behalf |
| Time horizon | Seconds | Months to years | Set once, reviewed afterwards |
| What they want to see | Who, how much, done | What is protected, and how | What it may do, what it did, what is left |
| How risk should feel | Close to none | Deliberate, with friction where it helps | Bounded in advance |
| The wallet | Everyday | Savings | Agent |
The third column is the newest. When spending or saving, a person is present at the moment money moves. When delegating, they decided earlier and arrive afterwards. See Letting an agent spend.
Why mixing them hurts
Attention. Somebody paying for a coffee does not need their savings total. Somebody checking their savings does not need a pay button.
Risk feels wrong. A large savings balance next to a quick-pay button makes moving a large sum feel as routine as a small one. The screen's calm becomes the problem; see A calm screen can hide a dangerous action.
Everything becomes adequate. A screen built for every state of mind ends up good at none of them.
Do
Decide which state of mind each screen is for, and design that screen for it alone.
Don't
Put a savings total and a quick-pay action on the same screen. The total makes the payment feel smaller than it is.
On BSV the separation is in the keys
A layout can separate these states. A BSV product can also separate them in the wallets themselves: an everyday wallet connected to apps, a savings wallet that is not, and an agent wallet with its own keys and a fixed budget. See Wallet setups and Multiple wallets.
That makes the design question easier. A screen belongs to a wallet, the wallet has one job, and the screen inherits it.
Do
Build each state of mind on its own wallet, so the separation holds even when the interface does not. A layout can be redesigned; a key the everyday wallet never had cannot leak from it.
Build bridges, not blends
The states of mind still connect. Link them with a deliberate step, offered where it is useful, rather than one screen trying to be both.
- After a payment, show what is left in that wallet, so spending stays connected to the balance it came from.
- When the everyday wallet holds more than the person's own ceiling, offer to move the extra to savings. See Wallet setups.
- From savings, offer a top-up of the everyday wallet as a separate, deliberate action, never an automatic one.
- After an agent has worked, show what it spent, on what, and what remains of its budget.
Do
Make every move between states of mind a visible step the person takes, with its own confirmation.
Don't
Let the everyday wallet draw from savings on its own, or let an agent raise its own budget. Both turn a bridge into a leak.
Recommendation
Pick the primary state of mind for the product, and say so. A payments app is for spending, with saving as an optional layer reached by a bridge. A savings product is for saving, with a quick top-up as its one shortcut. A product that will not choose ends up with the savings total next to the pay button.
Open questions
- Does a second wallet for savings read to a new user as safety or as complexity?
- At what balance do people accept an offer to move money to savings?
Related
Written from: BRC-100, BRC-151, CRADL research on user mindsets (2022).
Checklist
The rules on this page, in a form you can work through.
6 rules