TT Wallet ยท Mobile App ยท 2021โ2023
They asked for an entry point. I delivered an information architecture.
I received a feature request to add a credit card payment entry. I discovered the real problem was a broken deposit flow architecture โ and redesigned the entire system.
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":
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: 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.
v0 vs Final: avoiding visual recommendation โ intentional equal weight
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.
Concrete options over abstract questions
This was the core shift from v0 to Final: from "asking users who they are" to "showing reality so users recognize themselves."
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.
Full flow: no payment yet (reversible) โ user control (step back) โ payment confirmed (irreversible)
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
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.