Making crypto transfers
clear across blockchains.

The brief started with Maya: she had sent USDC across chains and wanted to understand what was happening. I used that moment to define the job of the explorer before changing its screens.

Outcome

Has the transfer arrived, or is it still moving?

Expectation

Is this wait normal for the route?

Action

Should she wait, retry, pay or ask for help?

I audited the interface against its documented states and timing behavior. Transaction evidence was valuable, but the reading order left people to translate protocol language and reconcile separate clocks.

Keep

Preserve transaction records, event history and precise evidence for investigation.

Prioritize

Make outcome, timing and relevant action the first layer of the page.

Accept the tradeoff

Move protocol detail into a disclosure, even though expert users lose some immediate density.

I gave a transaction hash and a wallet address the same front door. One identifies a transfer; the other opens a collection. Neither should require the person to understand the explorer’s structure first.

Find

Put the tracking question and input before the network-wide information.

Recognize

Keep the familiar asset, amount and route visible; prioritize transfers needing attention.

Revise

I initially removed the network console. Building the page exposed the cost for developers and analysts, so I restored it below tracking.

I mapped fifteen technical statuses into six core user states, with slow progress as a timing modifier. Source, network and destination became a stable journey while the explanation changed with the active leg.

State

Give a distinct label when it changes what someone needs to understand or do.

Time

Use a range, then stop offering a remaining-time promise when the model no longer supports it.

Evidence

Keep the original transaction and the observed event available below the explanation.

I modeled a paid gas top-up, a free retry and automatic recovery separately. The interface needed to explain the cause and cost, then offer only the action that the record justified.

Required action

Group the reason, the approximate cost and the next step together.

Automatic recovery

Suppress the paid action when the network is already recovering the transfer without a charge.

Reassurance

Describe the position of funds only when the available record supports the statement.

A receiving contract can reject a transfer even after earlier stages complete. I separated that situation from a recoverable pause and gave support the context a person should not have to reconstruct.

Explain

Name the failure without implying that another payment will solve it.

Establish

Show what completed, where delivery stopped and what the record says about the funds.

Carry forward

Prepare the route, timestamps and error in a copyable transfer report.

Completion needed a clear answer and a usable receipt. I brought the received amount and recipient into the main view, then kept fees, refunds and event-level detail in their proper place.

Confirm

State what arrived and on which network, with the intended recipient visible.

Reconcile

Keep the receipt copyable so it can be checked against the wallet.

Separate

Treat a gas refund as accounting after delivery, rather than another milestone in the journey.

I moved from ranked findings into a specification, then built the React prototype with Claude Code. Eleven deterministic scenarios let me inspect waiting, failure and recovery; an as-built review recorded deviations instead of treating the implementation as proof.

Design outcome

A connected tracking journey with a clear hierarchy, explicit states and conditional actions.

Still to verify

Route timing, reliable funds-position signals, recovery eligibility and a joined view of multi-hop transfers.

Next evaluation

Watch people identify a transfer, interpret a delay and choose a recovery path; check whether they can verify the recipient afterward.