1. Understand users and their needs

This guidance will help you apply standard point 1.

Everyone is responsible for meeting the Service Standard. This standard point is most relevant to:

User researchersService designersAccessibility specialistsContent designers

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.

Discovery

Things to consider:

  • understand the types and numbers of users who might use your service
  • define the problem to be solved
  • how to involve and consider users with access needs
  • how to demonstrate why you have selected certain research methods
  • set clear, well-scoped research questions
  • use a variety of research methods
  • produce and maintain a prioritised list of user needs based on evidence
  • show how you understand the difference between users and project stakeholders and consider both appropriately
  • start a Data Protection Impact Assessment (DPIA) (opens in new tab, DfE SharePoint users only), where necessary. If you do not have access to the DfE intranet, ask a civil servant to get the information for you
  • create a clear 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

  • define clear hypotheses based on user needs
  • test hypotheses with a variety of quick, throwaway prototypes
  • collaborate with other service-related teams and stakeholders, including policy
  • use existing research and performance data across DfE
  • clearly describe user needs in plain language familiar to users
  • clearly define user groups
  • create a maintain a prioritised list of user stories
  • consider inclusive design from the start, not only when testing with people with access needs
  • use the How many people? tool to help you identify numbers of people with access needs
  • put a plan in place for an accessibility audit
  • carry out research to identify parts of your service which users find difficult
  • evidence how you iterated your 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
  • create a plan for private beta, including the eligibility criteria for real user participation and methods of measuring their experience
  • research and thought into how your service will be maintained and supported once it's live
  • consider how your 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:

  • address recommendations from the most recent phase assessment
  • create a plan for ongoing research and continuous improvement
  • choose the best methods to get results and feedback for the problems identified, do not just rely on usability testing. Other methods you could use include a survey or analytics
  • user research work with performance analysis to define success metrics
  • show how design and user needs have changed over time based on user research
  • test assisted digital routes, for example, offline or supporting routes,
  • complete an accessibility audit of the service and actions taken based on findings
  • carry out a Data Protection Impact Assessment (DPIA) (opens in new tab, DfE SharePoint users only) has been carried out, where necessary
  • complete any necessary security testing
  • consider what you have 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