Fixing the friction behind
registration drop-off

• ~43%Registration completion before improvements
• 28Issues found, five of them critical
• ~80%Of drop-off in three early steps
• 40+Scenarios across 10 markets

The challenge

Nearly three in five people who started PaysafeCard registration didn’t finish it. Registration is one of the first things a customer does with us, and it was losing them before they began.

The losses were concentrated early: country selection, email verification and mobile verification. Completion also varied by interface, from about one in five on web to about one in three in the app. Signups were declining while activation held steady and retention was rising, so leadership saw signup as the most pressing problem. Yet there was no agreed target, and completion was only visible in a Splunk report.

My role

The evidence was scattered, not missing

Different teams already held pieces of the answer. Individually, each source told part of the story. Side by side, they showed not only where people dropped off, but why they dropped off at those exact steps.

1. 01
   Funnel analytics

   Where people left, step by step, and how that differed between web, app and the payment flow.

2. 02
   Heuristic and scenario review

   Happy paths, error states, validation, recovery, content and consent, walked through in ten markets.

3. 03
   Customer Support and Ops

   The verification and recovery problems that kept turning into contacts, and what agents saw behind them.

4. 04
   Voice of the customer

   A year of app-store and Trustpilot reviews. People praised security, privacy and speed; the complaints clustered around verification, restrictions and not knowing what happens next.

What emerged

The biggest problems weren’t visual. A country search that didn’t recognise a valid name made people think PaysafeCard wasn’t available to them. A phone number accepted without proper validation sent people to an SMS step they could never complete. A missed AutoFill prompt left the code fields dead. A broken recovery page kept existing customers out of their account. Different causes, one consequence: people were asked to continue through journeys that didn’t give them a way forward.

Challenging the brief

The Phase 1 brief set out to reduce the number of screens and consolidate form fields. It was a reasonable idea. But the evidence pointed elsewhere: broken interactions and field-level friction were more immediate problems than screen count alone. People were hitting invalid states, unclear requirements and recovery paths that didn’t work. Consolidating the steps without fixing those failures would only move the same broken fields onto fewer screens. Research from Baymard and Nielsen Norman Group says the same: abandonment comes from per-field friction and unexpected requirements, not screen count.

That gave every field the same six questions:

• Do we need it here?Ask only what this step needs.
• Can we check it now?Validate before people move on, not after.
• Is the format clear?Show a local example, not a generic hint.
• What if it fails?Say what happened and offer a way forward.
• Can people recover?Without starting again from step one.
• Is compliance handled?Consent and eligibility explained and enforced.

It also surfaced a scope decision: three of the five critical fixes were validation changes, not visual ones, so “reduce screens” and “no backend changes” couldn’t both hold. I flagged it to settle with Engineering before the flow was designed. The rest of this case shows the evidence behind the reframe and what we fixed first.

Testing registration across ten markets

Registration isn’t one journey. We recorded full walkthroughs in ten markets and reviewed 40+ scenarios across seven steps, because the same screen fails differently depending on where you are: ZIP and state logic in the US, postcode and proof-of-address in the UK, mixed Greek and Latin input in Greece, double surnames and DNI/NIE in Spain, Codice Fiscale and long names in Italy, slower networks and lower-end devices in Romania.

Five critical findings

The assessment found 28 issues across all severity levels. Five needed attention first, and all of them sat inside the three high-drop-off steps. (The Phase 1 backlog built from it later lists 29 items; the 28 here are the original assessment.)

1. 01
   An eligibility check didn’t hold on every attempt

   Location rules have to apply every time, not only on the first try, or accounts can be created where they shouldn’t be. Fix: re-check eligibility on every relevant attempt, enforced on the server.

2. 02
   The login recovery page was broken

   It showed raw system keys instead of content, so the main recovery path for existing customers was a dead end. Fix: restore the page and stop untranslated content reaching production.

3. 03
   Code fields stopped responding

   On iOS, missing the AutoFill prompt left the one-time-code cells dead at the final step. Fix: manual entry always works, with or without AutoFill.

4. 04
   Invalid phone numbers got through

   An incomplete number passed validation, and people waited for an SMS that could never arrive. Fix: validate the number against the selected country before Continue, with a local example.

5. 05
   Marketing consent was pre-ticked

   Every channel was opted in by default, a privacy risk and a loss of control for the customer. Fix: explicit opt-in, reviewed with Legal and Privacy.

One model to prioritise

A broken verification step, confusing error copy and a compliance gap can’t be ranked by how visible they are. I built one severity model across six dimensions: usability, trust and transparency, content and tone, business impact, behavioural fit and growth readiness. A copy problem and a compliance gap could then be compared by consequence, whichever team had raised them, and Design, Product, Engineering and Compliance had a common language.

1. 01
   Fix first

   The five critical findings, within two weeks, with the two compliance items sent to Legal that week.

2. 02
   Quick wins

   Low-effort fixes with direct conversion impact: country search that matches local and English names, the native date picker, phone format guidance, legal documents opened inside the app so progress isn’t lost, and one pattern for SMS status and errors.

3. 03
   Copy, consent and localisation

   Explicit terms acceptance, one voice in consent copy, plain-language errors and local address formats, owned with our copywriter.

4. 04
   Polish

   Terminology and consistency issues batched into a single copy pass, instead of a ticket each.

From recommendations to product

The best solutions were often changes to existing interactions, not new screens. To keep the record honest, shipped work and further recommendations are listed separately.

Shipped: the five critical fixes

1. 01
   Eligibility checked every time

   Location checked at step 1 with a reason, and re-checked on every attempt.

2. 02
   Login recovery restored

   The recovery page shows real content again, so existing customers can get back in.

3. 03
   Code entry that always works

   Code cells stay tappable with or without AutoFill, with one resend pattern and attempts left shown.

4. 04
   Phone numbers validated before Continue

   Checked against the selected country, with a local example.

5. 05
   Explicit marketing consent

   No pre-ticked channels; opt-in reviewed with Legal and Privacy.

Recommended next, in the prioritised backlog

The quick wins, the copy and consent pass, and the polish batch above, plus what Customer Support added from their side: the same SMS code reused on resend, a clear message instead of a blank screen when the resend limit is reached, typo detection for email domains (“Did you mean gmail.com?”), and short troubleshooting when an email or SMS doesn’t arrive. These are recommendations, not all of them shipped.

Outcome and what we measure next

• 28Findings across registration, verification, recovery, content and compliance
• 5Critical fixes, shipped first
• 40+Scenarios beyond the happy path, in 10 markets
• 1 modelShared severity language across Design, Product, Engineering and Compliance

Status: identified, recommended, designed and implemented. Critical findings were tracked through the UX Quality Bar (Design Gates & UX Quality Bar →). Measurement is planned for early 2027, once there are six months of data after launch: completion at each of the three steps against the baseline, verification failures, and support contacts on the same flows. Until then, 43% is a baseline, not a result.

UX Assessment Programme →

Reflection

The answer to a product problem often already exists somewhere in the organisation. The funnel alone would have shown where people left. The interface alone would have shown usability issues. Support alone would have shown recurring frustration. Connecting them showed the real problem.

It also reinforced something I believe as a designer: shorter isn’t the same as easier. A registration can have fewer screens and still be hard to finish. What matters is whether people understand what is asked, can complete each step, and know how to recover when something goes wrong. Some of the most valuable design work here isn’t visible in a polished screen at all: it is an error that no longer happens.