UX: finish the remaining Don't Make Me Think review fixes #468

Problem and review baseline

Several extension screens still make users recall transaction context, interpret technical terms, or discover what an unlabeled control means. This tracks the remaining work from a UX review using Steve Krug's Don't Make Me Think principles: self-evident choices, recognition rather than recall, clear navigation, and progressive disclosure.

Rechecked on 2026-10-01 against the top of the open PR stack, #450, at a65b2241ed4baa41b4ac834405b5a8f5fcf3b685, using production UI Lab screens and source inspection. Scope is the browser extension, not the new native mobile apps. #450 was based on #466 but lacked four newer deployment/NFT receipt commits; those differences do not affect these findings.

Remaining fixes and acceptance criteria

1. Complete the final Send review context — first priority

The final review now names the sender and recipient and shows amount and cost. The network appears on amount entry but disappears from the final review. Addresses are truncated and depend on hover/copy for exact inspection.

• Show the reviewed network on the final confirmation alongside From, To, Amount, and Cost.
• Provide an explicit, keyboard-accessible way to inspect each complete address in place, without requiring hover or copying elsewhere; retain copy controls.
• Keep these details bound to the same account/network/recipient being authorized, including after editing and returning to review.

Evidence: transfer-review-markup.ts. Related: #451, #458, #460.

2. Remove the unnecessary single-account choice in new-wallet setup — first priority

The address-confirmation instruction and Mainnet acknowledgement have been removed. However, the sole newly generated account still starts unselected and “Add selected account” stays disabled until the user selects it.

• Present the sole newly generated account as the account being created, without requiring a redundant selection click.
• Use an outcome-specific final action such as “Finish setup.”
• Preserve recovery-phrase verification, passphrase validation, account-preview validity, and explicit selection where recovery discovers multiple accounts.

Evidence: onboarding-views.ts. Related: #159, #430.

3. Explain privacy actions in terms of their outcome — first priority; coordinate with #438

The journey still mixes “Shield,” “Go private,” and “Activate private balances.” Its main review explains “private notes” and a “viewing-key commitment” before making the user's task obvious.

• Clearly distinguish enabling private balances from moving funds into a private balance, using consistent wording across entry points and reviews.
• Explain the outcome, fees, and what remains public in concise plain language. Do not imply registration itself moves funds or makes every account action private.
• Move cryptographic implementation terminology into Technical details while keeping material privacy consequences visible.
• Track completion with Explain what Shield / Go private does #438 rather than opening a duplicate privacy-copy issue.

Evidence: privacy-views.ts. Related: #437.

4. Make primary navigation identifiable without hover

Home, Activity, and Settings still render as icons only. Accessible names and native tooltips exist, but there are no persistent visible captions.

• Show visible Home, Activity, and Settings labels with the dock icons.
• Preserve selected-state indication, accessible names, keyboard behavior, and usable layout at side-panel and popup sizes.

Evidence: navigation.ts.

5. Name the connection approval action and account

The heading is now the simpler “Cost,” but connection requests still end with generic “Approve” / “Deny.” The account is identified by its truncated address without its familiar name.

• Use action-specific connection wording such as “Connect account” / “Cancel,” while preserving the existing rejection behavior.
• Show the account's familiar display name alongside its address and network.
• Retain the clear explanation of address sharing, its duration, and the absence of a transaction/network fee.
• Apply wording appropriate to each approval kind; do not relabel signing or transaction approval as connection.

Evidence: approval-cards.ts.

6. Finish the minor Receive naming cleanup

The main Receive overload is fixed: QR and address lead, and contact-card/key controls are behind Advanced. The remaining inconsistency inside Advanced is “Bramble contact card” versus “Copy wallet card.”

• Use one consistent name for the same contact-card object and its copy action.
• Keep the default Receive surface focused on the address; do not bring the advanced key controls back onto it.

Evidence: receive-view.ts. Related: #403, #416.

UI Lab accuracy correction — not a production fee vulnerability

The activation checkpoint still shows “Maximum network fee: Unavailable” with an enabled activation button because its fixture omits networkFee. Production registration already awaits a successful fee estimate before returning the review. This requirement was present at the original review too; the earlier high-priority production-flow claim is withdrawn.

• Give the normal activation-review fixture a realistic network fee and pool fee matching the production review contract.
• Represent fee-estimation failure through the actual preparation failure/retry path, rather than presenting an incomplete fixture as a normal ready-to-authorize state.

Evidence: incomplete fixture, production fee requirement.

Validation

• Exercise affected production templates and bindings in the UI Lab at 400 × 760 and 380 × 600, plus the full-screen onboarding surface; check both themes and keyboard access.
• Update meaningful journey/interaction tests for selection gates and approval behavior, and run the repository's required checks for implementation changes.
• Validate the wording with representative users performing setup, receive, send review, and privacy activation. Ask what they expect the next action to do before clicking; record hesitation and misunderstandings.

This is a heuristic review and follow-up checklist, not a claim of measured user-study results. No signing, permission, or fee-validation boundary should be weakened to simplify presentation.