We’ve talked about our initial analysis, our design rules and our technology. This post is about how we tried to get from those starting points to that technology — to the built thing — which is what you can see at Alpha.gov.uk.
One of the big problems Alpha.gov.uk has is that there’s a bit of all things to all men about the concept. Government does a lot of different things that citizens need to know about or interact with. Traditionally, an over-arching one-size-fits-all solution like the Content Management Systems that power sites like Directgov results in one of two things: A site that’s hard to use for its users and its administrators, or a site of such vaulting ambition that, if it gets off the drawing board, overruns its time and budget and is scrapped before launch.
Equally, a soup of unconnected sites and services can very quickly become a disjointed and hard-to-maintain mess, with massive duplication of effort and code. Simple things like adding text to a footer across all sites can become a nightmare to coordinate, manage, and implement.
This is about how we tried to avoid falling into either of those traps.
Start with sketches
Our early work was to try and understand what user needs we were going to try and fulfil, and move from those to an understanding of what we needed to build to get there. Taking sketches as our starting point (like these), we then needed to understand how we might build something that could satisfy them. It was clear very early on that, in order to build the best possible answers to the variety of needs we’d identified, we would have to build a variety of different kinds of thing.
The typical way to present information on government sites has been through text. One of our key design rules – tools before content – grew from the recognition that for many things text is a really problematic choice. For example, the passports section on Directgov is good example of where having to use text makes a problem – ‘I’ve lost my passport, how do I get a new one’ – harder to understand. Much of the information is only relevant in particular circumstances (if your passport is lost, but not if it’s been stolen). We’ve attempted to simplify this task on Alpha.gov.uk by using an interactive process which asks you questions so that we only have to show you the relevant information.
Another obvious case is when someone is searching for a service that is provided by local councils, like how to report a stray dog where the obvious thing is to start by asking where you are and then provide you with the correct link.
Text is, of course, the absolute best way to answer some questions, particularly where you want to find out a lot about something. We made guides to various subjects, including redundancy, to demonstrate that.
Being firmly situated in that dangerous territory which could result in either a grinding monolith, or a dissolute soup of technical solutions if we weren’t careful, we decided, naturally enough, to try and sketch our way towards a sane solution.
A natural extension of our intent to build the most appropriate solution for a given problem, coupled with the constraints of time, budget and personnel, lead us to the conclusion that we should pick the most appropriate technology for a given problem (or, at least, the most appropriate technology we knew about and has some familiarity with). This was our most important technical design rule:
pick technologies whose grain runs with, not against, the problem you’re trying to solve.
For the apps which were mainly concerned with text content we built using the Django framework, because of its excellent built-in editing tools; for apps with a lot of interactive HTML we used Rails, and for anything lighter-weight we used the light-weight framework Sinatra. Each of these has definite strengths, and definite weaknesses. Picking tools to match the problem allowed us to play to strengths, and not just compensate for weaknesses.
In some ways, everything on the site is a sketch, whether that’s in terms of interaction design or the underlying technology. The technical architecture is an exploratory sketch in how you might support a large range of tools and apps. It’s one of the great strengths of an alpha that what we want from it is to find out if we’ve understood the problem(s) well enough to start making something that will solve them.
Designing with your hands (refactor for insight)
As we tackled each of the tools we’d identified we were able to take a very iterative and exploratory approach, one which regards interaction, visual, and software design as interdependent peers. In this sense everything is design, even though it may not be visual design.
Being focussed on using small-a-agile practices and principles to move as quickly as possible allowed us to move from sketches on paper to sketches in code very quickly. With sketches in code its possible to actually use something and figure out whether it works, and whether it makes sense. Several tools changed radically once we had running code and could try them out. Often these changes would occur throughout a tool – changing the code as well as the interaction or visual design, and sometimes one layer would feel right and the others would change to support it. This pragmatic approach allowed all of us to gain greater insight into the problems we were trying to solve, and that greater insight allowed us to refine further.
What we want to find out now is what happens when a lot of real people use Alpha.gov.uk. Some of that we can find out from analytics, some of it we can find out from comments and feedback, and we find out as much as possible of the rest by doing formal user testing.
A lot of the work we did in the alpha was trying to figure out how on earth we could build something that could cope with that, and then having a go.
We’re road-testing an approach and, should there be a beta, we’re not going to just sit down and add more stuff to the site. It’s an alpha, and its value lies primarily in what we can learn about our assumptions, approaches, and practice across all our disciplines, and in making sure a beta would be better.