Digital design principles
We build content on Hantsweb in line with the Government Digital Services digital principles.
- Starts with user needs
Digital design starts with identifying the real customer needs – not the ‘internal’ process. We must understand the needs thoroughly by using data, not by making assumptions. We should remember what people ask for is not always what they need.
- Do less
Local government should only do what only local government can do. If someone else is doing it — link to it. If we can provide resources (like APIs) that will help other people build things — do that. We should concentrate on the irreducible core.
- Design with data
Normally, we’re not starting from scratch — users are already using our services. This means we can learn from real world behaviour. We should do this, but we should make sure we continue this into the build and development process — prototyping and testing with real users on the live web. We should understand the desire paths of how we are designing with data and use them in our designs.
- Work hard to make it simple
Making something simple to use is hard, especially when the existing systems and business processes are complex. We will start at the beginning, digital cannot simplify what is not already simple – change the process.
- Iterate. Then iterate again
The best way to build effective services is to start small and iterate. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.
- Build for inclusion
Accessible design is good design. We should build a product that’s as inclusive, legible and readable as possible. If we have to sacrifice elegance — so be it. We shouldn’t be afraid of the obvious, shouldn’t try to reinvent web design conventions and should set expectations clearly.
- Build digital services not websites
Our service doesn’t begin and end at our website. It might start with a search engine and end at a registry office. We need to design for that, even if we can’t control it.
- Be consistent, not uniform
Wherever possible we should use the same language and the same design patterns — this helps people get familiar with our services. But, when this isn't possible, we should make sure our underlying approach is consistent. So our users will have a reasonable chance of guessing what they’re supposed to do.
- Understand context
We're designing for a diverse group of users with different technologies and needs. We need to make sure we've understood the technological and practical circumstances in which our services are used. Otherwise we risk designing beautiful services that aren't relevant to people.
- Make things open
We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets.