This is part of a series of blog posts about reflections on my time at GDS. See background and caveats.

A solid approach to building digital services and to digital transformation emerged from the work of GDS - a synthesis of established processes of user-centered design, civil service processes and the collective wisdom (and, inevitably, biases) of lots of people*. It is broadly set out in the Government Service Design Manual and can be characterised as 1) assume you know nothing 2) setup a multi-disciplinary team of 5 - 15 people 3) then do some combination of Discovery, Alpha, Beta, Live over a period of 4 - 12 months.

This is a good thing.

The UK government now has an approach to building digital services that is better suited to the world of shortened development cycles that a combination of open-source, commoditised platforms and integration testing have brought us.

Reflecting on my time at GDS, I think there is something missing from that approach, as it is understood.

Not everything that followed that process succeeded, and not everything that succeeded followed that process.

From the original alphagov project to the reset of the Universal Credit project, there are examples of where just making something at speed and setting as much direction as possible worked as a strategy to create the space and permission to do more work, and to change the way people view a problem.

When it comes to digital transformation, I think we are missing a mature approach to knowing when to run fast and when to follow a more structured process.

We don’t have the words** and as a result, it gets used haphazardly as an approach and a risk of accusations of cutting corners

I don’t know exactly what form that narrative should take, but I think it could include some of the following:

• Generating ideas and prototypes early on is OK, so long as the ideas are loosely held. (Projects can fail through a lack of good ideas and speed, just as much as they can by a lack of top-cover.)
• That moving fast is a strategic tool, with a different set of outcomes.
• Designers should design in a way that embraces high-level concepts but allows for details to be filled in later (more on this coming in a future blog post).

• An acceptance that, sometimes, we are not starting from scratch and the only thing to do is get something done. (By the time Alphagov started, the flaws and opportunities of Directgov had been debated and prototyped again and again at GovCamp, at RewiredState hack days and in the community surrounding mySociety.) As the development cycle gets even shorter (see Google App Maker and the as a hint of what the future might bring), knowing when to run is only going to get more pressing.

• The initial work on the Service Manual was in part about removing a general sense of unease about duplication, and about what technical best-practice should look like, as the GDS got bigger. There had been a few sporadic blog-posts, but the process of writing the manual distilled lots of things for the first time.