Design notes / Financial workflows
Wallet access
needs a way back.
A connection button is the visible part of a larger interaction. The useful design work is often in the states around it.
Start with the blocked task.
A person arrives to inspect a position, stake or participate in governance. Connecting a wallet is a condition for some of those tasks. It is rarely the task itself.
The original PieDAO-to-AUXO access map makes that distinction tangible. It branches around whether a wallet is available, whether the network is correct and whether access succeeds. Installation, switching networks, rechecking, reporting a problem and exiting all appear in the planning material.
That gives the interface a more useful question to answer: what can this person do next, and how do they return to their intention?
Inspect the complete original ↗
01 / Design the exception
An error state still needs an action.
A generic failure message leaves the person to diagnose the system. A useful state distinguishes what happened from what can happen next. The table below is a new summary of the routes in the original map.
| Condition | Route in the map | Question for the interface |
|---|---|---|
| No wallet available | Installation, then another connection check. | Can the person find their way back after leaving to install it? |
| Wrong network | Switch the network and check the result. | Is the requested change clear before the external wallet interaction? |
| Connection still fails | Report a problem or exit. | Does the person have a useful choice after a failed retry? |
| Access succeeds | Continue into the product. | Does the person return to the task that required access? |
02 / Keep the boundary visible
The product and the wallet share the journey.
Some steps happen outside the product. A wallet prompt can be dismissed; a network change can take time; installation moves someone into another environment. The experience needs to account for returning, rather than ending at the point where control leaves the page.
In a current implementation review, I would specify the pending, cancelled, failed and returned states alongside the successful one. I would also check which context can safely persist. That is a practical next step from the diagram, rather than a claim that the original artifact already defines every technical detail.
03 / Make the next question testable
Test the return journey.
A successful connection alone would be an incomplete evaluation. A useful follow-up study would ask someone to begin a product task, encounter a blocked access state and recover without being told the route.
- Can they explain why access is blocked?
- Can they choose the appropriate next action?
- After switching or installing, can they resume the intended task?
- When recovery fails, can they leave or seek help deliberately?
Those are proposed validation questions. They are not historical test results or a measured conversion improvement.