Designing policy in a new, familiar way

Anselm Cox

We have just published 3 new digital sourcing policies, which will come into effect on 1 July 2019, to complement the Digital Sourcing Framework for ICT Procurement.

What’s different about these policies is that they, and the framework, were developed using a brand-new way of designing regulatory policy in government.

This blog is about the process we created to design policies, not the policies themselves.

Like the service design and delivery process, but for policy

Since our inception, we have been using an iterative development cycle to build digital products and services – websites, platforms and tools.

They all follow an agile system of iterative development, which has distinct stages of delivery and benefit realisation.

So, why haven’t we been using it for policies?

We hypothesised that a lack of user experience research and understanding of user needs was the sticking point in the typical 8-step policy cycle from the Australian Policy Handbook. We also hypothesised that this was what needed to change the most.

To be clear, we are not saying there was a lack of research, but there’s a big difference between user experience research and other kinds of research, and likewise user needs compared to user wants.

To test this, we set out to go through Discovery, Alpha, Beta and Live processes to develop better policies.

What does that mean?

The service design and delivery process is about having well-defined stages of development to ensure we don’t jump ahead to building a solution before fully understanding the problem.

Discovery is about involving your whole team in user experience research. This makes sure everyone builds empathy with users and develops a thorough understanding of their problems.

You then move to Alpha where you explore as many potential solutions as possible, using the deep knowledge built in Discovery to start understanding which solutions are best.

In Beta, the most promising solution from Alpha is taken through to be developed from the idea into useable product, going back to the end of Alpha if that solution fails.

Finally, a product reaches Live after it’s well-developed and delivering real value to all its users.

Where we started: exemplars

To kick this process off, we stood up an ‘exemplar’ team for the Digital Sourcing Framework, then each for our Consider First, Panel and Fair Criteria policies.

Exemplars are multidisciplinary teams. Each member brings a different set of skills and is empowered to deliver one or more stages of the service design process in a time-boxed period.

Our exemplars had a time-box of 4 weeks. The teams included procurement or policy experts from up to 8 different Australian Government agencies partnered with service designers and user researchers.

The greatest benefit exemplars bring in agile service design is their ability to quickly the team to understand the users’ experience. Building empathy is critical to move the team beyond their assumptions to understand user needs.

For our teams, that meant sending each of them out with user researchers to visit both government buyers and digital sellers. Their goal was to understand where established ICT procurement processes were not getting the best results.

As an example, we entered the Fair Criteria exemplar with an assumption from contract data that ‘fairness’ was relevant to a business’ size.

However, our research demonstrated that large sellers without previous government contracts faced the same fairness barriers as small-to-medium businesses.

Without the exemplar, the Fair Criteria Policy would have looked very different.

Iterating on the design process itself

We found that it was a balancing act in the first exemplars as to how much research and discovery work we could do versus how much Alpha policy drafting we could fit into the time-box.

We took an agile approach to creating the policy design process and made iterative changes to the process following each exemplar.

For example, in the Digital Sourcing Framework exemplar we conducted only 20 or so user research sessions but achieved a good prototype of the framework afterwards.

However, in the Fair Criteria exemplar, we managed to conduct 70 pieces of user research in the same 4-week period but didn’t narrow it down to a single prototype policy. Instead, we had a lot of options to explore.

Where we landed for our exemplar model is to focus primarily on Discovery, with a small start on testing the prototype policies that could be taken through Alpha. This enabled our team to carry on with Alpha testing and into Beta drafting following the exemplars.

Our results from the policy design and delivery process

 The policy design and delivery process is a double-divergent-diamond model, where during the Discovery stage policy designers expand their field of view to learn the problem, then start narrowing their field of view during Alpha. In Beta drafting they expand their field of view again before narrowing down to a Live product.

The 3 new policies under the Digital Sourcing Framework are in the final stages of Beta.

The policies have just been published and will come into effect on 1 July 2019. In the meantime, we are drafting and testing the final pieces of guidance following our usability testing.

We are now turning our attention to the already Live ICT Contract Capped Term and Value Policy. We will turn our process to iterating on a Live policy to ensure it is still the best approach to meet the user needs of both government buyers and digital sellers.

The early results of this process look promising, and we will know more once the policies come into effect on 1 July.