Understand users and their needs
This guidance will help you apply standard point 1 (opens in a new tab).
Everyone is responsible for meeting the Service Standard. This standard point is most relevant to:
User researchers DesignersSummary
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 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.
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) 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 in discovery
-
user needs that describe solutions or business requirements
-
confusing user needs with desires or preferences
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
Things to avoid in 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
Beta and live
Things to consider:
recommendations from the 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) has been carried out, where necessary
any necessary 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 in beta and live
-
Not testing all service touchpoints
-
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.