At the outset, it wasn't clear that we were making a manual.
Our brief was to draw up the thing that all new services will be judged against - the Digital by Default Service Standard, as set out in the government's digital strategy.
Discovery
We knew that it needed to offer the rich detail to help departmental service owners and their teams deliver great digital services, while providing a simple, shared definition of what a good government digital service looks like.
To get an idea of the shape of that, we used a Google Site as a scratch-pad.
That prototype told us that we were potentially looking at 4 things.
1) The standard itself (a simple list of things a service must do), 2) guides and toolkits, 3) some way of reporting the progress of a project against the standard, 4) some communication tools for service managers to discuss improvements to the standard and share their work.
Alpha
Reaching the edge of what we could do with a Google Site, we began to build an alpha using the Django framework. We also settled on the word 'manual' as a wrapper for those different concepts.
The alpha had a place for the standard (clearly delineated from the rest of the manual in the design) along with very detailed guidance on things like the GOV.UK colour pallet and API design, and a page for email groups and other communications channels for service managers and their teams.
It also introduced project pages where service managers could record their progress and share their learnings:
Guides and toolkits were stored on Github, then synced into the alpha to make it easier to contribute.
Rather than just try garner feedback on what was still a pretty empty website, we followed Dropbox's lead, and produced a video to demonstrate a minimum viable product.
We shared the video and the alpha with people across government to see what they liked, and what they didn't.
Beta
From the alpha we learned some important things:
- people understood the standard
- but they wanted much more guidance. They wanted it setting in context
- the community aspect was going to be hard and needed to evolve as service managers started work across government
- the project pages solved a problem (helping service managers to talk and share progress with each other and the public), but didn't feel quite right
So we decided to strip things right back.
We descoped the project pages, leaving service managers to blog publicly elsewhere (much as the Ministry of Justice has been doing with the prison visits project).
The community aspect was best approached by splitting it out from the manual and allowing it to evolve separately. Katie will be writing about this soon.
We then focused most of our effort on expanding the guidance and toolkits, and setting it in the context of our design principles and the discovery->alpha->beta->live lifecycle of a project.
Since we were now dealing almost exclusively with text, we moved from Django to a simple publishing system called Jekyll that converts Markdown to HTML and hosted it on Github so anyone across GDS could contribute.
Now the beta of the manual is live we are also getting contributions from people across government as well as members of the public.
There have been 29 such edits since we launched last week, and the manual will continue to evolve throughout its beta period.
If you've spotted something wrong and would like to suggest an improvement, you can find the contents of the manual on Github or send us feedback to dbdss@digital.cabinet-office.gov.uk
2 comments
Comment by Debbie Ward posted on
Hi Richard. I think I understand what you are talking about, including application of a digital manual. I digital manual is fine. But, I think a "Help Desk" of some sort would be useful as well for a variety of reasons. The manual can be used for look up for answers. But, if something is not clear, than the help desk can be utilized. I'm now just in the process of implementing a help desk on my site at Canadian Legal Services.
A help desk has many advantages:
(a) You learn where most people need the most help (you can over time revise the Digital Manual to include commonly asked questions).
(b) Over time you can build standard responses to commonly asked questions.
In my company it is difficult to control everything all of my employees tell my customers. Plus, I do not want them create emails over and over again to similar questions. So, the help desk (a) controls what is said/how it is said (b) ensures that the information given is accurate; and (c) saves employees a lot of time from writing answers.
Immigration Canada has "service manuals" that tell their immigration officers exactly how to handle every immigration application. The good news is that that these manuals are also available to the public. This means that (a) a person can download the immigration forms and instructions and complete everything; and (b) they can go to the government manual to see the rules the immigration officials must follow when granting an application. So, the manual you refer to is great for government employees but can also be used by the public. Results in accountability.
When government workers know that this accountability is built in...I think they'll work a lot harder to follow it.
Richard, I don't really understand 100% what you are doing. But, if I did understand correctly, I have some very strong opinions on (a) manuals; and (b) help desks that have excellent application to businesses and government. And, for this reason, you receive a long reply from me!! Hope it relates.
Cheers from Canada.
Comment by @PhilRumens posted on
I really like the idea of a manual for Central Government services
I posted on my blog whether it might also work for local governments too.
http://philrumens.blogspot.co.uk/2013/03/making-digital-services-for-dummies.html