Designing government services – in public

The British government is taking service design very seriously indeed. Two members of the Government Digital Service spoke at Cool Content Coming Soon last week - and they gave an insight into the difference it makes.

Can you redesign government web services – and do it in public, with software that’s open to access on GitHub?

The UK Government’s Digital Service – part of the Cabinet Office – thinks so, and has been successfully redesigning the digital service provision in public, iterating through alpha and beta rapidly over the last year. I had the chance to hear two people from the GDS speak at the Cool Content Coming Soon conference in Brighton last week – here’s my liveblogged notes:

Paul Annett and Tim Paul

There are around 200 people in the Government Digital Service, from the public and private sectors, from startups and big businesses. It was set up to transform the way UK citizens can interact with government: everything from finding out the date of the next bank holiday to complex financial transaction. They need to improve existing services, and digitise ones that aren’t online.

Most people think of ecommerce when they think of transactions online. Government transactions are quite different – they are often low frequency, with no money involved, and sometime there is obligation involved: things people have to do, rather than want to do. It’s a challenge, but if they get it right, it makes everyone’s life easier.

Before the GDS went to work there were two main big sites – BusinessLink and Direct.gov – and hundreds of small sites. You had to know how government works to know where to look. One in four calls to helplines were down to digital helplines. One service in particular was generating seven calls per transaction. They could save a lot of money by dealing with that. They were stuck with contracts for websites where changing a single line of code cost £50,000. Since then, they’ve closed 1,500 sites, and are building gov.uk, a single replacement. alpha.gov.uk was built quickly and provocatively to test what they could do – and show it off. They avoided transactions and built it in 12 weeks – and built it in public, not behind closed doors. They blogged, they invited feedback in social media. Based on that feedback, they moved into Beta, starting from scratch.

They have been rapidly iterating since January, and are planning on launching a new version this week. They still don’t have transactions – that pushes you to direct.gov. But they will bring them in when the time is right.

The design principles are public: Start with needs. If the website doesn’t meet them, they’ll go to more expensive channels, or they’ll go to commercial alternatives. People search thousands of times a day on direct.gov – a great database of needs they could – and do – use. For example – it’s hard to find VAT rates on direct.gov. You go straight there from a search on the new site.

Equally, they should concentrate on the things that only governments do – not pre vide general interest information. If you do less stuff, you can do important stuff better. Last year the US Government closed 50% of their websites – including Fiddling Foresters… If you have the data, you can design around what people actually want to do, not what they tell you they want, or what you assume they want. Call centres are a rich source of data, too.

It often takes time to makes things simpler – but its often worth it. Lurking behind some systems is legacy hardware and software, entrenched working styles and legislation. Simplifying some processes will require legislation. For example, on Direct.gov you have to wade through pages of information on maternity pay to figure out your situation. They guide you through it on the new site. But on the power of attorney site, people felt that they were being rushed through it too quickly. And some people get suspicious if things are too simple.

Iteration is vital. Websites are services that you can refine as you go along. You can’t leave people behind, though. You need to meet accessibility needs – and ensure that people who are homeless can still use it without a home address. Some people who have never used a computer before don’t know about scrolling – so the fold is back, if you’re designing for everyone.

Context matters. People use the site from home, from the street, from hospital beds… And there’s emotional contexts – death and taxes. People may be upset or confused. Sometimes they need to slow things down and force people to consider consequences.

They’re building services – not websites. Could they allow webcams to grab signatures? Could there be a mobile phone app to take, and check the eligibility, of passport photos? Their approach is about consistency, not uniformity. And making things open makes things better. Have the courage to share things with people. THe more eyes there are on a service, the more feedback you get, and the better the product is. Within weeks of the beta, they had code live on the site supplied by users. Plus, we own the website. We paid for it with our taxes.

What’s the future? They’ll iterate until the old sites can be turned off.

And always keep their focus on the needs of the users.