We follow Government Digital Service (GDS) design principles, which govern GOV.UK and all gov.uk public websites.
Our foundation
Design content for the user, not the service
A service begins when the user starts to interact with the council and ends when they finish. It isn't just the part that's online or the project at hand – it's all offline interaction as well. No matter how we deliver a message, we design it as part of the whole journey.
Focus on removing content, not creating it
We know that most people don't read most words on a web page. That's why it's important to make sure that every word on a page is there for a reason. Including anything that isn't absolutely necessary, means the crucial content is not read. Removing content is the best way of finding out if it's needed in the first place. Often, the answer is 'no'.
Be clear
If we need to choose between clarity and decorative, clear content wins every time.
We design for every person who needs to use our services. We do that with straightforward journeys and uncluttered pages. We're unapologetic about using plain language: not just simple words that are easy to read, but words that are easy to understand.
Use evidence to make decisions
We use website analytics to spot which parts of content aren't meeting the needs of people using them. We find out which words our users use.
We take time to make sure we only ask people for information that's essential. We design with evidence, test with real users, and iterate to make the content (and service) better.
Help service teams communicate clearly
If we're not communicating well with each other, it's unlikely we're communicating well with users. That's why we challenge the use of jargon and work with service teams to write content that everyone understands.
These principles are not only useful for web and digital teams, but also colleagues working in all areas that touch content design - service teams, policy, communications and operations.
Core Design Principles
1. Start with user needs
Content design starts with identifying user needs. If you don't know what the user needs are, you won't build the right thing. The Digital Content team are here to support you to:
- Research, analyse data, talk to users.
- Not make assumptions.
- Have empathy for users.
- Remember that what they ask for isn't always what they need, or what you want them to have.
2. Do less
A service/council should only do what only a service/council can do.
If we've found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time. This means using adaptable templates, providing resources that others can use, and linking to the work of others.
3. Design with data
In most cases, we can learn from real world behaviour by looking at how existing services and content are used. Let data drive decision-making, not hunches or guesswork. Keep doing that after taking your content live, and testing with users then iterating in response.
Analytics should be built-in to the content project, always on and easy to read. They're an essential tool.
4. Do the hard work to make it simple
Making something look simple is easy. Making something simple to use is much harder - especially when the underlying policies or systems are complex - but that's what we should be doing.
Don't take "It's always been that way" for an answer. It's usually more and harder work to make things simple, but it's the right thing to do.
5. Iterate. Then iterate again
The best way to build good content and services is to start small and iterate wildly. Release first-go content early, test with actual users, then iterate live content by adding features, deleting things that don't work and making refinements based on feedback.
Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. If something isn't working, don't be afraid to scrap it and start again.
6. This is for everyone
Accessible design is good design. Everything we build should be as inclusive, legible, and readable as possible. If we have to sacrifice elegance or decorative elements - so be it.
- We're building for needs, not audiences.
- We're designing for the whole county, not just the ones who are used to using the web or our services.
- The people who most need our services are often the people who find them hardest to use.
- We think about those people from the start.
7. Understand context
We're not designing for a screen; we're designing for people. We need to think hard about the context in which they're accessing and/or using our services.
- Are they in a library?
- Are they on a phone?
- Are they only familiar with social media?
- Have they never used the web before?
- Do they only use the web and not printed documents?
8. Build digital services, not websites
Service and content is something that helps people to do something. Our job is to uncover user needs and build the content that meets those needs.
Of course, much of that will be pages on the web, but we're not here to build websites. The digital world must connect to the real world, so we think about all aspects of a service when supporting teams to create good content. We make sure they add up to something that meets user needs.
9. Be consistent, not uniform
We should use the same language and the same design patterns wherever possible. This helps people get familiar with our content, but when this isn't possible we should make sure our approach is consistent.
This isn't a straitjacket or a rule book. Every circumstance is different. When we find patterns that work, we should share them, and talk about why we use them. But that shouldn't stop us from improving or changing them in the future when we find better ways of doing things or – more importantly - the needs of users change.
10. Make things open: it makes things better
We should share what we're doing whenever we can. With colleagues, with users, with other councils. Share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets - howlers are spotted, better alternatives are pointed out, the bar is raised.
