Make a wallet design case study.
A useful case study shows how you made a difficult task clearer. Start with one flow and make the reasoning visible.
Choose a narrow problem: requesting a payment, understanding a pending transaction, or recovering from an expired invoice. A complete flow with careful decisions is easier to assess than a large collection of disconnected screens.
1. Write the brief in three sentences.
Name the person, their goal and the confusing moment. For example: “A freelancer sends a payment request to a client. They need to know whether the request was paid. The current screen does not explain what to do when the invoice expires.” Mark this as your proposed scenario unless it comes from research you actually conducted.
Separate the product assumptions: on-chain or Lightning, custodial or self-custodial, first-time or experienced user. Different assumptions change what the interface must explain.
2. Study a relevant reference.
The Bitcoin Design Guide covers user flows, research, accessibility and Bitcoin-specific considerations. Pick the sections relevant to your scenario. Use the Bitcoin UI Kit to speed up prototyping, while crediting reused components and following the license.
Write down what you reuse, what you change and why. A kit provides components; your case study should make your own reasoning visible.
3. Design the entire small flow.
| Moment | Question your design should answer |
|---|---|
| Create a request | What amount and unit am I asking for, and can I check it before sharing? |
| Share it | What gets copied, and how do I know the action worked? |
| Wait | Is the app waiting for payment, checking a status, or offline? |
| Finish | What confirms the result, and where can I find it again? |
| Recover | What changed, and what can I do next without guessing? |
Include readable labels, visible focus, sufficient contrast and layouts that survive long amounts or translations. Do not use color alone to distinguish paid, pending and failed states.
4. Test a question you can answer.
Prepare a short task script: “Request payment for this item, share the request, then explain its current status.” Ask participants to describe what they think happened. Use a prototype with fictional amounts and test data. Obtain their agreement before recording or publishing any session material.
If you do not run user sessions, publish a heuristic review and a proposed research plan. Do not invent participants, completion rates, quotes or commercial outcomes. Record uncertainty as part of the work.
5. Tell the portfolio story.
- Context: the user, task and product assumptions.
- Your role: what you personally researched, designed and tested.
- Alternatives: two plausible directions and why you chose one.
- Evidence: annotated flows, prototype and actual observations.
- Iteration: what changed after feedback and what remains unresolved.
Finish with a handover note: component states, content rules, loading and error behavior, and questions for engineering. This makes the work useful to a team as well as attractive in a portfolio.
To contribute the work publicly, read the Bitcoin Design community’s participation information and understand an existing project before proposing a redesign.
Keep the evidence.
Download a worksheet to record what you tried, what happened and what you would improve.
Download evidence worksheet ↓