4. Make the service simple to use
This guidance will help you apply standard point 4 (opens in new tab).
Everyone is responsible for meeting the Service Standard. This standard point is most relevant to:
Content Designers Interaction Designers Service DesignersSummary
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 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:
- evidence of how policy decisions can be implemented in a user-centred way
- use of plain English and language that users understand (opens in new tab)
- the types of users and scenarios relevant to the service
- using existing technologies, GOV.UK components and patterns (opens in new tab)
- developing your understanding of the user needs and pain points
Things to avoid at discovery
- designing solutions without understanding user needs
In alpha
Things to consider:
- the user journey being simple to use (opens in new tab) 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 (opens in new tab)
- offline elements, including assisted digital (opens in new tab) 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 (opens in new tab) built and tested with users identified in discovery
- any unique component or pattern, or an adaptation of an existing component from the Design System (opens in new tab), 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 of any resolution
Things to avoid at 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
In 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 at 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.