Desktop-first onboarding for a browser wallet
Razor Wallet is a browser extension wallet for the Movement blockchain. The redesign focused on reducing friction without softening the security steps that make a non-custodial wallet trustworthy.
Web3 wallets often ask people to make three high-stakes decisions before they have a real sense of the product: accept terms, create a password, and store a recovery phrase. The original Razor Wallet flow had more steps than it needed, which gave users more chances to drop off.
I started from user complaints in Razor's Discord. They pointed to familiarity: the flow didn't look like the wallets people already knew, so they didn't trust its steps. I ran a competitive analysis of the main wallets, then set the goal: cut the flow down, keep every security requirement, and make each screen feel clear instead of intimidating.
The standard wallet onboarding pattern asks too much too early. Users are expected to agree to terms, create a password they cannot recover, and write down a 12-word phrase that controls access to their funds before they have had a single meaningful interaction with the product.
For a devnet launch aimed at developers and early adopters, that means every abandoned sign-up is a lost signal. For a mainnet launch aimed at general users, it becomes a lost customer.
Most wallets bury the reason for each step in a help article no one reads. This redesign puts the explanation beside the action, on the same screen, at the moment the user needs it.
| Screen | Purpose |
|---|---|
| 1. Splash - Terms of Service | Entry gate with legal acknowledgement |
| 2. Welcome - Wallet Choice | Route returning vs new users |
| 3. Create a Password | Security layer 1 - local access |
| 4. Secret Recovery Phrase | Security layer 2 - wallet ownership |
| 5. Congratulations | Confirmation and entry into the product |
The first screen establishes the product identity and gates entry behind a single consent action. It is almost entirely negative space: brand, one sentence, one checkbox, one CTA.
That is deliberate friction. The checkbox forces an active acknowledgement instead of a passive scroll-past, but nothing else competes for attention.
The copy matters here because the buttons are really user self-identification statements. A returning user should know instantly which path is theirs; a new user should feel clearly invited to continue.
The main weakness in the current draft is tone. The screen works, but the body copy leans too far into marketing language for a flow that is otherwise plain and functional.
This is the first moment where a user might pause and ask why the product needs more from them. The layout answers that question without forcing them into a separate help screen.
The left panel handles the action. The right panel handles the explanation. That separation keeps the screen calm, readable, and easy to scan.
This is the most consequential screen in the entire flow. The design has to avoid both extremes: warning overload and under-explaining the risk.
The structure returns to the same two-panel layout, which gives the user visual familiarity after Screen 3. The left panel handles the phrase. The right panel answers the actual questions people have in the moment.
The final screen closes the loop, confirms success, and gives the user one clear way forward. The Razor logo appears here as a reward signal after the effort of the setup flow.
The CTA should stay final and simple. Done works better than any eager onboarding language because it ends the chapter instead of opening a new one.
The redesigned flow shipped for Razor Wallet's devnet launch. Razor reported:
These figures describe the whole launch, including marketing and community campaigns, not the redesign on its own. I didn't measure onboarding time or completion before and after the change, so this page walks through the design decisions rather than proving a result.
What I'm measuring next: I still work on Razor, so the next step is to measure the live flow, with onboarding completion and time from analytics and a timed usability test. When that's done, this becomes a full case study.
Security and simplicity are not opposites in Web3 onboarding. The better question is whether you explain the why at the right moment, on the right screen, in plain language.
A few extra mascot explorations from the Razor world, kept here as a small visual appendix after the walkthrough.
