4a. Design for easy and successful journeys

This guideline refers to helping people achieve their goal quickly and easily, reducing the time they spend and asscoiated electricity consumption. It also points to them succeeding first time, to reduce task repetition and the creation of ‘failure demand’.

Lifecycle phases

Alpha Public Beta

Actions

(i) Use established service and design patterns

Designs that are more familiar for users aid navigation, speedy completion of tasks and ultimately success rate. They also save teams the time taken to develop patterns from scratch by providing starting points that have been proven to work well.

(ii) Use clear service signposting and content

Design content that is easy to understand, clearly structured and organised in order to help users achieve their goals efficiently, thus reducing energy consumed in the process.

Synergies

1. General Usability: Services that are quick and easy for users to complete their goals on may tend to be more usable. However, with more complex services, there may be a tension, in that some users may report being unnerved by processes/services that move too quickly. Services should be designed to be at the right pace for users.

2. Financial Cost: Services with less failure demand require fewer resources for providing help to users and could reduce financial costs to operate in this regard.

Measurement

Measure user time on task and success rates.

Further Reading

GOV.UK, Tech Code of Practice, Point 12, Making Technology More Sustainable

4b. Design for lightweight digital pages, documents and communications

The goal of this guideline is to reduce the size of pages on websites and applications, documents and communications, and in so doing reducing data storage and transfer to end users and the energy consumption associated with it.

Lifecycle phases

Alpha Public Beta

Actions

(i) Set an overall page weight budget

A page weight budget encourages close consideration of what content, features and interactions are most essential for users with small screen sizes or low bandwidth.

(ii) Design for lightweight multimedia

Images, videos and animation are frequently the most significant contributors to overall page weight. Actions could include some of the following in the table below:

Aspect Actions
Rationale for multimedia Only use images, videos, sound and animations when there is a clear value-add for users
Formats, resolutions and compression When images, videos, sound or animation is used, choose lower resolutions, appropriate formats and compress as much as possible. Multimedia content can be served in degraded quality when necessary. For example: substitute raster (pixelated) images for vectors where possible, such as SVGs. Use WebP format where possible.
Autoplay and lazyloading Disable autoplay, use lazy loading and allow users to pause videos, sound and animation.

(iii) Design lightweight and minimal webforms

Lightweight forms will require fewer resources to process.

(iv) Only send emails, SMS, website and other notifications when necessary and keep these lightweight

Notifications such as emails have a carbon footprint, of particular significance when they have attachments.

Set up notifications so user can turn these off or choose how often to receive them. If users do not want or need to receive notifications, then the ability to turn these off will reduce transfer and energy use.

(v) Use lightweight publishing formats for documentation

Use the HTML publishing format instead of PDFs where possible. Along with accessibility issues, PDFs tend to be larger file sizes.

Synergies

1. Inclusivity: A lightweight digital servivce is more inclusive of users with slower internet connections.

2. Accessibility: User experiences designed without reliance on multimedia content are likely to be more accessible.

3. General Usability: Faster page loading speeds will also tend to keep users engaged and increase completion and satisfaction rates.

Measurement

The 'weight' of webpages, emails, notifications and documents can be measured directly in bytes.

NB: The ‘data transfer approach’ to estimating digital carbon emissions

There are a number of web-focused methods, such as the ‘Sustainable Web Design Model’, that take the weight (in bytes) of web pages and uses this to estimate the carbon emissions from the transfer of this data to the end user.

This means taking data transfer as an proxy indicator for total resource usage, and using this number to extrapolate energy usage as a fraction of the energy used by the total internet system.

A number of online webpage carbon footprint calculators use these methods.

Caveat: The 'data transfer' approach is more appropriate for standalone websites rather than complex services, as it focused on the front end and does not consider what is going on on the ‘back end’, with hosting and databases for example.

4c. Design for lower offline impacts

This guideline is about designing service journeys so that the environmental impacts coming from offline actions are kept to a minimum.

Lifecycle phases

Alpha Public Beta

Actions

(i) Design services so that impacts from users’ and agents’ physical travel is kept to a minimum

In the UK, transport is usually one of the largest contributors to an individual’s carbon footprint. Globally, transport accounts for around a quarter of all carbon emissions from energy. However, there may be instances when users need to travel, for example for health appointments.

(ii) Design services so that users’ and agents’ consumption of paper is as low as possible

Consumption can come from printing and posting of paper.

(iii) Design so that the need for electricity, heating and cooling that comes from occupying buildings is kept to a minimum

Significant environmental impacts come from the energy used for heating and cooling and electricity consumption for lighting.

Measurement

There are a number of tools that can help with estimating the offline impacts coming from service journeys