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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.