Understand users and their needs

Summary

Take time to understand users' needs and the problem you're trying to solve for them.

Think about people's entire experience and the systems and processes around the product or service you're building.

Why it's important

You need to understand your users and their needs (opens in new tab) to build something that helps them. Otherwise you could build the wrong thing or make DfE services more difficult to use.

Understanding as much of the context of the user needs as possible will give you the best chance of meeting them in the most simple, cost effective way.

The most obvious problem is not always the one that needs solving. Test assumptions early and often to reduce the risk of building the wrong thing.

How to meet this standard in every phase

You'll be assessed on what you've done to meet this standard at service assessments. However, even if the service you're working on is not being assessed, it's good practice to consider how you'll meet this standard point.

In discovery

Things to consider:

• an understanding of the types and numbers of users who might use the service
• how the team articulate the problem to be solved
• how the team have involved and considered users with access needs
• how to demonstrate why the team selected the research methods they used
• well scoped research questions
• a variety of methods of user research
• a prioritised list of user needs
• an understanding of the difference between users and project stakeholders
• a Data Protection Impact Assessment (DPIA) (opens in new tab) has been started, where necessary. If you do not have access to the DfE intranet, ask a civil servant to get the information for you
• a plan for alpha

In alpha

Things to consider:

• hypotheses related to user needs
• hypotheses tested with a variety of quick, throwaway prototypes
• collaboration with other service-related teams and stakeholders, including policy
• use of existing research and performance data across DfE
• clear definition of user needs written in language familiar to users
• clear definition of user groups
• a prioritised list of user stories
• how inclusive design is being considered in addition to testing with people with access needs
• use the inclusivity calculator to help you identify numbers of people with access needs
• an accessibility audit plan
• research that identifies parts of the service which users find difficult
• evidence of how the team iterated the service to make these parts easier for users and how this was tested and researched
• test and validate concepts with users with access needs
• show an understanding of the tools and technology users have access to
• a plan for private beta, including the eligibility criteria for real user participation and methods of measuring their experience
• research and thought into how the service will be maintained and supported
• how the service might need to scale in the future

In beta and live

Things to consider:

• recommendations from most recent phase assessment have been addressed
• a plan for ongoing research and continuous improvement
• choosing the best methods to get results and feedback for the problems identified, not just relying on usability testing. Other methods you could use include a survey or analytics
• user research working with performance analysis to define success metrics
• how design and user needs have changed over time based on user research
• assisted digital routes, for example, offline or supporting routes, have been tested
• a third party accessibility audit of the service and actions taken based on findings
• a Data Protection Impact Assessment (DPIA) (opens in new tab) has been carried out, where neccessary
• any neccessary security testing
• what the team has done beyond public beta to continue to meet user needs and deliver outcomes, when moving to live

Profession specific guidance

Each DDaT profession in DfE has their own community and guidance.

User Research Manual

Design Manual