We build all of our content in line with the Government Digital Services 10 design principles.
To make sure we’re creating the right content, we’ll identify our user needs and start from there. We’ll do research, analyse data, talk to our users and won’t make any assumptions.
We will make sure that our users can do the thing they need to do as simply and quickly as possible, so that people succeed on their first visit.
We will use performance data to make decisions about how to fix problems and improve the service. We will also test our services with users and listen to their feedback and have analytics built-in, always on and easy to read.
We won’t take “It’s always been that way” for an answer and we will put in the research and time needed to make the right changes needed to simplify services. Once those changes are made, we will make sure that service staff are kept up to date.
We’ll use agile ways of working to release services early, test them with users and make changes based on feedback. We won’t be afraid to scrap and start again.
Accessible design is good design. Everything we build will be as inclusive, legible and readable as possible and we’ll carry out research with participants with access needs who represent the potential audience for the service.
We’re not designing for a screen, we’re designing for people and we will think hard about the context in which they’re using our services. Are they somewhere public? Are they on a phone? Are they only familiar with Facebook? Have they never used the web before?
A service helps people do something and its digital tools must connect to the real world, so we will think about all aspects of a service to make sure it meets the user needs. We will also carry out quality assurance testing and respond to problems as quickly as we can and fix them as soon as possible and actively identify security and privacy threats.
We will use the same language and the same design patterns wherever possible to help users become more familiar with our services. When we find patterns that work we will share them and talk about why we use them but also improve or change them in the future when we find better ways of doing things or the needs of our users change.
We will share our code, designs, ideas, intentions and failures whenever we can with colleagues, with users and with the world. The more eyes there are on a service and the more feedback given and listened to, the more improvements we can make.