From fragmented ecosystem
to scalable product
2023 - 2025
Lead Designer
AAVEGOTCHI
A full product transformation of Aavegotchi from a scattered, trust-broken experience into a coherent system built to grow.
The product wasn't broken.
It was unreadable.
The UI looked unfinished. But visual inconsistency wasn't the root cause it was a symptom. The deeper problem was that the product communicated nothing: not what it was, not where to start, not how its parts related to each other.
New users arrived with real intent and left without orientation. Existing users were deeply engaged, but had built their understanding around the product, not through it via Discord, friends, YouTube videos, and community-built third-party tools. The product was outsourcing its own comprehension.
Simultaneously, the ecosystem was expanding new game modes, marketplace features, governance tools, staking mechanics each added in isolation, each with its own logic. There was no foundation to hold any of it together.
The brief was "modernize the UI." The actual problem was: build a product foundation that earns trust on arrival and scales without fracturing.
The community had become the product's onboarding layer and that was the most important thing to fix.
51% of users learned how to use Aavegotchi through Discord or direct community referral. Not because the documentation was bad. Because the product never explained itself. Users who stayed did so because someone helped them — not because the experience guided them. That dependency worked at small scale. It was a ceiling at any larger one.
Four overlapping systems.
One product surface.
Before redesigning anything, the product needed to be mapped as a system. Aavegotchi isn't a single experience — it's four distinct but interdependent layers, each with different users, different frequencies, and different definitions of value.
Identity
The gotchi — a user's on-chain avatar with traits, kinship, and visual character. The emotional core of the product. Everything else orbits it.
Asset & Marketplace
The Baazaar — buying, selling, and equipping wearables and portals. High-frequency for experienced users, opaque and unforgiving for new ones.
Gameplay
Minigames, rarity farming, the Gotchiverse. The "why you stay" layer — but only reachable after navigating the first two successfully.
Governance
DAO voting, proposals, staking GHST. Used daily by power users, invisible to most new entrants.
501 participants.
The data said four things clearly.
The research combined a structured survey with open community feedback. The goal wasn't to generate personas — it was to identify where the product was actively costing users, and where it was getting by on community goodwill alone.
Onboarding depended on people, not product
1
51% of users first learned Aavegotchi through Discord or personal referral. The product itself was not the entry point — community was. This wasn't a strength to celebrate. It was a structural fragility: impossible to scale, invisible to new users without a connection.
51% community-dependent onboarding · 501 respondents
34% found the product difficult to enter
2
On a 1–10 onboarding ease scale, 34% of respondents rated getting started at 5 or below. Average score: 6.3. These aren't skeptics — these are people who stayed despite confusion. The number that left is unknown, and likely higher.
Avg onboarding score: 6.3 / 10 · 34% rated ≤5
Mobile was in active use — with no real support
3
48% of respondents accessed Aavegotchi on a phone. The mobile experience was not designed for this — it was an afterthought adaptation of a desktop product. The marketplace, staking, and governance flows were effectively broken at mobile scale.
48% accessed via phone · 0 mobile-first flows at baseline
The marketplace was the highest-traffic surface — and the most complained about
4
The Baazaar accounted for the majority of daily visits, but generated the most friction complaints: broken filtering, unclear sorting, tedious listing formats. 78% of users visited daily or more. The surface they used most was the least refined.
73 marketplace complaints · 78% daily+ users
One entry point.
Four layers of depth.
Complexity wasn't the enemy — hidden complexity was. Navigation was reorganized around user intent, not product categories. The top-level structure reflected what people came to do: discover, own, play, participate.
Onboarding was rebuilt as a progressive disclosure system. New users received the minimum viable context to take one meaningful action. Complexity revealed itself as familiarity increased — rather than arriving all at once at the front door.
The decisions that shaped
the system made before
any UI was drawn.
Decision 01
Restructure the IA before touching the visual layer
The temptation in any redesign is to start with visual polish it creates the fastest visible progress. Instead, the first phase was entirely structural: mapping the full ecosystem, identifying where features orphaned users, where navigation contradicted itself, where four product layers were fighting for the same surface. IA was rebuilt before any UI began.
Decision 02
Design system first — as a constraint, not a deliverable
Tokens, components, spacing logic, and interaction patterns were defined before the final UI. This wasn't about efficiency — it was a deliberate decision to force consistency from day one. Every screen would be built from the same parts. No one-off solutions.
Decision 03
Modernize the product — preserve the character
The pixel aesthetic is not incidental to Aavegotchi — it's structural to its identity. The decision was to elevate everything around it: navigation, typography, layout, component logic, information hierarchy. The gotchis didn't change. The product context they lived in did.
Decision 04
Mobile as a primary surface — not an adaptation
With 48% of users on phone, mobile was designed in parallel with desktop — with its own interaction logic, not shrunk from a desktop layout. Governance, marketplace browsing, and social flows were rebuilt for the context of a thumb, not translated from a cursor.
Community-tested.
Decision-driven throughout.
Prototypes were tested with real community members before finalization. Loom walkthrough sessions ran in parallel with formal testing — surfacing edge cases, power-user workflows, and emotionally significant moments that structured tests wouldn't have reached.
Desktop and mobile were delivered at full fidelity. The design system shipped alongside — documented for team adoption, not just designer handoff.
The community is not
a focus group. They're co-authors.
Web3 communities don't observe they participate. Validation was continuous: Discord threads, Loom feedback, and direct testing sessions all ran in parallel with iteration. The most significant changes in the final version came from community input, not internal review.
One onboarding flow was restructured entirely based on how users described their own mental model of the product. Several navigation patterns were adjusted after Loom walkthroughs revealed routing assumptions that hadn't survived first contact.
The system held where it needed to.
The redesign is measured against the problems it set out to solve — not against abstract metrics. The product now explains itself. Navigation has a logic. New users can orient without external help. The design system provides a foundation the product can grow from without fracturing again.
501
Research participants across quantitative + qualitative methods
51%
Community-dependent onboarding — identified and addressed through structural product redesign
48%
Mobile users who now have a first-class experience rather than a broken adaptation
4 → 1
Product layers unified under a single coherent navigation and information architecture
Onboarding drop-off reduced. Retention improved. Community feedback shifted from "clunky" and "unfinished" to recognition of a product that had grown up. The design system was adopted by the team — enabling consistent future development without resetting the foundation on every new feature.
Not a visual refresh.
A structural transformation.
The gap between before and after isn't captured in a side-by-side screenshot.
It lives in the product's underlying logic how it sequences users, how it handles complexity, how it communicates trust.
BEFORE
No IA — four product layers competing for the same surface
Onboarding outsourced to Discord and community referral
Mobile experience broken for all key flows
Inconsistent visual language across the ecosystem
No design system — every new feature required new decisions
Marketplace filtering broken, listings opaque
Product read as "unfinished" — eroding trust at entry
AFTER
Unified IA organized around user intent and product depth
Progressive onboarding — product explains itself
Mobile designed as a primary surface, not adapted
Cohesive design language across desktop and mobile
Token-based design system — scalable without regression
Marketplace restructured for clarity and decision-making
Visual credibility that supports trust from first contact
What the work actually required.
The real brief is rarely the stated brief.
The ask was "modernize the UI." The actual problem was product coherence, trust at entry, and a system that could scale. Identifying that distinction early — and getting alignment on it — shaped every decision that followed. That's the work that doesn't show up in a Figma file, and it's the most important work in the project.
A community that compensates for your product is not a feature. It's a warning.
51% of users learned Aavegotchi through Discord. That number looked like community strength. It was actually a product gap — one that would cap growth the moment the community couldn't scale fast enough to match new user volume. Fixing it required making the product do what the community had been doing: explain, orient, and build confidence.
Design systems are product infrastructure, not design deliverables.
The most durable part of this work isn't any individual screen — it's the token-based system underneath it. Decisions about naming, scope, flexibility, and documentation compound over time. A system that a team can actually use is harder to build than a system that looks good in a presentation. Getting this right early changed the quality of everything that followed.
In trust-sensitive products, visual coherence is a product requirement.
Aavegotchi users are holding real assets. In that context, a UI that reads as "unfinished" doesn't just create friction — it creates doubt. Visual consistency isn't aesthetic preference here. It's a signal the product sends about its own reliability. That reframing changed how every design decision was evaluated.
