The UK government now has several hundred designers working on services for citizens. How do we design at scale? By working with our designers as a community.
Presentation by Caroline Jarrett @cjforms at the UXPA 2016 conference in Seattle
Caroline JarrettForms and surveys specialist. Passionate about improving the user experience.
31. @cjforms #gdsteam
There were two videos
• a woman in her 30s struggling to complete a date-
• a man with low vision unable to use a select box
because the browser failed to enlarge it.
67. @cjforms #gdsteam
Read about building a design community:
Follow GDS design notes:
Follow GDS user research:
Join in our discussion of patterns:
Great for establishing a common design culture.
Actually useful - it’s a decision-making tool.
They look good on posters, too.
1 Start with user 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
There are (far) more designers working on GOV.UK outside GDS than there are within GDS
How to design at scale
How to make design patterns for everyone
How to get designers to use patterns
Here are some of the things we’ve done to try and keep the benefits of a small team.
Contains our styles, templates and patterns.
We’ve started doing 3 day training courses.
Started by Clara Greo - we all contribute.
A chance to meet other designers and learn something.
Understand context - origins of GOV.UK
War stories and case studies
We teach people to code using our prototype kit
X-Gov meet ups
Ad hoc workshops
Style guides, templates and patterns
The raw materials.
Ingredients and recipes.
Embodied in code wherever possible.
We work collectively on them via a wiki called Hackpad.
This is how we maintain consistency.
This is how it all hangs together.
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
The main thing that informs our design patterns 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. 1st time internet users. 1st time computer users.
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.
Excerpt from blog post by Katy Arnold, https://assisteddigital.blog.gov.uk/2015/02/13/tales-of-the-unexpected-visas-assisted-digital-research/
A reality check
It’s easy to assume that skilled people will all be IT literate, but what we found was that some skilled visa applicants (for example chefs, oil rig workers, small business retailers and church workers) lacked the skills, confidence or ability to get online.
We’ll give two examples of what happens when you make patterns that work for everyone.
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’.
This pattern explains how to structure forms for GOV.UK services.
The pattern actually has three steps, but for some reason people only remember the last one…
It’s not enough to just churn out a bunch of patterns.
Anyone who’s worked on a large website will know what can happen.
They can quickly go stale, unused by most people.
The tumbleweed effect.
We’re going to discuss 4 methods we’ve tried in the last year.
We’ll give a few examples of each method and talk about how successful we think they’ve been.
Obviously, all patterns should be grounded in research.
But as well as that, the guidance itself should be researched.
Service teams are users of patterns too.
They won’t use them if they can’t find them or they’re not useful.
Here are some things we’ve learned testing patterns with service teams.
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.
We discovered that some patterns are more like ingredients, whereas some are more like recipes.
Help people understand where they are in a transaction and give them the confidence to continue.
On this page:
Start without a progress indicator
If you do use one, keep it simple
Avoid complex progress indicators
1. Start without a progress indicator
Test your service first without any progress indicators at all. It may be simple enough that you don’t need them. If it isn’t, then at least you’ll discover the point at which people start to struggle.
It’s often the order, type or number of questions that causes issues, so try improving these first.
Smart people don’t like being told what to do.
Also - the value of patterns is as much in their creation as in their use.
So you want to include as many people in their creation as you can.
By working on patterns with the people who will be using them, you get the benefit of their experience and their buy-in.
I’m going to give 2 examples of where this method has benefitted us.
So, governments have a habit of asking people personal questions when they don’t need to.
Historically, we’ve had a very black and white attitude to things like gender and sex.
So, this long and interesting discussion on Hackpad enabled us to write a pattern for gender and sex.
We were able to take a potentially controversial topic and invite people to collaborate on it before it made it’s way into formal guidance.
This is basically open policy making.
We had input from international forms experts (Jessica Enders) and from people from the transgender community.
This made the pattern better.
Our form fields used to look like this
On 5 October Simon Hurst is a researcher from DWP, on Personal Independence Payment.
He used our mailing list to raise an issue he’d seen with some participants not being able to see the borders on our text fields.
One participant referred to this as ‘The Apple Effect’
He got responses from Companies House saying they’d found similar issues.
Other parts of government chimed in with they experience.
We established that it was the thickness, not just the colour that was an issue.
We used the list to ask the design and research communities to try out some thicker, darker borders next time they were testing with users with low vision.
Within a couple of weeks we were able to:
Verify that the issue exists in more than one service
Agree collectively on a design change
Test the design change in research on more than one service
Implement the change to our global styles
Our form fields used to look like this
Now they look like this
Seems like a relatively minor change, but it will have had a huge effect for lots of our users.
We were only able to identify the issue and co-ordinate the change because of the community tools we had in place.
Another approach is to try to compel people to follow our advice.
We’ve got two ways we’ve tried to do this - one for the public sector, one for the private sector.
The Service Standard is the thing that GDS and departments use to assess the quality of the services we make.
Services are assessed at least twice during development, and can’t go properly live unless they pass.
Item 13 explicitly tells people to use our design patterns.
This gives us the leverage we need if a service is being developed that is wilfully ignoring our design patterns.
However, we try to make it very clear that service teams can iterate a pattern if they can demonstrate that this better meets the needs of their users.
Embed your patterns into the tools that designers use.
Make it easier to use those patterns than do something else.
We’ve made this specifically for designers.
It lets you make interactive prototypes of GOV.UK services.
It’s a great intro to coding - we offer training too.
It contains a growing number of our patterns.
We added page templates for
Check your answers pages
Put them together and you’ve got a basic transaction.
In our training we teach people how to make a simple transaction using these pages.
They learn how to re-use data across pages and to route users to different questions.
We’re trying to make it easier to use our patterns than to not use them.
Did it work?
The kit is very popular (sometimes too popular)
Feedback from training is very positive
It’s given us a place to put coded patterns