User personas
Five people to design against, what each needs from a BSV product, and where each one is lost.
Personas let a team argue about a design without arguing about themselves. These five cover a wide range of the people a BSV product will meet, and each has a journey map showing where they stop.
Use them to ask "would Musa get past this screen?", which has an answer, rather than "is this clear?", which does not.
To recruit people like them, use the situation criteria on Recruiting participants, not the names.
Musa, shopkeeper
Runs a small shop. Pays a percentage plus a fixed fee on every card sale and has done the arithmetic. Not interested in the technology at all.
Wants: to keep the fee, and to be paid now rather than in three days. Fears: a customer at the counter and something not working. Lost at: anything that makes a sale slower than a card. If the till cannot say "Paid" while the customer is standing there, he will not use it twice.
Do
Design the paid state for a glance across a counter. See Hardware categories.
Peter, remote worker
Paid by clients in another country. Loses a week and a percentage to the banks in between.
Wants: to be paid without a correspondent bank, and to convert some of it locally. Fears: holding a volatile asset when rent is due. Lost at: getting money out at the other end. The transfer is the easy part; the exchange is where the cost and the identity documents are.
Do
Show where the user's money goes after your product, including the exchange step and its cost, even when another company runs it.
Ilse, privacy-minded
Does not want a phone number attached to buying a newspaper. Technically capable, and reads what she agrees to.
Wants: to pay for things without an account. Fears: a permanent public record with her name attached. Lost at: a product that collects an email to create a wallet, or that is vague about what its services learn.
Do
Say what each service your wallet uses learns, in one line. See Privacy.
Hugo, long-term saver
Holds a meaningful amount and intends to pass it on. Reads carefully, moves slowly, and will abandon a setup that needs three people at once.
Wants: protection against theft and against his own mistakes, and a plan for after. Fears: his family being unable to reach it. Lost at: a multi-key setup that cannot be saved halfway, or a backup flow that does not say what it covers.
Do
Let an unfinished setup be resumed. See Inheritance wallet.
Emma, app developer
Building something that charges per use. Has never held BSV and does not especially want to.
Wants: to take small payments without an account system or a payment processor. Fears: asking her users for too much and losing them at the permission prompt. Lost at: documentation that explains the protocol instead of the integration, or a permission model she cannot summarise to her users.
Do
Make the permission request read as part of the app it comes from, in the app's words, with the wallet's prompt as confirmation. See Connecting a wallet.
Using them
Do
Pick one as primary and say so. A product for Musa and a product for Ilse are different products, and trying to be both produces one for neither.
Do
Test against the one you are not designing for, to find where you have assumed too much.
Don't
Add a persona who already understands bitcoin and use them to justify a decision. That person exists, but they will not show you where a newcomer stops.
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.
8 rules