One of the UK's biggest insurers: turning 30+ authentication dead ends into recoverable journeys
I redesigned registration and sign-in for a service handling millions of registrations each year, mapping more than 30 failure states into accessible self-service recovery and helping ship passwordless magic links.
- Role
- Mid UX Designer
- Team
- Product · Engineering · Senior stakeholders
- Year
- Nov 2023 to Oct 2024
- Platform
- Web · iOS · Android · FCA-regulated
- failure states mapped
- 30+
- unserved errors when I left
- 0
- registrations each year
- Millions
- passwordless magic links
- Shipped
Evidence note: NDA-safe reconstructions show the shipped interaction model without reproducing employer branding, production UI, source files, analytics or customer records.
The problem
The account-access service handled millions of registrations each year, including returning customers whose account state could change while they were away. Yet registration and sign-in did not always apply the same password conditions, and more than 30 observed failure states collapsed into one generic error. Customers could not tell what had happened, why their details no longer worked, or how to recover without support.
The work
Mapping failure states into recovery paths
My first task was to understand the failure model with engineering. Some conditions already existed as faults or error codes; others were still emerging through delivery. We worked through the registration, sign-in, return-user, and recovery flows until the known failure states were visible as one service architecture.
This was the right evidence before interface design. The problems were observable, technically reproducible, and already affecting a service with millions of annual registrations. Initial exploratory usability testing would not have changed the diagnosis. The priority was to make the existing system legible, then design a recovery response for every condition we could identify.
I translated the engineering conditions into customer-facing responses. Each known failure needed to answer three questions: what happened, what it meant for the account, and what the customer could do next.
That changed error handling from one generic endpoint into a designed recovery model. Bespoke guidance helped customers correct their details, understand a changed account state, or take the appropriate next step without starting again or defaulting to assisted support.
Structuring the access surface
The mapping needed a shape before anything could be designed against it. I drew the service as four parts: where people arrive, the surface they land on, the conditions that can interrupt them, and where each of those conditions has to leave them.
Framing it this way made the gap plain. The product had a wide set of entry points and a competent access surface, but the routing in the middle resolved almost everything into the same generic exit. The architecture became the working contract with engineering. A condition was only considered handled once it had a named destination a customer could reach on their own.
It also set the boundary of the work. Anything that genuinely could not be resolved inside the access surface was routed to assisted support deliberately, rather than arriving there because nothing else had been designed.
Wireframing the recovery journeys
With the architecture agreed, I stayed in greyscale for as long as the open questions were structural. Working without colour or brand kept reviews with Product and Engineering on sequence, hierarchy and state, instead of on visual treatment we were not ready to settle.
Each pass carried a single decision I wanted a view on, so a review could reject one idea without unpicking the journey around it. The annotations below record what each screen was arguing for.
- State the contract before the fieldRegistration and sign-in had accepted different characters. The rules move above the input so one contract is visible at the point of entry.
- Resolve requirements liveThe helper checks each rule as it is met, so the most common failure is prevented rather than reported after submission.
- Offer two routes at equal weightPassword and secure link sit side by side. Neither is buried, so a returning customer who cannot recall a credential is not forced into recovery.
- Name the condition, not the failureEach mapped error answers what happened, what it means for the account, and the single next action. This replaced one generic message.
- Separate account state from user errorAn expired or locked account is a different problem from a mistyped password and needed its own explanation and route back in.
- Reduce the email to one decisionThe secure link carries a single action with the expiry and security conditions visible in context, so the recovery task cannot fork.
The wireframes were disposable and several ideas in them did not survive review. Their value was surfacing disagreement while the cost of changing direction was a redrawn box rather than a rebuilt component. By the time the work moved into visual design and the full state contract, the sequence and the recovery logic were already settled.
Preventing password failures before submission
Recovery was only half of the interaction model. The product also needed to stop creating avoidable failures.
We aligned the password conditions used by registration and sign-in, then introduced a reusable password-helper component so requirements were visible while someone created a credential. Full default, focus, filled, valid, error, and disabled states made validation and accessibility part of the component contract rather than a final annotation.
Extending the journey with passwordless access
The foundational work made password access reliable, but it also showed where the password itself added friction. Reviews, online sentiment, and competitor analysis gave me evidence for a second move: introduce magic links as a first-class access route.
I developed the proposal, brought senior stakeholders into workshops, and worked with Product and Engineering to influence the backlog. Magic links then shipped, giving returning customers a passwordless route into the account while keeping the existing credential path available.
The mapping remained a delivery artifact rather than a discovery document. I supported engineers through implementation, reviewed the interaction states and bespoke guidance in context, and worked with Product as new technical conditions surfaced. That kept the recovery model connected to the service behaviour it was designed to explain.
From 30+ dead ends to zero unserved errors
The redesigned registration and sign-in journeys shipped with aligned password rules, a new password-helper component, bespoke error guidance, accessible interaction states, and passwordless magic links.
By the time I left, every observed authentication failure had a defined self-service response. This was a verified improvement in service coverage, not a claim about conversion or support-call reduction.
The edge cases became the case for a design system
Mapping the edge cases showed that the patterns needed for reliable validation, accessibility and recovery were missing across the wider product estate, which led me into system-level work.