In April the Government Digital Service’s flagship project, GOV.UK, collected the Design Museum’s Design of the Year Award. Civil Service Quarterly asked Ben Terrett, the Head of Design behind GOV.UK, what the award means, how the UK’s design heritage has helped influence the site, and the importance of ‘agile working’.
The Government Digital Service (GDS) is one of the newest parts of the Cabinet Office. Its team of designers, developers, policy experts and analysts is busy transforming services across government, working with colleagues at places like the Driving Vehicle Licensing Agency (DVLA) and the Ministry of Justice (MoJ) to make 25 services, including vehicle registration and prison visit bookings, digital by default.
GOV.UK is not a design project, it is a way of delivering better services to the public. But design skills help achieve that aim.
What makes good design?
Some designs matter. The original Mini, designed by Alec Issigonis, became an international symbol of 1960s Britain, winning the Monte Carlo rally four times in the middle of the decade and making a celebrated appearance in the film The Italian Job. Yet style alone does not account for the fact that it was in production for over 40 years.
Designed in the context of the fuel shortages following the Suez crisis in 1956, the Mini was a model of efficiency. It was the first production front-wheel drive car with a watercooled, inline four-cylinder engine mounted transversely. This layout allowed 80 percent of the floor plan to be used for passengers and luggage, saving space and weight compared with traditional layouts. The Mini’s configuration is now used by the majority of cars on public roads.
Most of us now have computers in our pockets, not simply a phone, thanks to the radical design changes unveiled by Apple in its iPhone. The iPhone’s influence is due to its popularisation of the touch screen interface and the (now-common) idea that a mobile phone should be able to do much more than simple communication tasks.
Designs like the Mini and the iPhone have had a demonstrable impact on society; they correspond well to what people want and need, and change their expectations of what is possible. The public sector can learn lessons from great design.
Public sector design
The public sector, too, has produced iconic design, such as Harry Beck’s famous London Underground map. Today’s tube maps, helping over one billion passengers a year get around London, are direct descendants of the first designs Beck started as a project in his spare time in the early 1930s. Joseph Bazalgette’s blueprint for the London sewers is another example. It was designed to improve sanitation and prevent devastating cholera epidemics like those during the 1840s and 1850s. It used a network of underground brick main sewers which were deliberately over-engineered, so that they remained able to cope with huge increases in London’s population over the next 100 years.
Central to understanding iconic public sector designs like these is that they were not primarily design projects: they were projects with a design element, but that element was focused on achieving larger goals. Think again about the Tube map. The design is treated as an aesthetic object (and today is available as a poster, t-shirt, or even fridge magnet). Beck’s primary purpose was not to make his map ‘look good’, and certainly not to open up merchandising options for London Underground. His goal was to help passengers get around London more easily without the visual cues they would have above ground.
It occurred to him that geographical accuracy, and in particular the semi-accurate relative distances between stations that previous mapshad featured, was not useful in a map of the Underground. It hindered rather than helped passengers, many of whom would not be familiar with the geography of London. They simply wanted to know how to get where they were going via the most convenient route. Beck’s design prioritised their needs above geographical accuracy.
Projects with design elements (not ‘design projects’)
The importance of these projects is that they use design as one tool among many. Form follows function and their lasting appeal as designs is that they work really well. These are instances that show a beauty or elegance in design can come from focusing on user needs, from letting form follow function.
To illustrate this further, think of the design of the road signage system by Margaret Calvert and Jock Kinneir. In the late 1950s, Britain had a localised road signage system where each town could make its own signs. This worked well during the early decades of the 20th century, when road traffic and car speeds were low. But when government decided to build motorways, it became clear that there could be problems, potentially accidents, if someone driving from London to Leeds was presented with different signs as they passed through different areas. An old signage system that had grown up piecemeal was now no longer fit for purpose in the face of a significant change in the type and volume of road traffic.
In response the Ministry of Transport (the forerunner of today’s Department for Transport) commissioned Calvert and Kinneir to create a system of motorway signs. What they produced was consistent across the country, deliberately simple, and rigorously tested. Calvert and Kinneir wanted to ensure the signs would meet the tests of real life; they would drive past prototypes at 60mph in the rain at night, to see whether they could read the signs in difficult conditions. Their success is demonstrated by the fact they set a standard for how road signs look that is emulated around the world.
Just as a single, simplified road signage system was needed in the late 1950s for the new motorway system, as society becomes more digital so it needs a single, simplified way of interacting online with government services.
Agile design
GDS employs an ‘agile’ methodology. Agile methodologies started life in software development firms, as a new way of building products that were very responsive to user feedback and behaviour. Agile teams work in short sprints, typically a week long, and see what they can achieve in that time. Then they do the same the next week, and the week after, etc.
Once the team gets to a ‘minimum viable product’ (a product that has just enough of the necessary features to enable it to work in a basic fashion) – whether it’s an app, a digital service, or anything else – it is made available for testing by users and feedback is collected by the product design team. This feedback and analysis of users’ behaviour informs the next stages of development across further ‘sprints’. The product is refined by analysis of all this user data and released again, then refined and released again, in an iterative process.
GOV.UK is a massive project, so this process is broken down into smaller, simpler tasks that can be worked on in short sprints. The larger strategic plan is kept under regular review: sometimes the sprints take you nearer your original goals; sometimes they take in a different direction, but for a good reason.
You can learn more about agile methodologies, and where they are applied across government services, on the GDS website.
Designers have not traditionally worked in this way. It has been more common for them to go off with a brief for a couple of months and then come back to a client with well-developed proposals. This traditional approach does not sit well with an agile methodology, where products are developed by working in short sprints. Therefore, the team at GDS set itself some rules for design work within the context of a modern, digitalfocused organisation.
Design principles like these can be applied to much of what Government does.
1. Start with needs (user needs not Government needs)
The design process should start with identifying and thinking about the needs of real users. The design should be based around those, not necessarily around the way government works at the moment (the two are not always the same).
To do this it is necessary to interrogate data, not just make assumptions. User feedback is important, but what users ask for is not always what they need: not many users would have thought to ask for the original iPhone, for example.
2. Design with data
Designers can learn from the real-world behaviour of those already using government services. In the case of digital products, prototyping and testing with real users on the live web can assist the build and development process ofdigital products.
Looking at the work highlighted in other articles in Civil Service Quarterly, the work of Her Majesty’s Revenue and Customs on service redesign is an example of focusing services around user needs. The work of the Behavioural Insights Team demonstrates a clear focus on designing with real data.
GOV.UK has seen the successful application of the GDS design principles to deliver better services to the public. These principles can be used more widely; but they – or something like them – already inform best practice across much of government.
Don’t forget to sign up for email alerts from CSQ
Other CSQ articles you may be interested in:
Alex Ellis talks about his experience improving policy making in the FCO
1 comment
Comment by Robin Newton posted on
I'm going to make what a minor quibble, but one that relates to a more important point.
What's described here isn't quite "agile software development" in the sense that this phrase has normally been used over the past decade-and-a-bit since the Agile Manifesto was published. Yes, feedback is a key concept in agile development: as the saying goes, optimism is an occupational hazard of software development and feedback is the treatment. However, the like of Jakob Nielsen have for a long time been advocating basing design decisions on observations of real user behaviour. Moreover, it's _customer_ feedback that agile methodologies emphasize: that's not quite the same thing, and the difference is important.
In some cases, of course, the customer and the end user are exactly the same person: Apple's target market is a great example of this. Even when this isn't the case, the customer's interests are often closely aligned with those of the user.
However, in some cases there isn't much alignment. Things can get unpleasant when the person making purchasing decisions has more reason to be swayed by how bold and forward-looking they will appear than by how good a product will prove to be in practice. Public sector IT projects have the reputation of being like this. (The private sector can be like this too, but it doesn't have to deal with the same degree of scrutiny.)
All of which makes the work GDS is doing, as described here, all the more impressive. Although the customers, the government, are accountable to the users, the British public, I can't imagine that there are many votes to be won in this area. When there are problems then people will complain, and when there aren't then people will just take it for granted.
It's odd to think that, within the industry, GDS is getting a reputation of being the place where the "cool kids" want to work. (I've even heard complaints from the start-up scene that GDS and the BBC between them are hoovering up the top talent in London.) Since no-one's going to get rich on stock options, perhaps this is evidence that public-spiritedness isn't as dead as one might think.