Some things are obvious, and some really aren’t

Chris Atherton
Nov 28, 2018 · 7 min read
A screenshot from the visas service when we were developing dual language support for applicants from China. I learned at least as much about how to run projects as I learned about interaction design.

I spent a few years helping design and build GOV.UK digital services, and supporting teams doing that work. That the whole GOV.UK project succeeded at all sometimes feels like a miracle — and that it still works, a very delicate balancing act. Here’s what I know.

1. You need a set of objective standards.

You need something that defines what “good enough” looks like. This is the Digital Service Standard, 18 things a delivery team should be able to demonstrate when developing a digital service. If I have to pick one thing from the list, it’s “make sure users succeed first time”, but they’re all great. What an incredible summary of the things you need to think about to build sustainable digital services.

Of course, any set of standards will evolve as your understanding of the problem matures — which it should, because if you are designing and building and testing, you are learning. And remember that the standard is the minimum required: you can, and should, shoot for more (thank you to Mark Dalgarno for this reminder 👌).

Without objective standards, it’s impossible to evaluate progress. Bluntly stated, if a supplier isn’t delivering to the required standard, you should be able to fire them and get someone else who will.

2. It really helps to take a principled approach.

Design is political — if you are serving an entire country’s population, that should be political with a small p — so you might as well pick a fixed point to steer towards, a manifesto that the people delivering services can unite behind. Here are the GOV.UK design principles, a set of 10 reminders of how to approach digital service design economically and inclusively. As an interaction designer, my favourite is “do the hard work to make things simple”, which is kind of a reframing of Tesler’s Law.

Without a philosophical centre, it’s easy to be mechanistic about delivery. If the Digital Service Standard is the brain of the GOV.UK machine, the design principles are the heart. They are about empathy and inclusion and unwavering spirit in delivery. But they are also about pragmatism (“do less”).

Whatever your manifesto, I can’t recommend using it as a stick to beat non-believers with, because I have seen this backfire (no one likes being moralised at).

3. You need a tight coupling between your standards and continued financing.

This is something many people seem to overlook when trying to recreate the success of GOV.UK. Having a standard is meaningless if you can’t enforce it —and the way to do this is by withholding money. Nobody should keep getting paid for delivering services that don’t meet the standard.

One of the shrewdest thing the Government Digital Service ever did was to define the different phases of service delivery, from discovery through retiring a service, and evaluate projects against the service standard at the end of each phase. A phase might only last a few weeks or, in more advanced projects, months. If you don’t meet the standard at evaluation time (and you should get help and support with this), you can be given a little time to fix it, but if it’s clearly gone off the rails, you need to stop wasting taxpayers’ money, right now.

Without such short, tight feedback loops, it would be easy for projects to run over budget without even delivering against user needs. Contrast the GOV.UK approach with the old way of doing things, where a project could burn millions of pounds over several years before any evaluation took place, and then with no guarantee of having delivered something fit for purpose.

4. Anything that isn’t serving 1, 2 and 3 above is exerting friction.

Your digital service delivery teams need a 💩-umbrella to deflect anything that could exert drag on the delivery effort. This means having a role, or maybe several roles, that cover the functions of internal sponsor, product or service owner, and delivery manager — depending on the size of the project and the work to be done.

A surprising amount of friction arises through lumbering, hierarchical organisations that trap employees in meetings and their own inboxes for 25% of the week (or more!), hobbling their effectiveness. You can get around this to some extent by hiring in an external delivery team that is free of such hindrances — see point 5, below. Or you can let employees off the leash. Either way, you need a traffic cop who sees when the team is getting 💩 on them anyway, and who is empowered to fix it. Other friction can arise from power struggles in hierarchical organisations, or from people trying to hijack the team’s momentum for their own ends (often with sincere intentions).

Without these umbrella functions, the team will take longer to deliver. This costs money.

5. It’s okay to hire in expertise; sometimes it’s actually essential.

A note on organisational knowledge: if the work to be done lies a long way outside your organisation’s core competence, hiring a delivery team may the smartest thing to do. This was the only way GOV.UK could build momentum so fast: historically, civil servants have always been generalists, and not really technologists. All the competence needed to deliver good digital services was out in the private sector, and it took a while before GOV.UK became attractive enough to entice technologists into (often less-well-paid) civil service roles. In the meantime, agile consultants came in, delivered good quality services, and helped many civil servants gain vital experience in digital service delivery.

