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
Filed under: Digital Strategy
