Three products dominate the design conversation in Web3.
Uniswap. Phantom. Rainbow.
They are referenced constantly in briefs, in Twitter threads, in pitch decks, in founder interviews. Everyone agrees they have something the rest of the space lacks.
And almost no one has actually copied what they did.
Not the visual style. Not the feature set. The decision-making process that produced the product.
The short version
- Uniswap's insight was not minimalism. It was the discipline to remove things that seemed reasonable.
- Phantom's insight was not better UI. It was designing for someone who did not already understand crypto.
- Rainbow's insight was not delight. It was that a wallet people enjoy using is one they return to.
- All three required holding an opinion against obvious alternatives. Most teams have feature lists, not opinions.
The teams that reference these products in briefs usually want the aesthetic. What made them work was the conviction behind it.
Uniswap: the decision to remove everything
The original Uniswap interface had one swap pair, a single input, and almost nothing else.
This was not a limitation. It was a position.
Hayden Adams has talked about designing the interface by removing features until the core action was exposed. Not simplifying to make things approachable. Actively cutting until the product could only do the one thing users needed most.
The Uniswap wallet swap screen. One amount field. One token selector. The "Swap" button is the only action. Everything else was cut.
This is a harder decision than it sounds.
Every product team has a backlog. Every product team has stakeholders asking for features. Every product team has a designer who sees a competitor with more functionality and wants to match it.
Uniswap chose not to.
The teams that reference Uniswap in briefs usually want the aesthetic. The clean layout, the green color, the token picker. What they rarely copy is the discipline required to remove the tenth feature instead of adding it.
That discipline is what made Uniswap. The visual language came after the decision, not before.
Phantom: the decision to look like a consumer app
Phantom launched as a Solana wallet in 2021 into a market where wallet UX was defined by MetaMask. At the time, MetaMask was the standard, and the standard was: confusing, developer-facing, and designed for people who already understood what a seed phrase meant.
Phantom made a different decision. They designed the wallet like a consumer financial app.
Phantom's home screen. Your balance is front and center. Token logos and prices are visible immediately. The tab bar uses plain language: Tokens, NFTs, Activity. No jargon, no raw addresses.
The asset list had logos and prices. The transaction history used human-readable descriptions. The NFT gallery looked like a native iOS photo library. The onboarding explained seed phrases using plain language that assumed the user had no prior knowledge.
None of the technical capabilities were different. The keys were the same. The security model was the same.
What was different was the assumption about who the user was.
Most wallet teams design for the user who already understands crypto. Phantom designed for the user who was about to understand crypto.
That is a different product. It reached a different audience. And it grew faster than any Solana wallet before it.
The teams that reference Phantom in briefs usually want the dark background and the purple accent. What they rarely copy is the foundational assumption that the user is a normal person, not a developer.
Rainbow: the decision that the wallet is the product
Rainbow could have shipped as a functional Ethereum wallet with a cleaner interface than MetaMask. That would have been enough to differentiate.
Instead, the team made a more unusual bet. They decided that the wallet experience itself was the product, not a thin layer on top of Ethereum.
Rainbow's Discover screen. Color-coded token cards. Animated transitions. A profile system that turns a wallet address into something personal. None of this is required for a wallet to function — it is required for a wallet to feel worth using.
This meant visual delight as a design principle. Animations that communicated system state. An interface that responded to user actions in ways that felt good, not just correct. A native iOS app that used iOS conventions instead of mapping a web app to a smaller screen.
The Rainbow team shipped things that had no direct correlation to financial performance: card-like asset display, animated transaction completion states, color-coded portfolio breakdowns. They optimized for how the product felt to use, not just what it enabled.
This is an unusual priority in an industry where most design decisions are justified by conversion rates or retention metrics. Rainbow justified them on the grounds that a financial product people enjoy using is one they return to.
The teams that reference Rainbow in briefs usually want the colorful visual language. What they rarely copy is the product philosophy that the wallet experience should be pleasant enough to use daily by choice.
The pattern across all three
Looking at all three together, the common element is not aesthetic. It is a clear product opinion held with enough conviction to resist the obvious alternatives.
Uniswap: the product should do one thing and do it perfectly.
Phantom: the product should feel familiar to someone with no crypto background.
Rainbow: the product should be something users want to use, not just have to use.
Each of those opinions required saying no to things that seemed reasonable. More features. More technical exposure. More utility at the expense of delight.
Most Web3 products do not have a clear product opinion. They have a feature list. Features and opinions are not the same thing.
A feature list produces an interface that looks like every other DeFi app. An opinion produces something people remember.
Why the copying problem persists
Web3 teams are good at copying visual outputs. They clone the color palette, the card layout, the typography system, the button shape.
They are worse at copying the conditions that produced those outputs. Because those conditions are not visible in the interface. They live in the product process, the hiring decisions, the organizational structure, the willingness to cut a feature the founder wanted.
Phantom required a team that could tell the difference between features that served users and features that served engineers.
Rainbow required leadership willing to invest in motion design before the product had significant market share.
Uniswap required the discipline to not build what every competitor was building.
None of those things are in Figma. They are in how the team operates.
What this actually means for your product
If you want to build something that ends up in the reference list, the starting point is not a better Figma file.
It is a clearer product opinion.
What is the one thing your product should do better than anything else? Not five things. One.
If you cannot answer that in one sentence, the design does not have a foundation to build on. Any designer you hire will be decorating an unclear brief, and the interface will reflect that.
State the opinion. Hold the opinion. Build the product around the opinion.
The visual system follows naturally, because it has something to express.
If you are building a Web3 product and want help turning a product opinion into a design direction, somaryuu.xyz
Top comments (0)