Using analytics to challenge assumptions about a registration service

Department for Education · via Version 1 · Nov 2024 - Dec 2025

Used analytics to identify where teachers dropped out of National Professional Qualification registration, then worked with policy to test three funding-eligibility concepts.

DfE
NPQ
Analytics
Discovery

The problem

Teachers applying for National Professional Qualifications were dropping out of registration in large numbers. The working theory was funding eligibility: users could choose a course and provider before finding out they weren't eligible for DfE funding, and existing guidance wasn't clear enough to check beforehand. We had a strong hunch - but a hunch isn't a design brief. The first job was to see if the data backed it up, and exactly where in the journey it was biting.

NPQ discovery board showing session paths after the ineligible-for-funding page, including 15% of sessions re-choosing an NPQ and about 55% continuing backwards through the journey — NPQ discovery - session-path analysis after users hit ineligible for funding, mapped with the performance analyst (source: discovery board). Click the image to open it full size.

My role

This sat inside a wider discovery with three streams: the funding eligibility checker (new build), GOV.UK One Login (owned by another team), and the overseas applicant journey. I owned the eligibility-checker strand end to end - framing analytics questions, running problem-statement and “how might we” workshops with UCD, turning findings into design options, and taking those options to policy. The performance analyst owned the tooling (GA dashboards, BigQuery funnel analysis, session paths). I shaped what to ask for and what to do with what came back, iterating with them on what “ineligible” meant in the data before drawing design conclusions.

NPQ discovery board showing three workstreams: delayed One Login teacher auth, new-build funding eligibility checker, and revisit of the overseas applicant journey, with shared registration impact and deadlines — NPQ discovery - the three connected workstreams and how they impact the registration journey (source: discovery board). Click the image to open it full size.

The evidence

Drop-off wasn't uniform. In the analytics window we reviewed, “Choose an NPQ and provider” had a high combined bounce and exit rate (around 70%). “Registration is temporarily closed” - shown to England applicants outside the funding window - had roughly 48% bounce and 52% exit across about 970 views. Early, low-stakes pages like “Which early years setting do you work in?” exited under 1%. The friction clustered around funding and course-choice decisions.

A more targeted session-path question followed: of people who saw an ineligible-for-funding result, what happened next? Around 15% re-chose their NPQ, roughly 55% navigated backwards rather than leaving outright, and about 72% still continued on an onward path after the result. That last figure mattered - an eligibility checker wasn't only about stopping drop-off; it also needed to help the majority who would carry on anyway do it with less friction.

Analytics board comparing bounce and exit rates across NPQ registration pages, from about 70% on choose an NPQ and provider down to under 1% on an early years setting question — Page-level bounce and exit rates across the NPQ registration journey - drop-off clustered around funding and course-choice pages (source: discovery board).

Design decisions

A “how might we” with the UCD team produced three distinct concepts in Lucid. I kept them deliberately separate rather than converging early, so policy had something real to react to:

Full transparency - show eligibility across every NPQ course before sign-in
Check before registration - ask which course they're interested in, then tell them if they're eligible
Standalone funding checker - a separate tool on the guidance page, decoupled from registration

I also ran an assumption-mapping session with policy - for example, that users shouldn't need to sign in to check eligibility, and that systems could support self-funded and overseas users outside the funding window - and asked them to name the risks from their side.

Lucid user journey for checking NPQ eligibility before registration, showing course selection, eligibility outcome, identity verification and registration success — Checking NPQ eligibility before registration - draft journey explored after the three concepts (source: discovery board). Click the image to open it full size.

Iteration / testing

Policy reshaped the direction. Showing eligibility across all courses upfront risked people choosing what they could get funded for rather than what was right for them. They also worried registrations would drop if people could check eligibility without ever registering. That ruled out full transparency in its purest form.

After Crazy 8s and dot-voting, two hypotheses remained to test: that checking funding eligibility before sign-in would cut drop-off after identity verification without losing genuine registrations; and that splitting the registration window - open all year for self-funded and overseas users, time-limited for funded ones - would reduce confusion for people outside the standard funded pathway.

Policy workshop board mapping core assumptions against evidence, policy risk and end-user impact for NPQ funding eligibility — Policy workshop on validating assumptions - working through evidence, risks and end-user impact for each assumption with the policy team (source: discovery board, 25 Nov).

Outcome / impact

We didn't ship a feature. We ruled out the highest-risk eligibility design before build, and took two policy-reviewed hypotheses into prototyping and research. Analytics had already shown where drop-off clustered; discovery turned that into a narrower brief for early-2026 testing instead of building on an untested hunch.

What I learned

Data doesn't design the solution, but it should veto the ones that don't hold up. The ~72% onward-path figure stopped me over-designing for drop-off at the expense of people who carried on. Next time I'd map assumptions with policy before building three full concepts - some of that work didn't survive their constraints. Framing the analytics question is a design skill: the analyst could tell me what happened on a page; sitting with them and iterating on the ask is how we got to why.