The problem

Our registration journey, originally asked users three additional questions about their setting:

  1. What setting type they worked in (school, nursery, childminder and other)
  2. What their Ofsted number is (if they had one)
  3. What their setting postcode was

Data had told us we had a high number of users selecting 'other'. We had 23% of users selecting this option. In the data, we also saw that 38% of people were not entering an Ofsted number. This could be because they did not want to provide it, or they didn't have one because of their setting type. Of the 62% that were entering Ofsted numbers, 14% were entering invalid numbers.

At the time we benchmarked this data, which was a short period during the private beta, registration conversion was at 75%.

Additionally, some users who fell into the 'other' group, were being asked for their setting postcode, and for an Ofsted number, when these questions may not have been relevant for them.

In earlier contextual enquiries, before launching private beta, some users would express surprise that we asked them for their Ofsted number. Some users fed back that they might need to ask somebody else for this information. However, they generally understood how to use the journey and what information they needed to provide.

Understanding what data we needed

Upon analysing the data, we believed we could add more options to the list of settings we currently provided, that matched to the kinds of information we were gathering from the 'other setting' field. This would help us understand and collate the setting types that were completing the training.

After some discussions with policy colleagues, we were able to conclude together that we didn't need to ask for Ofsted number, we could instead ask other questions that may be easier for our users to answer, that would provide us with a similar outcome. For example, we could ask for role, setting type and local authority. This would mean we would no longer need to ask for Ofsted number and postcode, which we hypothesised felt more intrusive.

Our hypotheses and HMW questions

HMW questions

  • How might we allow users avoid irrelevant questions?
  • How might we improve data capture for ofsted number?
  • How might we reduce the number of ‘other’ options entered?

Hypotheses

We believe that users do not know or feel uncomfortable providing their setting postcode and ofsted number We will ask them for their role and local authority area We will know this to be true if we have less fields left blank

We believe that more than just schools, nurseries and childminders are completing the training We will add additional settings to the setting type list We will know this to be true if we gather additional setting data

We believe that users do not wish to see questions that aren't relevant to them We will only show users questions that are relevant to them We will know this to be true if registration conversion increases

Design solution

Mapping questions to roles

To help solve the problem that users were being presented with questions that they didn't need to answer, we looked at mapping the questions to specific roles.

For example, if you were an early years provider, you would be asked:

  1. What is your setting type?
  2. What is your local authority area?
  3. What best describes your role?

Whereas, if you were from a local authority you would only be asked:

  1. What is your setting type?

Choosing from a big list

As we'd improved the list of settings users could choose from, the list became slightly too big for the radio button pattern that is commonly used across government services.

There was a DfE pattern for selecting a school from a list, that used a select box and autocomplete. This helped with our problem and had been tested on other services, so we hypothesised that this would be an appropriate solution for choosing your setting, and for selecting your local authority; where there was over 300 options.

We also added free text alternatives for if users couldn't find their setting type in the list, or their role in the list of roles, so that we could keep learning and iterating the lists to work for our users.

The overall journey

The journey for early years providers had been changed to:

What is your setting type > What is your local authority > What is your role > Learning dashboard

The journey for non early years providers was:

What is your setting type > Learning dashboard

A diagram showing a users journey from receiving an email to registering, the journey path is dependant on if you are an early years provider or not

Screenshots of the new pages

A screenshot of the page asking users for their setting type, showing a question and an autocomplete answer box

A screenshot of the page asking users for their local authority, there is a question, a text input box, a button and a link

How it tested

We created a HTML prototype of the new registration journey and tested it in a round of usability testing. We also did an additional round of testing during the public beta phase with users who had access needs, or proxy users.

Key findings were that:

  • Users could use the setting type page with ease, but we could add a search icon to make the autocomplete clearer
  • Users could find their local authority with ease
  • Childminders didn't really identify with the role types we had presented on the role selection page
  • If the question is mandatory, we should make sure to add validation (as the prototype we used didn't have validation included)

We have been analysing the registration data regularly after launching the service into public beta, our registration conversion rate has been quite consistent at around 90%.

What data we can now gather

We have been able to closely monitor the setting types that are engaging with the training, and the local authority areas that are making use of the service.