What people call things
Four methods for testing a product's words with the people who will read them, and a template for testing the guide's own vocabulary: handle, Pass, allowance, recovery words, connect and sats.
This guide chose its words by reasoning, not by testing. "Handle", "Pass", "allowance", "recovery words", "connect" and "sats" are in the vocabulary table because they seemed the clearest available. Each one is a hypothesis about what people will understand.
Four methods test words, each answering a different question. Use the one that matches what you need to decide.
Interviews give you a fifth source for free: the words participants use unprompted. Interview guides says how to collect them without leading.
| Method | Answers | When |
|---|---|---|
| Open card sort | What do people group together, and what do they call the groups? | Before naming a section or menu |
| Tree test | Can people find a thing by its label alone? | Once a structure exists |
| First-click test | Where do people look first for a task? | Once a screen exists |
| Comprehension check | What do people think a word or button will do? | Any time, on any screen |
Open card sort
Give participants cards, each naming one thing the product does, written in plain description rather than in your terms: "Give an app a daily budget it can spend without asking", not "Allowance". Ask them to group the cards in whatever way makes sense and to name each group.
The group names are the finding. If six people put the budget card in a group they call "Limits" and nobody uses "allowance", that is evidence about the word, not just the structure.
Do
Write card text as a description of what the thing does, never using the term you are testing.
Do
Record the exact names participants give their groups, including spelling, before tidying them into themes.
Tree test
Give participants the product's menu structure as plain text, with no design, and a set of tasks: "Where would you go to stop an app taking money?" Record the path they take and where they end up.
A tree test isolates the labels from the layout. A label that fails here will not be rescued by a good icon.
Do
Test the menu labels as plain text before they are designed, so a failure points at the word and not the visual.
First-click test
Show one screen and one task, and record where the participant clicks or taps first. The first click shows whether the labels send people the right way before anything else on the screen can help or hinder them.
Use it on screens where the vocabulary carries the decision: a home screen with "Send", "Request" and "Connect", or a settings screen with "Recovery words" and "Backup" side by side.
Do
Run a first-click test on the real screen size the product ships at; a label that works on a desktop mock can fail on a phone.
Comprehension check
The simplest and most direct method. Point at a word or a control and ask: "What do you think happens when you tap this?" Then: "What do you think this word means here?"
Do it before the participant has used the thing. Once they have tapped it, they know.
Do
Ask what a control will do before the participant uses it, and record the prediction word for word.
Don't
Explain a term and then ask whether it is clear. Every explained term is clear to the person who has just had it explained.
Don't
Offer a choice of meanings ("does this mean A or B?"). It hands the participant an answer they would not have reached.
The guide's vocabulary, as hypotheses
| Word | What the guide means | What would contradict the choice |
|---|---|---|
| Handle | A readable name that resolves to someone's wallet, like anna@example.com | Participants read it as a username only, or expect it to log them in |
| Pass | A signed statement from an issuer, revealing only what is needed | Participants expect a Pass to be a ticket, or think it reveals everything |
| Allowance | A budget an app may spend without asking each time | Participants read it as money already handed over, or as a balance |
| Recovery words | The words that restore the wallet's keys on a new device | Participants think the words restore everything, or are a password |
| Connect | Letting an app ask the wallet to act, without handing over keys | Participants believe the app now holds or can see all their money |
| Sats | The unit payments are made in, shown beside local currency | Participants cannot say whether 2,000 sats is a lot or a little |
See Amounts and units for why satoshis are the default and local currency leads, and the glossary for each term in full.
Do
Test each word in the context where it appears in the product, not as an isolated vocabulary list.
Do
Test a candidate replacement alongside the current word with different participants, so nobody sees both and compares.
Recording template
One row per participant per word. Keep the participant's words exactly; interpret in the last two columns.
| Participant | Word or control | Method | Shown in context | Their words, verbatim | Matches intended meaning? | Notes |
|---|---|---|---|---|---|---|
| P03 | Allowance | Comprehension check | The Satoshi Vision prompt | "So that's how much they've taken off me?" | No: read as spent | Newcomer; did not scroll |
| P03 | Connect | First-click test | Pixel Arcade home | Tapped "Connect" first | Yes | |
| P04 | Recovery words | Comprehension check | Wallet settings | "The password for the app, I think" | Partly | Has a banking app |
The rows above show the format, with invented answers. They are not findings.
Open questions
- Whether "Pass" is understood without a picture of one is untested.
- Whether showing sats beside a local-currency price helps people judge it, or whether they ignore the sats entirely, is untested.
- Whether "connect" sounds safer or riskier than what it grants is the question most worth a comprehension check.
Related
Written from: Content guidelines vocabulary table, Amounts and units, Glossary, open card sorting, tree testing, first-click testing, comprehension testing.
Checklist
The rules on this page, in a form you can work through.
9 rules