Making it easier for businesses to find out about regulations
The aim is to build and deliver the service iteratively as the team works toward the end goal
We recently completed a project with the Better Regulation Executive (BRE) to design a service for UK businesses to make it easier for them to find out about, and interact with, regulations.
We gave it the snappy title, Digital Regulation Navigator, and it successfully passed its alpha service assessment.
Why we were doing this work
The project is one of 3 that BRE are working on as part of their digital transformation programme.
Our aim is to make regulations easier for end users to find their way around, with a particular focus on helping small businesses. Our findings showed, not surprisingly, that small businesses are at a disadvantage when it comes to dedicating time and resources to meeting regulations.
The discovery phase had identified some core concepts for the service which we then designed and tested with real businesses. We tested 2 main concepts: finding relevant regulations and keeping track of changes to provide the right, up-to-date advice to businesses.
Our focus for alpha
We formed a multidisciplinary delivery team with BRE and together ran a series of sessions, most of which were dedicated to collaboratively designing the core concepts.
Our interaction with the other teams and stakeholders who were also looking at regulations was an important part of the work. This included teams in the BRE, the Government Digital Service, and other subject matter experts.
Small businesses represent a very large group of potential users, so we looked at how they could be broken down by industry and again by business size (in relation to the number of employees rather than profit) and location.
We decided to begin by selecting a single industry as the focus for most of our research and design work. Once something had been designed around the needs of this industry, it would then be tested with a small number of businesses from other industries to understand if it met their needs too.
We focussed on food businesses with between 1 and 49 employees, and targeted people who were responsible for making sure their business meets regulatory requirements day to day.
Solving the problem in a simpler way
User research gave us some helpful insights about our alpha designs. By speaking to businesses and getting them to test what we’d designed, we learned something important that led to a change in direction at the end of our 4th sprint (we had 6 sprints in total).
Our main prototype required a business to answer a few questions for us to know what regulations would apply to them. On face value, the questions seemed quite simple. They were about their business activities, number of employees and location. However when we spoke to businesses we found that there are many ways to interpret these questions and subsequently many ways to answer them.
Even though we were looking at small businesses and mostly in a single industry (food), the characteristics of each business was unique and there was variation between all the businesses we interviewed.
Describing the activities a business does is not a simple task. We found that there wasn’t uniformity between answers but instead lots of diversity. Some businesses describe the same activities in different ways.
Through exploration we also found that activities are hard to categorise from a technical perspective.
Location was another area of complexity. For example, a food business may have a shop in one location, but their produce may be stocked elsewhere. In addition to location, premises need to be considered too. The regulations attached to a given premises can vary between businesses located next-door to each other.
All this complexity can be solved. But now we were aware of it we wanted to see if there was an alternative way of doing things which would have the same outcomes.
We hypothesised that by taking a minimal viable approach to the same problem we may be able to learn more about businesses, and we could return to the more complex approach we’d started (if needed) later down the line.
What did we do instead? The service proposition remained the same – to have all relevant regulations for businesses in one place and to be proactively updated when regulations that apply to your business change. To remove the complexity we took out the questions which proved difficult to answer and replaced them with a filter for businesses to use to look for the regulations applicable to them.
Businesses could find the same regulatory information, but they would search for it themselves. We created this alternative version of the service in sprint 5, and began to test the 2 versions of the service design towards the end of the alpha.
Recommendations for the next phase
Given both the complexity and scale involved, we’ve recommended that the service is built and rolled out industry by industry, and also regionally as there’s a local dimension to regulation that needs to be taken into account as well.
The team will think about who the service will be most beneficial for when prioritising where to start.
The aim is to build and deliver the service iteratively as the team works toward the end goal. This will mean managing the expectations of businesses, so they’re clear about what they’re getting, when, and why.
Taking this approach will add value for businesses along the way, and ultimately mean a better end product that meets their needs and saves them valuable time and money.