GDS Retrospective #3: professions and design

Richard Pope,

I've said a few times to people who've asked "what worked and what didn't at GDS?" that setting up a dedicated design team was one of our bigger strategic mistakes.

In reality, it's something I think to be simultaneously true and not true.

It's true because you only get good stuff from people with different skills working together, when every member of a team can contribute to the design of products and that it is important to use and understand the materials available.

I also think it's also true because how we build digital products was changing - platforms like Twilio and Heroku, and mature CSS and web frameworks making just easier to build things. We are increasingly assembling things from components, the lines between development and design have blurred, and development cycles continue to shorten.

In some circumstances, the best designer for a given task might be a developer. Sometimes, an understanding of what you could build, if only you had good data, or could apply a particular bit of technology to solving a problem are the most important thing.

That stuff's just harder the more distinct the identities of dev and design teams are.

Certainly, some of the civic-tech design thinking that had been in and around at the beginning of GDS seemed to evaporate as professions emerged, and some of the technically driven design ideas from the alpha and beta of GOV.UK, didn't come near happening for a long time.

However, it is simultaneously not true because making design and development separate, distinct things meant that some amazing designers and developers were attracted to GDS and have gone on to do amazing work.

Creating professions can help scale an organisation. They also mean people have a home, a professional network and a clear understanding of what their role is on a team. That might not have happened without there being a design and development teams in place.

But prematurely optimising for professions does come at a cost.

Professions are an abstraction against a background of constantly shifting practices and technologies, and ideas and people will always fall between the gaps between them. That's a balance other transformation projects need to think hard about.

Addendum:

This was hard to write and I didn't get it 100% right (despite, or maybe because, it has been rattle around in my head for some years).

In the absence of any doubt - and the way I worded some of this created some - I think having world-class designers in government is an important thing. Getting designers and developers into government was why we started RewiredState back in 2008.

Giving those designers a home and a sense of mission was also critical and a huge achievement.

However, I do think that the way teams emerged in GDS had an effect on the type of products we designed, the way we designed, and who practised design, where perceived ownership lied and what our strategic priorities were.

Collectively this also, to some extent, limited our approach to things like shared platforms, data and use of recently emerged technology. However, that does not take away from the achievements.

To put it another way: the shape of organisations inevitably has an effect on the products they make.

Changes: 3rd July 2017 changed: "how we build digital products is changing" to "how we build digital products was changing" to clarify period I am talking about. 3rd July 2017 changed: "That stuff's just harder when you have separate dev and design teams" to "That stuff's just harder the more distinct the identities of dev and design teams are" as it is not a dichotomy 4th July added addendum