GDS Retrospective #2: tools for making & communities

16 April 2017

Tools that help teams make things faster and tools help teams talk to each other better are very powerful levers when it comes to digital transformation.

That networks eventually emerged across government in the form of Slack channels and deparmental git repositories is great, and I am genuinely excited everytime I see an update to the GOV.UK prototyping tools and design patterns that edge them towards becoming a more solid, generic tool-set*.

But, collectively, we did not realise that this stuff was important early enough at GDS.

The Government Service Manual project could have gone in that direction - a place to share and view the progress of projects across government.

And it nearly did (I think the prototype is still on Github somewhere). It could have become a place to link to the source code on GitHub, to list team members and resources of a project, and to share progress against the Digital by Default Service Standard throughout a project. A bit like Launchpad does for various FOSS projects. In doing so, it could have set the expectation that projects should be open and that they should share their work, as well as set the expectation of the sort of infrastructure that needed to exist to support teams like email groups, git repositories, blogs, IRC (this was pre-slack IIRC).

That project was probably never the right place to do that work, but we should have done it in some form, somewhere. We could have provided more tools for communities across government earlier, and we could have built more tools to make it easier to make things.

It’s hard to say why it didn’t happen. Partly, we just didn’t collectively realise it was a priority. Partly, these things are quite boring, quite geeky and hard to explain to people who’ve not had to rely on such tools before. Partly, they cross disciplines/professions, which makes the ownership problem harder and the opportunity harder to see. Partly, there was just lots going on!

Anyway, my main reflection on this is: start investing in your tooling early.

  • The accessibility thinking baked into the design patterns is so good it has the potential to have a big impact if non-government developers started regularly using it in place of Bootstrap or Foundation.