Design patterns for government services: A community, not a library

No notes for slide

This is the name of this tutorial.

We’re going to talk about:

What it’s like to design a big site like GOV.UK
How we approached the challenge of designing at scale
How we built a community around our design patterns
Specific design patterns we think are interesting or relevant to government services

Our colleagues at GDS identified 8 groups of things that designers do:

Back-end: building interfaces into actual systems
Front-end: production ready HTML and CSS
Making: front-end code and prototyping
Interaction: interaction patterns and sketching
Journey: what the flow of events should be
Process + system: interrogate and improve backend, business, processes, costs
Org + purpose: articulate organisation objectives, communicting them clearly
Communication design: create simple and effective signage, conference materials, booklets, posters, stickers, web graphics

And then looked at the typical things that some sorts of designers do:

Front-end developer: back-end, front-end and making
Interaction designer: making, interaction and journey
Service designer: journey, process+system, org+purpose
Graphic designer: org+purpose, communication design

We’re still thinking about how other people within the team fit into the picture

At the conference, we asked people whether they identified with any of these roles. ‘Interaction designer’ was the most popular choice, with an interesting spread amongst all the other roles and several people picking more than one.

Hands up:

Who currently works on a government service?
Who’s worked on one in the last year?
Who’s used one in the last year?

Compared to the map, what job titles do we have?

GDS is part of the Cabinet Office.

We’re a department of about 600 people.

We work with government departments to help make their digital services and information simpler, clearer and faster.

We’re responsible for GOV.UK

Designing GOV.UK
A brief history of how the GOV.UK design team grew from one person to over 100 people, and how we’ve approach the challenges that this presents.

2. Using design patterns
We’re going to introduce one of our more recent design patterns and ask you to help us apply it to a problem page on GOV.UK.

3. Example patterns
We’ll talk about 4 or 5 of the patterns we use regularly in government services and what we’ve learned (or rediscovered) about them.

4. Summary and questions
A quick summing up of what we learned, what we’re planning, the limits of design patterns and a chance to ask any questions.

GOV.UK A single website for people interacting with the UK Government

That saving is based on what it would have cost to maintain all the different websites that existed before.

GOV.UK is a mixture of information and services.

Information like…

A guide to keeping a pet pig or ‘micro pig’.

Did you know you needed a licence to walk your pet micro pig?

Get a birthday or anniversary message from the Queen

Report treasure

Burial at sea

How to claim asylum in the UK

Carer’s allowance was one of the first services that GDS worked on.

Carer’s allowance video

https://www.youtube.com/watch?v=IYBLX3V8ek4

Over 138,000 Carer’s have used the service so far

Real social impact - Carer’s have very little time for anything else and the service is 24hr

——-

Transcript of video: GOV.UK Transformation

You can now apply for Carer's Allowance using a simple online service.

Pete Desmond, Service Manager, Carer's Allowance Digital Service:
"Carer's allowance is a benefit that's provided to people who are really deserving in society.

These are people who are looking after friends and family that are very ill, in some cases terminally ill, and it's providing them with an income to help support the cost of caring for that individual.

When having to deal with all these problems and all the other strife that's going on in their lives, being able to claim Carer's Allowance should be the least of their worries."

Kathryn Baxendale, Subject Matter Expert, Carer's Allowance Digital Service:
"The new service is to enable people to claim Carer's Allowance online which is a much quicker and easier process than using the paper form."

Pete Desmond:
"We've been able to remove 170 questions from the process; that's 49%, and we've done that because we've challenged the way that policy's been interpreted on the claim form."

Kathryn Baxendale:
"Make sure that the customer can understand and progess through the claim, giving us the right information to make a quick decision on their application."

Pete Desmond:
"We've simplified things and cut things back to just the bare information that customers need, and we've done that via our user testing and research.

The service would not be up and running without the user research, to make sure that the participants, the carers' voice is at the heart of everything that we do.

We've had people, less confident users, who by the time they get from the start of the claim through to the end, you can see them, they say this, 'That's so much better than I expected. I could go away and do that on my own now, it's been so good'."

Kathryn Baxendale:
"Carers are busy people and these are some of the most vulernable people in society, so if we're supporting them by providing a really easy method of claiming Carer's Allowance, then that to me has got to be a good thing because that's what we're here to do."

www.gov.uk/apply-carers-allowance

The main thing that informs our design are our users.

Because we provide government services, our users are ANYONE who is entitled to and needs that service.

We can’t leave anyone behind.

This means we have to try extra hard to reach people who might be unfamiliar with digital technologies.

Imagine the bell curve of your users and how skilled or confident they are at using computers.

The GOV.UK curve extends much further to the left than the average - these are the users we need to reach.

We thought we’d start with a very quick history of designing GOV.UK.

The context is helpful in understanding our approach.

June 2011

alpha.gov.uk goes live.

The team is 14 strong. 1 lead designer, Paul Annett, but others like Richard Pope and James Weiner are also having a strong input.

By May 2012 we had a small design team of around 10 people, all co-located in Holborn, led by Ben Terrett.

GOV.UK was in Public Beta. No services - just information.

GDS was less than 100 people.

We were a small enough team to all fit in a room.

And here we all are - in a stairwell.

The great thing about a team of this size was:

Easy to share and discuss ideas

- Quality and consistency emerged naturally

Now fast forward a few years

GOV.UK has been live for a while

GDS is 500+ people

