Fintech · Web3
Designing a High-Stakes DeFi Bridge Experience
Users made irreversible, high-value decisions with zero visibility once execution started. I designed for trust at every stage (before, during, and after), as the sole designer on a 12+ person product team.
ThorFi: Eclipse (DeFi Bridge)
2 months (2023)
PO/PM, ~10 developers, 1 Creative Director, Marketing team
Crypto-native Avalanche users
End-to-end UX/UI Designer, sole designer
Figma, FigJam
Challenge
Eclipse is a Web3 DApp on Avalanche: on-chain financial infrastructure and wallet UX, not just a crypto interface. The core feature: a blockchain bridge, moving tokens across networks. The central question: how might we reduce uncertainty across the entire experience (before, during, and after execution) while keeping a highly complex system simple and trustworthy?
The gap wasn’t a single broken screen. It was the distance between what users see (connect wallet → select network/token → review fees → approve and sign) and what’s actually happening (multiple transactions executing behind the scenes, routing logic, liquidity dependencies, unpredictable execution time). Users made an irreversible, high-stakes decision upfront, then lost control the moment the transaction started.
Research here didn’t follow a conventional path: design and product proposed the topics, community specialists gathered data directly from users on Discord, and several proposals went back to the community for a vote before shipping, closer to DAO-style governance than a standard research process.
Constraints: a fixed ~2-month roadmap, speed vs. quality with no room to sacrifice trust, and alignment with existing DeFi conventions rather than inventing new patterns from scratch.
Results
A production-ready bridge flow delivered in ~2 months, well received by early users and stakeholders based on community feedback.
There was no usability testing before launch and no usage metrics afterward. The only validation came from qualitative community signals. That wasn’t an oversight: when time is tight, testing is usually the first thing cut, and that loss gets compensated by leaning on patterns users already know. That’s exactly why aligning with Web3 standards was a constraint from day one, not just a preference. Given the choice, tracking usage metrics from the start would have turned a well-received flow into a provably effective one.
Solo
Designer on a 12+ person team
2 months
Timeline
Process
Research: heuristic analysis, benchmarking against other DeFi/Web3 products, community research via Discord, information architecture work, and early dev validation followed by design critiques before final UI. Designing payment flows this high-stakes meant validating direction with engineering before polishing pixels, the same stakeholder management and cross-functional collaboration with the Creative Director, PO, and developers that shaped every decision here.
Before execution: reducing the moment of highest risk
· Progressive disclosure: bridge details collapsed by default, “view more” expands fees, slippage, and minimum received
· Safe exploration: users could simulate the bridge without connecting a wallet
· Smart defaults: best route auto-selected by lowest cost
· Token icons instead of technical text, for routes understandable at a glance
During execution: building trust in real time
· A dynamic CTA evolving with system state: Connect → Approve → Awaiting Approval → Bridge → Bridging
· Real-time feedback while routes calculate and the bridge runs
· Transparent outcomes: success toasts linking to Snowtrace for independent verification, error toasts with clear next steps
Conclusion
Testing is always my first choice. Without evidence, decisions tend to turn into opinions, and teams end up arguing in circles instead of moving forward. Here, the timeline didn’t allow for it. Rather than let that turn into another guessing game, I anchored decisions in something more solid than opinion, widely recognized UX principles: progressive disclosure, showing users the information they expect at each step, clear system feedback, and guidance through complexity. The real challenge was understanding what was happening underneath well enough to translate it into something simple. That understanding is what made the call defensible, not just convenient.
Kuala Lumpur, APAC
