Severn Trent

Transforming the digital experience of the existing website into a new responsive site, helping customers to self-serve better.

Design Team

Amrit, Estelle, Mark, Max and Tanya

Contribution

UX Design, UI Design

Delivered

stwater.co.uk

Purpose

Severn Trent (FTSE 100) is a major water company in the UK. They supply fresh water and treat sewage for around 8 million people living in the Midlands of England and also a small area of Wales.

The purpose of the project was to transform the old website into a new responsive site that improves customer self-service and reduces the amount of calls to the call centre. The new system would also be built on Adobe Experience Manager, allowing the client to create and manage content easier.

The project involved a discovery phase of 6 weeks and a delivery phase of ten 2-week sprints.

Discovery

The discovery phase was broken up into design sprints, where each sprint focused on a key user journey to tackle. User research was carried out at the beginning with the client and customers to understand the needs of the people that we were designing for. The outcomes from this research was modelled in the form of personas, empathy maps, user needs and cognitive models that would feed into the beginning of a design sprint. 

 
Each sprint involved understanding customer needs, evaluating how the existing system serves customers' goals and rapidly testing prototypes. We worked closely with the client to co-create new solutions that were aligned with the business goals and customer desirability.

Research in the contact centre

This step was about understanding how the organisation works and better understanding the people that we were designing for. This includes all current Severn Trent customers and considers new customers in the future.

I spent a day in the client’s contact office, in Derby, to listen to customers’ problems and observe how staff tried to resolve these problems. It allowed me to learn more about who the customers are, what they were trying to do, and the problems and frustrations they faced.

The three departments that I shadowed were: 

1. Telephone call team
2. Live chat team
3. Social media and email team

User needs

User needs statements were identified from the early user research. They helped frame the problem at the beginning of a design sprint and allowed the new design to be centred around the needs and wishes of the customer. Each member in the team would collaborate around the existing user research and write out the key user needs.

Mapping out the existing system

We made full use of our design studio wall spaces, to map out the as-is system. Each design sprint explored one of the five main user journeys of the website.

1. Setting up an account
2. Paying a bill
3. Submit a meter reading
4. Moving house
5. Report a problem

The wall space allowed our work to be a living and changing thing that acted as an invitation for multiple stakeholders to critique the existing system and engage in the design process.

Comparative analysis

We analysed other services that were ‘best in class’. This was to see what design patterns and conventions were used for universal services such as allowing customers to make a payment.  

Sketching

We sketched out initial designs for the end-to-end user journeys. It took into account the key information from the as-is system, along with the needs and goals of the customers, to iteratively create new solutions that makes sense.

Lo-fidelity design

The best sketches/ideas were critiqued and taken forward to wireframe the to-be user flows. This stage was focused on how the customer would interact with the website and navigate through the system to reach their goal. It considered the happy and unhappy paths.

Hi-fidelity design

The visual design was a shared responsibility within the design team. I worked on turning some of these lo-fidelity designs into hi-fidelity user interfaces.

Creating a component library

To maintain consistency within the design team, I created a component library from the lo-fidelity and hi-fidelity designs that were being rapidly created throughout the sprints. This helped develop a design language, enabling everyone to create something based around the same shared set of principles and patterns. The library was started during the discovery and was continually updated and evolving through to the delivery.

Prototyping and Testing (as-is and to-be)

Functional prototypes were developed for the to-be solution. Prototypes were built mobile-first and the self-service tasks were tested against the as-is system. The client hired an external company to conduct the usability testing, with myself sitting in to note take. A mixture of existing customers were recruited for testing.

For submitting a meter reading, I requested that participants read a real life meter reading (from a Google photo) and then enter this as if it was their own reading. I anticipated that this might be an area where people struggle (as it is done so infrequently but very important in getting the billing right).

Analysing the findings

Findings from the testing were fed back into the design process and helped us to iterate and make design improvements that were human-centred. Some of the key findings included:

• Language can be difficult to understand. Unclear on what’s required from the user
• Clarify why different payments are due on initial and subsequent months
• Provide a monthly payment schedule
• Clarify how the monthly payment figure was devised
• Participants were not confident about reading and entering water meter readings
• Most participants entered a water meter reading incorrectly

"Surely they would need all numbers"

- Research Participant

"I guess I would leave the zero off at the beginning and leave the end ones off but I don't know..."

- Research Participant

Problems with meter readings

I was particularly interested in the struggle that people had with reading and entering water meter readings. Most competitor websites use a plain textfield, with no front-end validation, and let you enter any length of alpha-numeric input. Some of them include instructions for how to read and enter a meter reading (as shown in the following images).

Key observations

I watched individual usability testing videos back and summarised key observations for entering a water meter reading.

•  Some participants weren't sure if they needed to include the leading zero
• Some participants entered the whole reading including the red numbers
• Most of the participants read the instructions but then went on to enter the numbers incorrectly
• Some participants didn't read the instructions
• Most participants took around 1 minute to enter a reading

Reflection: I realised that you cannot rely on instructions alone for getting people to enter data correctly. Instructions can also be missed or not understood well. A system should be smart enough to guide the user and accommodate human error. Some customers will enter all of the numbers if the system allows it. This makes them feel more confident as they aren’t leaving anything behind.

Rethinking web forms that capture water meter readings

Web forms that require user input should map to how people think and behave. They should help guide them naturally, in context, and should accomodate for human error.

The concept of using the camera on a phone to scan a meter reading was discussed, however it was not technically feasible to implement at this stage. We still needed a universal way of doing it.

I started sketching various ways that this could be done for a new input that captures water meter readings. 

Concept for entering a water meter reading

• Does not allow text or symbols to be entered, only numbers.
• After five numbers (max) have been entered, if the user tries to enter a 6th number, then a decimal point is added (.) and it makes all numbers after this red. Only three red numbers can be entered (maximum of 5 black and 3 red).
• If a user enters less than four black numbers, it displays a message telling the user what they need to do.
• If a user enters less than 5 numbers then they are reminded to check if their reading begins with a zero and it does then they should include this too.

Lastly, I had the idea that if it is technically feasible, you could check the number entered with the number that was last recorded when they paid a bill. You could then calculate the usage over the time and check if the number isn’t way out of range.

Creating and testing interactions

To get a feel for how these concepts could work, I started prototyping in the browser, using CSS and JS, to create the interactions. 

Delivery

The discovery phase helped to create a strategy for the delivery phase. The delivery was split into two phases, where phase one was concentrated on content migration and phase two was focused on self-service. During the delivery phase, the team had to be co-located within the client’s head office. We worked in an agile cross-functional team. Each sprint started with a planning session and we used Jira to track our progress. At the end of a sprint we would have retrospectives and demos with the team and organisation.

Here are some screenshots of the final deliverables. Also available live at stwater.co.uk.

Navigate

Work

Publications

About

Find me elsewhere

LinkedIn

Twitter

Instagram

© 2019 Mark Davies