11 July 2013
These are the Design Principles of the Government Digital Service which is a team within Cabinet Office of the Government in UK. Listed below are their design principles.
Source: Gov.uk
*user needs not government needs
The design process must start with identifying and thinking about real user needs. We should design around those — not around the way the ‘official process’ is at the moment. We must understand those needs thoroughly — interrogating data, not just making assumptions — and we should remember that what users ask for is not always what they need.
We use ‘needs’ as an organising principle since people come to our sites to accomplish tasks and to fulfil needs, not just to hang out. Focusing on needs means we can concentrate on the things that deliver most value for money.
Government should only do what only 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.
We’ll make better services and save more money by focusing resources where they’ll do the most good.
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.
This is the great advantage of digital services — we can watch and learn from user behaviour, shaping the system to fit what people naturally choose to do rather than bending them to a system we’ve invented.
Making something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.
With great power comes great responsibility — very often people have no choice but to use our services. If we don’t work hard to make them simple and usable we’re abusing that power, and wasting people’s time.
The best way to build effective services is to start small and iterate wildly. 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.
Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. This avoids the 200 page spec document which can turn into a bottleneck. This, again, is the core advantage of digital: we’re not building bridges — things can be undone.
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.
We’re designing for the whole country — not just the ones who are used to using the web. In fact, the people who most need our services are often the people who find them hardest to use. If we think about those people at the beginning we should make a better site for everyone.
We’re not designing for a screen, we’re designing for people. We need to think hard about the context in which they’re using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?
We’re designing for a very diverse group of users with very 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’s lives.
Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office. We need to design for that, even if we can’t control it. And we need to recognise that some day, before we know it, it’ll be about different digital services again.
We shouldn’t be about websites, we should be about digital services. Right now, the best way to deliver digital services is via the web — but that might change, and sooner than we might expect.
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.
This isn’t a straitjacket or a rule book. We can’t build great services by rote. We can’t imagine every scenario and write rules for it. Every circumstance is different and should be addressed on its own terms. What unites things, therefore, should be a consistent approach — one that users will hopefully come to understand and trust — even as we move into new digital spaces.
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 — howlers get spotted, better alternatives get pointed out, the bar gets raised.
Partly because much of what we’re doing is only possible because of open source code and the generosity of the web design community. So we should pay that back. But mostly because more openness makes for better services — better understood and better scrutinised. If we give away our code, we’ll be repaid in better code. That’s why we’re giving away all this...
*user needs not government needs
The design process must start with identifying and thinking about real user needs. We should design around those — not around the way the ‘official process’ is at the moment. We must understand those needs thoroughly — interrogating data, not just making assumptions — and we should remember that what users ask for is not always what they need.
We use ‘needs’ as an organising principle since people come to our sites to accomplish tasks and to fulfil needs, not just to hang out. Focusing on needs means we can concentrate on the things that deliver most value for money.
Government should only do what only 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.
We’ll make better services and save more money by focusing resources where they’ll do the most good.
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.
This is the great advantage of digital services — we can watch and learn from user behaviour, shaping the system to fit what people naturally choose to do rather than bending them to a system we’ve invented.
Making something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.
With great power comes great responsibility — very often people have no choice but to use our services. If we don’t work hard to make them simple and usable we’re abusing that power, and wasting people’s time.
The best way to build effective services is to start small and iterate wildly. 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.
Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. This avoids the 200 page spec document which can turn into a bottleneck. This, again, is the core advantage of digital: we’re not building bridges — things can be undone.
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.
We’re designing for the whole country — not just the ones who are used to using the web. In fact, the people who most need our services are often the people who find them hardest to use. If we think about those people at the beginning we should make a better site for everyone.
We’re not designing for a screen, we’re designing for people. We need to think hard about the context in which they’re using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?
We’re designing for a very diverse group of users with very 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’s lives.
Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office. We need to design for that, even if we can’t control it. And we need to recognise that some day, before we know it, it’ll be about different digital services again.
We shouldn’t be about websites, we should be about digital services. Right now, the best way to deliver digital services is via the web — but that might change, and sooner than we might expect.
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.
This isn’t a straitjacket or a rule book. We can’t build great services by rote. We can’t imagine every scenario and write rules for it. Every circumstance is different and should be addressed on its own terms. What unites things, therefore, should be a consistent approach — one that users will hopefully come to understand and trust — even as we move into new digital spaces.
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 — howlers get spotted, better alternatives get pointed out, the bar gets raised.
Partly because much of what we’re doing is only possible because of open source code and the generosity of the web design community. So we should pay that back. But mostly because more openness makes for better services — better understood and better scrutinised. If we give away our code, we’ll be repaid in better code. That’s why we’re giving away all this...
