Conducting research
Where to start a study of a BSV product: the three constraints money adds, the questions worth asking, what to test, and how to keep participants' finances private.
Three constraints separate research on a money product from ordinary product research: you cannot let people lose real money, the easiest participants are the wrong ones, and the flows that matter most are the hardest to set up.
This page covers all three, then points to the pages with the detail: who to recruit, interview guides, test plans and a write-up template.
The three constraints
You cannot let people fail with real money. In most products a failed usability task ends with a shrug. Here it can end with somebody's savings gone. Test with worthless funds on a test network, and say so clearly, because a participant who thinks the money is real will behave differently.
This rule is about the participant's own money. If a study needs real stakes, give the participant a small amount from your research wallet that they keep whatever happens.
Your participants are not your users. The people easiest to recruit are already in the ecosystem, and they are rarely the people you are designing for. A test with somebody who already owns a wallet tells you little about somebody who does not.
The failure paths are the product. Recovery, a wrong recipient, a lost phone, an app asking for too much: these are the flows where money is lost. They are also the ones teams skip, because they are awkward to set up.
Do
Script the failure paths into every study. "Your phone is gone and you have this piece of paper. Get your money back" is the task most likely to show you where your product loses people's money.
Who to recruit instead, with a screener, is on Recruiting participants.
Questions worth asking
Ask about behaviour, not opinion:
- How do you pay people now, and what annoys you about it?
- Where is your money, and what would you do if your phone disappeared?
- Has anything ever been blocked, frozen or delayed? What happened?
- What would make you stop using an app that held money?
Two full discussion guides built on these questions are on Interview guides.
Don't
Ask whether somebody would use bitcoin. The answer is about identity rather than behaviour, and it predicts nothing.
What to test, and how
| Flow | What you are looking for |
|---|---|
| First use | Where they stop, and what they were asked that they could not answer |
| Receiving | Whether they understand they have been paid |
| Sending to a new recipient | Whether they check anything before confirming |
| A permission request | Whether they read it, and what they think they agreed to |
| Recovery | Whether they can, at all, without help |
| Backup | What they believe is backed up, and whether it matches what is |
Three of these flows are written up as runnable plans on Usability test plans.
Do
Ask participants to say what they think just happened, after each step. The gap between what the interface did and what they believe it did is the finding.
Privacy in research
Research on money carries a heavier duty of care, because the material is financial and can be permanent.
Do
Use test funds, test identities and a test network, or a small amount of your own that the participant keeps. Never ask somebody to connect a wallet holding their own money.
Do
Say what you will record, and never capture real recovery words, even accidentally, in a screen recording.
Don't
Keep more than you need. A research archive containing people's real financial behaviour is a liability.
Research that already exists
Before running a study, check whether the question has been answered. Published research on wallet onboarding, recovery and terminology mostly applies whatever the network. See Published research.
Do
Publish what you find. The ecosystem is small and most of the useful research in it does not exist yet. See Open design.
Writing up findings has a template.
Related
Written from: published wallet usability research, Getting to know your users.
Checklist
The rules on this page, in a form you can work through.
7 rules