How product teams are using prototyping in the public sector

Two weeks ago I ran a session on prototyping at Product for the People in Manchester. I wanted to find out how teams were using prototyping as a practice, and how it fit into their product design and development models.

About 50 people turned up on the day and people from 10 teams joined my session. This gave me the chance to do some scrappy research and pick up signals, find threads we might want to pull in a more dedicated study. It took me about 3 minutes to plan and 45 minutes to run, which is dirt cheap. But it means that any other research we might decide to run can be more targeted and focus on exactly what we need to learn.

I asked the teams

what tools they were using
who got involved
what stages of design and development they used the tools
what was good about it, and
what was bad about it.

Headlines

All teams used a mix of tools, except one team who only used Figma. 80% of teams used Figma. 70% of teams used Miro or Mural. 40% of teams used the GOV.‌UK Prototype Kit. 50% of teams used paper prototypes, which I was delighted to hear! A couple of teams used Powerpoint. Some folks built scrappy technical prototypes or edited existing services in the browser’s developer tools.

Designers were always involved in prototyping, but only half the teams got developers involved. That wasn’t always dependent on whether the team used Prototype Kit or other technical methods, which suggests it’s down to another factor.

A few teams were very mature in their prototyping practices. When they needed to move fast, try out loads of ideas and surface issues quickly, they used low-fidelity prototypes in paper, Powerpoint, and Mural or Miro. These helped them test out different journeys and flows. They progressed to Figma and Prototype Kit when they needed more fidelity or to test out technical approaches.

Figma can be complicated but is worth learning and using, as prototypes can be iterated quickly and easily. Prototype Kit has a steeper learning curve but is more functional, feels more real.

Teams using paper prototyping did so as a way to get non-digital colleagues from Policy and Communications involved. Usually those people would suggest approaches that couldn’t be implemented, helping the team catch and explain those assumptions early.

Two teams went beyond the interaction and technical layers to prototype the operations layer of a service too, using Lean techniques like Wizard of Oz and Concierge.

Stakeholders like to see a ‘real’ thing, they struggle to make the leaps of imagination required to comprehend low-fidelity prototypes. However, they sometimes find clickable prototypes too real, not understanding that the finished thing may still change or will take a while to build properly.

My personal highlight

One team asked if there could be a print-out-and-cut-out version of GOV.‌UK Design System for paper prototyping. I love that idea!

So what?

Like I said, this was scrappy research and it’s not massively reliable data. But I’d safely bet on all this being sensible and worthwhile to do.

I had a hunch that Figma was being used by the majority of teams, so it’s good to have uncovered that thread. If all the departments building the Top 75 services use Figma, I’d say it’d be worth GDS investing in an officially supported Figma component library, kept up-to-date with GOV.‌UK Design System.

Only one team mentioned building scrappy technical prototypes, and only half the teams mentioned prototyping beyond the interaction layer. That’s a shame because joining the front-end up to the back-end in the alpha phase can result in a quicker beta phase, because there’s less back and forth between design and development. Aim for tangible, demoable prototypes as early as possible and integrate one slice of a step or service.

We need more stories of teams using different types of prototyping well. If your service looks the same as 80% of services just like it, ignore the interaction layer: jump to the technical or operational layer, you’ll learn more.

Paper prototyping is quick, fun and, most importantly, really helpful! An officially supported resource might help more teams engage with Policy and Comms colleagues through collaborative prototyping.

My hunch

While generative AI could help teams build more detailed prototypes more quickly, it won’t build capability. Better training, better pay, and better tools will bridge the gap between teams in the public and private sector.

As GOV.UK Forms offers more components and patterns to services, it’ll become a more helpful prototyping tool for teams with little funding and little digital training and experience. For example, it doesn’t expect users to know the difference between radio buttons and checkboxes, it simply asks if users should choose one option or many.

What do you think?

Does any of above ring true for your organisation? Or have you learned something you might take back to base? I’d love to hear from more people!