2. Solve a whole problem for users

This guidance will help you apply standard point 2.

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

Service designersUser researchersContent designersInteraction designers

Why it's important

People often don't know how education services fit together. It helps if you can bring things together into a journey which makes sense to users, irrespective of which organisation they belong to or channel they use.

You may not be able to fix a whole problem, but you may be able to improve it and support or influence a wider solution.

Discovery

Things to consider:

Things to avoid in discovery

  • designing solutions or building a service. Discovery is about understanding the problem that needs to be solved before committing to building a service

  • not exploring if the benefits of looking further into the problem outweigh the cost of moving into alpha

  • ending your service at the end of an application, for example, not when the user has achieved their goal

Alpha

Things to consider:

  • evidence where your service interacts with other products and services and whether you've spoken to those teams. Use FIPS (DfE staff only) to help you do this
  • speak to teams working on similar services to share knowledge of the types of users, user research carried out, or design work done to meet user needs
  • plan how to talk through an end-to-end journey at a service assessment
  • understand non-digital or offline processes and their impact or relationship to your service
  • explore how your service fits in with other channels or services relevant to your user group
  • consider how to make your service consistent in the look and feel, the language used, and the tone of voice of other DfE services that are part of the same user journey
  • create a map of the current user journey, pain points, and what the user journey will look like
  • make it easy for users to focus on the next step in a journey. For example, how to navigate their way through your service to help them achieve their goal
  • how the concepts being tested avoid duplication of what already exists
  • join together other relevant services or DfE content to solve a whole problem

Things to avoid in alpha

  • just designing a digital version of a paper process

  • ending your service at a point that doesn't make sense for a user

  • the scope for private beta being too large. You won't be able to iterate your service if it's for too many users

  • using AI without explaining why it's the best way to solve the problem

Beta and live

Things to consider:

  • use research and private beta analytics to show your service works. Demonstrate, with evidence, how users can get through the end-to-end journey unaided, especially during public beta
  • collaborate with teams that make part of the end-to-end service
  • understand - and research - the full end-to-end journey, including online and offline journeys and GOV.UK content
  • consider how support, including assisted digital channels, are working
  • show how users will know about your service, including whether it has a clear starting point on GOV.UK.
  • design and test offline processes and user support, including assisted digital routes, do this by public beta
  • understand non-digital or offline processes and their impact or relationship to your service
  • ensure user support process is in place

Things to avoid in beta and live

  • not testing all service touch points

  • not doing usability testing with users with access needs, separate from an audit