One of the major differences between policy and product design cycles is that, in product design, testing and refinement processes receive explicit focus. Mainstream policymaking models jump directly into implementation, with no dedicated referral to testing or iterating. Policy formulation and implementation remain two clearly distinguished stages, and policymaking continues to follow a static and linear logic: It first identifies a public problem, formulates a series of policy options, makes decisions upon the former and implements the selected option(s) to finally evaluate them.
The policy-making cycle, adapted from Howlett, Ramesh & Perl (2009) & Dye (1992)
Public policy is understood by interventions such as programs, services, regulations or guidelines that enable or restrict “policy end users”. If policies hold the visions of the society we would like to live in tomorrow, we must urgently ask ourselves: what is the detailed design stage that makes those visions actionable? And for whom are they intended in the first place? Whose reality are we about to modify? And what are the benefits and costs?
Evaluation in policymaking occurs predominantly after implementation. We talk about policy impact, as opposed to outcomes. Product development processes, on the other hand, iterate through testing to actively learn as implementation is happening, which is user focussed and experience-led. This could be applied to serve the early policy formulation and problem identification stages, to both inform and refine the problem focus and the policy framework on the go.
A user testing session at play Source photo : Flickr - https://www.flickr.com/photos/gdsteam/21082442200/in/album-72157656067629263/
If we continue to see policy as no more than a void, distant regulatory framework detached from its implementation and actual use cases, we continue working on the realm of imagination; a shared understanding that the proposed view of society is somehow better than it currently is. In product development, imagination and creativity are valid sources for innovation. However, the testing of these shared views — mainly by means of prototyping — is crucial before deploying an innovation. Similarly, testing policy-based services in a detailed design stage would provide an essential step toward a more flexible and experimental policymaking process.
In the 1960s and 70s still, product development was of the compartmentalised, “over-the-wall” type: planning teams conceptualised the product, and this was passed onto design teams responsible for execution or implementation. Cross-functional teams conjointly responsible for entire development, planning, engineering, and implementation stages were essentially absent. Moving away from such “over the wall policymaking” as it is still done today could end up being a key component in the evolution of policymaking, as much as it was in product engineering.
Designing a regulatory framework holds different challenges than the ones in product and service design. But even if the outcomes necessarily differ for policy and product (or service) development, lessons can be learned from the respective process, as we come to see policymaking as a design science. Focusing on what is meaningful to those affected by the policy could have meaningful implications in terms of the resulting user experience.
Public institutions will need to shift to lead on such changes. Establishing dedicated design departments in policymaking institutions could foster a more human-centric, collaborative way from the outset, via a gamut of stakeholders simultaneously becoming part of the process. This would help to realise new ways of understanding for whom policies are actually geared to, away from the policymaker to the experience of the policy end user.