This week the US Government announced that it is to create a U.S Digital Service in what many people are saying is a copy of the UK’s Government Digital Service (it’s not quite but that’s for another post).
As is the want of any governmental digital service you have to produce a bulleted list of things you’re going to do and the U.S. Digital Service is no different: The Digital Services Playbook sets out 13 ‘plays’ that define how they are going to do digital.
Over here the UK’s Government Digital Services has 10 Design Principles; so putting aside the difference between plays and principles for now*, what does each one say and are they really that different?
Just in case you haven’t see the Playbook or the Design Principles here they are below:
Government Digital Services - Design Principles
- Start with needs
- Do less
- Design with data
- Do the hard work to make it simple
- Iterate. Then iterate again.
- Build for inclusion
- Understand context
- Build digital services, not websites
- Be consistent, not uniform
- Make things open: it makes things better
US Digital Services Playbook
- Understand what people need
- Address the whole experience, from start to finish
- Make it simple and intuitive
- Build the service using agile and iterative practices
- Structure budgets and contracts to support delivery
- Assign one leader and hold that person accountable
- Bring in experienced teams
- Choose a modern technology stack
- Deploy in a flexible hosting environment
- Automate testing and deployments
- Manage security and privacy through reusable processes
- Use data to drive decisions
- Default to open
The Similarities
As you would expect when two government set up a central digital team and then outline how they are going to deliver services with short concise lists there are going to be similarities, and there are a number of areas where the two lists cover the same ground:
- Principles : 1. Start with Needs* (user needs not government needs)
Playbook : 1. Understand what people need
Principles: 4. Do the hard work to make it simple
Playbook: 3. Make it simple and intuitive
Principles: 3. Design with Data
Playbook: 12. Use data to drive decisions
Principles: 5. Iterate, The iterate again
Playbook: 4. Build the service using agile and iterative practices
Principles: 10. Make things open: it makes things better
- Playbook: 13. Default to Open
In summary Users Rock, things should be simple, and agile and open are they way to do things. A lot has been said about all of these principles. No self-respecting organisation is going to deliberately start a project without at least the first 4 of these in place - the battle to convince people to do it properly could fill a library - lets just say we all agree, it’s important to remember the people who will be using the services when developing them.
The Differences:
In the Playbook:
Being a longer list the Playbook was always bound to have a few things that are not mentioned in the Design principles;
- Playbook: 8. Choose a modern technology stack
- Playbook: 9. Deploy in a flexible hosting environment
Playbook: 10. Automate testing and deployments
The Playbook is a bit more technical than the Digital Principles. Personally I think they are in danger of mixing strategy and delivery, you could just as easily capture 2-3 of the plays’ under a single “Do technology properly” play - but it is a direct reflection on how the two organisations are set-up to do different things.Playbook: 11. Manage security and privacy through reusable processes
Along with the other technical plays - I think it’s important to note that the U.S are much more explicit about security and privacy here (Maybe they are just a bit more sensitive to this since Snowdon).
When you look at the Digital principles, a lot of these technical and security elements are implicit. It’s assumed the platform will be right, open and secure. With an organisational structure like GDS - where the majority of development and management is done in house - you don’t necessarily need these elements stating directly in your principles. In any case these elements are covered in the Government Digital Service Design Manual - but the US model is different, in their much more advisory role, they have a need to put more upfront on how things should be done.
2. Address the whole experience start to finish
This is one of my hobby horses, it’s very easy to fall into the trap of just worrying about the part of a service you’re responsible for and forget just how people interact in other ways, from the sign on the lamppost to the conversations with social workers, you need to consider where people start and end their journeys to get a more all complete service delivery. It’s good that this mentioned upfront. getting people to think beyond their “digital fence” is important in good service delivery.5. Structure budgets and contracts to support delivery
- 6. Assign one leader and hold that person accountable
- 7. Bring in experienced teams
These three plays highlight one of the differences between the US Digital Service model and the UK one. The US Digital service is explicitly a ‘small team’** working with other government agencies. It appears they will be taking on a much more advisory role and it certainly doesn’t look like they will have an army of developers to solve all the problems - although the US does have 18F a digital delivery team that they will no doubt call upon when needed.
The US is also looking outwards to external companies much more than the UK does. One criticism of the GDS service has been that it’s very inward facing, not looking to others (both in the private and public sectors, in the UK and further afield) for the answers but almost always building its’ own solutions.
Missing principles:
There are a few principles that are not matched by ‘plays’
- 2. Do Less
- 6. Build for Inclusion
- 7. Understand context
9. Be consistent, not uniform
These remaining digital principles are much more focused on the user and making things just work. You could bunch most of these below the first three plays of the Playbook, and you sort to have to assume they have, they all fall into user needs, simplicity and user experience in one way or another.8. Build digital services no websites
Maybe this is a digital principle that’s showing it’s age? When GDS first launched their principles, the mass of new digital devices was just starting to impact on people - explicitly pointing out that digital was more than just a website was something they obviously felt they needed to do. Looking back those 3 long years, you wonder if this is needed any-more? The US Service is going to “make websites better for consumers” but no one thinks that excludes them from fixing other digital stuff?
Summary
The US Playbook differs from the UK Principles mainly because of the set-up of the two agencies. Despite the easy headline, the US Digital Service is not a copy of GDS. GDS has a budget of £58million and over 550 staff and the US Service will be a ‘small team’.
There appears to be no intention in the US to build a development team within the Digital Service (but they do have 18F). The Playbook is much more aimed at helping other federal agencies manage and deliver their own projects, hence the inclusion of more technical ‘plays’ and the focus on procurement and building the right project team.
The US Model is a much more decentralized approach - driving best practice from the centre, but expecting the agencies to manage a lot of the development and delivery themselves, something that would work well if you have say around 400 organisations all delivering service to different people across a country.
* It’s a lot like the Philosopher’s/Sorcerer’s stone - We know we are right and the US will come around to our way of thinking eventually.
** It remains to be seen what the US define as Small, i would guess it would probably be bigger than GDS - but in context of the wider government machine it will still be very small.