Working checklist
Wallet UX review checklist
Review the prompts, permissions, states, and support boundaries of a wallet-connected application.
How to use this review
Work through the steps with the person responsible for the relevant decision. For each item, record the answer, supporting evidence, owner, and unresolved questions in your own review notes. This page does not store responses or mark the system as approved. Use your browser's print dialog for an offline copy, or download the plain-text version below.
- Inventory every wallet prompt
For every button that opens a wallet, record the requesting application, operation, authority, and expected outcome. Connection, message signing, spending approval, and transaction submission should not be disguised behind the same unexplained action label. Verify that the prompt matches what the preceding screen promised.
- Show the relevant identity
Keep the network, asset reference, and destination visible during review. Make full identifiers available even when a compact display truncates them. Distinguish test activity from production activity clearly enough that a screenshot or copied description still communicates the environment.
- Explain the requested authority
Describe what the user is granting, including the spender and requested amount where supported. An ongoing allowance should not be presented as a harmless one-time identity check. An undecodable operation should remain visibly unresolved rather than receiving a confident but incomplete summary.
- Separate each completion milestone
Define the evidence for signed, submitted, observed, and unresolved states in your application. Closing a wallet dialog does not prove the final action happened. Preserve a stable request identifier so an interrupted flow can be checked before another attempt is encouraged.
- Make decline an ordinary choice
Return a user who declines to a stable review screen. Do not automatically request another signature or frame cancellation as a failure of the user. Preserve non-sensitive context while leaving a clear path to stop, change details, or investigate the request further.
- Label fees and uncertainty
Keep the transfer quantity distinct from network fees and application charges. Explain which amounts are estimated, where conversion values came from, and when they were observed. Missing cost information should not become a reassuring zero. Avoid implying that a simulation guarantees execution.
- Review keyboard and reading behavior
Check the screen using a keyboard and at increased text size. Keep focus visible, maintain a logical order, and explain status in text rather than color alone. Avoid motion or countdowns that pressure users to act before they have reviewed the request.
- Test support and recovery
Use safe request references and public transaction identifiers where appropriate. Never ask for recovery phrases, private keys, or authentication tokens. Test wallet closure, browser reload, and connection loss after signing. Confirm that the application reconciles uncertain actions before recommending another irreversible attempt.
Finish with evidence, not a score
Decide which unresolved items block release and which require a visible limitation. Keep that decision with the reviewed version of the system. Revisit the checklist when a provider, network, permission model, or reporting scope changes. A completed list is a record of questions considered, not a guarantee that every risk has been found.
Read the full background guide for examples, limitations, and the primary reference behind the discussion. The solution blueprints place this checklist within a broader workflow.