The Government Digital Service started out as a small group of people with experience building and running large online services. Since then we’ve grown the team, added lots of smart people, and talked to even more experts from other organisations. The Government Service Design Manual is an attempt to bottle that collective wisdom, with the aim of improving public services and making sure they meet the Digital by Default Service Standard.
So how did we write and review more than 286 (at the time of writing) items of guidance?
Most of the content was authored by people who do what they wrote about. So members of our user research team wrote about card sorting and ethnographic research, designers and developers wrote about accessibility, testing and APIs and product and delivery managers wrote about agile. There is content from analytics specialists, content editors, web operations experts, procurement professionals and more.
For me, this meant writing on lots of topics I’m passionate about, from hosting and configuration management to monitoring and releasing software. I’m particularly proud of the guide on what is devops as it’s an emerging area I’ve been actively involved in.
What makes a strong piece of guidance is passion. Anyone in GDS was able to get involved in creating content for the manual if they wanted, all it took was to start writing. Hopefully this same passion for the individual topics will keep the content up-to-date.
With that interest and expertise for a given topic also comes access to a wider community of other experts, and we’ve used this to get as many eyes on specialist topics as possible.
Even with all that writing going on we wouldn’t have a coherent manual without the efforts of a central team. The Digital by Default Standard team took on the job of curating the deluge of incoming content, making sure links between documents existed and that we weren’t contradicting each other or government policy. The content also needed to fit into an understandable hierarchy and the Digital by Default team managed this, evolving it based on feedback and more active user testing.
Having so many different (and different types of) people writing content should have led to a huge number of typos and crimes against grammar. While the Digital by Default Standard team did some of the work here, the open and collaborative approach really helped too. Many eyes really did make light work, with a collaborative spirit around finding and fixing problems as content was written. We even got some grammar and spelling corrections submitted by people from outside GDS, so a big thank you to anyone who helped out in that way.
Over to you
The service design manual content is available on GitHub and includes advice on contributing. This can’t be a static document. Language can always be made clearer, new topics added or old ones amended. We’re all still learning, and keeping the manual up-to-date is critical. If you have experience building services, especially inside government, and you want to share then please help by writing new content or commenting on suggested changes.
Comment by topchimp (@topchimp) posted on
Great approach - happy to try and contribute! I think one area that it is often difficult for users to understand is risk, so weaving a theme throughout would be a really positive step.
Comment by Link roundup | Kind of Digital posted on
[...] Writing guidance for the service design manual [...]
Comment by Matt Watson posted on
This is a fantastic resource! I will certainly be trying to digest as much as possible for my upcoming local government work.
Congratulations guys on a job well done!
Comment by Jess Scott-Lewis (@Jess_sle) posted on
Great approach to creating a living document, it's nice to see this level of collaboration and drawing on individual's expertise. Good stuff!