We want to make sure we build things that people actually want to use, meaning that we build the right thing in the right way. Let's explore how this can be done.
A lesson in service delivery
There’s a little anecdote I have from working in government where an agency that was focused on delivering services for pensioners decided to update their website so that pensioners could access more services online, including self service.
They went about writing up a spec of requirements based on what they wanted the pensioners to use (to make life easier for themselves) and what they thought pensioners wanted from the service (it wasn’t clear how they determined this). The civil servants then went through a procurement process and procured a company to build the website.
The company built the site as requested and did so by matching the specifications that were given to them. The website was approved by the department to launch and a date was set. The department had estimated that they would need at least 20,000 visitors to the site on a daily basis to make the development of the website worth the cost.
During the first week, the website launched it attracted a total of 200 visitors. The civil servants couldn’t understand why pensioners weren’t using the site.
Did you ask the end user?
It could have been down to poor marketing, but it wasn’t. It was due to the fact that at no point during this project was a single pensioner or ‘end user’ asked:
- If they wanted a website to access services or to undertake self service?
- If they did want a website, what would they like to be able to do on the site?
- More crucially, what could the department do to make accessing pensioner services easier for them?
Secondly, when the website was built it was at no point tested with end users to make sure it met their needs or that using it was an enjoyable (or at least non painful) experience.
Focusing on user needs significantly reduces the chances of this scenario playing out and therefore reduces the risk of this example happening in the first place, while also reducing the costs of creating something that nobody wants to use, and then having to fix that mistake.
The practical steps to meeting service users' needs
Focusing on meeting service users' needs doesn’t need to be hugely complicated. When undertaking user research, projects that focus on the redesign of large services will obviously need to engage and test with large groups of people to ensure they have covered as wide a spectrum of user types as possible.
However, the practical methods of doing user research to understand your users essentially boil down to:
- identifying your core users
- capturing their pain points (frustrations)
- discovering what they want out of a product or service, and
- the main contact points the user has throughout their journey.
Having someone to recruit people for user research can be a really effective way of identifying various user groups. This can often take quite a bit of time and be costly so it should be considered as part of your project timeline and budget. Nevertheless, it is definitely worth the effort to make sure you aren’t simply talking to people to reinforce your own opinions.
Developing personas and user journey mapping
In instances where we have identified our core user group/s and have recruited participants to be involved in user research, we then work on developing personas to understand user needs in more detail.
Techniques like persona and empathy mapping capture the various persona groups involved with a service and their needs, goals, thoughts, feelings and frustrations.
We also use journey mapping to understand the journey they take - from start to finish - through a service or when using a product, so we can look at how we might improve that journey based on their needs.
Other user research techniques include ethnographic research, where we might observe a user or group of users within the context of the product or service or undertake one on one interviews or surveys to capture their requirements.
Don't take it too literally...
It’s important to understand that the purpose of gathering user needs isn’t about implementing everything they’ve said verbatim. For a start this would be impossible as people have different likes and dislikes.
Instead, it’s more about understanding how they use a service or product from their perspective, identifying patterns or similarities and then using our expertise to design or develop something that meets their needs as effectively as possible.
For this reason, testing with end users is crucial to constantly iterate the product or service quickly.
Meeting service user needs at the Ministry of Justice
During my time working in government I was often told by colleagues that we couldn’t employ user research techniques in a policy setting because we deal with varied, specialist, or sensitive stakeholders and user groups that require higher levels of confidence than other sectors.
However, I think the great work that the User centred policy design (UCPD) team at the Ministry of Justice is doing disproves that myth. They have shown over a long period of time that it is possible to deploy user research techniques with a highly sensitive audience — in terms of both victims of crime as well as offenders — across a wide spectrum of offences.
More information on what they’ve done and how they’ve done it can be found in this blog post.
So why do we focus on understanding user needs? Because it gets the best results. It helps ensure we build products and services that people want to use, will use, and which make a positive difference in their lives.
Our recent insights
Bringing together ambitious changemakers to share radically new, standards-based models and tools for local public services
Faced with a lack of resources and expertise, organisational barriers and little government support, councils aren’t sure how to take action on net zero. But service design can help.
Focusing first on child protection, FamilyStory is transforming the way local authorities approach technology for children’s social care.