TT Wallet · Mobile App · 2021–2023
From functional requirements to information architecture redesign.
I don't just handle UI-level requests; I identify where information architecture misaligns with user mental models. This case demonstrates how I move from executing a brief to reframing the core problem.
ROLE
Product Designer — Research, Strategy, UI/UX, Flow Design
TEAM
Product, Engineering, Marketing
DURATION
2021–2023
✓
PROBLEM REFRAMING
✓
ARCHITECTURE ADOPTED
∅
QUANTIFIED DATA
The Brief
"Add a credit card entry point."
The task seemed straightforward: integrate a third-party credit card service and add an entry point to the wallet. On the surface, a one-day feature request.
“Let TT Wallet users buy crypto with credit cards, and clean up the deposit entry points.”
— Product Brief
What I Actually Saw
It's not about missing entry points — the architecture is creating confusion.
When I examined the existing user paths, I found the real issue hidden behind "clean up entry points":
Error Analysis
Error Propagation: From Misunderstanding to Consequence
Small misunderstanding
user enters the flow
Wrong path selected
small error
Proceeds to payment
error grows
Confirms transaction
error locked in
Money lost / Trust broken
large consequence
The user sees the deposit interface but doesn't fully understand what selecting a network means — a subtle but critical gap.
If I just "add an entry point," I'm adding complexity to an already chaotic architecture, making the problem worse.
I proposed to the team: this isn't an "add entry point" problem — it's an "the deposit flow's information architecture needs a redesign" problem. The team agreed to let me redefine the design scope.
First Instinct (v0)
It looked smart. I killed it myself.
Judgment: Overturn your own design when the assumption fails.
My first instinct: since users can't tell which function they need, just ask them.
v0 Perspective
v0: Ask "Do you have crypto?" at the start of the deposit flow → branch to Transfer or Credit Card flow.
“Assumption: users can accurately describe their own state — the product just needs to ask the right question.”
Why I killed v0
Different people interpret "Do you have crypto?" completely differently:
v0 wasn't helping users choose — it was forcing them to make a judgment they couldn't reliably make, then locking them into a potentially wrong path.
Problem Reframing
Final Design
Let users see reality — don't classify them.
After killing v0, I redesigned the entire deposit flow architecture based on three principles.
Side by side, no recommendation
Deposit and Buy Crypto coexist as equals, switchable at any time. No visual recommendation, no Next Best Action, no default path. The system can't know the user's asset situation better than they do.
Visual Evidence / Comparison
Avoiding Recommendation: Intentional Equal Weight
4 action buttons with equal weight — but "Deposit" and "Receive" cause user confusion
4 action buttons with equal weight — but "Deposit" and "Receive" cause user confusion
Intentional equal visual weight: no 'Next Best Action' recommended. User decides.
Intentional equal visual weight: no 'Next Best Action' recommended. User decides.
Design Judgment: Return control to user. Prioritize user autonomy over conversion optimization.
Hover over each phone to see design details
Concrete options over abstract questions
Instead of asking "Do you have crypto?", directly show the supported token list. Users identify their own state through concrete options: which tokens they recognize, which they actually hold, which are currently unavailable.
“This was the core shift from v0 to Final: from "asking users who they are" to "showing reality so users recognize themselves."”
Concrete options over abstract questions
Delayed commitment — fully reversible until the last step
After entering the deposit flow, users can still switch between Buy and Deposit. Token and Network choices remain reversible. Only the final step ("Pay Now") triggers an irreversible action.
Needs Wallet1/2/3.png
Architecture Comparison
From high-risk pipeline to safe exploration zone.
v0 required users to make a judgment before seeing their asset reality — one wrong call cascades into irreversible consequences. The Final design turns every choice into reversible exploration — users can always go back until they press "Pay Now."
Decision Moment
轉化效率
問題分流
快速完成
預測式推薦
Faster conversion
決策安全
並列選項
狀態揭露
延遲承諾
Safer decisions
Side by side, no recommendation
Design Boundary
Design Responsibility Boundary
Acceptable Friction
Respect user autonomy
Decision Time
Users need more time to weigh their options.
Freedom to Exit
Users abandon the flow midway.
Unacceptable Consequences
Prevent irreversible errors
Financial Loss
Users pay for mistakes caused by misunderstanding.
Trust Decline
A huge gap between user expectations and reality.
Design Stance
Honest Disclosure
This case has no quantified outcome data.
I did not obtain production environment data during the tracking phase due to organizational resource allocation changes. The architecture logic was adopted in subsequent versions, indicating team alignment with this design direction. But I cannot provide conversion rate or support ticket before/after numbers.
What I Delivered
- ✓ Redesigned the entire deposit flow information architecture
- ✓ Established "side by side + concrete options + delayed commitment" framework
- ✓ Architecture adopted in subsequent versions
QUANTIFIED DATA
- ✗ No production conversion rate data
- ✗ No support ticket before/after
- → Architecture logic adopted in subsequent versions
Reflections
Three things I learned from reframing a brief.
Feature requests often hide architecture problems.
"Add an entry point" looked like a one-day job. But if I had only added an entry, I'd be stacking complexity onto an already chaotic architecture. A senior designer's value isn't executing faster — it's recognizing "this brief is asking the wrong question" before executing.
Overturning your own design is harder than overturning someone else's — but more valuable.
v0 was my own design, and it was logically sound. Killing it meant admitting "my first instinct was wrong." But if I had stuck with v0 due to sunk cost, users would pay for my ego.
"The system doesn't know the user's state" is an architecture decision.
v0's failure taught me: the system can't know the user's asset situation better than they do. This isn't a UI decision (whether to ask a question) — it's an architecture decision (whether the system should assume it knows who the user is). Choosing "don't assume" reshapes the entire flow structure.