How ESFA are keeping users at the heart of the #apprenticeship service

Understanding user needs

At the apprenticeship service, we know the importance of focussing on user need.

An important part of my role as lead user researcher is to bring together the knowledge of our user’ needs into a format which makes them accessible and easy to draw on as we plan new developments. This has been a central function of our  user research team since 2015, when we started to develop the service to enable large employers to spend their levy.

When developing services, it is fundamental to build empathy with the people who will be using our services. We need to have a clear understanding of their needs within the apprenticeship system, and to use them as a reference point when thinking about what we develop. In this way we can create something that fully meets their needs.

Since the service was established, we’ve spoken to around 5,000 users, capturing how they do their jobs and their ‘pain points’ – what makes it hard to do their jobs effectively.  From this information, we can get a picture of our users and their behaviours and needs. We have lots of research from many different users, so I wanted to ensure these were streamlined and available when we needed.

We currently maintain a user needs catalogue, which shows the results of our analysis as the service has developed. It almost tells the story of evolution of the service.

However, looking at these recently, I wanted to organise them better to ensure they gave a true picture of our users. The first task was to consolidate the research we have, and to ensure each user need we keep was valid.

Let me explain

User needs are more often expressed like this: ‘as a [type of user], I need to [do something], so that [I can get an output]’. So for example, one user need might be: ‘as a levy-payer, I need to check my levy balance, so I can plan how many apprentices I can afford’.

I asked my junior researcher for one-line summaries of each need, written on cards. She removed the description of who the need was associated with, so the statement stood alone. So in the case of the levy-payer above, the need would be ‘to check my levy balance’.

Next, I got the research team together to review the cards.

Dividing the team into 2 groups I asked them to:

• Take half the pile of cards
• Look for duplicate needs within their pile
• Look for cards that were not strictly needs, but something the service should automatically provide. For example, one read ‘make the system easy to use first time’
• Look for cards that were tied to a solution – ones that explain what we’ve developed but not why we needed to develop it. For example, one read ‘I need to be able to download this so that I have a copy’. But this doesn’t explain why they need the download. The ‘need’ would refer to the thinking behind this request.
• Write new cards if they felt anything was missing, or edit to clarify needs where required

Applying the user needs test

The teams then grouped the cards into categories and hierarchy.

After this, we applied the user needs test, adapted from the work of Leisa Reichelt, former Head of User Research at Government Digital Service (GDS). The user needs test features a number of questions, including:

• If you showed it to a user, would they recognise it as their need?
• Is it written with words real users use?
• Does it describe the problem rather than the solution?
• Will it stay the same regardless of changes to technology, policy and existing services?
• Does it help organise and prioritise work?

I can safely say this was a lively session with plenty of debate. By working through our reasoning, talking about the people we’ve met, and challenging each other, we whittled down the 250 needs we began with to 25 key needs for employers and training providers.

It might seem to be a simple organisational task, but this work will help us review our user needs quickly and easily in future, meaning it will be easier to ensure the user stays at the heart of all we do.

It might seem to be a simple organisational task, but this work means our user needs are clearly defined. Better organisation of this work means that when our researchers, designers and product owners are considering what the our users need, they can find the high level results of our research immediately accessible.

Understanding the user need underpins everything we do on the service.

Jess Gough, Lead user researcher at the apprenticeship service