Interview with Will Myddelton – UK Government as a Platform programme

Tell me a bit about you

I’m a user centered designer. I came to the Government Digital Service as a user researcher. Prior to that I was working in design agencies doing both usability testing and more exploratory research stuff. Things like looking at what clusters of problems people have and using those to think about potential areas for innovation – speculating about what companies should build.

I had previously worked in government as a web manager but left in 2011 as part of the bonfire of the quangos. I saw the likes of Steph Gray, Neil Williams and Mark O’Neill talking about GDS. Later, I saw Leisa Reichelt as a hero and wanted to follow her to GDS.

When did you join the GDS Government as a Platform programme?

I initially joined the GOV.UK Verify team for a month in November 2015. Then I joined the GOV.UK Notify team as a user researcher, but I was also asked to look at research across all of the Government as a Platform (GaaP) programme. Over the next year I spent time on each of the platforms and then hired people into the research roles in each team.

There were lots of existential questions early on:

• What’s the model?
• Who are the users?
• Of the things we are doing, what are ‘reckons’ and what is solid?

Over time, we started to build up ideas about what GaaP was and what we should be making ‘bets’ on. This was partly driven by the need to talk about GaaP to new hires in a coherent way. It’s hard to explain what someone’s job is when everything is so abstract.

My starting point was: what is the right way to think about user-centred design to do my job at GDS? We were mostly not doing citizen-facing services at this point. We needed to start thinking about our users as being service teams around government. Citizens are not the only valid users – even GOV.UK itself has a huge number of civil servant users who are using it as a publishing tool.

Shifting from thinking about making services for citizens to making products for service teams was a tough shift. I presented at a scary all staff meeting when I told GDS that service teams were our users and we should stop talking about them in such an offhand way. I made the point that we wouldn’t accept that attitude if we were talking about citizens. To be fair, GDS listened and we changed the way we thought after that.

How did the thinking about Government as a Platform develop?

We found it helpful to draw a distinction between GaaP-the-programme (where the funding was) and GaaP-the-concept (where the big ideas were). It took a while to work this out. GaaP-the-programme was making a bunch of products. It relied on a bunch of infrastructure (e.g. hosting) that underpinned all our products. And broadly we were trying to do 3 things with those products over time:

1. Add more service teams as users

2. Add new products to our portfolio

3. Add infrastructure to support the products

GaaP-the-concept is not just about these products though – there were wider organisational things that needed to come together including standards, guidance, documentation, spend controls, design patterns, etc.

Eventually, we simplified GaaP-the-programme by removing things that didn’t fit the model of making software-as-a-service products for service teams. For example, civil service learning and service patterns. We focused on GOV.UK PaaS, GOV.UK Notify and GOV.UK Pay. And we spent time talking to GOV.UK Verify and GOV.UK about the principles we were learning about self-service.

What worked when it came to ‘marketing’ platforms?

If you approach GaaP as a user centred design problem, without the ability to mandate its use, then the products need to be better than the other things teams could use. They need to freely choose our products over the market. To be honest, I think this is a better long-term strategy for digital government anyway. Mandating only lasts so long.

Long term, it’s better that people want to use it. Services so good that people want to use them.

The key measure for this for our platform products was: do people self-serve?

We can’t hand-hold people because that means our team would need to scale linearly with adoption and that contradicts the point of platforms. GOV.UK Notify proved early on that we could do self-service. We did this by making it straightforward and useful for everyone from technical architects using APIs to caseworkers using spreadsheets.

GDS has a cultural distrust of marketing and comms websites. This comes from our history of seeing terrible marketing and comms on hundreds of websites when we were moving everything to GOV.UK. So it was hard work to get people to understand that having landing pages for GaaP products with marketing graphics on was important.

Who should run these products in the long-run?

There was an idea that any part of government could run a GaaP product for the rest of government. But the capability and the investment to run these things is high. And there is a huge, huge trust issue at the centre of running a platform for the whole of government – how does the service adopting this know it will be here in a year’s time?

My view, having worked in a department now, is that if push came to shove why would a department invest in it? I’m possibly biased because I’ve worked at the centre, but I think – quite strongly – that platforms need a central organisation to maintain them. They are not a bolt on to the other work of government. Of course the ideas can (and should) start elsewhere, but running these platforms government-wide is a serious undertaking.

Another interesting thing is that the behaviours people display when they are adopting platforms is that of buying. At least in the short term, people are in the mental model of buying a service. They are thinking how am I going to budget etc. And the people that make a buying decision (finance people, SROs) are NOT the same as the people that want to use the product (technical architects, product managers).

So we found that because our products didn’t fit the mental model – external supplier, purchase order, invoices – this was a barrier because we didn’t fit with any of their budget and finance processes. Platforms need equivalents / analogues – e.g. monthly statements, memorandums of understanding. There is inertia if people can’t buy it in the same way they do today. I often wondered if we should just set up as an external supplier to make this easy.

What makes for a good self service product?

• You can use it within 30 seconds
• From private beta, you need to be seeing people signing up online so you know you’ve got the pitch right. Early on it’s your product manager making the pitch, but pretty quickly you need to make the website do the pitch for you. If your product owner is still explaining the product in person to people after a few months of private beta you haven’t done the work to make it clear online.
• You can find it, understand what it does, use it first time.
• You can use it in practical work e.g. use it in a prototype within an hour. With Notify, we did testing with developers to see how they could make a service for a fake ‘cats service’. This showed us how bad the initial documentation was. Developer documentation is an interesting and unsolved user-centred design problem.
• Remove procurement entirely from the process where possible. Contracts and procurement put people off.

How do you identify which platform products to build?

There are many ways. You can use user research to identify needs. You can use Wardley mapping to find things that are common across many services. Or you can do tech horizon scanning to spot emergent needs. All of these are valid.

To identify the needs of our users, we did 150 interviews with service teams across government. We identified those teams from service assessments, the GOV.UK performance platform and also the 4,000+ PDF forms that are hosted on GOV.UK.

We identified the needs that service teams have and were able to put numbers next to them so we knew which were most important.

If you could say one thing to people thinking about building platforms, what would it be?

That the users of platforms are the teams building services, and there is a respect that comes with that. They are the focus of your user-centred design, not citizens. (The citizens are the focus for the service teams. Platforms are an abstraction).

There’s also something important about what the live operational model looks like and where the funding comes from – to solve the trust problem. How can we set up the funding and the governance so that it’s clear these platforms will be around for years? And that during that time they will be getting proper updates so they don’t slip into being legacy nightmares…

Will is currently a user researcher at the Home Office. You can follow him on Twitter, or read his blog.