Don’t expect to bootstrap agile delivery in a large organisation without at least some delivery team members who know what they’re doing. A good rule of thumb I heard was that the team composition should be minimum 60% experienced hands, maximum 40% learners — that way you can still deliver at pace while also ensuring knowledge transfer. Your mileage may vary, depending on project ambitions, scope, etc.

Exercise healthy scepticism when you read headlines about the cost of delivering digital services, and the word “consultants” starts getting thrown around. Yes, maybe it costs more per day to hire a consultant. But if you want to build quality digital services that will last, and you really don’t have the skills in house, it’s a much smaller risk to bring in experienced people. And with tight feedback loops, you can let them go quickly if they don’t deliver to the standard.

6. Risk is not what most people think it is.

“Nobody ever got fired for hiring IBM”, as the saying goes. But perhaps they should have, since the big, old consulting companies used to spend millions, only to produce reams of documentation and some truly half-assed digital services after years on the job. Taxpayers’ money.

Risk arises from not having tight feedback loops. Risk comes from not assessing and designing for actual user needs from the beginning, or when you aren’t continually validating design against real user behaviours. Risky development practices include not investing in systematic use of data, and waiting until everything is built before you start testing (don’t get me started on “user acceptance tests”).

Selling this alternative model of risk perception to leaders is essential. It’s also hard, because leaders often fall into the trap of believing that “less risk” means “a rigid plan with everything decided up front”. But if you have ever started building anything, you know that no battle plan survives contact with the enemy. There are always surprises. A flexible backlog and continual reprioritisation is your best protection against the inevitable new information. Set against the alternative of refusing to acknowledge reality, it’s not hard to see which makes more sense.

7. These aren’t just good rules for delivery, but a blueprint for job satisfaction.

Yes, this was some of the hardest work I’ve ever done. We dealt with demanding stakeholders, internal power struggles, and frustrating and apparently arbitrary decisions by senior figures who weren’t close to the delivery process. Sometimes it was pretty tough.

But we thrived anyway. It was inspiring to work on something meaningful, and exhilarating to be delivering fast. Sometimes really fast — like when usability testing in the morning led to design changes in production that afternoon. The way GOV.UK projects are commissioned meant that we worked together as a cross-functional team every day, on the client’s premises, right in the middle of things. Doing this developed our understanding of, and respect for, each other’s competencies, and the client’s reality. Collocation made us more approachable for the client, and our process more transparent. We weren’t just working for them, but with them.

Without the service standard, without the design principles, without collocation, and without our wonderful 💩-umbrellas, we would have struggled. Having objective standards to refer to is key when you are arguing for user-centred design and good development hygiene. Having a coherent philosophy was useful for team cohesion and for getting buy-in. Being collocated with the client allowed us to show progress easily and regularly, super-important when the client has a history of failed IT projects with suppliers who didn’t deliver, and corresponding trust issues. Having 💩-umbrellas spared us a lot of grief — and my favourite umbrella of all was also the person who reframed my understanding of risk.

For surprisingly many of us, the work we did is still a touchstone, something we look to when we need a reference point for what good looks like, or how to solve really gnarly problems — or when we just need to be reminded that motivated people working together can figure most things out. Many of us became friends, and keep in touch. I am so glad I got to be there.

If you are looking for practical resources on how to be better at this stuff, GOV.UK recently published a terrific guide to Designing Government Services, a summary of principles that could and should form the basis of all digital services, not just those belonging to government. Another great, general resource is Internet Era Ways of Working, by Tom Loosemore, formerly of the Government Digital Service. You get a sense of where he is coming from in the comment “Finally, break any of these rules sooner than do anything barbaric”.

How do we know this stuff works? Because we see negative consequences when it stops. Tom Loosemore recently addressed the Science and Technology committee and talked about what happens when the relationship between standards and project funding is weakened.

Here’s another great read, about how design decisions are really about business decisions, which are really about infrastructure decisions .


Vi løser digitale hverdagsproblemer! / We make stuff that works.

Thanks to Are Sandvik and Mark Dalgarno

Chris Atherton

Written by

Designer/nerd-middleware layer at Also co-host of



Vi løser digitale hverdagsproblemer! / We make stuff that works.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade