The Government Digital Service (GDS) of the UK is doing something extraordinary – combining all of the UK Government’s web sites into a single portal.
GOV.UK’s Inside Government is surprisingly coherent. Content from dozens of agencies and other groups is presented in one consistent format, yet each government agency has a unique identity on the site.
How could GDS possibly achieve buy-in from so many government agencies? It helped to commission and endorse a study by a respected leader in the field, and to fund the project from the top.
At least as interesting, though, is the design and implementation process. From it, we can take lessons for our own digital projects.
Organize for the user, not for the business
Every government has a complex hierarchy that makes little sense to most citizens. Their web sites often reflect this, requiring people to figure out which agency handles a particular subject matter.
GOV.UK turns this typical scenario on its head, allowing people to navigate by topic or service. Sure, someone can find out what agency is behind this, but many won’t care. The citizen has been connected with a government service without needing to understand an org chart.
Government is still, of course, centered around agencies. Every topic links to the agency – or agencies – that handles it. And each agency in turn links to the topics it handles.
The relationship between topics and agencies is brilliant – one has to know only the topic or agency they are seeking, not both.
Adhere to patterns that work, across your site
GOV.UK applies smart design patterns across all of its content.
Here is a look at how GOV.UK handles a few scenarios:
Regulations can be intimidating, so why not make them look like a friendly wizard?
Forget PDF’s – allow people to navigate long-form documents in their browser, with quick access to the table of contents.
GDS found that people often wanted to know one piece of information, such as the standard VAT (value added tax) rate. Why not make it stand out, and only give people the information they need?
Apply (expensive) best practices broadly
GOV.UK is fully responsive. It looks good on just about any device.
Rather than combining agencies’ content into a single portal and making it all responsive, the UK government could have kept agency sites separate and asked each one to implement responsive design. This might have worked, but results would be uneven and very expensive. The designers who applied responsive design to GOV.UK did an excellent job, and their work benefitted all agencies involved.
The same can be said for RSS, which is widely available on the site, and likely API’s in the future.
Radical ideas need a prototype
This [an agile prototype] isn’t a new approach, but it’s one that still all too rare across government.
The GOV.UK project started with a £200k pilot, led by a small in-house team for twelve weeks.
That’s right. Twelve weeks to develop a prototype web site for the UK government. Agile and Scrum came in handy, and the project lead used a combination of methodology and pragmatism, as he put it, to get the work done.
GDS recognized the gravity of what it accomplished, but also pointed out the top 10 problems. They included the inability to browse for content, inaccurate search, lack of accessibility, and incompatibility with some browsers.
Thankfully for GDS, continued funding has allowed it to fix those problems and move out of alpha. But it recognizes that the project was rooted in a pilot that embraced agile methods and avoided red tape.
Educate content providers and the public
I couldn’t have written this article if it were not for the outreach efforts of GDS. The team discussed nearly every step of the project via its blog and Tumblr, and made its style guide and design principals public. The GOV.UK story is inspiring, and the government is smart to share it.
The style guide, by the way, takes its own advice. It is refreshingly easy to read.
What it all means
GDS’s top design principal is user-centricity. Design for the user, not for the government. They applied this principal through extensive usability testing, a user-focused development team, and a site architecture centered around user needs.
This sounds simple, but many web sites are designed for the organizations that create them. Whatever it takes, put yourself in the users’ shoes. Prioritize user research, and make your team come together and think about a site from the users’ perspective.