Like completing a crossword, sudoku or a puzzle, product management enables you to solve problems daily; and there’s an enormous sense of satisfaction in doing so.

Plus, there’s a creative side to it. Designing wireframes, user interfaces and understanding user needs and journeys. At this point you might be asking why this is relevant to a blog about a Digital Blue Badge service.

In this instance, owing to the complexity of many councils’ differing requirements in this area, we’re going to step into the shoes of a product manager to understand the challenges faced and how to solve them when creating a genuinely innovative Blue Badge platform.

Some background to the Blue Badge service

Prior to 2019, all applications for Blue Badge were made through the Blue Badge Improvement Service (BBIS) provided by Northgate. This service was criticised  owing to the poor user journey, the lack of content needed to make decisions and it being based on legacy technology built years ago.

Indeed, in the alpha stage of assessing the BBIS service, the Government Digital service found:

The previous scheme was consistently the Department of Transport’s service that received the most complaints and clearly did not meet the needs of users

For some perspective, back in 2013 IEG4 actually provided an alternative Blue Badge form to the London Borough of Ealing because the BBIS service was hindering, not helping.

The DfT recognised the need for improvement and, as a result of a successful tender, the previous supplier was replaced with a new one: Valtech. Adopting genuine design principles, carrying out user research, doing live show and tells and, importantly for external software suppliers, the provision of best practice based RESTful APIs to drive efficiencies in back office processes.

The new service is night and day when compared to its predecessor.

But what did this mean for Local Government?

The actual back office administration of Blue Badges, prior to 2019, largely involved spreadsheets, Microsoft Word/PDF-based assessment documents designed to fill in the missing blanks of the BBIS service and inherently led to lots of manual processes.

IEG4 had experience of the online form side of blue badge but needed to understand the intricacies of the back-office operation. In doing so we established that there were the following core stakeholders in the processes around Blue Badge Administration:

Then when understanding the different user needs, we asked different Blue Badge managers:

How do you process Blue Badges currently?

Similar to most departments’ processes complex discretion-based applications there were massive differences of approach, which was both surprising and unsurprising at the same time. 

In fact, the most challenging aspect of designing software for local government is in assuring flexibility across different ways of working and nuance of process; keeping most people happy most of the time.

Consider that every dot in the image below is an element of a process. And the different colours represent different ways of doing similar things across councils.

The role of a product manager is to take this complexity and bring order:

By being very selective on which ideas should ‘win’ and instilling a framework of flexibility, it’s possible to create a product with a vast array of nuance in process. To help explain this, let’s walk through the key challenges we faced in the design of our Digital Blue Badge Platform:

1. Workflow

2. Invisible Integration

3. Helping managers plan

4. Channel shift to digital 

1. Workflow

 This is where pretty much all of the aforementioned complexity lives in the administration of Blue Badges.

Whenever an application is received by a council, they have an associated ‘workflow’ that users follow. Kent County Council has 25 distinct stages for new applications, which could be triggered dependent upon the information provided and subsequent assessments undertaken.

Plus, for each stage there can be ’n’ actions. An action is an event that is triggered during or on completion of a stage. For example:

• Auto-trigger an assessment
• Auto-trigger a SMS via GOV.UK NOTIFY
• Auto start a different workflow
• Automatically trigger a request for payment via GOV.UK PAY

We have mapped out seven distinct actions and, on some stages, there can be more than one of each.

So, what started off as 25 stages might have seven actions / branches in process meaning quite quickly the number of permutations exceeds 100.

How does one make this manageable in a software system where each council’s requirements are different?

Well some organisations are suggesting using low code. Low code can provide a lot of flexibility for organisations that have the technical resource to build and maintain applications. However, these will inherently have a user base of one, so may suffer from a lack of functionality and upgrades as the economics of doing so for just one customer makes this difficult.

Our approach at IEG4 is to remove the technical curtain of even ‘low code’. To enable business users to manage their operations and change what the system does in a workflow without the need for IT.

Our approach to this significant challenge was to simplify the complexity to the rudimentary elements. To recognise that you could have an infinite number of stages in a workflow with an infinite number of linked assessments and actions. The solution to this challenge was to provide non-technical users with the means to:

• modify the stages within a workflow
• add actions to stages including the automated issuing of GOV.UK Notify templates
• build assessments to capture additional questions that need to be asked
• set which users could view/work on a stage

