A few design rules for Alpha.gov.uk
Back in February when we were kicking off the alpha project, we spent the first couple of weeks scouring search logs and analytics for the various central government websites; thinking about who our users were and generally discussing the kind of thing we were setting out to make.
‘User centred’ was always going to be one of the fundamentals of the project, but it’s a mutable concept so we wanted to set out more clearly what we were all about – to set out some rules to guide our thinking and to keep us honest.
Here are some of the rules we set ourselves:
Based on what we learned from looking at search-logs, we knew that there was a relatively small subset of tasks that require the majority of people need to interact with government online. So we should do less and focus on tasks.
Since people generally only interact with government when they have to government websites are a very different proposition from consumer facing destination-sites. We should minimise the time people have to spend on a gov.uk site. Minimal faff.
People frequently have a particular issue they want to resolve (find out about Cold Winter Payments, register for VAT, report a beached whale) so we should help them find the quick do and put tools before content so people don’t have to wade through pages of text to find the right link to register for this or that service.
As a result category pages, such as ‘everything todo with benefits’, become much less useful – hierarchy and send a confused message to search engines (see more of that below) so we should never assume hierarchies and only use them where there are two overlapping user needs such as ‘redundancy for employers’ vs ‘redundancy for employees’.
It was obvious that the best solution for a given user task would vary from task to task -
sometimes the answer might be a single table (e.g. what is the minimum wage), other times it might be a custom app that finds your nearest registrars office. So the site should be consistent, not uniform and we should aim to fix a single need at a time with the best available solution.
Having a user-base of all the entire adult population of a country it is easy to fall into the trap of piling loads of caveats upfront, making sure that every last edge-case is dealt with upfront before allowing anyone to progress. e.g. there are more people wanting to take a standard driving test than an HGV one, more people get made redundant than have to make someone redundant, so we should optimise for the common case.
The start of any process, be it linking to a local council to pay your council tax, booking a driving test, or reading a guide to exporting goods should set clear expectations upfront.
Since for the vast majority of people their web journeys (finding out the date of the next bank-holiday, or reporting a lost passport) start with a search engine rather than a direct visit we should think of Google as the homepage and we should also feed Google, Bing and other search engines nice friendly urls.
If someone is just landing at a page on your site then it’s helpful to start thinking of every visit being a new user, assuming they have no prior knowledge of the structure or content website they have landed at.
Similarly, there should be no need for a user to understand government to interact with it. Government (especially given the maturity of the British constitution) and the services it provides are often complicated, so we should hide complexity where possible.
For example tools and content should be Location aware – once a user’s location is known it can be used to surface the most relevant content and to tailor services.
Similarly with branding – design should be neutral be the government online, not a new brand or collection of silos that require extra understanding from the user.
Given it has 3.5% UK market share and Microsoft are trying to persuade everyone to shift off it, we assumed IE6 is dead (actually, we were a tad ruder than that). Finally, we should be device agnostic, not lowest common denominator.
We certainly haven’t stuck to these rules dogmatically, but they have been a good guide through the build process and hopefully have helped us build a (more tightly defined) user centred product.