Make the service simple to use
This guidance will help you apply standard point 4 (opens in a new tab).
Everyone is responsible for meeting the Service Standard. This standard point is most relevant to:
Designers User researchersSummary
Build a service that's simple to use so that people can succeed first time. Test it with users to make sure it works for them.
Why it's important
People expect services to work. They need things to be easy when they are trying to complete a task or find information.
As a public sector organisation we have a legal duty to consider everyone's needs when designing and delivering services.
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:
evidence of how policy decisions can be implemented in a user-centred way
use of plain English and language that users understand
the types of users and scenarios relevant to the service
using existing technologies, GOV.UK components and patterns
developing your understanding of the user needs and pain points
Things to avoid in discovery
-
designing solutions without understanding user needs
Alpha
Things to consider:
the user journey being simple to use and understand, and based on research
risks associated with the service have been mitigated through design
a consistent user experience with other DfE services
the route users take to the service has been considered
how the service will look and work on every browser or device users access it on
offline elements, including assisted digital routes, have been considered
a user-centred approach has been taken
technology decisions supporting accessible and usable design
content being tested to make sure that users understand it
prototypes built and tested with users identified in discovery
any unique component or pattern, or an adaptation of an existing component from the Design System, are shared and tested. Plus, a plan for how you will keep them up-to-date with existing systems
how users will report a problem with the service and how they'll be supported and updated on any resolution
Things to avoid in alpha
-
dead ends in the journey or a disconnect between online and offline actions
-
where the service starts and ends not being clear
-
the service not achieving the users' goal
Beta and live
Things to consider:
how data has been used to understand service performance and a plan for how you'll use this in live
evidence of continuous improvement to make changes to the user journey or content
continual monitoring of feedback and testing usability
evidence of usability testing, including users with the lowest level of digital skills
how the service meets accessibility requirements
user research to understand any performance issues
Things to avoid in beta and live
-
not having a plan to continually improve the service
-
not understanding how user needs might change over time
Profession specific guidance
Each DDaT profession in DfE has their own community and guidance.