How we iterated the design from Alpha to Beta

17 July 2026

Throughout the Beta phase, we continuously iterated the registration journey to improve the user experience. Changes were informed by multiple sources, including:

• user research findings

• observed user pain points

• known issues inherited from the NPQ service

• content reviews

• policy developments

• differences between NPD and NPQ services

• feedback from providers

Content review

A comprehensive review of the service content was undertaken during Beta. This review resulted in revisions across the service to better meet user needs and align with content design best practice.

Changes in policy

As policy decisions became clearer during Beta, the service needed to adapt to reflect updated requirements. This was particularly important in relation to eligibility criteria and associated guidance. Content and design changes ensured users would be presented with accurate, up-to-date information.

Differences between NPD and NPQ

Although the service builds on aspects of the NPQ journey, there are important differences between NPD and NPQ. These differences required changes to terminology, labels, content and user-facing guidance to ensure the service accurately reflected the NPD service.

Making the registration guidance clearer

Research in Alpha showed that users did not always understand the registration process. Multiple guidance pages and many links created confusion, with some users getting stuck in loops between guidance pages. We also knew this was an inherited issue from the NPQ service, where some users applied with providers before registering with DfE.

To address this, we consolidated guidance into a single page, introduced numbered steps to clearly explain the process, and replaced text links with a prominent GOV.UK-style button for registration. We also revised the page heading so users understood that the purpose of the service was to check eligibility and register for a course.

Following these changes, users demonstrated a clearer understanding of the process and were able to correctly identify that they needed to choose a provider, register with DfE and then apply with their provider.

Simplifying selection options

User testing identified confusion around questions asking users where they worked. Participants were often unsure which option applied to them, particularly those working within academy trusts or those interpreting “early years” differently.

At the same time, policy refinement clarified that detailed workplace information was no longer required to assess eligibility. Working with policy colleagues, we simplified the question to focus on broader categories such as state-funded and private settings. We also ensured academy trusts were represented clearly.

This reduced the cognitive effort required to complete the registration journey and enabled users to answer the question more confidently and quickly.

Improving post-registration guidance

Alpha testing showed that users frequently overlooked the success banner displayed after registration. As a result, some participants were uncertain whether their registration had been completed and what they needed to do next.

We replaced the success banner with a dedicated confirmation page that clearly stated the registration had been submitted successfully. The page included numbered next steps, links to registration details, and confirmation that the information had also been sent by email.

Research demonstrated that users were much clearer about the process after registration, understanding that their chosen provider would now contact them and that no further action was required immediately.

Adding a timeframe for provider contact

During Beta testing, every participant wanted more certainty about when they would hear from their chosen provider. Although users understood that the provider would contact them, they wanted reassurance about how long they should wait before following up.

In response, we consulted providers and contract teams to understand realistic contact timescales. We then updated the confirmation page to explain that users should hear from their provider within five days.

This small content change addressed a common user concern, reduced uncertainty, and provided a clearer expectation of what would happen next.

Reducing unnecessary anxiety about funded places

Research highlighted that some users were concerned by repeated messages warning that eligibility for funding did not guarantee a funded place. While technically accurate, policy analysis showed that the number of funded places available represented a high proportion of the target audience, making the risk of users not securing a place relatively low.

We reviewed this content and removed warnings that felt disproportionate to the actual risk. This reduced unnecessary anxiety for participants and created a more confident registration experience.

Alongside these changes, we held ideation sessions with stakeholders to explore longer-term approaches to communicating funded place availability. While these ideas were not feasible for Reception at launch, they have informed ongoing work for our future SEND service.

Provider feedback

Provider engagement played an important role in shaping the service during Beta. We regularly shared guidance pages and demonstrated the service to providers to gather feedback. Their insights helped validate design decisions, identify areas requiring greater clarity and ensure the service met operational needs as well as user requirements.

Outcomes of our design iterations

The Beta phase was characterised by continuous improvement driven by user needs, stakeholder feedback and evolving programme requirements. By combining user research, observed pain points, lessons from NPQ, content reviews, policy updates, programme-specific requirements and provider feedback, we were able to iteratively refine the service and improve both its usability and clarity.