Policy prototyping is something you can do, and might already be doing

Have you ever sat in a working group, or briefing, where conversations circled, and wondered if people were listening to each other or even talking about the same thing?

Have you ever paused the group, to work something out on a white board, or collaboration space like Mural, or used good old fashioned pen and paper, to help people make an idea together, using visuals instead of words?

Have you ever encouraged someone else to do this, when their point wasn’t coming across, and words seemed to be failing them?

Have you ever worked with an abstract thinker, who speaks descriptively, and seeks for analogies, but struggles to convey the specifics of what they’re talking about, as it relates to delivery or deliverables?

Do you ever find yourself drawing during moments like this? Or even while talking? Do you ever put visual things out there, as a question, like “Is this helpful? Is this what you mean? Is this how things are operating?”

If you find yourself in situations like this, you might have an opportunity to prototype. You might be prototyping.

If you happen to work in policy, or with policy teams, you might be doing policy prototyping already, simply by encouraging the development of something concrete that people can react to.

When working with designers, the word prototype is often thrown around like a pancake at a busy Saturday morning brunch spot. The word — and practice — are used so frequently to get to a workable, testable, sample, it seems amiss to remove ‘prototype’ from a field that is centered on it, and attach it to one like policy.

If you’ve ever attempted to help policy and design teams work together, you’ve likely encountered the meeting of two worlds that deeply impact each other, and often speak slightly different languages, with different conceptions of what it means to work an idea through to delivery.

This is not a problem to be solved. It is a reason for prototyping.

Lots of teams, around the world, are and have been bringing these professional threads together, to learn each other’s approaches to delivery, and the considerations made by different disciplines, on the way to launch.

“We need to get this in front of policy” is not an uncommon thing to hear on design teams.

“We need to get this in front of design”, however, might be happening less frequently, in policy shops.

Why?

Among many possible reasons, because it’s traditionally less common to find policy engaged with design until there’s a tangible deliverable, often something digital, in the wings. And because many designers have learned that if they are not aware of the policy environment they are operating in, the thing they’re working on could be held up at the door.

Lots of people have waken up to this. What we conceive of as traditional policy is changing.

What is needed?

To prototype for, or with, or around, or in policy, you need a team. It’s great if it includes design and policy, but what is more important is that it’s a small group, who are open to and interested in making things as a way to understand how interconnected systems and parts of a service could or do work… possibly, together.

Even and especially if this team does not have a mandate to change policy, they need to be willing to look closely at it, to inform delivery. Why? Because policy affects (almost?) everything, and the components of delivery require cohesive policymaking.

What the team needs to build is awareness. Of mandate, desired outcomes, and interconnection.

Prototyping can help create that awareness, so long as the working culture of the team, and its surroundings, are open to sharing ideas and feedback and being in uncertainty together. Prototyping is about curiosity. If you, and the people around you, don’t have that, it’s hard to do it well.

At its core, policy prototyping involves asking questions about affect, effects, and interactions among the ‘thing’ of delivery, the policy environment it operates within, and the outcome sought.

A prototype might get you to an MVP or a version one, and, as a starting point, it can be much simpler than that.

Meeting some kind of standard of prototyping is not the goal.

Learning is.

Prototyping is an activity that allows us to surface questions, like “Am I understanding this right?” “Is this how things currently operate?” It can also be about the creation of something that people can interact with, as a way to test an assumption, explore a possible solution, formulate an hypothesis, and visualize or experience how something works, in order to improve it.

Don’t let the word intimidate you or make you overthink what it is, and how to do it.

While you can certainly advance in skill and complexity, and run sessions, or prototype over a period of days, weeks, or months, you can also prototype in a moment. One that needs something tangible to be provided, as a way to help a group of people work toward understanding what each other mean, and need.

As with most things, keep it simple. If you’re looking to start, start.