The fastest way to improve policy is to build it

Introduction

Jamie Laing

The UK’s Modern Industrial Strategy opens with a clear assessment of the context in which government must now operate:

“The world is in a new era. It is more volatile, with new threats to our security and living standards. But it is also a world of enormous and exciting possibility.”

We must adapt the ways we build public services too.

I’ve been working on the delivery of the British Industrial Competitiveness Scheme (BICS), an important part of the 10-year plan set out in that strategy. It will reduce electricity costs for some of the country’s most important businesses, strengthening our industrial competitiveness, encouraging investment and supporting high-quality manufacturing jobs across Great Britain.

The scheme had been announced with a clear deadline for delivering support to businesses, but there was still significant work to do. The policy required 2 consultations and legislative change. Partner organisations needed time to prepare. We also needed to build the service through which businesses would apply.  

That deadline meant policy and delivery could not happen one after the other. We needed to work in parallel, quickly turning emerging policy into something we could test with businesses and using what we learned to strengthen both the service and the policy. 

We decided to quickly build something testable, so that our service could feed back into the policy. 

Building the smallest useful thing

From a rapid discovery phase, we knew from comparative schemes that the complex eligibility requirements for BICS would make them difficult to understand and time-consuming to prepare for.

With this in mind, we decided to build the smallest, useful thing we could: an eligibility checker, now live on GOV.UK, that helps businesses decide if the scheme is relevant to them before preparing a full application.

By turning emerging policy into a set of questions and rules that a business could work through, we are now able to test it, while working towards something that could provide immediate value when released.

Through the checker, we hope to:

• reduce the time businesses spend understanding their eligibility or applying unnecessarily
• encourage eligible businesses to prepare earlier for the scheme
• support faster decisions once the full application service launches
• minimise avoidable processing costs for the taxpayer

Delivering value daily

Michal Charemza

The first thing we decided was that we would not have separate mock-up, prototype and build stages. Instead, I used existing GOV.UK Design System and security components to make a limited, but working, checker. I then deployed it into a secure production-like environment from virtually day one.

From that initial deployment we iterated, with the working principle that we should deliver value daily whenever possible. Every day, I tried to make a change to the checker that:

• worked in a real way – no mockups, placeholders, or fake data
• could be shown to users and colleagues for feedback
• moved us closer to the service that we thought we needed

The every day aspect was crucial to not get bogged down in a quest for perfection. “What doesn’t need to be done?” or “What can we leave until later?” were questions I constantly asked myself and others.

For example, when deciding how to identify a user’s company, we assumed we would need a search by company name. Initially, because it was easier, we asked the user for their Companies House number. This kept it simple for users during testing, so we kept the interface pretty much as it was and decided to spend our time elsewhere.

Some of that time was spent improving the robustness of the lookup. We added features that made the experience faster and more reliable for users once they had entered their Companies House number. These included integration with our internal data service (the Company Data Layer), retries, and a short cache to reduce load and waiting times. These improvements were added gradually, once we had validated that using a Companies House number was the right solution for users.

Testing different versions with users

Building the eligibility checker for real from the beginning helped clarify the key requirements for users, policy colleagues, and ourselves.

Sometimes this clarity came from finding the best solution from a range, so we built 20 variants into the checker and switched between them to test our approach.

They allowed us to observe how users interacted with an interface that behaved exactly like a production service would, giving us evidence grounded in their use of a real service. It opened discussions with users not just around the interface itself, but around policy, such as whether it was even possible for them to answer certain questions, or what evidence we could ask of them. Interestingly, not all users could conceive that they could have an impact on government policy. ‘It is what it is’ was an attitude I witnessed on several occasions. But they can!

Iterating with policy

To build a working checker so early, we had to create and iterate on a shared language that users, policy and operational teams could all understand and agree on.

For example, research participants using the checker reported that they wanted it to resolve uncertainty so that they could decide whether it was worth continuing with an application.

That prompted useful conversations between policy and delivery colleagues about how we communicated eligibility, helping us to make the checker service clearer and more useful. What seemed like subtle differences in wording raised important questions that helped inform the policy as it developed.

Testing the checker early also highlighted the significance of defining the word ‘site’. BICS is applied at the level of a manufacturing site, but initially the policy definition of a ‘site’ was not clear. When users tried to use the checker to enter products they manufactured at a single site, they had difficulty using the vague definition. This forced us to confront the fact that users could not split up their products into sites without an easily applicable definition, and the policy evolved.

Delivery as part of policy

Jamie Laing

Instead of treating delivery as an interpretation of policy, delivery became one of the ways in which policy was developed.

Building and testing how rules worked for businesses reduced policy risk, before further details were placed into legislation and announced publicly.

It also reduced delivery risk. By building early, we brought forward work on reusable components and data integrations that we have now been able to reuse in the full application service. It will be launched in the autumn.

The close relationship between policy and delivery has been one of the strongest features of BICS. Working as a multidisciplinary team meant assumptions could be turned into something testable, challenged by users and improved with evidence.

We are still adapting to this way of working and learning to balance rapid feedback with the pressure of a fixed deadline. As we are working towards a hard deadline to deliver the larger application service, we are testing a more deliberate division of work. One part of the team has protected space to build the agreed scope, while another looks ahead through research, testing and design.

Build to learn

The biggest lesson from BICS is that building earlier actually creates more time to learn and helps to prioritise the areas where research and decisions are needed.

Every day you delay putting something testable in front of users reduces the time available to learn from it.

As government tackles increasingly urgent and complex policy challenges, digital teams can do more than implement policy. By turning assumptions into rules and testing them with real users, we can help make policy clearer and more practical and evidence-based from the start.

What assumptions in your policy could you put in front of your users sooner?