Usage life cycle
From never having heard of it to using it without thinking, what each stage needs, and where people actually drop out.
Design for every stage of somebody's relationship with a product, because each stage needs something different. Treat a first-time user and a daily user the same, and the product patronises one and baffles the other.
The stages
Unaware
Has not thought about it. Reached only through somebody they already trust, or a problem they already have.
Needs: nothing from your product. This stage is won by a shopkeeper, a friend, or a service that will not take their money otherwise.
Aware
Has heard of it, probably alongside a story about a scam or a crash.
Needs: a reason that is about them, and evidence that this is not another scam. Concrete beats ideological: the fee, the speed, not needing an account. See Getting to know your users.
Interested
Considering it, and looking for the catch.
Needs: honest limits. A page that says what this is not good for persuades better than one that does not, because it tells them you are not selling.
First use
The stage where products most often lose people, and much of that loss is avoidable.
Needs: a wallet in seconds, no questions they cannot answer, and a way to get some money that does not start with an identity document.
Recommendation
We suggest two causes to check first: being asked to choose a key scheme, and having nowhere to get any BSV. The first is yours to fix. See First use.
Repeat use
Has used it more than once and is deciding whether it is part of their life.
Needs: speed, contacts so they never type a handle twice, and a backup prompt at the point the balance is worth protecting.
Habitual use
Uses it without thinking. The stage products tend to neglect, because the people in it have stopped complaining.
Needs: to get out of the way. Fewer taps, better search, an activity list that is still readable after a thousand entries. See Activity.
Don't
Keep showing onboarding hints to somebody on their hundredth payment.
What somebody has to know
To make a first payment safely, a person needs to understand four things:
- The money in the wallet is theirs, and only they can move it. Not how keys work.
- A payment cannot be called back once it is sent. Not why.
- The backup has two parts, and both matter. Not how keys are derived.
- BSV is the name of the network. Money sent to an address on a different network is usually gone. See Wrong-network payments.
What they do not need: fees, because less than 1p is not a decision; waiting for confirmations, for everyday amounts; key schemes; and addresses, because they share a handle.
Do
Teach each of the four at the moment it first applies: ownership when money first arrives, irreversibility on the first review screen, the backup when the balance is worth protecting, the network name wherever somebody pastes an address.
Don't
Teach what the product can take care of for them, such as fees or key schemes. Every concept taught before it is needed is a reason to stop.
Learning by holding something
People learn what a wallet is by having something in one. A tutorial about wallets teaches little; a real payment arriving teaches the whole idea at once.
On BSV the first real thing can arrive almost free. A friend sending a thousand satoshis pays less than 1p in fees, and an app can sell one article for a few satoshis. The first task can be owning something, rather than reading about it.
Do
Make the first thing a new user does end with them holding real money: received from a person, or spent on something they wanted anyway.
Don't
Build a practice wallet or a simulated payment in place of a real first receive. It teaches the user that the real thing is somewhere else.
Arriving through somebody
Many people do not find this alone. A friend shows them, a shop asks for it, a colleague pays them. The person bringing them in is part of the onboarding, whether the product designs for them or not.
Do
Design for the person doing the introducing: a handle they can share, a payment request they can send, and a first payment that says who it came from. See Contacts.
Checking your onboarding
Four checks for a first-use flow, made after watching somebody go through it:
Do
Get a new user from opening the app to holding money in one sitting, without leaving the app except to ask somebody to pay them.
Do
Give every setup step a way back. A mistake during setup should cost a tap, not the wallet.
Do
Ask the person, after a test, to explain to a friend what they just did. What they cannot explain did not land.
Do
Measure where people stop, step by step, and work on the worst step first. A whole-funnel number tells you there is a problem and not where it is.
Dropping out
People leave at every stage, for different reasons. This table is our reading of the research in the sources, not a measured result; check it against your own funnel.
| Leaves at | Usually because |
|---|---|
| Aware | No reason that applies to them |
| Interested | Could not find an honest answer about the risk |
| First use | Asked something they could not answer, or could not get any |
| Repeat use | Nobody to pay, or a frightening moment with no explanation |
| Habitual | A loss, or an update they did not understand |
Do
Design the "frightening moment" explicitly. A payment that looks stuck, an unexpected balance, an app asking for something alarming. One clear explanation at that moment can keep somebody who would otherwise leave.
Open questions
- Does a real first payment teach more than a guided tour for people who arrive with no one to pay them?
- At what balance do people treat a backup prompt as useful rather than alarming?
Related
Written from: published adoption and retention research, CRADL onboarding research (2022).
Checklist
The rules on this page, in a form you can work through.
12 rules