17/04/13 GDS design principles

https://www.gov.uk/designprinciples 1/16

For a safer, faster, better experience online you should upgrade your browser. Find out m ore about browsers(https://www.gov.uk/support/browsers) Close

ALPHA (http://digital.cabinetoffice.gov.uk/2012/04/03/introducing-the-design-principles-alpha-for-gds/) Last updated 2 July 2012

Government Digital Service Design Principles

Listed below are our design principles and exam ples of how we’ve used them so far. These build on, and add to, our original 7digital principles (http://www.flickr.com/photos/benterrett/7041509709/).

1. Start with needs*

*user needs not government needs

The design process m ust start with identifying and thinking about real user needs. We shoulddesign around those — not around the way the ‘off icial process’ is at the m om ent. We m ustunderstand those needs thoroughly — interrogating data, not just m aking assum ptions — andwe should rem em ber that what users ask for is not always what they need.

We use ‘needs’ as an organising principle since people com e to our sites to accom plish tasksand to fulf il needs, not just to hang out. Focusing on needs m eans we can concentrate on thethings that deliver m ost value for m oney.

Examples

Examples of how we start with needs.

Tried & tested

If we start from the wrong place there’s no chance we will get the designright. Before we begin any project we spend a long tim e working out whatthe user needs are. This blog post explains a bit m ore about how we do that.(http://digital.cabinetoffice.gov.uk/2011/09/19/introducing-the-needotron-working-

out-the-shape-of-the-product/)

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 2/16

Be clear

Tried & tested

(https://assets.digital.cabinet-office.gov.uk/designprinciples/content/01/example-

vat-3a821ac29eacf738e55c5d6c79d4dbcf.png)

This VAT page (https://www.gov.uk/vat-rates) is a good exam ple of a designthat results from thinking about user needs. Most people will arrive at thispage after a search for VAT rates. The answer m ost people are after is 20%,so we’ve m ade that the largest, clearest piece of inform ation on the page.You can get the answer you are looking for incredibly quickly. There is m oreto VAT than just one rate so we’ve included this but clearly designed assecondary inform ation. There’s a slim chance you’ve arrived at the wrongpage so we have links to genuinely related item s in the box on the top right.

The page is sim ple and clear but contains all the dif ferent inform ation youm ight need.

2. Do less

Governm ent should only do what only governm ent can do. If som eone else is doing it — link toit. If we can provide resources (like APIs(http://en.wikipedia.org/wiki/Application_programming_interface)) that will help other people buildthings — do that. We should concentrate on the irreducible core.

We’ll m ake better services and save m ore m oney by focusing resources where they’ll do them ost good.

Examples

An example of how we are doing less

Tried & tested

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 3/16

Lots of page designs fail because the focus of the page isn’t clear. Don’t tryto cram everything on to one page. By trying to do less and deciding what’sthe m ost im portant thing on the page before you start designing you’ll endup with sim pler, clearer designs.

Rem em ber that governm ent should only do what only governm ent can do,so while it’s right we should provide inform ation about VAT it’s notnecessary for us to provide inform ation about keeping bees(http://webarchive.nationalarchives.gov.uk/20121015000000/www.direct.gov.uk/

en/Environmentandgreenerliving/Smallholders/DG_179478).

3. Design with data

Norm ally, we’re not starting from scratch — users are already using our services. This m eanswe can learn from real world behaviour. We should do this, but we should m ake sure wecontinue this into the build and developm ent process — prototyping and testing with real userson the live web. We should understand the desire paths of how we are designing with data anduse them in our designs.

This is the great advantage of digital services — we can watch and learn from user behaviour,shaping the system to f it what people naturally choose to do rather than bending them to asystem we’ve invented.

Examples

Examples of how we are designing with data

Experim ental

Desire paths are a great way to understand what your user is trying to do.

You can read a great explanation of desire paths on wikipedia(http://en.wikipedia.org/wiki/Desire_path) as well as see som e exam ples in thisf lickr pool (http://www.flickr.com/groups/desire_paths/pool/).

A/B testing

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 4/16

Experim ental

We’re using A/B testing (http://en.wikipedia.org/wiki/A/B_testing) to see howcolour changes can affect user behaviour.

We’ll write m ore about what we are m easuring around user behaviour soon.There are lots of ways to approach this: to give one exam ple GoogleAnalytics (http://www.google.com/analytics/) is a popular tool that can helpassess user data.

4. Do the hard work to make it simple

Making som ething look sim ple is easy; m aking som ething sim ple to use is m uch harder —especially when the underlying system s are com plex — but that’s what we should be doing.

With great power com es great responsibility — very often people have no choice but to use ourservices. If we don’t work hard to m ake them sim ple and usable we’re abusing that power, andwasting people’s tim e.

Examples

An example of where we have done the hard work to make

something simple

Tried & tested

You shouldn’t have to understand how governm ent works to be able to

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 5/16

You shouldn’t have to understand how governm ent works to be able tointeract with it. Governm ent and the services it provides are oftencom plicated, so we should hide com plexity where possible.

Our Sm art Answer (http://digital.cabinetoffice.gov.uk/2012/02/16/smart-

answers-are-smart/) form at is a good exam ple of this. Both Married Couple’sAllowance (https://www.gov.uk/calculate-married-couples-allowance) andMaternity Pay Entitlem ent (https://www.gov.uk/maternity-benefits) are goodexam ples of how we have taken som ething com plicated and m ade theinteraction sim ple for the user. The code for sm art answers is available onGitHub. (https://github.com/alphagov/smart-answers)

5. Iterate. Then iterate again.

The best way to build effective services is to start sm all and iterate wildly. Release Minim umViable Products (http://en.wikipedia.org/wiki/Minimum_viable_product) early, test them with realusers, m ove from Alpha (http://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha) to Beta(http://en.wikipedia.org/wiki/Software_release_life_cycle#Beta) to Launch adding features andref inem ents based on feedback from real users.

Iteration reduces risk. It m akes big failures unlikely and turns sm all failures into lessons. Thisavoids the 200 page spec docum ent which can turn into a bottleneck. This, again, is the coreadvantage of digital: we’re not building bridges — things can be undone.

Examples

Some examples of how we have been iterating

Tried & tested

Once you’re happy with what som e code is doing, m ake sure it is ‘clean’ andeasy to read to aid future m aintenance by yourself and others. You m ightalso consider using this to reduce com plexity and code ‘bloat’. If you’ve builtsom ething twice before, pause before doing it a third tim e and considerwhether you can refactor to avoid duplication. For instance, in your CSS, useclasses rather than IDs to target com m only styled elem ents.

Release and keep improving

Tried & tested

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 6/16

(https://assets.digital.cabinet-

office.gov.uk/designprinciples/content/05/early_designs-

2aa3985654e16e7c0133f1173bf6d9f4.jpg)

Release often and release early. A ‘launch’ is not the end of the project, butan opportunity to test the product in the wild, and get feedback quickly. Acton the feedback and continuously im prove the product. You can read som eexam ples of this on the blog, day 1 iterations(http://digital.cabinetoffice.gov.uk/2012/02/01/govuk-beta-day1/) and furtheriterations the following week(http://digital.cabinetoffice.gov.uk/2012/02/02/day-2-of-gov-uk-more-iteration/)

m ade on the GOV.UK beta, and the INSIDE GOVERNMENT f irst weekiteration (http://digital.cabinetoffice.gov.uk/2012/03/13/inside-government-how-

busy-the-busy-bees-have-been/).

Alpha. Beta.

Tried & tested

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 7/16

(https://assets.digital.cabinet-office.gov.uk/designprinciples/content/05/iterate-

07eecd4339f09355b4b251ccbf58f822.png)

We released an alpha version of GOV.UK (http://alpha.gov.uk/) last year andwe released the beta version (https://www.gov.uk/) in January. Other people ingovernm ent are starting to use this approach: Shropshire WIP(http://shropshire.gov.uk/projectwip/) and DirectScot(http://www.directscot.org/) being good exam ples.

6. Build for inclusion

Accessible design is good design. We should build a product that’s as inclusive, legible andreadable as possible. If we have to sacrif ice elegance — so be it. We shouldn’t be afraid of theobvious, 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. Infact, the people who m ost need our services are often the people who f ind them hardest touse. If we think about those people at the beginning we should m ake a better site for everyone.

Examples

Some examples of how we have been building for inclusion

Tried & tested

This table shows an exam ple of using highly contrasting colours, whichm akes the inform ation easier to read.

ARIA landmark roles

Tried & tested

<header role=”banner”>…</header>

<nav role=”navigation”><ul>…</ul></nav>

<footer role=”contentinfo”>…</footer>

ARIA landm ark roles help people who use screen readers and other assistivetechnologies understand the purpose of dif ferent areas of a page. Thisvideo dem onstrates how som eone using a screen reader benef its fromARIA landm ark roles: http://www.nom ensa.com /blog/2011/how-aria-

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 8/16

landm ark-roles-help-screen-reader- users/(http://www.nomensa.com/blog/2011/how-aria-landmark-roles-help-screen-reader-

users/)

Form fields and labels

Tried & tested

<label for=”name”>Name:<input type=”text” id=”name” placeholder=”For example John Smith”></label>

<label for=”yes”><input type=”radio” name=”citizen” id=”yes” value=”yes”>Yes</label><label for=”no”>

<input type=”radio” name=”citizen” id=”no” value=”no”>No</label>

Form labels help everyone enter the right inform ation. Associating the formlabel and form f ield within the HTML m eans that people using screenreaders also have access to the label.

The position of the label text is im portant. For checkboxes and radio buttonsthe label is best positioned to the right of the f ield. For all other f ield typesthe label is best positioned to the left.

Skip links and hidden content

Tried & tested

<!-- In HTML --><a href=”#content” class=”visuallyHidden”>Skip to content </a>

/* In CSS */.visuallyHidden { position: absolute; left: -999em;}

Skip links lead to a point on the sam e page instead of another page. Theyprovide a useful shortcut for people who do not use a m ouse.

The best place to include a skip to content link is towards the top of the page.This m akes it easy for keyboard only users to reach, and it provides aconvenient way of m oving keyboard focus directly to the start of the m ainbody of the page.

Skip links m ay be hidden from view by default, but should be brought intoview when the link is given keyboard focus. This approach m akes the skiplink available to both sighted and non sighted keyboard only users, whilstkeeping the visual experience clean.

Clear link text

Tried & tested

<a href=”guide.html”>Guide to maternity leave</a>

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 9/16

Links should act like signposts to inform ation. It’s best if they do thisconcisely and accurately, so that people are given a clear indication of wherethe link will lead.

It’s also a good idea to avoid references to the way the link will be activated.People on touch screen devices won’t “Click here” for exam ple, and neitherwill people unable to use a m ouse for accessibility reasons.

7. Understand context

We’re not designing for a screen, we’re designing for people. We need to think hard about thecontext in which they’re using our services. Are they in a library? Are they on a phone? Are theyonly really fam iliar with Facebook? Have they never used the web before?

We’re designing for a very diverse group of users with very dif ferent technologies and needs.We need to m ake sure we’ve understood the technological and practical circum stances inwhich our services are used. Otherwise we risk designing beautiful services that aren’t relevantto people’s lives.

Examples

Examples of how we have been considering context

Experim ental

Your service could be accessed from alm ost anywhere on a wide variety ofdevices in all sorts of dif ferent environm ents. Consider how the usagem ight change for each of these. For instance, a low-cost, low-power sharedPC in a public library or a sm art phone used whilst walking down the street.

Rem em ber we are designing inform ation, not pushing pixels around ascreen.

8. Build digital services, not websites

Our service doesn’t begin and end at our website. It m ight start with a search engine and end at

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 10/16

Our service doesn’t begin and end at our website. It m ight start with a search engine and end atthe post off ice. We need to design for that, even if we can’t control it. And we need to recognisethat som e day, before we know it, it’ll be about dif ferent digital services again.

We shouldn’t be about websites, we should be about digital services. Right now, the best way todeliver digital services is via the web — but that m ight change, and sooner than we m ightexpect.

Examples

One example of our content being used outside of our

website

Experim ental

One exam ple of this is the WordPress plugin that Saul Cozens(http://saulcozens.co.uk/pages/wordpressgovuk) m ade to “reproduce contentfrom GOV.UK on any Wordpress post or page.”

9. Be consistent, not uniform

Wherever possible we should use the sam e language and the sam e design patterns — thishelps people get fam iliar with our services. But, when this isn’t possible, we should m ake sureour underlying approach is consistent. So our users will have a reasonable chance of guessingwhat 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 im agineevery scenario and write rules for it. Every circum stance is dif ferent and should be addressedon its own term s. What unites things, therefore, should be a consistent approach — one thatusers will hopefully com e to understand and trust — even as we m ove into new digital spaces.

Examples

Examples of our design work being consistent but notuniform

Likely to change

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 11/16

So far we have released beta versions of GOV.UK and INSIDEGOVERNMENT. Com paring page designs from both of these projects givesyou a good visual exam ple of what we m ean in this principle. These designsfeel like they com e from the sam e fam ily, but they are dif ferent dependingon the dif ferent requirem ents of the page.

10. Make things open: it makes things better

We should share what we’re doing whenever we can. With colleagues, with users, with theworld. Share code, share designs, share ideas, share intentions, share failures. The m ore eyesthere are on a service the better it gets — howlers get spotted, better alternatives get pointedout, the bar gets raised.

Partly because m uch of what we’re doing is only possible because of open source code and thegenerosity of the web design com m unity. So we should pay that back. But m ostly becausem ore openness m akes for better services — better understood and better scrutinised. If wegive away our code, we’ll be repaid in better code. That’s why we’re giving away all this...

Examples

Design

Tried & tested

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 12/16

This is an exam ple from the GOV.UK beta (https://www.gov.uk/) that illustratesm any of these design principles in action.

Colour palette

Tried & tested

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 13/16

These are the colours we’ve used for GOV.UK (https://www.gov.uk/). It’s adeliberately broad palette as the scope for the site is so large. We use thepaler colours the m ost and the stronger colours when we want to drawattention to som ething.

You can download this colour palette as an Adobe Swatch Exchange f ile(https://assets.digital.cabinet-office.gov.uk/designprinciples/betacolours-

e728143a52c2f271405623feab2d7a1a.ase), then you can im port them straightinto Photoshop or Illustrator

You can also download a pdf of the colour palette(https://assets.digital.cabinet-office.gov.uk/designprinciples/betacolours-

31e01ba9a1f276e9f7c972e3858d9be9.pdf), so you can copy and paste the hexvalues.

Typography

Experim ental

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 14/16

Typography is extrem ely im portant in any design. It’s a key factor inlegibility. We have m ore control over web typography than ever before andwe should ensure our designs are clear and easy to read.

Over the next few m onths we will be testing dif ferent typographic designs.

Currently we’re using Gill Sans (http://en.wikipedia.org/wiki/Gill_Sans) forheadlines and section headings. We’re using it as ‘web font’, which isn’twithout issues so we’re using it sparingly and carefully. It adds character and,spaced properly, feels British and m odern.

We’re using Georgia for body text. That’s text that you would actually read,as opposed to glance at, or as used in highlights or warnings.

It was also created by a British typographer(http://en.wikipedia.org/wiki/Georgia_(typeface)).

For pretty m uch everything else we’re using Helvetica, where people have itinstalled, or Arial.

The full list of type styles we’ve used is illustrated here.

Icons

Likely to change

Here are the icons we’ve used on GOV.UK (https://www.gov.uk/).

Collaborative code

Tried & tested

Tools like Github (http://www.github.com) are useful because people can

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 15/16

Tools like Github (http://www.github.com) are useful because people canm ake ‘pull requests (http://help.github.com/send-pull-requests/)’ to help youim prove your code. Find out m ore in our blog post — GOV.UK - a truly openand collaborative platform (http://digital.cabinetoffice.gov.uk/2012/02/02/gov-

uk-truly-open-platform/)

Content principles

Tried & tested

Content is king. Our content design decisions, style and tone are explainedhere (https://www.gov.uk/designprinciples/styleguide).

Transactions

Experim ental

What is a transaction?

At the end of a transaction som e kind of action has been perform ed (aboveand beyond the sim ple exchange of inform ation). Typically this wouldinvolve an exchange of goods and m oney, but governm ent transactions alsoinvolve the transfer or creation of legal rights and obligations. Anotherdistinguishing feature of m any governm ent transactions is that they ofteninvolve m ore than two parties.

More detail coming soon

Experim ental

17/04/13 GDS design principles

https://www.gov.uk/designprinciples 16/16

We’re currently working on a broad range of transactions to create apick’n’m ix of consistent design patterns which we can choose from for usein a num ber of scenarios.

Some things we’ve banned

Tried & tested

We should be sim ple and clear in all our com m unications. Visual m etaphorswhich are overused tend to hinder com m unication rather than help it. Forthat reason lightbulbs, brains, jigsaws, cheetahs, cham eleons andbutterf lies are all banned.

This is an alpha release of the principles and we would like your feedback. Is there anything you think we should add that wouldm ake these principles m ore helpful? You can em ail your feedback to govuk-feedback@digital.cabinet-off ice.gov.uk.

Feedback from GOV.UK