Sketching our way to

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

One of the big problems 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 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 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.


  1. Comment by Harry Harrold posted on

    I think an interesting consequence of the "tools before content" approach is a change in the dynamic of publication. Monolithic blocks of text can be handed over easily; thrown over a fence to the "web people", or dumped in a box on your cms. The production of a tool looks to me to impose a more collaborative approach between domain experts and developers. I think that might have some useful consequences for both sides, still more so when users are brought to the development process in as well. Add to that the fact that the production of a single tool within this kind of framework is a comparatively small project, and... Well, it's an iterative approach with many small opportunities to .succeed. Or fail-and-learn. Sounds great.

    I guess a weakness might be fragmentation of user experience. If your app. development doesn't pick from a common set of interfaces when it can, then your visitors might never get any familiarity, and their use of the site/toolset as a whole might not get any easier. I'm sure that's occurred to you, mind... Soup's got its problems for visitors as well as maintainers.

  2. Comment by Matt Patterson posted on

    One of our design principles was to be constistent, not uniform. Which means (crudely) that we tried to use common interface elements and patterns where possible, but when that wasn't appropriate we didn't.

    The fragmentation of User Experience question then becomes more of a question about whether differences in tools are needless, or genuinely needed.

    This is one of those things which becomes trickier as you add more tools, and while we explored it as much as we could (with driving test, passport, VAT, and Holiday Pay tools) we couldn't cover much ground in the time we had.

    The key to maintaining this approach, and managing the trickiness, is going to be in developing, and communicating, a really solid core of visual, editorial, and technical patterns and examples. Essentially, make it easier to do the right thing than any old thing, and ensure that time and effort is invested in keeping that easier as more tools come about.

  3. Comment by Jodi posted on

    This is way better than a brick & mortar estabhlisment.

  4. Comment by Francis Maude, Minister for the Cabinet Office, opens the new home of the Government Digital Service | Government Digital Service posted on

    [...] digital community to try something very different with Government and technology. We’ve done it very quickly, starting in early August, we’ve moved people, structures and buildings simultaneously, never an [...]

  5. Comment by Francis Maude, Minister for the Cabinet Office, opens the new home of the Government Digital Service - Mike Bracken. posted on

    [...] digital community to try something very different with Government and technology. We’ve done it very quickly, starting in early August, we’ve moved people, structures and buildings simultaneously, never an [...]