Withdrawing fiat from a Skrill wallet straight into a crypto wallet was one of Digital wallets' fastest-growing money-out features – volumes had grown steadily, and a large share of that growth was coming from expanding to new countries. It had also never had a designer properly on it: the journey had shipped, expanded market by market, and accumulated friction. What product saw from a bird's-eye view was a funnel drop-off of more than 50% on a single step, and a persistent stream of customer-support contacts.
I designed and ran the discovery, definition, ideation and delivery for its redesign as a full design-thinking cycle, and I deliberately did not run it alone. Product, stakeholders and engineering went through every step with me, in a series of workshops: agreeing a 12-month goal and the success metrics behind it, gathering the evidence, building a proto persona and mapping the journey, then prioritising the opportunities that best address our long-term goal. From there we ideated against the winners, put the proposals through design reviews and usability testing, and shaped the scope for development.
In an initiative aimed at scaling up an already well-performing money-out journey, transparency is everything. Opening up the process to all stakeholders ensures absolute alignment from day one. This builds trust, accelerates decision-making and breaks down communication silos by introducing a single, unified framework where every step of the process is fully visible to everyone.
The spine of the initiative was the double diamond: diverge and converge on the problem, then diverge and converge on the solution. I opened the very first workshop by walking the room through it – five minutes on empathise, define, ideate, prototype, test – so that everyone knew at every later session which part of the process we were in, and why we're going through it.
That set an expectation early: we would spend real time in the problem space before talking about solutions.
The initiative ran as a series of working sessions, each with a written agenda and a timebox on every exercise. Two things were deliberate: silent individual writing before any group discussion, so the loudest voice in the room didn't set the frame; and dot-voting to converge, so decisions came from the group.
Growth for the "Withdraw to Crypto" feature was happening despite the user journey, not because of it.
With the help of product, analytics and customer support, I gathered all the data we had onto one board, where every later exercise could see it. Five sources, each answering a different kind of question:
The Amplitude data could say where people left, but could not say why. So I gathered the product team with the suggestion to write down every hypothesis we had for that drop-off. Some of the suggestions included mismatch of user expectations, no available balance, difficulty entering an address, and balance-switching limitations on app. Against each one we marked what kind of experiment or research would confirm or discard it: some against BI data, some in the interviews, some in usability testing.
That list is what stopped the quantitative data from being a set of charts everyone nodded at, and turned it into a research agenda with owners.
I conducted stakeholder interviews upfront to gather the research questions and topics, which would then shape the interview guide and script – covering current user behaviour, withdrawal habits, pain points and unmet needs. The interview also included a hands-on test with dummy account data. The results from this research would feed persona creation, journey mapping of pain points, and enrich the picture on the Amplitude drop-off.
Ten moderated sessions on web and ten on mobile. The ones on mobile – five Skrill users and five non-users, across the UK, Brazil, Italy, Portugal and Argentina, spread between users who trade with crypto, users who only store value via crypto, and users who perform withdrawals of funds to crypto wallets. Two findings on mobile did most of the damage.
Discoverability. Only 5 of 10 users managed to complete a withdrawal to a crypto wallet at all, because they couldn't find the feature. Seven of ten began their search in the crypto tab, starting from "buy crypto" and then hunting under "more"; three started from the exchange; transfer, where the feature lives, was the last resort. Asked how easy it was to find the option, users scored it 3.2 out of 5 – and the score flatters the experience, because half of them never found it. This confirmed my hypothesis: if we were to target those users, we'd need an entry point aligned with their expectations.
Clarity. The withdraw-to-crypto-wallet concept is not what crypto users are used to from exchanges. They expect to buy crypto and then send it to an external wallet, or to send from an existing crypto balance. Here the feature buys crypto with fiat and sends it to the wallet in a single step, acting as an on-ramp. Genuinely more convenient, and genuinely confusing: users couldn't tell what the feature was or how it worked.
The first workshop was pure alignment, run in tight timeboxes: five minutes on the process itself, ten on the goal, ten on metrics, five on scope and constraints. Everyone wrote silently first, then we discussed and dot-voted.
"What would Withdrawals to crypto wallet look like in 12 months for our users, and how would it impact the business?" One sentence each – bold and idealistic, no metrics, no solutions. Everyone wrote in silence, then we read them out and dot-voted to land on a single statement the whole room had chosen rather than been given.
"How will we know we've reached our goal?" – split into business outcomes and user outcomes, with the instruction to imagine everything goes perfectly and to include a number where possible. The room produced candidates on both sides – conversion through the withdrawal flow, volume growth, fewer support contacts – and voted on the ones it believed in.
"Imagine the project has failed miserably. Write every reason you can think of for the failure." Although the group did not manage to go through this step, I had marked two "reasons for failure" on my side: that we did not get to the core of the users' problems and needs, so we did not provide enough additional value; and that we had a hypothesis whose effectiveness we did not test or measure, so we built a feature that did not actually improve the user experience or the metrics significantly.
Boundaries before ideas: what the initiative covers on app and web, with regulatory, technical and product constraints named explicitly – so that nobody fell in love with something that couldn't ship.
With the destination set, the next workshop turned to whom we were designing for. Unfortunately the interviews initiative did not bring any participants due to the specifics of the target group, so we used desk research, the BI segments and the team's accumulated knowledge to draft a proto persona together – whom are we serving, what are their pain points and needs, what would we help them achieve – deliberately labelled "proto": a hypothesis to be sharpened by further research. Alongside the proto persona we also placed our already existing trader personas as secondary target groups.
Journey mapping. We mapped the current journey end to end and placed the user pain points along it – from discovering the feature exists, locating it in the interface, through entering an amount, address and choosing a network, to waiting for funds to arrive. The map made visible what the funnel chart structurally couldn't: the pain starts before the first funnel step, because a feature people don't know about and can't find has a problem no flow redesign will fix.
Grouping together similar user problems from the journey map and then naming them produced 16 distinct items – from "users don't know about the feature" through "unclear what limit is hit" and "clarity on insufficient funds to cover amount + fees", to "get help and support along the flow" and "get rewarded when using the withdrawals".
Every problem plotted on impact on the business metric against impact on the user outcome, with the goal and metrics from workshop one pinned physically at the top of the frame as the yardstick. Nobody had to argue from taste.
Then a second pass: how easy is it to build, splitting the high-impact items into quick wins and big bets. The effort axis is what turns a wish-list into a plan.
The ideation workshop ran on a tight agenda: five minutes of intro, then six How Might We rounds of five minutes each, a vote, a rest – then fifteen minutes of lightning demos of competitor solutions to the top-voted problems.
Each top-voted problem was reframed as a question – rephrasing a problem as a question is what switches a room from panic into solution mode. The four that carried the session:
Silent, timeboxed idea generation against each question. Quantity first; judgement later, by vote. Against discoverability in account: a new entry point on the crypto dashboard, redirecting from crypto buy, and iconography that reads dollar-sign to crypto to wallet. Against knowing the feature exists: a notification centre and push notifications linked to it, and reaching users where they already are. Against comprehension: a descriptive card on the crypto dashboard, the same on the home screen, and educational screens. Against support: an entry to FAQ, help and support along the flow behind an information icon, improved FAQ articles, and checking the current journey on the virtual assistant.
Competitor walk-throughs against the top-voted problems – how exchanges and onramps handle withdrawal flows, naming, limits and network choices. Participants brought their own findings; the demos grounded the ideas in what the market already teaches users to expect.
A very useful exercise that unfortunately didn't make the cut due to time constraints. Surviving ideas need to be written up as hypothesis statements – we believe that doing this, for this user, will achieve this outcome, and we will know it is true when we see this metric change.
I laid down in Figma the results from the ideation with the How Might We questions and the unmet needs and jobs, along with the existing flow and the new flows I was building – so that I always kept them front and centre, and so that I could easily defend my design decisions by pointing at ideas and problems the committee had already approved.
For the first iteration I came up with four variants of the journey for app and web – four different proposals for new entry points and reworked steps. Then I took them through design reviews with design, product, engineering, legal and partner networks, each carrying its own approval status.
This is where the hardest constraint showed itself. Two of the four variants leaned on renaming the feature or introducing clearer wording, and both were disapproved by partner networks and legal: no "Buy" or "Send" in the naming. As you may recall earlier in the case study, we saw from the usability testing of the current state that the majority of users searched for the feature under "Buy" on the crypto dashboard. As for "Send" – the competitor analysis done earlier showed that "Send" and "Withdraw" were equally used across crypto exchanges, digital wallets and onramps. This left me with the only direction of keeping the naming as "Withdraw to crypto wallet".
The variant that survived kept the current naming and the entry point at "Transfer" for existing users, and supported discoverability for the trading personas we'd like to acquire via an entry point on the crypto dashboard – under "More" – plus much stronger communication and education around the feature.
Working inside a constraint you cannot argue with is a large part of what this project actually was.
Each variant carries its own concept, rationale, the votes it drew from product and design, the constraints it hit, and – where testing ran – what came back. Step through them with the arrows.
Due to the constraints and what I was left with, I got the unpleasant feeling of not delivering the best result for our users – the entry point was rather hidden, and we were about to miss our goal of increasing acquisition of trading users. So I sat down and iterated further, coming out with a new proposal for the entry point: a descriptive card, front and centre at the top of the crypto dashboard. This solution bothered me at first, as it may be perceived as a widget or an ad – something with temporary status. Still, it kept a consistent appearance according to our design system with the already existing entry point, and it covered much better the users' need for an explanation of what the feature offers them, compared with a standalone "Withdrawal" button that usability testing had proved confusing.
The proposed entry points and user flows from the first two iterations underwent usability testing across both app and web platforms. Each design was evaluated by 10 participants from the EEA, UK and LATAM regions. We assessed these journeys against three criteria: entry-point discoverability, overall ease of use, and end-to-end clarity of the withdrawal process. Every task was mapped to a specific metric and success criteria, then scored individually. This data was compiled into a response matrix, from which the final conclusions were drawn.
To support all user groups, it is essential to keep both entry points. Although we introduced a new path through the "Crypto" tab, usability testing showed that many participants still headed straight to "Transfer" to find the feature.
That closes the loop the pre-mortem would have demanded: no untested hypothesis ships.
Users found the "Withdraw to crypto wallet" card on the crypto dashboard to be the easiest entry point to locate. Entry-point ratings, among users who used that specific entry:
Each of the problems the research had named was worked through to a concrete screen. What follows pairs the user problem with what we built against it.
This is the screen the whole initiative started from – the details step carrying the drop-off. The old version asked for everything at once: cryptocurrency, network, wallet address and amount, with the limits reported only after the fact and, in this state, contradicting themselves – "Min: 21.00 | Max: 19.40" against a dead Continue button.
The redesign splits the screen into Spend and Receive, puts the balance, the minimum, the live exchange rate and the total fees on screen before you commit, and moves the crypto address to a step of its own.
In the old model fees sat on top of the spend amount and the displayed limits did not account for them, so users could not tell whether they had enough to cover the amount plus the fee. The receive amount is now spend minus all fees, with the total fee stated on screen.
Avoid the case with "Max" being smaller than "Min" by only showing one limit at a time – either the min or the max, depending on the case.
Part of a user's balance can be restricted for withdrawal to a crypto wallet, depending on how the money was deposited. Android and iOS disagreed on whether to show it, and nothing on the screen explained the difference.
The three How Might We questions that carried the ideation – knowing the feature exists, understanding what it does, and getting help along the way – each became a concrete piece of the release.
The existing design-system components did not support what the optimal solution needed, so a new list item was specified and taken into the library as coin_network_list_item – anatomy, brand, states, layout and behaviour.
Behind the entry points sat the smaller decisions that decide whether a flow actually works, for example: how the address field and its confirmation checkbox behave together, how verification status is communicated, and what the journey does when a market or a service is unavailable.
I worked with product and engineering on prioritising which features and flow improvements entered development first, weighing the impact on users and the business against the development effort each required. As a result the work was divided into three stages of development, each a complete, shippable slice for both app and web rather than a partial release.
The redesign increased first-page landings on the "enter amount" step by 25% in a quarter, and monthly withdrawal volume grew from 10K to 15K transactions per month.
Beyond the numbers, the initiative changed how the problem was understood. It began as "fix the drop-off in the flow" and ended with much greater understanding of the "why" behind the number, plus clear evidence that discoverability and clarity along the journey are equally harmful for business metrics.
Stakeholders and engineering managers highly appreciated the collaborative approach, which often eased their decision-making and saved time.
It was a lot to run in the time available, and next time I would look at cutting down some of the workshop exercises to fit the constraints more comfortably. Where there is capacity, the project would also benefit from a second designer or researcher joining for the research activities, to increase efficiency further.
Two case studies sit close to this one – the same conviction that alignment comes before execution, applied with different instruments.