By delivering this we have not only catered for the different ways councils wish to work now - we have delivered the means to easily change workflows, enhance them based upon feedback and, probably most importantly, have a ready-made solution to make nuances in workflows caused by the hidden disabilities changes coming in August 2019.

2. Invisible Integration

Whilst the front of the Blue Badge service is what most people see, the most improved and powerful part of the new service is in the integration capabilities now available; both in terms of the services provided by the DfT and also those by GDS - GOV.UK PAY and NOTIFY.

Now, while us geeks love integrating services together, there are real efficiency savings and user experience improvements made possible by these integrations. Our challenge was to take as much advantage of these as possible without a user needing to see any of the technical gobbledegook and for this to be invisible and just work while the user does their job.

There are lots of examples of this but here are some of the best examples of how this is done:

1. Automated creation of cases as soon as forms are completed using the national DfT forms

2. A national search option is available that looks just like the council specific search - but in fact is powered by the DfT’s badge search API

3. Automated creation of cases where someone has made a paper claim but exists in another council having been found in the search

4. Automated and dynamic notifications sent via GOV.UK NOTIFY, as stages are updated by users. I.e. different outcomes result in different templates being used

5. Automated badge creation when a user makes a payment via GOV.UK PAY. I.e. when one API returned a successful response trigger another in a chain of events

  A real-life example of the benefits of this approach is the instant an application is submitted in the national form, our application imports it and sends them a text message/email to let them know how they can track the process of it online.

As the application progresses, the customer is constantly updated and if necessary asked for information. Not only does this mean the customer feels engaged with, but there is a simultaneous mutual benefit to the council in that it minimises calls from customers chasing the progress of their application

3. Channel shift to digital

Delivering digital-by-default applications is ingrained into the psyche of the IEG4 team. For us, providing a self-service element to the Blue Badge platform was not an afterthought or seen as an additional module; it was seen as a core challenge that was just as important as the case management application to be solved.

When we reviewed how the online service worked prior to 2019 and, even today, we found that there was a broken element in the user journey: even if a user completes an application and has the best possible digital experience, the second they press submit they then lose sight of what’s happening. This creates both an assumption someone is working on that application that very second and also a sense of doubt as to whether the council is aware of how important it is to them.

Understanding the challenge and with the help of customer services insight, we established that a self-service function needed to enable customers to:

• have secure / real time access for a citizen to their application on any device
• see the current status of their application
• see the current payment status and make a payment via GOV.UK PAY
• upload supporting evidence

These functions were designed to not only engage users but to enable citizens to provide data / make payments in a manner that enables automation / optimisation of process.

Plus, as >65% of people that apply do so online, the odds are they will also use the self-service functions to check the status, upload any supporting documentation and make payments.

Some of the most exceptional functionality delivered by the development team in the platform is in the interlinking of the case management workflows to the self-service solution.

For example, the status of a customer’s application is updated and can be seen by them in real-time as a user updates it in the CMS.

When a user sets the application as incomplete in the CMS, the citizen is notified in real-time of which documents they need to upload and how to do it online. When documents are uploaded by a customer these are automatically pushed back against the case.

By seeing the self-serve function as a core component of your operations, it becomes an enabler of efficiency and channel shift.

4. Helping Managers Plan

Rather than simply asking what managers would like to have reporting against, we sought to derive and provide genuine insight from the data held.

The net result of our efforts, heavily assisted by Hannah Buckley (Operations Supervisor at Kent County Council) was the delivery of reporting that reports on the things that you’d expect but also:

• highlights variance in workloads and what to expect in the future
• illustrates hotspots via heatmaps across the county to understand areas channel shift is better/worse in order to proactively target channel shift in those areas
• indicates exactly which officers were performing well and which were not
• conveys the efficacy and performance of contractors delivering parts of services

For example, rather than just report upon the number of new applications received over a period of time we delivered a report that would illustrate when badges would expire.

With the ability to filter these by circumstance i.e. Walking / Blind etc., a manager can understand not only when peaks of work will take place but also allows them to understand the nature of the renewals. Clearly if your peak of renewals is entirely walking assessment based, more work will be involved than if they were mainly automatic qualifiers; this will be particularly beneficial when the hidden disabilities application commences in August 2019. 

Wrap up

We hope you’ve enjoyed our whistle-stop tour of the challenges faced by product managers in the design of a Blue Badge platform and how we looked to solve them.

At IEG4, 'We do Tricky'. We take the supposedly complex, remove the technical gobbledygook and enable business users to do their jobs better. This means the removal of any code at all - a solution designed to achieve exactly what you need in a flexible manner.