Carbon Calculator Reporting [Action Sustainability]

Action Sustainability was experiencing the following problems with the reporting platform used in conjunction with their web-based tool the "Carbon Calculator":

→  Data input was invariably incomplete with full sections left blank

→  Users needed extensive training to understand how to submit reports

→  Client support was overwhelmed with tickets relating to user problems

→  Lack of clarity surrounding data requirements, resulting in 0/blank responses

I was tasked to complete UX/UI research to assess the reporting process, then redesign to optimise usability, minimising incorrect data input and maximising data completeness.

I conducted user surveys, interviews and contextual inquiry work with external users (clients), internal users, programmers and stakeholders to assess the product’s use and problems.

While the user's technical ability varied across companies and generally correlated to the frequency & complexity of reporting, the research revealed a few key pain points that were common across user groups.

Some of these included:

→  Confusing to track progress in report submission

→  Slow and time-consuming UX

→  Overwhelming and unintuitive UI

The three personas that were exposed had unique experiences submitting their carbon data reports:

→  John, 48

An infrequent supply chain reporter who is busy and struggles to find time to report. His technical ability is low so commonly leaves many fields and sections blank or with a 0 input. His main aim is just to get the report submitted on time.

→  Adriana, 36

A comparative super-user, Adriana works for a larger company and uses the supply chain reporting frequently. She has learned a roundabout way of submitting reports efficiently despite the difficulties she faced when first receiving training. 

→  Marie, 27

Marie is an example of a user that has a supply chain of reporters and is also a supply chain reporter herself. She struggles to get her supply chain reporting correctly due to a lack of training and clarity over requirements. This results in an inaccurate, incomplete data set for her own submission.

Initial sketching

Alongside iterative user testing, I developed a stepped approach that reduced overwhelm by creating a report "homepage" that tracked overall progress and made it clear how to step through and revisit each section. It was broken down into the following core sections:

→  Selection of reporting period (modal)

→  Adding company information (form)

→  Completion of data report (form)

→  Apportionment to clients (table & modal)

By creating a stepped approach with clear progress status on the homepage, users would be able to follow their progress through the reports in chronological order and be less likely to miss sections. Each subsection would also have its own persistent progress tracker, making it easier to move through multi-page forms.

I designed an interface that used a mixture of horizontal tabs (homepage) with vertical forms and progress trackers. Modals were used when only a small amount of data input was required for an individual section, to create warnings over seemingly incorrect data, and to confirm report submission.

While an initial training would be provided to all users, clearer signposting and a logical progression through the report would now reduce the dependency on support. Additional tooltips, chatbot and links to modal help videos and user guides would further attenuate the amount of blank or 0 responses.

Carbon reporting homepage wireframe

Due to strict accessibility requirements, and the need to be bulletproof across old browsers and corporate laptops, the visual design elements of the new reporting pages were simple. Colours, iconography and fonts were used primarily to highlight users' progress, advise them of the potential result of their actions and to denote outstanding requirements of data input.

Carbon reporting homepage UI design

Select reporting period modal

Data report with progress tracker

Client apportionment step

Report submission

Initial external user testing of the interactive prototype has shown an average increase in usability rating from 4.5/10 to 8/10, showing a significant increase in initial user satisfaction. Using dummy data and an interactive prototype, test users that were unfamiliar with both old and new reporting processes were able to move through the steps up to 40% faster, requesting assistance 28% less. Data completeness was around 20% higher. 

Due to the dummy data, it was not possible to track data accuracy at this stage - however the implementation of a "large data difference" alert functionality helped users know when their data input was likely to be wrong and needed revising.

Longer term analysis of the results of the changes will be carried out periodically, to assess the change in user habits. The rebuild is a complex piece of work from both a front and back end perspective with a significant amount of new functionality, so the likelihood is that the impact of the changes will be seen gradually over time.

The implementation of the new design will be completed in Q2-Q4 2024 by the Action Sustainability engineering team.

Action Sustainability praised the work delivered, saying that it was a strong foundation for achieving the two most important goals of the wider product strategy: data accuracy and data completeness.