Transforming the digital experience of the existing website into a new responsive site, helping customers to self-serve better.
Amrit, Estelle, Mark, Max and Tanya
UX Design, UI Design
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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).
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:
- 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
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).
I watched individual usability testing videos back and summarised key observations for entering a water meter 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.
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.
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.
To get a feel for how these concepts could work, I started prototyping in the browser, using CSS and JS, to create the interactions.
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.
Just Eat | Rethinking the rating and reviewsHow we enhanced the existing ratings system and made it more reliable for our customers
Just Eat | Fixing the minimum spendHow we improved the usability of ordering food and increased conversion by 0.25% (270,000 extra orders per year)
Severn Trent | Digital transformationHow we transformed the digital experience, helping customers to self-serve better
ivDripRateiPhone app for managing drug infusions, which has generated more than 25,000 downloads and is used by healthcare practitioners globally
© 2019 Mark Davies