1. Understand users and their needs
This guidance will help you apply standard point 1 (opens in new tab).
Everyone is responsible for meeting the Service Standard. This standard point is most relevant to:
User Researchers
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 are 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 intranet page 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
Things to avoid at discovery
- user needs that describe solutions or business requirements
- confusing user needs with desires
In alpha
Things to consider:
- hypotheses related to user needs
- hypotheses tested with a variety of quick, throwaway prototypes (opens in new tab)
- 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 (opens in new tab) is being considered in addition to testing with 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
Things to avoid at alpha
- research findings that are about user preferences rather than user behaviour
- a lack of different ways of testing solutions
- not testing with users with access needs
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 (opens in new tab) 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 intranet page in new tab) has been carried out, where neccessary. If you do not have access to the DfE intranet, ask a civil servant to get the information for you
- 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
Things to avoid at beta and live
- not testing all service touch points
- not doing usability testing with users with access needs, separate from an audit
Profession specific guidance
Each DDaT profession in DfE has their own community and guidance.