Designing Trust in Crypto Withdrawal (On-chain)
By analyzing behavioral data and support signals, I identified that the issue was not usability, but a lack of transparency around system processes. This project focused on reducing uncertainty, building trust, and improving withdrawal completion.
What I did
Funneling optimization
Behavioral data analysis
Problem framing
Interaction design
Cross-functional collaboration
Collaboration
Nontawan Mesakulroong (PM)
Jesada Hongsi (FE)
Sukit Kajonpradapkul (BI)
Sutthikan Singkhonart (CS)
Company
Timeline
Feb - Mar 2026
Background
Overview
Bitazza is a cryptocurrency exchange based in Thailand. It allows users to buy, sell, and trade digital assets on both web and mobile.
At the time, the withdrawal flow had clear issues. Users dropped off at different steps. Many also contacted support during processing. Even though most withdrawals were completed quickly, some took longer than expected. During this time, users had no visibility into what was happening. They started to worry if something went wrong.
My role
I led the end-to-end redesign of the crypto withdrawal experience, focusing on understanding user behavior across the funnel and identifying root causes behind drop-offs and support escalation. Based on this, I defined the main problems and designed solutions to reduce uncertainty, build trust, and improve completion.
How crypto withdrawal works
Before diving in, here’s a quick overview of how crypto withdrawal works on a centralized exchange (CEX):
- External withdrawal (on-chain): transfer crypto to another exchange or personal wallet
- Internal withdrawal: transfer crypto to another account within the same platform
This case study focuses on external withdrawal (on-chain) as below:
Understanding the issues we’re facing
During the last two quarter of 2025, despite a functional withdrawal flow, Bitazza witnessed a dropping off at multiple stages. At the same time, support tickets revealed high user anxiety during processing, even though most transactions were completed within minutes.
To understand this better, I decided to look at the full user journey.
Reading the funnel
Looking at the funnel, I could see where users were dropping off, but not exactly why. Some reasons could be inferred, but they were still my assumptions. To get a clearer picture, I scheduled a session with PMs, dev leads, QCs, and BAs to walk through each drop-off together and validate what might be happening behind the scenes.
20.4 % drop off when click Withdraw menu button
42.1 % drop off when landing at Withdrawal flow
22.2% Drop off at the final withdrawal form screen
While the funnel helped us identify where users were dropping off, it did not fully explain why. Ideally, we would go one step deeper and segment users to uncover different behavioral patterns. However, due to limitations in available data, we did not have the opportunity to explore the problem at that level.
If we had the opportunity to perform segmentation, how could it change the way we understand the drop-off? 🤔
As a result, the following insights should be treated as hypotheses, informed by funnel patterns and domain knowledge.
20.4 % drop off when click Withdraw menu button
Finding
From engineering logs and internal discussion, the majority of drop-offs at this step are caused by users who haven’t completed KYC. Crash and performance issues exist but are relatively minor.
Insight
This is not a usability issue within the withdrawal flow, but a gating issue where users attempt actions they are not yet eligible for.
42.1 % drop off when landing at Withdrawal flow
Finding
- Users are required to select coin and network before seeing full withdrawal details
- Network selection is a high-risk decision(wrong network → loss of funds)
Insight
We hypothesize this drop-off is driven by decision anxiety under uncertainty. Users hesitate maybe because:
- They are asked to make a high-risk decision (network selection)
- Without sufficient info (fees, processing time, compatibility)
- And without clear guidance or reassurance
22.2% Drop off at the final withdrawal form screen
Finding
- Users must input wallet address manually
- A warning about irreversible loss appears at this stage
- No strong validation feedback is provided before submission
Insight
We hypothesize this drop-off is driven by fear of making irreversible mistakes, not just cognitive load. Users hesitate maybe because:
- Entering a wallet address feels error-prone and high-risk
- The system emphasizes risk (loss warning) without providing enough safety reassurance
- There is limited validation or confidence-building feedback before committing
👉 The funnel revealed a clear pattern: users were not blocked by usability issues, but appeared to hesitate before proceeding. Although we could not validate this through deeper segmentation, the data suggests that uncertainty, perceived risk, and low confidence may be driving this behavior. We therefore treat this hesitation as a key hypothesis behind the low conversion rate (~34%).
What we learned from BI data
However, the funnel above captures only what happens until users confirm their withdrawal via email. Completing the form does not mean the experience is over. Once users confirm the request, they enter a processing phase, where control shifts from the user to the system. And we didn’t have visibility into that part.
So I decided to reach out the BI team. I initially looked into success rate. But it turned out to be less useful, since most withdrawals were technically successful. At this time, what happens before that is more meaningful. That's why I shifted the focus to processing time instead. And here is the data from BI team:
- Avg Processing time: 3.87 mins
- 90% cases is below 5 mins
At first glance, the system seemed to work well. Most withdrawals were processed within minutes. But users didn’t experience it that way. According to the Support logs, many users still reported that their withdrawal was “taking too long” or felt unsure about what was happening. This revealed a gap between how the system performed and how users perceived it.
During the processing time, users see “processing” status and wait till their asset is transferred to the receiving wallet.
To understand this gap better, I looked into insights from the Customer Support team.
What support tickets revealed
Over the last two quarters of 2025, there were around 24 cases where users contacted support because they felt their withdrawals processing were taking too long or were unsure about the status of their funds.
From internal investigation, we found that not all “processing” cases are the same. While most transactions are processed quickly, some withdrawals are held due to risk screening (Anti-Money Laundering compliance checks). In these cases, the system does not immediately send the funds to the blockchain. However, from the user’s perspective, all of these cases appear the same, they only see a generic “processing” status. This made users feel uncertain and nervous. Many ended up contacting support to check what was going on.
The sad thing is the 24 cases above were those that failed the AML compliance, meaning that they would need to take some additional steps first to be eligible for crypto withdrawal. This caused these users frustration because they were not informed. From their perspective, the withdrawal was still “processing”. In reality, it was stuck.
👉 The processing status lack of transparency. This creates uncertainty, making users anxious as they cannot tell whether their transaction is progressing normally or facing an issue.
Putting it all together
Key pain points we uncovered
Bringing these findings together, the core issue is not simply usability or system performance, but user confidence throughout the withdrawal journey.
🔴 Users may hesitate to proceed due to uncertainty and perceived risk
During the flow, users are required to make high-stakes decisions (e.g. network selection, wallet address) without sufficient clarity. This suggests that uncertainty and perceived risk may be contributing to hesitation and drop-off.
Insights from: Product Data
🔴 Users feel anxious when control shifts to the system
After submission, users lose visibility into what is happening, creating uncertainty and a lack of confidence during the processing phase, especially when the waiting time is long.
Insights from: BI and CS
Design goals moving forward
Based on the above pain point, I defined two design principles to guide the solution:
🎯 Help users proceed with confidence before submitting a withdrawal
Reduce hesitation by making key info clear and supporting users in making safe decisions.
🎯 Goal 2: Reduce user anxiety during the processing phase
Ensure users feel informed and reassured even when the system is handling the transaction.
How I Would Measure Success
1. Leading indicators
Measures whether users feel more confident and move through the flow with less hesitation
Time to completion
Drop-off rate at high-risk steps
User-reported confidence and clarity (via survey or feedback)
Support contact rate related to withdrawal
2. Business outcomes
Measures whether improved confidence translates into business impact
Support volume related to withdrawal
Withdrawal completion rate
Designing the solution
Before moving into high-fidelity designs, I ran a walkthrough session with PMs, BAs, engineers, and QCs to validate the flow early and gather feedback from different perspectives.
During this discussion, we explored two possible approaches for handling users who are not eligible to withdraw (e.g. incomplete KYC or unmet AML requirements):
- Block users from initiating the withdrawal flow upfront to save their time
- Allow users to explore the flow and apply gating at the final step
Internal discussion
Option 1
Option 2
We chose option 2 because:Early gating can make the conversion rate look better by filtering out users who are not eligible. However, this does not actually increase the number of users who successfully complete withdrawals. By allowing users to explore the flow first, they can better understand the requirements and are more likely to complete the process.
Users see all key details upfront. Fees, time, and amount are visible before they proceed. They are also informed that the withdrawal might just take a few minutes.
👉 Reducing uncertainty before commitment
Validation happens early. We guide users before they make a wrong choice.
👉 Preventing mistakes before they happen.
Users understand the risk clearly. They know the network must match before picking.
👉 Helping them make safer decisions
We check inputs in real time. Users get feedback as they enter details.
👉 Giving immediate feedback and confidence
Users see what they will receive. The final amount is clear before confirming...
👉 Making outcomes predictable before confirming
Withdrawal
Users controlled-stage
Final design
Goal 1: Help users proceed with confidence before submitting a withdrawal
Goal 2: Reduce user anxiety during the processing phase
Users can track their withdrawal status. They know what is happening and what to expect next
👉 Giving users a sense of control, reducing uncertainty and anxiety
Users are informed about the required verification steps upfront, while still being able to preview the withdrawal process.
👉 This may help first-time users better understand what is needed before committing to setup requirements.
Users receive clear confirmation when completed. They can track the transaction on-chain if needed
👉 Reinforcing trust and reducing anxiety
System checking
Withdrawal screens...
Withdrawal
System processing stage
Withdrawal
Some users are not eligible for withdrawal, the system ask them to take actions from the beginning to avoid withdrawal failure later
Reflection
We won’t always have all the data we need
One limitation I faced was the lack of certain metrics, especially completion time. This made it harder to fully understand how long users were at each step and how that affected their experience. Because of that, I had to rely on patterns from user behavior and support data to form hypotheses. It worked to some extent, but it also showed me how important proper tracking is from the beginning.
Without segmentation, funnel data can be misleading
I also realized that funnel numbers can sometimes make a problem look more general than it actually is. A high drop-off rate does not always mean every user is struggling in the same way.
Through segmentation, we can start seeing which specific groups are affected more heavily, under what conditions, and what behavioral patterns might be contributing to the problem. That deeper context can completely change how we form product hypotheses and approach design decisions.
If we had the opportunity to perform segmentation, how could it change the way we understand the drop-off? 🤔
Acknowledgement
This project was shaped by close collaboration across teams.
Special thanks to Jesada Hongsi (Frontend Engineer) for managing the Google Analytics setup, making sure events were tracked correctly, and sharing internal training on how to read product data. Sukit Kajonpradapkul (Business Intelligence) helped surface key data around processing time, which clarified what actually happens after users submit a withdrawal. Finally, Sutthikan Singkhonart (Customer Support) shared insights from AML-related support cases, helping uncover the real reasons behind user concerns and incoming calls.
I also want to thank all PMs, BAs, QCs, and engineers who joined the working sessions. Their input helped validate assumptions, highlight constraints, and shape more realistic solutions.
More case studies
Redesigning Crypto Wallet to Improve Asset Engagement
Increase wallet engagement and reduce friction between portfolio monitoring and trading actions.
Read case study
Designing a Dispute Workflow for Sidekick CRM
Enabling frontline agents to create and track dispute cases directly inside Sidekick.
Read case study
Let's work together
Feel free to reach out. I’d love to hear what you’re working on.
Work
About me
Notes
Gallery
Contact
Designing Trust in Crypto Withdrawal (On-chain)
By analyzing behavioral data and support signals, I identified that the issue was not usability, but a lack of transparency around system processes. This project focused on reducing uncertainty, building trust, and improving withdrawal completion.
What I did
Funneling optimization
Behavioral data analysis
Problem framing
Interaction design
Cross-functional collaboration
Collaboration
Nontawan (PM)
Jesada (FE)
Sukit (BI)
Sutthikan (CS)
Company
Timeline
Feb - Mar 2026
Background
Overview
Bitazza is a cryptocurrency exchange based in Thailand. It allows users to buy, sell, and trade digital assets on both web and mobile.
At the time, the withdrawal flow had clear issues. Users dropped off at different steps. Many also contacted support during processing. Even though most withdrawals were completed quickly, some took longer than expected. During this time, users had no visibility into what was happening. They started to worry if something went wrong.
My role
I led the end-to-end redesign of the crypto withdrawal experience, focusing on understanding user behavior across the funnel and identifying root causes behind drop-offs and support escalation. Based on this, I defined the main problems and designed solutions to reduce uncertainty, build trust, and improve completion.
How crypto withdrawal works
Before diving in, here’s a quick overview of how crypto withdrawal works on a centralized exchange (CEX):
- External withdrawal (on-chain): transfer crypto to another exchange or personal wallet
- Internal withdrawal: transfer crypto to another account within the same platform
This case study focuses on external withdrawal (on-chain) as below:
Understanding the issues we’re facing
During the last two quarter of 2025, despite a functional withdrawal flow, Bitazza witnessed a dropping off at multiple stages. At the same time, support tickets revealed high user anxiety during processing, even though most transactions were completed within minutes.
To understand this better, I decided to look at the full user journey.
Reading the funnel
Looking at the funnel, I could see where users were dropping off, but not exactly why. Some reasons could be inferred, but they were still my assumptions. To get a clearer picture, I scheduled a session with PMs, dev leads, QCs, and BAs to walk through each drop-off together and validate what might be happening behind the scenes.
20.4 % drop off when click Withdraw menu button
42.1 % drop off when landing at Withdrawal flow
22.2% Drop off at the final withdrawal form screen
While the funnel helped us identify where users were dropping off, it did not fully explain why. Ideally, we would go one step deeper and segment users to uncover different behavioral patterns. However, due to limitations in available data, we did not have the opportunity to explore the problem at that level.
If we had the opportunity to perform segmentation, how could it change the way we understand the drop-off? 🤔
As a result, the following insights should be treated as hypotheses, informed by funnel patterns and domain knowledge.
20.4 % drop off when click Withdraw menu button
Finding
From engineering logs and internal discussion, the majority of drop-offs at this step are caused by users who haven’t completed KYC. Crash and performance issues exist but are relatively minor.
Insight
This is not a usability issue within the withdrawal flow, but a gating issue where users attempt actions they are not yet eligible for.
42.1 % drop off when landing at Withdrawal flow
Finding
- Users are required to select coin and network before seeing full withdrawal details
- Network selection is a high-risk decision(wrong network → loss of funds)
Insight
We hypothesize this drop-off is driven by decision anxiety under uncertainty. Users hesitate maybe because:
- They are asked to make a high-risk decision (network selection)
- Without sufficient info (fees, processing time, compatibility)
- And without clear guidance or reassurance
22.2% drop off at the final withdrawal form screen
Finding
- Users must input wallet address manually
- A warning about irreversible loss appears at this stage
- No strong validation feedback is provided before submission
Insight
We hypothesize this drop-off is driven by fear of making irreversible mistakes, not just cognitive load. Users hesitate maybe because:
- Entering a wallet address feels error-prone and high-risk
- The system emphasizes risk (loss warning) without providing enough safety reassurance
- There is limited validation or confidence-building feedback before committing
👉 The funnel revealed a clear pattern: users were not blocked by usability issues, but appeared to hesitate before proceeding. Although we could not validate this through deeper segmentation, the data suggests that uncertainty, perceived risk, and low confidence may be driving this behavior. We therefore treat this hesitation as a key hypothesis behind the low conversion rate (~34%).
What we learned from BI data
However, the funnel above captures only what happens until users confirm their withdrawal via email. Completing the form does not mean the experience is over. Once users confirm the request, they enter a processing phase, where control shifts from the user to the system. And we didn’t have visibility into that part.
So I decided to reach out the BI team. I initially looked into success rate. But it turned out to be less useful, since most withdrawals were technically successful. At this time, what happens before that is more meaningful. That's why I shifted the focus to processing time instead. And here is the data from BI team:
- Avg Processing time: 3.87 mins
- 90% cases is below 5 mins
At first glance, the system seemed to work well. Most withdrawals were processed within minutes. But users didn’t experience it that way. According to the Support logs, many users still reported that their withdrawal was “taking too long” or felt unsure about what was happening. This revealed a gap between how the system performed and how users perceived it.
During the processing time, users see “processing” status and wait till their asset is transferred to the receiving wallet.
To understand this gap better, I looked into insights from the Customer Support team.
What support tickets revealed
Over the last two quarters of 2025, there were around 24 cases where users contacted support because they felt their withdrawals processing were taking too long or were unsure about the status of their funds.
From internal investigation, we found that not all “processing” cases are the same. While most transactions are processed quickly, some withdrawals are held due to risk screening (Anti-Money Laundering compliance checks). In these cases, the system does not immediately send the funds to the blockchain. However, from the user’s perspective, all of these cases appear the same, they only see a generic “processing” status. This made users feel uncertain and nervous. Many ended up contacting support to check what was going on.
The sad thing is the 24 cases above were those that failed the AML compliance, meaning that they would need to take some additional steps first to be eligible for crypto withdrawal. This caused these users frustration because they were not informed. From their perspective, the withdrawal was still “processing”. In reality, it was stuck.
👉 The processing status lack of transparency. This creates uncertainty, making users anxious as they cannot tell whether their transaction is progressing normally or facing an issue.
Putting it all together
Key pain points we uncovered
Bringing these findings together, the core issue is not simply usability or system performance, but user confidence throughout the withdrawal journey.
🔴 Users may hesitate to proceed due to uncertainty and perceived risk
During the flow, users are required to make high-stakes decisions (e.g. network selection, wallet address) without sufficient clarity. This suggests that uncertainty and perceived risk may be contributing to hesitation and drop-off.
Insights from: Product Data
🔴 Users feel anxious when control shifts to the system
After submission, users lose visibility into what is happening, creating uncertainty and a lack of confidence during the processing phase, especially when the waiting time is long.
Insights from: BI and CS
Design goals moving forward
Based on the above pain point, I defined two design principles to guide the solution:
🎯 Help users proceed with confidence before submitting a withdrawal
Reduce hesitation by making key info clear and supporting users in making safe decisions.
🎯 Goal 2: Reduce user anxiety during the processing phase
Ensure users feel informed and reassured even when the system is handling the transaction.
How I Would Measure Success
1. Leading indicators
Measures whether users feel more confident and move through the flow with less hesitation
Time to completion
Drop-off rate at high-risk steps
User-reported confidence and clarity (via survey or feedback)
Support contact rate related to withdrawal
2. Business outcomes
Measures whether improved confidence translates into business impact
Support volume related to withdrawal
Withdrawal completion rate (proxy for trust)
Designing the solution
Before moving into high-fidelity designs, I ran a walkthrough session with PMs, BAs, engineers, and QCs to validate the flow early and gather feedback from different perspectives.
During this discussion, we explored two possible approaches for handling users who are not eligible to withdraw (e.g. incomplete KYC or unmet AML requirements):
- Block users from initiating the withdrawal flow upfront to save their time
- Allow users to explore the flow and apply gating at the final step
Internal discussion
Option 1
Option 2
We chose option 2 because:Early gating can make the conversion rate look better by filtering out users who are not eligible. However, this does not actually increase the number of users who successfully complete withdrawals. By allowing users to explore the flow first, they can better understand the requirements and are more likely to complete the process.
Final design
Goal 1: Help users proceed with confidence before submitting a withdrawal
Users see all key details upfront. Fees, time, and amount are visible before they proceed. They are also informed that the withdrawal might just take a few minutes.
👉 Reducing uncertainty before commitment
Validation happens early. We guide users before they make a wrong choice.
👉 Preventing mistakes before they happen.
Users understand the risk clearly. They know the network must match before picking.
👉 Helping them make safer decisions
We check inputs in real time. Users get feedback as they enter details.
👉 Giving immediate feedback and confidence
Users see what they will receive. The final amount is clear before confirming...
👉 Making outcomes predictable before confirming
Withdrawal
Users controlled-stage
Goal 2: Reduce user anxiety during the processing phase
Users can track their withdrawal status. They know what is happening and what to expect next
👉 Giving users a sense of control, reducing uncertainty and anxiety
Users are informed about the required verification steps upfront, while still being able to preview the withdrawal process.
👉 This may help first-time users better understand what is needed before committing to setup requirements.
Users receive clear confirmation when completed. They can track the transaction on-chain if needed
👉 Reinforcing trust and reducing anxiety
System checking
Withdrawal screens...
Withdrawal
System processing stage
Withdrawal
Some users are not eligible for withdrawal, the system ask them to take actions from the beginning to avoid withdrawal failure later
Reflection
We won’t always have all the data we need
One limitation I faced was the lack of certain metrics, especially completion time. This made it harder to fully understand how long users were at each step and how that affected their experience. Because of that, I had to rely on patterns from user behavior and support data to form hypotheses. It worked to some extent, but it also showed me how important proper tracking is from the beginning.
We won’t always have all the data we need
One limitation I faced was the lack of certain metrics, especially completion time. This made it harder to fully understand how long users were at each step and how that affected their experience. Because of that, I had to rely on patterns from user behavior and support data to form hypotheses. It worked to some extent, but it also showed me how important proper tracking is from the beginning.
If we had the opportunity to perform segmentation, how could it change the way we understand the drop-off? 🤔
Acknowledgement
This project was shaped by close collaboration across teams.
Special thanks to Jesada Hongsi (Frontend Engineer) for managing the Google Analytics setup, making sure events were tracked correctly, and sharing internal training on how to read product data. Sukit Kajonpradapkul (Business Intelligence) helped surface key data around processing time, which clarified what actually happens after users submit a withdrawal. Finally, Sutthikan Singkhonart (Customer Support) shared insights from AML-related support cases, helping uncover the real reasons behind user concerns and incoming calls.
I also want to thank all PMs, BAs, QCs, and engineers who joined the working sessions. Their input helped validate assumptions, highlight constraints, and shape more realistic solutions.
More case studies
Redesigning Crypto Wallet to Improve Asset Engagement
Increase wallet engagement and reduce friction between portfolio monitoring and trading actions.
Read case study
Designing a Dispute Workflow for Sidekick CRM
Enabling frontline agents to create and track dispute cases directly inside Sidekick.
Read case study
Let's work together
Feel free to reach out. I’d love to hear what you’re working on.
Work
About me
Notes
Gallery
Contact
Designing Trust in Crypto Withdrawal (On-chain)
By analyzing behavioral data and support signals, I identified that the issue was not usability, but a lack of transparency around system processes. This project focused on reducing uncertainty, building trust, and improving withdrawal completion.
What I did
Funneling optimization
Behavioral data analysis
Problem framing
Interaction design
Cross-functional collaboration
Collaboration
Nontawan Mesakulroong (PM)
Jesada Hongsi (FE)
Sukit Kajonpradapkul (BI)
Sutthikan Singkhonart (CS)
Company
Timeline
Feb - Mar 2026
Background
Overview
Bitazza is a cryptocurrency exchange based in Thailand. It allows users to buy, sell, and trade digital assets on both web and mobile.
At the time, the withdrawal flow had clear issues. Users dropped off at different steps. Many also contacted support during processing. Even though most withdrawals were completed quickly, some took longer than expected. During this time, users had no visibility into what was happening. They started to worry if something went wrong.
My role
I led the end-to-end redesign of the crypto withdrawal experience, focusing on understanding user behavior across the funnel and identifying root causes behind drop-offs and support escalation. Based on this, I defined the main problems and designed solutions to reduce uncertainty, build trust, and improve completion.
How crypto withdrawal works
Before diving in, here’s a quick overview of how crypto withdrawal works on a centralized exchange (CEX):
- External withdrawal (on-chain): transfer crypto to another exchange or personal wallet
- Internal withdrawal: transfer crypto to another account within the same platform
This case study focuses on external withdrawal (on-chain) as below:
Understanding the issues we’re facing
During the last two quarter of 2025, despite a functional withdrawal flow, Bitazza witnessed a dropping off at multiple stages. At the same time, support tickets revealed high user anxiety during processing, even though most transactions were completed within minutes.
To understand this better, I decided to look at the full user journey.
Reading the funnel
Looking at the funnel, I could see where users were dropping off, but not exactly why. Some reasons could be inferred, but they were still my assumptions. To get a clearer picture, I scheduled a session with PMs, dev leads, QCs, and BAs to walk through each drop-off together and validate what might be happening behind the scenes.
20.4 % drop off when click Withdraw menu button
42.1 % drop off when landing at Withdrawal flow
22.2% Drop off at the final withdrawal form screen
While the funnel helped us identify where users were dropping off, it did not fully explain why. Ideally, we would go one step deeper and segment users to uncover different behavioral patterns. However, due to limitations in available data, we did not have the opportunity to explore the problem at that level.
If we had the opportunity to perform segmentation, how could it change the way we understand the drop-off? 🤔
As a result, the following insights should be treated as hypotheses, informed by funnel patterns and domain knowledge.
20.4 % drop off when click Withdraw menu button
Finding
From engineering logs and internal discussion, the majority of drop-offs at this step are caused by users who haven’t completed KYC. Crash and performance issues exist but are relatively minor.
Insight
This is not a usability issue within the withdrawal flow, but a gating issue where users attempt actions they are not yet eligible for.
42.1 % drop off when landing at Withdrawal flow
Finding
- Users are required to select coin and network before seeing full withdrawal details
- Network selection is a high-risk decision(wrong network → loss of funds)
Insight
We hypothesize this drop-off is driven by decision anxiety under uncertainty. Users hesitate maybe because:
- They are asked to make a high-risk decision (network selection)
- Without sufficient info (fees, processing time, compatibility)
- And without clear guidance or reassurance
22.2% drop off at the final withdrawal form screen
Finding
- Users must input wallet address manually
- A warning about irreversible loss appears at this stage
- No strong validation feedback is provided before submission
Insight
We hypothesize this drop-off is driven by fear of making irreversible mistakes, not just cognitive load. Users hesitate maybe because:
- Entering a wallet address feels error-prone and high-risk
- The system emphasizes risk (loss warning) without providing enough safety reassurance
- There is limited validation or confidence-building feedback before committing
👉 The funnel revealed a clear pattern: users were not blocked by usability issues, but appeared to hesitate before proceeding. Although we could not validate this through deeper segmentation, the data suggests that uncertainty, perceived risk, and low confidence may be driving this behavior. We therefore treat this hesitation as a key hypothesis behind the low conversion rate (~34%).
What we learned from BI data
However, the funnel above captures only what happens until users confirm their withdrawal via email. Completing the form does not mean the experience is over. Once users confirm the request, they enter a processing phase, where control shifts from the user to the system. And we didn’t have visibility into that part.
So I decided to reach out the BI team. I initially looked into success rate (98.3%). But it turned out to be less useful, since most withdrawals were technically successful. At this time, what happens before that is more meaningful. That's why I shifted the focus to processing time instead. And here is the data from BI team:
- Avg Processing time: 3.87 mins
- 90% cases is below 5 mins
At first glance, the system seemed to work well. Most withdrawals were processed within minutes. But users didn’t experience it that way. According to the Support logs, many users still reported that their withdrawal was “taking too long” or felt unsure about what was happening. This revealed a gap between how the system performed and how users perceived it.
During the processing time, users see “processing” status and wait till their asset is transferred to the receiving wallet.
To understand this gap better, I looked into insights from the Customer Support team.
What support tickets revealed
Over the last two quarters of 2025, there were around 24 cases where users contacted support because they felt their withdrawals processing were taking too long or were unsure about the status of their funds.
From internal investigation, we found that not all “processing” cases are the same. While most transactions are processed quickly, some withdrawals are held due to risk screening (Anti-Money Laundering compliance checks). In these cases, the system does not immediately send the funds to the blockchain. However, from the user’s perspective, all of these cases appear the same, they only see a generic “processing” status. This made users feel uncertain and nervous. Many ended up contacting support to check what was going on.
The sad thing is the 24 cases above were those that failed the AML compliance, meaning that they would need to take some additional steps first to be eligible for crypto withdrawal. This caused these users frustration because they were not informed. From their perspective, the withdrawal was still “processing”. In reality, it was stuck.
👉 The processing status lack of transparency. This creates uncertainty, making users anxious as they cannot tell whether their transaction is progressing normally or facing an issue.
Putting it all together
Key pain points we uncovered
Bringing these findings together, the core issue is not simply usability or system performance, but user confidence throughout the withdrawal journey.
🔴 Users may hesitate to proceed due to uncertainty and perceived risk
During the flow, users are required to make high-stakes decisions (e.g. network selection, wallet address) without sufficient clarity. This suggests that uncertainty and perceived risk may be contributing to hesitation and drop-off.
Insights from: Product Data
🔴 Users feel anxious when control shifts to the system
After submission, users lose visibility into what is happening, creating uncertainty and a lack of confidence during the processing phase, especially when the waiting time is long.
Insights from: BI and CS
Design goals moving forward
Based on the above pain point, I defined two design principles to guide the solution:
🎯 Goal 1: Help users proceed with confidence before submitting a withdrawal
Reduce hesitation by making key info clear and supporting users in making safe decisions.
🎯 Goal 2: Reduce user anxiety during the processing phase
Ensure users feel informed and reassured even when the system is handling the transaction.
How I Would Measure Success
1. Leading indicators
Measures whether users feel more confident and move through the flow with less hesitation
Drop-off rate at high-risk steps
Time to completion
Support contact rate related to withdrawal
User-reported confidence and clarity (via survey or feedback)
2. Business outcomes
Measures whether improved confidence translates into business impact
Support volume related to withdrawal
Withdrawal completion rate
Designing the solution
Internal discussion
Before moving into high-fidelity designs, I ran a walkthrough session with PMs, BAs, engineers, and QCs to validate the flow early and gather feedback from different perspectives.
During this discussion, we explored two possible approaches for handling users who are not eligible to withdraw (e.g. incomplete KYC or unmet AML requirements):
- Block users from initiating the withdrawal flow upfront to save their time
- Allow users to explore the flow and apply gating at the final step
Option 1
Option 2
We chose option 2 because:Early gating can make the conversion rate look better by filtering out users who are not eligible. However, this does not actually increase the number of users who successfully complete withdrawals. By allowing users to explore the flow first, they can better understand the requirements and are more likely to complete the process.
Final design
Goal 1: Help users proceed with confidence before submitting a withdrawal
Users see all key details upfront. Fees, time, and amount are visible before they proceed. They are also informed that the withdrawal might just take a few minutes.
👉 Reducing uncertainty before commitment
Validation happens early. We guide users before they make a wrong choice.
👉 Preventing mistakes before they happen.
Users understand the risk clearly. They know the network must match before picking.
👉 Helping them make safer decisions
We check inputs in real time. Users get feedback as they enter details.
👉 Giving immediate feedback and confidence
Users see what they will receive. The final amount is clear before confirming...
👉 Making outcomes predictable before confirming
Withdrawal
Users controlled-stage
Goal 2: Reduce user anxiety during the processing phase
Users can track their withdrawal status. They know what is happening and what to expect next
👉 Giving users a sense of control, reducing uncertainty and anxiety
Users are informed about the required verification steps upfront, while still being able to preview the withdrawal process.
👉 This may help first-time users better understand what is needed before committing to setup requirements.
Users receive clear confirmation when completed. They can track the transaction on-chain if needed
👉 Reinforcing trust and reducing anxiety
System checking
Withdrawal screens...
Withdrawal
System processing stage
Withdrawal
Some users are not eligible for withdrawal, the system ask them to take actions from the beginning to avoid withdrawal failure later
Reflection
We won’t always have all the data we need
One limitation I faced was the lack of certain metrics, especially completion time. This made it harder to fully understand how long users were at each step and how that affected their experience. Because of that, I had to rely on patterns from user behavior and support data to form hypotheses. It worked to some extent, but it also showed me how important proper tracking is from the beginning.
Without segmentation, funnel data can be misleading
I also realized that funnel numbers can sometimes make a problem look more general than it actually is. A high drop-off rate does not always mean every user is struggling in the same way.
Through segmentation, we can start seeing which specific groups are affected more heavily, under what conditions, and what behavioral patterns might be contributing to the problem. That deeper context can completely change how we form product hypotheses and approach design decisions.
If we had the opportunity to perform segmentation, how could it change the way we understand the drop-off? 🤔
Acknowledgement
This project was shaped by close collaboration across teams.
Special thanks to Jesada Hongsi (Frontend Engineer) for managing the Google Analytics setup, making sure events were tracked correctly, and sharing internal training on how to read product data. Sukit Kajonpradapkul (Business Intelligence) helped surface key data around processing time, which clarified what actually happens after users submit a withdrawal. Finally, Sutthikan Singkhonart (Customer Support) shared insights from AML-related support cases, helping uncover the real reasons behind user concerns and incoming calls.
I also want to thank all PMs, BAs, QCs, and engineers who joined the working sessions. Their input helped validate assumptions, highlight constraints, and shape more realistic solutions.
More case studies
Redesigning Crypto Wallet to Improve Asset Engagement
Increase wallet engagement and reduce friction between portfolio monitoring and trading actions.
Read case study
Designing a Dispute Workflow for Sidekick CRM
Enabling frontline agents to create and track dispute cases directly inside Sidekick.
Read case study
Let's work together
Feel free to reach out. I’d love to hear what you’re working on.