Getting to know your users
What moves people towards a BSV product, what stops them, and which barriers to design against first.
People do not adopt a payment technology. They solve a problem with it, or they do not.
This page lists what moves people towards a BSV product and what stops them, so you know what to design against first.
What actually motivates people
In rough order, from the adoption research we worked from (see sources). Test the order with your own users:
Something cheaper. A shopkeeper losing 3% plus 30p on every sale has a number in front of them. This is the strongest motivator in the list.
Something that works where the current thing does not. Being paid across a border, selling something a card processor refuses, taking money without a bank account.
Getting paid fully and immediately. No held funds, no chargebacks, no waiting three days.
Not having to hand over personal data. Genuine, and broader than it looks: plenty of people who have never thought about privacy would rather not give a phone number to buy a newspaper.
Ideology. Real for a minority, and rarely the reason for anybody else. Designing for it is how products end up speaking only to people who already agree.
Do
Lead with the concrete benefit for the person in front of you. "Keep the 45p the card company takes on a £5 sale" beats any sentence containing the word sovereignty.
What stops them
The same research suggests this order, from the barrier that stops the most people to the one that stops the fewest.
Fear of losing it. First in the order, and a rational fear: there is no password reset. Every backup and recovery decision in this guide exists because of it.
Not knowing how to get any. The exchange, the identity documents, the waiting. Many people stop here and never come back.
Nobody to pay. A payment method nobody accepts is a curiosity.
Price movement. A reasonable worry. The honest answer is that BSV is not where to keep next month's rent.
Reputation. Years of scams and collapses attached to the word crypto. Arguing with this does not work; being obviously different does.
Technical difficulty. Last in the order. People manage complicated apps every day. What they will not tolerate is a complicated app that might lose their money.
Fear of loss comes first and difficulty last, so recovery deserves design effort before onboarding polish does.
Recommendation
Test recovery before you polish onboarding: confirm a new user can restore their wallet on a second device before refining the first-run screens.
Two kinds of barrier
Everything that stops somebody is one of two things:
- Material: friction in the product itself. What it costs, how long it takes, how many steps can fail.
- Conceptual: not knowing what something is, or what will happen when they press the button.
On BSV most of the material friction inside the product is gone before design starts. Getting BSV in the first place is the exception. A payment costs less than 1p. It is accepted when the recipient's wallet verifies it, not after a wait. An app asks the wallet to act instead of being handed keys, and there is one network to be on. What is left is almost entirely conceptual: what a wallet is, what a backup covers, what a permission grants, and what cannot be undone.
That changes where the work is. A fast, cheap flow is not necessarily an understood one.
Do
Count the ideas a person has to hold to finish their first task, not just the steps. Each new idea is a place they can stop.
Don't
Treat speed as comprehension. Removing friction removes the reason to stop; it does not answer "what did I just do?"
A calm screen can hide a dangerous action
Polish lowers people's guard. A payment to an address on the wrong network, a permission with no end date, or a large sum leaving the everyday wallet can look exactly as gentle as paying for a coffee. On a well-designed screen it often does.
Do
Let the weight of a confirmation follow its consequence: whether it can be undone, how large the amount is against what the wallet holds, whether the recipient is new, and whether it grants something that keeps working after today.
Don't
Use one confirmation style for everything. People learn the shape of "confirm" within a week and stop reading what is inside it.
Where your users are coming from
Three starting points, each needing a different product:
| Already has BSV | Has used another network | New to all of it | |
|---|---|---|---|
| Needs | A better product | Plain statements of what to expect: no fee to choose, no wait | A reason, then a route in |
| Biggest risk | They already have a wallet | Carried-over assumptions | They never get any |
| What to build | Interoperability | Clear statements of what differs | A path that does not start at an exchange |
Do
Decide which of the three you are for, and say so. A product aimed at all three serves none well.
Don't
Assume somebody who has used another chain understands this one. They will look for a fee picker, wait for confirmations, and assume their recovery words work here. See Legacy compatibility.
Open questions
- Does the barrier order hold for people who arrive through a merchant rather than a friend?
- Which single explanation most reduces fear of loss: recovery, or the limit on what the everyday wallet holds?
Related
Written from: BRC-151, published wallet usability research, CRADL adoption research (2022).
Checklist
The rules on this page, in a form you can work through.
8 rules