Design challenges
Ten take-home problems, each a real BSV design question with no settled answer. Four to six hours each.
Ten problems, four to six hours each. Each is a question this guide raises and does not answer, so a good solution is a contribution, not just an exercise.
Recommendation
Do them in low fidelity. The interesting decisions are about what to show and in what order, and a polished screen hides them.
1. First use
Anna paid for Tom's lunch. Tom wants to pay her back, and Anna has never held any BSV. She has just installed a wallet.
Design the flow from opening the app to Tom's money arriving. There is no funding step, no confirmation wait and no address to copy if you do not want one.
See First use.
2. The permission sheet
An app wants to spend small amounts from the user's wallet, up to 5,000 sats (about £2.50) a day, for the next thirty days. It is asking for the first time.
Design the sheet. The user has to understand what they are agreeing to, how to limit it, and how to take it back later. Then design the screen where they take it back.
We know of little prior art for this screen.
See Permissions and allowances and Connecting a wallet.
3. A hundred payments
A news app charges about 1p (20 sats) an article. Over a month, a reader gets through a hundred articles without being asked once.
Design the activity view. The reader should see where the money went without scrolling past a hundred rows, and stop it in one action.
See Charging per use and Activity.
4. Two halves of a backup
A complete backup has two halves: recovery words and the wallet backup. Words alone may not find all of the money, and the backup alone cannot spend it.
Design the flow that explains this and gets both done, for somebody who has heard of writing down twelve words and expects that to be the whole job. Then design the check that tells them six months later whether it still works.
See Backups and Backup and recovery.
5. The handle
Maya is getting a handle for the first time: something like maya@example.com, which people can pay without an address.
Design the moment it is chosen and the moment it is first shared. What do you call it? What happens when the one she wants is taken? What does she think it is?
See Paying by handle and Requesting.
6. Proving one thing
A site needs to know its visitor is over eighteen. The visitor's wallet holds a Pass from an issuer the site trusts.
Design both halves: the site's request, and the wallet's response. Nothing but the single fact should cross, and the user should be able to tell that nothing else did.
See Signing in and Identity.
7. A shared till
Three people run a market stall. Any one of them can take payments; two of them together can move money out.
Design the wallet. The conditions are visible on chain, so part of the problem is what to tell the user about that.
See Shared wallet.
8. Something went wrong
A payment was sent an hour ago and the recipient says it never arrived.
Design what the sender sees. They want one question answered before any other: did the money leave? A sent payment cannot be bumped or cancelled, so this is a communication problem rather than a control problem.
See Errors and failed payments.
9. Handing it on
A person wants their family to reach their savings if something happens to them, without giving anybody access now.
Design the setup flow and, separately, the flow the family follows years later with no help from the person who set it up. The second one is the harder design and the one nobody builds.
See Inheritance wallet.
10. An agent with a budget
An AI agent has 2,000 sats (about £1) a day to spend on a person's behalf.
Design how the person sees what it spent, and how they stop it.
See Letting an agent spend and Agent with a budget.
How to approach one
Do
Write the user's goal in a sentence before drawing anything. Most of these have a hidden second goal, and finding it is most of the work.
Do
Draw the failure path. In this field it is half the design, and in a four-hour exercise it is where the learning is.
Do
Write down your assumptions and the trade-offs you took. The reasoning is more interesting than the screens and easier to argue with.
Don't
Carry over a fee picker, a confirmation count or an expiring invoice without checking it applies to BSV.
Starting points
- The reference designs, which are the closest thing to a worked answer: Daily spending wallet, Pay-per-use reader, Connected web app and Agent with a budget.
- The Bitcoin UI Kit for components, with the caveats in Design files.
- The Glossary for what to call things on screen.
If you finish one, write it up. We know of no published attempts at any of these ten.
Related
Written from: guide reference designs.
Checklist
The rules on this page, in a form you can work through.
5 rules