Government
as a Platform

Building for a more dynamic public service landscape

I was part of a small exploration team tasked with doing some big picture thinking around how GDS could help support a more dynamic service landscape in the public sector. We examined how we'd approach building new products and platforms that would enable a future where the public sector had a much more agile digital service infrastructure that was being iterated constantly. A public service infrastructure that was built on structured data foundations and wasn't tied to old legacy IT.

We spent a few months experimenting in this area, developing proofs of concept and identifying next steps.

Sketching the vision for common platforms and where they fit within a more dynamic future service landscape

A common platform approach

After an extensive period of research with service teams across government it became clear repetition was often occurring in service delivery. Government was waisting time and money working in silos and building the same things time and time again.

We examined the most prominent commonalities across government services and realised we could create a set of common platforms that would make user-centred public services easier to create and cheaper to run.

Commonalities across user journeys when interacting with government and the common platforms that could be built to make service creation better, quicker and cheaper

Creating a series of start-up teams

We prioritised the areas where this approach would benefit citizens and government most and began setting up agile product teams to test the viability of delivering these common platforms. Some of the platforms we looked to create included a notifications platform, a payments platform, a hosting platform, a web chat platform, a structured data platform and a form-builder platform.

I led design across the platforms, working at a micro and macro level with the multidisciplinary delivery teams. I helped guide the strategic vision while also getting stuck into the nuts and bolts of delivering the platforms based on user needs.

The GOV.UK Notify multidisciplinary team. Observability of the platforms we developed was key to our ability to build trust and onboard services.

Identifying our core user groups

We had different user groups we were designing for when developing these platforms. Citizens were a core user group, along with the public servants building and running government services. The admin tools we developed for these platforms were designed based on extensive user research with the people who'd be using them daily.

Civil servants are users too - poster by my ex-colleague Sonia Turcotte

Screens from the GOV.UK Pay admin tool

Where possible we tried to make the admin tools consistent. But there were times when the products needed to approach problems differently - for example regarding user admin permission levels

Another user group were the engineering teams across the public sector who’d be incorporating these platforms into their service tech stack. We created extensive and accessible technical documentation formats to make that easy to do.

An example of the accessible technical documentation publishing tool we developed

The extensive GOV.UK design system documentation

Creating a framework for delivery

Running multiple platforms under one programme of work means there needs to be appropriate structures in place to enable effective feedback loops across teams and senior management. I led on developing a set of principles that became the delivery framework for the platforms we were developing.

The creation of this delivery framework was an inclusive and open process that involved multiple colleagues from different disciplines across the organisation.

Posters outlining the delivery framework

Focusing on adoption

We realised early on that ease of adoption was key to service teams using our platforms. We invested a lot of time researching potential blockers to adoption across the platforms and prioritised features based on user needs.

Some of the platforms we developed

Product features that helped adoption included this PaaS cost calculator – it enabled service teams to get the information they needed before they made the decision to use GOV.UK PaaS as their hosting solution

We did a lot of work improving our support funnels to better meet the needs of service teams

These common platforms are now used by thousands of services around government. They save tax-payer money and offer a better experience for users. They also save the teams building government services a lot of time, allowing them to focus on the problems bespoke to their service.

Identifying and promoting the benefits

Marketing posters for various GaaP platforms

I presented at many cross-government events and stakeholder meetings – raising awareness and getting buy-in for the common platforms we were building