Begin with a user problem, not a standards badge
Choose the friction you want to remove: a first transaction that requires acquiring gas, repeated approvals during a familiar activity, or a recovery process customers cannot complete. Describe the desired journey before selecting account infrastructure. ERC-4337 organizes smart-account operations around UserOperations and supporting services. It does not by itself define every recovery or permission feature your product needs. Ask a supplier to map each proposed benefit to an implemented capability, a configuration decision, or additional work. A standards label is useful context, but it is not a complete product specification.
Show what the customer is authorizing
An easier onboarding screen should still make authority understandable. Identify the signer, the account being controlled, and the scope of the action being approved. If several calls are grouped into one interaction, summarize their combined effect and expose useful detail. Describe what happens when only part of the desired business workflow is outside the account's transaction boundary. During review, ask an unfamiliar user to explain what they believe they approved. That exercise often reveals gaps between a technically correct request and a customer-facing explanation that is actually useful.
Treat sponsored fees as a bounded service
Paymasters can support gas sponsorship in an ERC-4337 flow, but the product must still decide who qualifies and who pays. Set budgets, supported actions, abuse controls, and a response when sponsorship is unavailable. Avoid making a free first interaction imply unlimited free usage. Show any required customer payment before approval, especially when a fallback changes the cost. Include the operator experience: someone must see spend, investigate unexpected consumption, and suspend a policy without unintentionally locking customers out of unrelated actions their accounts should still support.
Make limited permissions concrete
If the chosen account supports session permissions, define them in terms a customer can inspect: allowed destinations, allowed operations, spending limits, duration, and revocation. Do not describe a session as harmless simply because it reduces repeated prompts. Write an example of an allowed action beside a blocked one, then test both against the implemented rules. Show users where active permissions can be reviewed. Plan what happens when a session expires during a task, and avoid quietly requesting broader authority just to preserve a smooth-looking interface during a demonstration.
Specify recovery separately from normal access
Recovery design should name the parties involved, the conditions for changing a signer, and any notification or waiting period. A familiar email screen alone does not describe the underlying authority. Review lost-device and compromised-device cases separately, including how a legitimate customer can contest or stop a pending change if the design allows it. Document limitations rather than promising universal recovery. The handover should include an operator runbook and customer explanation that match the actual contracts and services. Test the full process, not only the button that starts it.
Evaluate dependencies as part of the product
Ask for a supported-network and component matrix covering account implementation, EntryPoint compatibility, bundler, paymaster, and required application services. Record which versions are deployed and who evaluates upgrades. Exercise provider downtime, sponsorship refusal, expired permissions, rejected operations, and account deployment failure in a controlled environment. Verify that the customer's history connects the application request to its eventual chain result. A well-scoped smart-wallet product is not the one with the fewest visible steps in every situation; it is one whose simplified journey remains understandable when its supporting services stop behaving normally.