Twice as many GDS designers, but half of them are out working with the departments.

That’s a photo of one of our last X-government design meet-ups.

80 designers from 5 departments, and that’s just the ones who could make it to Leeds.

And each service makes use of multiple suppliers from the private sector.

This is a map showing all the agencies and SMEs working on GOV.UK services.

So we’ve gone from stairwell - to this.

There are (far) more designers working on GOV.UK outside GDS than there are within GDS

How do you retain the benefits of a small co-located team, when you have multiple teams distributed around the country?

How do you get designers to feel engaged with the whole site and part of a larger team?

How do you keep the user experience consistent without stifling innovation in the teams?

How do you stop the centre becoming a bottleneck?

We learn from and engage with the design community in various ways:
- Face to face
- Through mailing lists and other informal resources
- By publishing advice in the service manual
- By checking whether services are following the advice in service assessments

We do all these things.

Last week we ran out first 3-day designer training course.

Great for establishing a common design culture.

Actually useful - it’s a decision-making tool.

They look good on posters, too.

1 Start with needs*
2 Do less
3 Design with data
4 Do the hard work to make it simple
5 Iterate. Then iterate again.
6 This is for everyone
7 Understand context
8 Build digital services, not websites
9 Be consistent, not uniform
10 Make things open: it makes things better

Then, we deliberately made the template as minimal as possible:

Header, footer, logo, New Transport typeface

That way:

it could accommodate lots of different kinds of service
we wouldn’t have to keep updating it
minimising dependencies (bad experience at tfl.gov.uk)

Then we created a set of common design elements.

Building blocks.

Grids, typography, colours, basic form styles etc.

Then we overlay higher level patterns. This is one that we launched recently: it’s about how to show error messages.
We’ve learned that we have to put hints to designers rather than example content to make sure it gets designed.

On the service manual we’ve got a small set of the most commonly requested patterns.

Each pattern, for example the Addresses one on the left, had a corresponding hackpad discussion, as on the right.

There are far fewer patterns and they tend to be much shorter. There are far more discussions and they’re a lot longer.

We also have a space to discuss and collaborate on patterns. We use Hackpad – it’s not pretty.

But it’s perfect for collaborating on ideas.

It’s just a wiki, but it’s a good one:

real-time
you can ‘follow’ pages
you can ‘at’ people
you can paste images from the clipboard
it’s got an API

It’s be around for just over 18 months and it’s still growing.

There’s some kind of activity most days.

About half the members are designers

We use a free service called Hackpad.

It’s now owned by Dropbox.

It’s be around for just over 18 months and it’s still growing.

There’s some kind of activity most days.

About half the members are designers

Google ‘service manual form structure’
This pattern explains how to structure forms for GOV.UK services.
We’re going to concentrate on section 3: ‘Start with one thing per page’

- Time and effort are subjective
- Good because:
- works well on small screens
- breaks complex tasks into simple chunks
- easier to recover from errors
- easier to do things like save progress

Find this page: look for ‘service manual form structure’

It’s far too long.

Try applying the ‘one thing per page’ pattern.

We’d like to share some particular patterns because we think they’re particularly interesting.

This is what I found a year and a half ago when I did an audit of progress indicators across the exemplars.

This was before the Hackpad and elements.

We wrote up this design pattern with three options.

We’ve learned that people like progress bars but they don’t make any difference

We’re working on a new pattern that will replace ‘summary menus’.

This is an example of what we now recommend.

Yes, you need validation on the fields. But remember - ‘Do the hard work to make it simple’.

The controls are way too small. Fitts Law.
To make matters worse, people don’t know (or trust) that they can click on labels.
We’ve tried to make the hit space more obvious.

Also - the circle/square thing is a learned convention - new users don’t know it. So, use language. Eg. “Select one, select all”

Important to note: we put 'select all that apply' when the user can select multiple answers.

We’re still experimenting with whether or not to expand the yes/no statements

This pattern has attracted a lot of great contributions from outside GDS and internationally.

We’d like to share some particular patterns because we think they’re particularly interesting.

I’ve heard people say “Well eventually the developers will just be able to go straight to the pattern library”.

You can use really good design patterns and still create a terrible service.

It's in the patterns you choose, how you combine them and how you customise them.

We especially see this with typographic design. GOV.UK services that use the templates, elements and patterns but just look wrong somehow. The spacing and rhythm is all out.

Well, maybe they can a bit - but it’s time consuming and not much fun and everyone ends up hating you.

Much better to develop the patterns from the ground up - that way you get consensus, because the people who need the patterns got to create them.

Designing for government can be really frustrating.
Often you know exactly what needs to happen.
But making it happen is the tricky bit.
You need to be persistent, you need to be able to explain, influence and negotiate.

Design patterns don’t help much with that.

It can feel like a least half of the usability gains come from successfully negotiating with the business rather than coming up with some amazing innovative design.

Carer’s Allowance video: 170 questions removed. 49%

Known answers to common problems

Designing for government can be really frustrating.
Often you know exactly what needs to happen.
But making it happen is the tricky bit.
You need to be persistent, you need to be able to explain, influence and negotiate.

Design patterns don’t help much with that.

It can feel like a least half of the usability gains come from successfully negotiating with the business rather than coming up with some amazing innovative design.

Carer’s Allowance video: 170 questions removed. 49%

Design patterns for government services: A community, not a library

Caroline Jarrett

Design patterns for government services: A community, not a library