Scope: what carries over from consumer fintech, and what is new
Kite is a fintech application that settles on crypto rails. A large portion of consumer fintech practice — onboarding, KYC, cards, money movement, trust and error states — applies directly. The web3-specific design task is determining which underlying complexity to abstract behind established fintech patterns and which concepts require new interface treatment.
Carries over from fintech
- Mobile-first onboarding & progressive disclosure
- KYC / identity capture flows (Sumsub, POA)
- Card issuance & spend UX
- Money in / money out, balances, history
- Trust, security states, error recovery
- Regional / regulatory variation
New in web3
- Custody & keys — abstracted in Kite via Dynamic embedded wallets, passkeys, no seed phrase
- Addresses: sending to a string, not an account number
- Networks / chains & tokens as first-class objects
- Gas / network fees on actions
- Irreversibility & finality — no chargebacks
- Web3-native scam & approval patterns
Tags: resources are marked FOUNDATION (orientation), CORE (the working set), and DEEP (reference for a specific surface). Each card notes its relevance to Kite.
Orientation to web3 design
General grounding and shared vocabulary.
The primary starting reference. Links to web3 user-research studies, UX heuristics, case studies, and a set of production design systems (see §06).
A structured practitioner's reference for designing crypto apps — onboarding, wallets, transactions, and recurring UX pitfalls. The closest single source to a textbook for this transition.
A collection of frameworks and notes on web3 UX principles, DeFi patterns, wallet UX, and protocol-level thinking. Suited to reference use once inside a specific flow.
A single-sitting roadmap that sequences the concepts relevant to a designer coming from web2, usable as a checklist against this reference.
Mental models and decision frameworks
The concepts that behave differently from web2 money, and frameworks for deciding what to expose.
A framework of UX rules for blockchain products, provided as a duplicatable Figma file. The frame-level format supports direct annotation.
A decision framework for how much of the underlying complexity (keys, gas, chains) to abstract versus surface. This is the recurring judgment on most crypto product screens.
Frames flows around the user's intended action ("pay this person," "cash out") rather than on-chain mechanics. The intents-first lens is central to presenting crypto as a conventional fintech experience.
Wallets and onboarding without seed phrases
The most Kite-relevant area. Kite uses Dynamic.xyz embedded wallets — social login, passkeys, no seed phrase.
How embedded wallets plus social login replace seed-phrase onboarding. This is the infrastructure behind Kite's Apple / Google / OTP sign-in.
The developer documentation, relevant to design for its constraints: what can and cannot be edited, MFA on transactions, and recovery paths. Designing to the platform's actual limits reduces rework.
The current consumer-crypto direction: a wallet the user is not required to think about. This aligns with Kite's model of a fintech application where crypto is infrastructure rather than a feature.
A plain-language primer on account abstraction and smart wallets (ERC-4337, EIP-7702) — the basis for gasless, recoverable, seedless onboarding. Sufficient background for design discussion with engineering.
Core money flows: balances, send, receive, fees
Where web3 patterns change the interface — multi-token balances, sending to an address, network fees, and confirmations.
The "getting started" links cover heuristics for transaction interfaces and reviewed case studies (wallets, OpenSea), including treatment of amounts, addresses, and the pre-transaction review step.
Reference component patterns for wallet connection, account display, network switching, and pending/confirmed states. The balance, address, and status micro-patterns transfer to an embedded-wallet context.
A wide catalogue of concrete patterns — address truncation, copy/QR, fee display, status feedback. Agency-authored; usable as a state-coverage checklist independent of its sales framing.
Trust, security, and irreversibility
The area where UX errors have the highest cost — a wrong address or blind approval loses funds with no chargeback.
Addresses the trust gap: designing confidence into irreversible actions, communicating risk accurately, and avoiding the blind-sign pattern. Applies to any Kite screen that moves money.
The security surfaces relevant to design: transactional MFA, account recovery, and step-up authentication. The recommended paths define what is both secure and supported.
Design systems for reference
Production, open design systems from established crypto teams, available for inspection in Figma.
A reference point for a warm, mobile-native consumer-crypto aesthetic, including component states, empty states, and motion — close in spirit to a consumer app such as Kite.
Publicly available systems from Safe (wallet security), ENS (names/addresses), Optimism, and Polygon — examples of color tokenization, address handling, and standardized transaction states. Accessed via the design-systems list on the ethereum.org hub.
Case studies
Two consumer wallets that addressed the non-crypto onboarding problem relevant to Kite.
How a self-custody wallet was made approachable. A companion onboarding breakdown details the specific decisions for onboarding non-crypto users.
Argues that Rainbow's competitive advantage is its design and delight — a strategic reference on the value of consumer-grade UX in crypto. Companion: CoinDesk on Rainbow's mobile-first design.
Ongoing sources
Web3 patterns change frequently; these sources keep the reference current.
A substantive ongoing source on consumer-crypto direction, including design and onboarding talks from Crypto Startup School.
The ethereum.org hub links to active web3 design communities and Design DAOs — venues for peer questions and current work.
Kite surface → resource map
Reference cluster for each Kite flow.
| Kite surface | What is new | Reference |
|---|---|---|
| Auth & account (Dynamic) Apple / Google / OTP, merge logic | Embedded wallet created silently; no seed phrase; account recovery | §03 (all) + §05 Dynamic security |
| Pre-KYC & identity self-declaration → email → Sumsub | Largely standard fintech KYC | §01 user research |
| Card (DCS / DeCard) issuance & spend | Standard card UX over a crypto balance; funding-source clarity | §04 balances |
| Ramp (Transfi) & QR pay | Fiat ↔ crypto conversion, fees, confirmation and finality | §04 core flows + §02 intents-first |
| Balances, send/receive, history | Addresses, tokens, networks, gas/fees, pending/confirmed states | §04 (all) + §06 systems |
| High-value actions & recovery | Irreversibility, step-up auth, blind-sign avoidance | §05 (all) |
Activities to complete
A checklist of actions, in no fixed order.
- Establish shared vocabulary. Work through the ethereum.org design hub, the Web3 UX Design Roadmap, and the Web3 UX Design Handbook (§01).
- Set the abstraction stance. Read the Web3 Design Decision-Making Framework and the Intents-First patterns; document a position on what Kite abstracts versus surfaces (§02).
- Create a Kite web3 principles document. Duplicate the Figma "Web3 Design Principles" file and adapt it to Kite (§02).
- Study the platform in depth. Review the Dynamic embedded-wallet, passkey, and security documentation and cross-reference the constraints in Kite's CLAUDE.md (§03, §05).
- Assemble a pattern reference. Pull RainbowKit and the Safe / ENS / Optimism systems into Figma and document reusable component states (§06).
- Run case-study teardowns. Analyze the Phantom and Rainbow case studies and record patterns applicable to Kite's send, ramp, and balance screens (§07).
- Build a money-movement state checklist. Cover address entry, fee display, pending/confirmed states, and error/recovery for every value-moving screen (§04, §05).
- Set up ongoing input. Follow a16z crypto and join one web3 design community for continuing pattern updates (§08).
- Use the surface map. Consult the surface → resource map as each Kite flow is picked up.