Lowering Web3 Barriers: A Design Guide to Progressive Onboarding in Crypto Games
TechFlow Selected TechFlow Selected
Lowering Web3 Barriers: A Design Guide to Progressive Onboarding in Crypto Games
Web3 should focus on enabling users to quickly try products in a simple format, while immediately linking successful interactions to progress.
Navigating Web3 tides with focused insightsWritten by: Will Robinson
Compiled by: TechFlow
This series explores the best user experiences in Web3. This is part one, focusing on gaming—but it should offer useful insights for more general products. Over the past few years, I’ve spoken with dozens (hundreds?) of Web3 game developers, and there’s a common sentiment: onboarding friction is still too high. But how do we move beyond Metamask and create better user experiences?
Progressive Onboarding
While “progressive onboarding” is a popular concept in UX circles, the first time I saw the term used in crypto was in the Privy.io blog. It’s a simple idea:
New users should only experience friction when necessary—and as late as possible.
Too often, crypto products demand “wallet connection” and signatures before they’re needed. But before diving into applying best practices to Web3, let’s start with the onboarding experience of an AAA mobile game: Marvel Snap (hereafter referred to as Snap). This is a game with excellent user retention that effectively introduces complex mechanics and a unique progression system through progressive onboarding.
Lesson One: Let People Try Your Product First
Design: Players starting Snap are given a choice: “Play as Guest” or “Already linked your account?” Surprisingly, the screen layout encourages users to play as guests. This means players can go through the entire tutorial without creating an account!
Lesson: Snap delivers value before asking for action: let people try your product first. By removing drop-off points during account creation, you retain more early-stage users.
Lesson Two: Simplify the Game
Design: Once past the initial screens, the game walks you through a simplified round containing only about 50% of its full mechanics. This tutorial round is designed to be nearly impossible to lose. Observe what it highlights—versus what it hides:
-
Play one card per turn;
-
Each card has a numerical strength;
-
There's only one valid location to play a card;
-
Win by having higher strength than your opponent.
Lesson: You don’t need to teach everything at once. The Snap team effectively designed a new player experience that prevents overwhelming users in the first few minutes. As a game designer, your goal is to shift players from indifference to focused engagement by simultaneously increasing their skill level and the game’s challenge. If the challenge is too high relative to skill, users will feel anxiety, boredom, or frustration—and leave. The same principle applies broadly to product design.
Lesson Three: Progressive Introduction
Design: After completing the Snap tutorial, you receive your first reward: a visual upgrade for your cards. Cosmetic upgrades are excellent early-game rewards because they don’t affect gameplay but provide immediate delight. But the game does something unexpected: the visual upgrade unlocks access to new cards in future rounds. This creates a loop: winning a round gives players resources to change their appearance, which in turn gives them new cards to win future rounds. To reinforce this cycle, Snap guides players through a second, more complex tutorial and another upgrade.
Lesson: Giving players motivation is powerful. Think of it as a second game played alongside the first. Rewards from the first game become resources in the second, and vice versa. In doing so, these systems validate each other’s value.
Lesson Four: Ensure Success
Design: After several tutorial rounds, the game returns you to the main lobby. Only now does a pop-up prompt you to choose a username! A few more rounds later, it prompts for social login. At this point, you enter a fully unlocked lobby filled with missions, resources, and news. Play long enough, and you’ll find a surprisingly affordable “first purchase” package for just a few dollars.
Lesson: Only ask users to complete administrative tasks after they’ve tried your product. Also, break these tasks into small steps so none take more than a few minutes. By this point, players are already committed and will register without dropping off.
And stay hands-off with monetization! Them giving you their number doesn’t mean they want to bring you home. As their gameplay and identity become tied to the game, players will naturally begin purchasing in-game assets.
How Does This Translate to Crypto Games?
Snap reveals that crypto onboarding should only happen when it's first needed—which likely isn’t yet, in almost all cases. I’ll use Primodium as an example—an early-stage project where a small team is building an on-chain strategy game.
Applying Lesson One: Let People Try Your Product First
The good news is that unlike many peers, Primodium doesn’t require wallet connection. Instead, your private key is stored in browser cache. If a player accidentally clears the cache, progress is lost—a risk similar to Snap before social login is added. Avoiding wallet management early on is a smart decision by the Primodium team.
However, when you first connect to Primodium, loading the world state takes two minutes. Game over. This is an absolute barrier to quick onboarding. Primodium incorrectly assumes players can jump straight into a multiplayer environment, but as we saw in Snap, that’s not necessary yet. By making the first hour of gameplay player-vs-AI, complexity is reduced and players can try the product while waiting for on-chain readiness.
Applying Lesson Two: Simplify the Game
At the start of Primodium, we’re thrown into a minefield of complexity. If you're prone to anxiety, prepare for a nervous breakdown. Developers hide nothing—showing rankings, scores, six buildings, star maps, three mineable resources, a main base, star map, eight icons in the top-right corner, and fifteen empty resource trackers. Complexity should be reduced by hiding unnecessary elements.
Primodium’s approach is tutorial boxes listing a set of tasks, following Snap’s example of a no-fail first tutorial. However, players can only claim rewards after blockchain transactions are executed. Ideally, the client would “optimistically” progress as if the transaction were confirmed, later syncing with chain state. This kind of frontend “cheating” isn’t unique to Web3—games have long relied on clients advancing faster than backends.
Applying Lesson Three: Go Slow
Since Primodium’s core loop revolves around building alien factories, visual progression comes naturally. Each time a player upgrades their base, they unlock new buildings. This not only helps introduce complexity gradually but also serves as a reward for past success. Additionally, since you control your base layout, seeing it grow more aesthetically pleasing becomes its own reward.
Beyond in-game progression, Primodium shows meta-level progress via global rankings. Since current rounds are small, new users can climb the leaderboard quickly. That dopamine hit from seeing your rank rise is crucial for retention. Over time, closing the loop—using leaderboard scores to unlock cosmetics and other in-game rewards—will be vital for Primodium.
Their loop should be: use assets to score, score to get cooler assets, use new cool assets to score more (or differently, in a balanced game).
Lesson Four: Ensure Success
Primodium excels here. The developers know they haven’t yet found product-market fit or built a strong repeat user base (at least not yet). Rather than chasing monetization, they’re focused on improving the game.
By choosing to ignore monetization for now, they gain a benefit: no need for wallet connection. Players are only prompted to sign anything when they want to link their game state to a personal address—for bragging rights. Here, we see a new crypto-native pattern emerging: separating hot wallets and cold wallets within games and apps. Use disposable devices for gameplay, but store your reputation (and perhaps NFTs in the future) in a more secure place.
Summary
Web3 user flows and onboarding shouldn’t differ from Web2. Web3 should focus on letting users quickly try the product in a simple format, immediately linking successful interactions with progression. Only after gaining traction should administrative tasks like account linking and wallet connection be introduced. And monetization opportunities should be offered to those who love your product and seek ways to participate in value creation.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Alliance
