Making access to healthcare simpler. Clearer self-serve, less confusion about what's covered, fewer dead-ends.
Users could lose access to care when registration, recovery, cover, or support failed.
Mapped the access journey across identity, recovery, cover, and self-service.
Showed where access problems were linked across teams, systems, and support routes.
Helped define clearer priorities for improving access and reducing avoidable support.
A healthcare organisation needed to improve a portfolio of connected access problems: registration, sign-in, account recovery, post-registration cover confusion, email dependency, customer-data quality across B2B and consumer contexts, FAQs, self-serve support, and a long tail of business requests arriving from different parts of the organisation.
None of these were one-off issues. Cover confusion at registration traced back to product purchase or employer enrolment. Brittle recovery paths protected, or didn't protect, access well after sign-up. Self-serve content was the difference between a user solving their own problem and a support call. Customer data quality (clean for consumer journeys, messier for B2B) changed what could be safely automated. Each fix revealed the next dependency.
My job was to make those links visible, prioritise what could move, and keep turning the mess into practical self-serve improvements across registration, recovery, FAQs, cover understanding, and future identity work.
Each access problem in this portfolio was connected to others, and the connections were what made the work hard. Cover confusion at registration traced back to unclear product information at purchase or employer enrolment. Recovery paths heavily dependent on email pushed users into assisted support. Self-serve content was the difference between a user solving their own problem and a support call. B2B journeys depended on employer and policy data that was incomplete, delayed, or inconsistent, so the service had to handle uncertainty differently than for consumer journeys.
Identity, cover, data, support, clinics, compliance, technology, and external integrations all sat behind what users experienced as one access-to-care journey. Each fix revealed the next dependency.
The real risk wasn't that the work would turn out to be bigger than expected, it was that without making the connections visible, teams would chase brilliant basics in isolation while the wider service kept producing the same kinds of failure.
The work combined service blueprinting, current-state mapping, survey insight, customer feedback, operational dependencies, design sprint activity, concept testing, and analysis of support drivers. We looked at what happened immediately after registration, including confusion around cover, expectations, and next steps, and earlier in the funnel, because some of that confusion was being created before registration when people bought or were given access to products they did not fully understand. The combined view showed how access problems compounded over time: registration, recovery, cover understanding, FAQs, customer data, and support were not separate issues, they were different points in the same access-to-care system.
Registration and sign-in were important because they were the gateway into care, but many of the problems users experienced did not start there. Confusion about cover, incomplete data, weak recovery paths, unclear next steps, and limited self-serve support all fed into the access experience.
Surveys soon after registration showed that users were confused about what they were covered for. That looked like an onboarding or content issue at first, but it pointed to something earlier in the funnel: were people being given clear enough information at the point of purchase, renewal, employer enrolment, or product setup?
Consumer journeys had a more direct customer-to-organisation relationship. B2B journeys were more complex because the organisation relied on employer or policy data that was incomplete, delayed, inconsistent, or not designed around the end user's digital experience. The same access problem could behave very differently depending on the customer model, identity and access could not be designed as one generic flow.
Too much of the access journey depended on users having access to the right email address at the right time. If a user lost access to their email, used an old email, mistyped it, or could not complete verification, they fell out of self-serve and into assisted support, increasing call volumes and avoidable cost.
Forgotten password and recovery paths mattered because they protected access after registration. A weak recovery journey meant users who should have been able to help themselves were forced into calls, manual checks, delays, or repeated frustration.
Users needed clearer answers before they called. Cover, eligibility, next steps, booking, claims, and access questions all needed to be easier to self-serve. A better FAQ or support model wasn't just content hygiene, it was part of reducing avoidable contact and helping users understand their route into care.
This wasn't one neat journey with one neat solution. It was a set of interconnected access issues where each fix revealed the next dependency. Identity, cover, recovery, data quality, self-serve support, integrations, and care access all had to be understood together, then prioritised into what could be delivered now and what needed deeper strategic work.
The work helped the organisation move from a loose set of access requests into a clearer view of healthcare identity and self-serve access. It showed how registration, recovery, cover understanding, email dependency, customer data, FAQs, and support routes were all connected.
Some work supported near-term delivery, including clearer registration, forgotten-password and recovery paths, and better self-serve routes for users who would otherwise need to call. Other work created a structured view of future opportunities, including NHS integration, Apple and Google sign-in, smarter profiles, flexible security, and more proactive care experiences.
The main impact was that teams could stop treating access issues as isolated requests and start seeing them as part of a wider access-to-care service: fewer dead ends, clearer cover understanding, better self-serve support, and stronger foundations for future identity work.