View navigation
Launched as a GOV.UK service page in July 2022 is a new heat pump check service, which has been created to:
In collaboration with technical experts from Energy Systems Catapult (ESC), OCC has ensured the site meets the GOV.UK Service Standard, by following the GOV.UK Service Manual, and using the GOV.UK Design System. These standards and systems are set out and administered by the Government Digital Service (GDS). Any site with a GOV.UK domain must meet these requirements. Below we explore how we achieved this on this project.
Prior to the GDS setting out their service standard, government sites were neither always consistent in appearance, nor well designed for users. The GDS service standard exists to ensure that the government can:
“deliver platforms, products and services that help government to become joined-up, trusted and responsive to user needs”.
This is crucial, given that there are approximately 7000 live services, covering everything from managing benefits, to appealing a hedgerow notice.
The GDS provides the resources and tools (components, styles and designs) that UX designers, front-end and back-end developers require to build a compliant site. This enables teams both inside and outside of government to design GOV.UK sites.
It is worth firstly delving briefly into the context of this project to understand the service we helped to create. Powered by electricity, heat pumps either absorb heat from the ground, water or air around a building before it is transferred into an indoor heat circulation system. Heat pumps are more environmentally friendly, and are growing in popularity due to a government scheme to assist households in transitioning to low carbon alternatives.
The goal of the site is to take users on a logical journey, asking a series of questions about their home to give personalised results detailing the potential options for installing a heat pump in their home. If a user is prepared to share their address, data can be extracted from an EPC report (where available). The below screenshot shows an example of selecting the home type in the tool. Providing clear and logical content is a requirement of the GDS standard. Explanations are therefore provided for each house type, and the tool gives clear information about the reason behind each question.
The questions update dynamically, depending on the answers to the previous question, i.e., for certain property types, additional questions will be presented to the users.
Finally, users are given their personalised results, with links to further resources and information:
For a team undertaking this type of work for the first time, we would recommend first studying the guidelines. These include the online user manual, the service standard and getting started guide, which informs designers and developers how to implement the components.
For this project, we worked with UX design agency Fruto, who planned out the wireframes with the requirements in mind. A GOV.UK prototype toolkit is available for UX designers.
OCC front-end developer Alec Keen recommends thorough research prior to starting service designs. “It is much easier to ensure compliance from the get-go than to retrofit designs to fit the requirements,” he explains. There is guidance available on what can be used and in what use cases.
The design system provides a powerful way of creating a simple, elegant, and accessible website quickly with tried and tested components, but there were challenges. For our project, the original designs included proposed images and icons to accompany the questions, as shown in the screenshot below.
To comply with the service standard, it was necessary that these were dropped, as such icons are not compliant with the design systems set out by the GDS. Designers wanting to propose changes to GDS design standards must prove the value of a proposed design change through extensive user testing.
Content is as important as page design. It was imperative that all written content followed the Service Standard. The content on the site was updated following multiple rounds of user research. By way of example, we added an extra screen at the beginning of the tool to inform the user of the implications of their decision to proceed either with or without the EPC data. The copy text explained that including EPC data would mean that some questions would be pre-answered. Adding this screen helped to better inform users, therefore improving their experience, and making it more compliant with GDS principles.
Front-end developer Alec Keen shares his tips for undertaking a GDS project:
Testing is key throughout each project phase. OCC’s internal testing team rigorously tested the site and the user journey at each stage. Our testers provided a formal document detailing any issues found so that our development team could fix them. Testing was an iterative process as each change to the site to fix one issue resulted in a retest. At OCC we keep open lines of communication between the testers and developers, making sure that everyone works together to achieve the desired result.
Our experienced, in-house testing team completed the following types of testing:
Testing also focused on the user journey and experience. This was a collaborative effort, (ESC) provided OCC with access to users for testing, including a number requiring assistive technologies. OCC’s UX team then carried out a combination of survey and online ‘face-to-face’ interviews. This allowed us the opportunity to hear first-hand from ‘everyday’ users and to find out if the site offered a logical user journey. This ensured that it worked as expected and that GDS design standards were met.
The trickiest aspect of building a GOV.UK service is deciding how to combine the available components. Each service is unique and will require a different combination of components. Working closely with UX designers to ensure that the end user journey is logical is crucial.
One of the key challenges was meeting GOV.UK accessibility requirements. Examples of these rules include that any government service must:
The wording for the heat pump options project was carefully scrutinised to ensure that it fitted the accessibility criteria. In some instances, content was revised to make it more universal.
It is important to be aware that different screen readers have different functionality, so it is crucial to test that a service can be accessed by different screen readers.
The testing team at OCC were provided with the accessibility requirements and helped to ensure that these were met.
The code required to comply with the guidelines is built into most of the components as standard. It is key to ensure that parts of the components which are included for accessibility reasons are not accidentally deleted. Understanding the components and checking work should mean that simple mistakes are spotted swiftly. Developers should also follow the procedures and understand the implications of any proposed changes.
Case Studies
Knowsley Council implements EYES on time and budget during Covid.
Case Studies
Working closely with the Department for Energy, Security, and Net Zero (DESNZ), System C Innovation Delivery has improved the eligibility checker by enabling users to self-serve more easily, helping reduce calls to the website’s helpline. Here we explore how we achieved this.
