Case study · OVO Energy

Helping customers understand their energy payments

Redesigning the Direct Debit journey in the OVO Energy app, so customers at risk of debt can see how their usage affects their payments and act sooner.

Role
Product designer in the payments squad
Team
Product manager, marketing lead, brand lead and engineers
Users
OVO customers at risk of ending up in debt
Impact
Significant reduction in calls to customer service
Four OVO Energy app screens: the home screen with an Adjust your payments card warning of £38 owed by the plan anniversary, the Direct Debit calculator with a counter set to £48, a balance over time tracker by month, and more options for managing your balance.
Product

The OVO Energy app

The OVO Energy app lets customers check their balance, see their bills and manage their monthly Direct Debit payment.

Team

Who I worked with

I was the designer in the product squad. I worked with a product manager, a marketing lead, a brand lead and engineers to come up with and build ways to help customers understand how we calculate their payments.

The problem

Customers couldn’t see how usage affected their payments

Insight from several sources showed there was an issue with how OVO managed payments. When we investigated the root cause, we found that customers simply didn’t understand the relationship between their energy usage and their Direct Debit payment.

The goal was to give better context to customers we had identified as being at risk of ending up in debt. We measured success with two metrics:

  1. Increase the percentage of customers who took action after being told about their debt risk.

  2. Decrease the percentage of customers who complained about our debt risk assessment.

Process

How I approached the problem

  1. Step 01

    Review research

    Made the most of existing research about payments and usage, as primary research was harder during the coronavirus pandemic.

  2. Step 02

    Sketching session

    Hosted a sketching session with the squad, using insights from the research to come up with solutions.

  3. Step 03

    Competitor analysis

    Mapped the payment journeys of every major UK energy supplier, and analysed their pain points and delighters.

  4. Step 04

    Design and test

    Designed the initial journey and ran a round of guerrilla user testing to check my hypothesis.

  5. Step 05

    Stress-test with real data

    Tested the designs against real customer data with engineers, and replaced the slider with a counter.

  6. Step 06

    Finalise and measure

    Worked with the copy and brand team on the final designs, and with the product manager on analytics tracking.

Consideration

A project I started, with no back-end support

This project was initiated entirely by me. Because of that, there was no resource to make any back-end changes. So everything had to be built using only our existing APIs and the information customers could already see.

That constraint shaped the whole design. Instead of new data, the experience brings together what already existed in one place: a warning on the home screen, a view of the balance and Direct Debit, a chart of the balance over time, and options for managing it.

Consideration

Research during a pandemic

The coronavirus pandemic made primary research much harder than usual. Instead, I made the most of research about payments and usage that had already been carried out. Using insights from those reports, I hosted a sketching session with the rest of the squad to come up with solutions to the problems customers were facing.

I also wanted to know what our competitors were doing to solve the same problem. I found friends and family who were customers of every major energy supplier in the UK, mapped out their digital experiences, and analysed the pain points and delighters of their payment journeys.

Home screens from five other UK energy supplier apps, each showing the account balance or Direct Debit amount.
How other UK energy suppliers show balances and payments.
Consideration

Designing for real data

After a round of guerrilla user testing, my hypothesis held up. Users understood the impact of their payments and felt encouraged to take action sooner.

But when I stress-tested the designs with the engineers using real data, it became clear that the slider at the heart of the initial designs wasn’t suitable. Real Direct Debit ranges varied too much: a range of £20 to £200 was too wide to control, and £20 to £25 was too narrow to be worth sliding.

I replaced the slider with a counter. It wasn’t as flexible, but it gave customers much more control while still letting them explore. My decision took into account:

  1. The strain on the customer’s hand when using the counter.

  2. How close the counter sat to the parts of the screen it affected.

  3. The existing design style guide.

Two versions of the monthly Direct Debit amount field. A slider set to £22 is marked as not working; a counter set to £48, with minus and plus buttons and a hint that the amount must be between £48 and £2000, is marked as working.
The slider was replaced with a counter that shows the allowed range.
Outcome

Fewer billing calls to customer service

Considerable drop in billing calls

After the feature launched, customer service calls about billing dropped considerably among customers who had downloaded the app.

Built to be measured

I worked with the product manager on analytics tracking, and added in-app feedback so customers could rate the new journey.

Key learning

Guerrilla testing, done right, can be as powerful as formal testing

The pandemic ruled out the formal research I would normally plan. So I turned to guerrilla testing, which was quick, cheap and easy to fit around the squad's work. It still gave us the answer we needed: customers understood how their payments worked and felt encouraged to act sooner.

What made it work was treating it with the same rigour as a formal study. I went in with a clear hypothesis, tested with people who matched the customers we were designing for, and knew what I needed to learn before each session.