Scope
The Department for Energy Security and Net Zero (DESNZ) brought me on to design a system that would allow UK-based energy installations to apply for emission permits.
This was to replace an existing system that was being used as a stop-gap following Brexit.
At first the system was targeted at static installations, such as power plants. Mid-way through the scope shifted, so that the system also needed to accommodate aviation emitters, including aircraft flying through UK airspace.
Being a government system, it also needed to pass a round of assessments from the government’s internal design experts. If it couldn’t get through these GDS assessments then it would never go live, and users would be stuck with a legacy system that looked like it was last iterated upon in 1992...
Involvement
Senior UX/UI Designer
Service Designer
User Researcher
Date
April 2022 - November 2023
Tools
Whimsical
Axure
InVision
Notion
Balsamiq
Mapping the legacy system
One of the first tasks on this project was to map out the system we planned to replace.
This was done in collaboration with a Business Analyst and several members of the Environment Agency who were familiar with the ins and outs of this system.
Identifying pain points
Before diving in with hammer and chisel I needed to identify what gave users grief, and what worked well.
To do this, I interviewed members of regulatory bodies such as the Environment Agency and the Offshore Petroleum Regulator for Environment and Decommissioning.
Employing the Government Design System
The UK government has a robust and well tested design system (GDS) that must be used across any systems within government.
Ensuring that prototypes and designs met GDS standards from the get-go had benefits for consistency and usability, and also meant it’d be easier to pass future internal assessments.
Transforming core pages
These three images demonstrate the design development of the system’s core areas over the project.
Our example is a ‘task page’. This is the first page users see when they log in. It shows all the work they have been assigned.
So what changed?
Well, the navigation shifted from a vertical left-alignment to sitting atop the page, as per the standard user schemata for modern websites.
The name of the task was given prominence, as that was identified as the information users most wanted from a task page (shocking, I know).
Link signifiers were made more obvious so that users could understand how to get to the individual tasks.
And information was condensed and (in the final version) arranged vertically. This ameliorated the layout issues in the legacy system where users had to horizontally scroll to reveal pertinent information.
As with all pages in this system regular user feedback was the special sauce that led to creating the most user-friendly designs.
These examples are from test environments and contain dummy data.
Making paper forms digital
It wasn’t all just updating the legacy system to a modern design - there were also several large processes that needed to be digitised for the first time.
Regulators were using a mix of paper forms, emails, and complex databases to complete such tasks as ‘annual emission reports’ and ‘new entrant reserve applications’. If we could make these tasks digital they would be easier and faster to complete.
This ‘digital transformation’ process was on-going for the full life-cycle of the project, and involved discussions with regulators, operators, and legal experts.
A few examples are on display here. These are Axure prototypes from various stages of development.
Passing the GDS assessments
Before a service can go live, you need to show that you’ve built a service that meets the needs identified at discovery, and that you’ve tested and iterated based on what’s been learnt.
To do this, I worked with the entire team to craft a story that showed our design processes, and how we were crafting a system with the user firmly in mind.
This story-driven approach led to a thumbs up from the assessors and a pass for all stages of GDS assessment.
Post-launch support
When a system goes live support shouldn’t screech to a halt.
Instead, focus should shift to the ‘back log’: that hinterland of changes and improvements that need doing, but couldn’t fit into the go-live schedule.
There were approximately 350 changes in the back log that needed tackling post-launch. Some were small (e.g., a text change, a new button), and some were enormous (such as implementing brand new functionality).
The back log was spread across Trello and Confluence.
I managed this process with a small team, having regular sessions with regulators, writers, and legal experts. By the end of my contract I had created final designs for more than 50% of all items in the back log.