Before arriving at the final flow, we explored several early concepts. The first option repeated the Send flow (asset → destination), but it broke early validation and recreated the issues seen in support tickets — users could pick tokens incompatible with the selected wallets.
A second option placed Transfer inside the Send section as a nested sub-flow. This made the feature hard to discover and didn’t match its role as a core action.
We moved to a dedicated Transfer entry point on the home screen, allowing a clean linear sequence (From → To → Asset → Amount) and reliable validation between wallets and networks.
A second option placed Transfer inside the Send section as a nested sub-flow. This made the feature hard to discover and didn’t match its role as a core action.
We moved to a dedicated Transfer entry point on the home screen, allowing a clean linear sequence (From → To → Asset → Amount) and reliable validation between wallets and networks.
6. First Iterations
This structure removed unnecessary decisions, reduced the chance of network-selection errors, and made the scenario easy to understand from the first screen.
FROM → TO → Asset → Amount → Confirmation
The old flow required 7−9 fragmented steps and relied heavily on manual actions.
The new flow was rebuilt around a single, predictable entry point — Transfer — and a clear linear sequence:
The new flow was rebuilt around a single, predictable entry point — Transfer — and a clear linear sequence:
7. Transfer
I adapted the flow for two environments — the mobile app and Telegram Mini App. Cross-platform work was supported by a unified pattern system, reducing adaptation time by ~30%.
11. Multi-platform: Mobile + TMA
QA also reported significantly fewer dead-end scenarios and fewer cases where users could get stuck without a clear next action.
During internal testing, it became clear that the new step structure helped users progress through the flow with fewer mistakes and less confusion.
8. Testing & Validation
The new flow needed to reduce the number of actions and make the scenario safe — especially for newcomers who don’t fully understand networks.
Simplify and speed up "self-transfer" between user wallets, remove manual steps, and introduce early validation for networks, balances, and restrictions.
2. Business Objective
3. My Role
Every decision went through product calls, design critiques, and design reviews. Alongside feature delivery, I helped maintain design-system consistency together with the rest of the design team.
As a Product Designer, I worked with the CPO, product design lead, art director, product managers, developers, and QA.
12. Result
A linear step structure cut completion time by ~50%, skeleton screens delivered a sub-second perceived load, and unified patterns kept behavior identical across mobile and TMA. The complete UX documentation — constraints, validation rules, maps, and prototypes — ensured smooth delivery of 30+ flows and aligned design, product, and engineering around a single model of the feature.
The final solution replaced a scattered, manual process with a predictable, safe, and scalable transfer flow. Early validation removed most network-selection mistakes and significantly reduced repeated attempts.
10. Release & Handoff
The flow passed internal checks by development and QA and was ready for release.
The UX documentation included:
— a constraints summary describing supported networks and tokens,
— a transition map for 20+ screens,
— an error-handling specification,
— an interactive prototype.
— a constraints summary describing supported networks and tokens,
— a transition map for 20+ screens,
— an error-handling specification,
— an interactive prototype.
9. UX System & Consistency
All visual logic was synchronized with the design system through regular reviews with designers and the art director.
To improve perceived speed and ensure visual stability, I designed 50+ skeleton screens. Skeletons and the launch animation ensured a near-instant loading experience (<1 sec).
5. Research
I started with a revision of the existing flow and support tickets — users often confused networks and attempted transfers across incompatible blockchains. A common case was mixing up identically named tokens like USDT (ERC20) and USDT (BEP20), overlooking the network difference.
To identify reliable UX patterns, I ran a competitor analysis of 20+ products (Binance, Crypto.com, MEXC, Bybit, Trust Wallet). This helped define early-validation rules, filtering logic, and a predictable step structure.
Alongside qualitative research, I evaluated core UX signals during design and testing — error-prone steps, repeated attempts, and major support themes. These insights shaped the structure of the new flow and informed the early-validation logic. Resulting insights shaped a structure that later reduced the completion time of the task by ~50%.
To identify reliable UX patterns, I ran a competitor analysis of 20+ products (Binance, Crypto.com, MEXC, Bybit, Trust Wallet). This helped define early-validation rules, filtering logic, and a predictable step structure.
Alongside qualitative research, I evaluated core UX signals during design and testing — error-prone steps, repeated attempts, and major support themes. These insights shaped the structure of the new flow and informed the early-validation logic. Resulting insights shaped a structure that later reduced the completion time of the task by ~50%.
4. Requirements
The logic also had to remain identical across Mobile and TMA so users wouldn’t face different rules on different platforms.
The flow had to reflect technical constraints:
— incompatible networks (e.g., ERC20/BSC),
— unavailable tokens,
— insufficient balance to cover gas fees,
— KYC requirements.
— incompatible networks (e.g., ERC20/BSC),
— unavailable tokens,
— insufficient balance to cover gas fees,
— KYC requirements.
End-to-end design of a transfer flow for a 6M+ user crypto wallet, turning a fragmented manual journey into a single predictable scenario. The flow was built on support data, error audits, and a full set of UX documentation.
Crypto FinTech Start-up
1. Context
The original transfer flow was stitched together from separate fragments: users had to copy the wallet address manually, return to the main screen, navigate to the Send section, paste the address, pick the network, verify network compatibility, check the balance for gas fees — only then could they send the transaction.
The process took 7–9 steps and produced high support load due to repeated errors and unclear validation.
The process took 7–9 steps and produced high support load due to repeated errors and unclear validation.
A crypto wallet where users manage both CeFi and DeFi balances.