Service design starts with identifying user needs. If you don’t
know what the user needs are, you won’t build the right thing. Do
research, analyse data, talk to users. Don’t make assumptions. Have
empathy for users, and remember that what they ask for isn’t
always what they need.

• What we mean when we say “service transformation” by Mike Bracken
• Most of government is mostly service design most of the time by Matt Edgar
• Vertical campfires: our user research walls by Kate Towsey

If you’ve found something that works, make it reusable and shareable instead of reinventing the wheel every time.  This means building platforms and registers others can build upon,
providing resources (like APIs) that others can use, and linking to
the work of others. Concentrate on the irreducible core.

• Building digital civic infrastructure from the ground up by Mike Bracken
• What we’ve learned about scaling agile by Jamie Arnold

Making something look simple is easy, but making something simple to
use is hard — especially with complex underlying systems.

Remember that you have a duty of care to the user. Don’t take “It’s always been that way” for an answer. It’s harder
work to make things simple, but it’s the right thing to do.

• Doing the hard work to make things simple by Mike Bracken
• I fought the law and the users won by Pete Herlihy
• This is what we mean when we say “service transformation” by Mike Bracken

The best way to build good services is to start small and iterate wildly. Release Minimum Viable Products early so you can test them with actual users. Move from Alpha to Beta to Live – 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 a prototype isn’t working, don’t be afraid to scrap it and start again.

• Discovering discovery by Sarah Prag
• 6 case studies using research and data to improve a live service by Ben Holliday
• Exemplars making examples of themselves by Mike Bracken

Accessible design is good design. Everything we build should be readable, intuitive and inclusive. If we have to
sacrifice elegance — so be it. We’re building for needs, not audiences. We’re designing for the whole country, not just people who are used to using the web, or who are knowledgeable in our particular subject matter.

The people who find our services hardest to use, are often those who need them most. Let’s think about those people from the start.

• What we mean when we talk about accessibility by Alistair Duggin
• Consider the range of people that will use your product or service by Alistair Duggin
• Hope, inspiration and inclusion by Steven Mark
• Building for inclusion by Léonie Watson

We’re designing for people, so we need to know how they will use our
services. Will they be in a library? Will they use a phone? Are they
only really familiar with Facebook? Or have they never used a website before?

• How we recruited people with low/no digital skills on Carer’s Allowance by Simon Hurst
• The right place to do rural research by Emily Ball

A service is something that helps people to do something. Our job
is to discover user needs and build a service to support those needs.

Often, building a digital service will include a new website or webpages, but the process doesn’t stop there. The digital world has to connect to the real world, so we have to think about all aspects of a service, and
make sure they add up to something that helps the user get what they need.

• Digital leadership by Kit Collingwood-Richardson
• Revealing the hidden side of transformation by Mike Bracken
• Not the HMRC of old by Mike Bracken

If possible, use the same language and design patterns
for everything you do. This will help people to become familiar with our services, learn how to use them more quickly, and recognise them as ours. When this isn’t possible, we should make sure our
approach is consistent, by following these principles and the wider values and design processes of the team.

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 the needs of users change.

• The GOV.UK Design Patterns Hackpad
• What’s the design process at GDS? by Ben Terrett

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 are
spotted, better alternatives are pointed out, the bar is raised.

Much of what we’re doing is only possible because of open source
code and the generosity of the web design community. We should
pay that back.

• GDS, USDS, and sharing expertise by Mike Bracken
• How sharing helps us improve digital services by Mike Bracken