Helping British Gas reduce £700k in costs per year as part of their digital transformation project

Redesigned Help & Support from the ground-up. We created a better experience for our customers, allowing them to self-serve faster and get in touch with us through the right channels. In doing so, we removed frustration drivers for our customers and decreased call centre costs. Furthermore, we also improved our NPS score, which is another key metric we were tracking.


This was a team effort! Besides myself, the product team consisted of engineers, QA testers, product owners, a business analyst, a CMS manager, and a scrum master. We also got to call on our analytics team when needed.

See the team
British Gas legacy
The legacy design featured a search bar, but it was not performing well
Most people were browsing our content through these eight categories, but this was not straightforward for them

The British Gas legacy design my team inherited

British Gas legacy
Energy and Home Services, our two content tiers, were exposing our business structure and confused our customers.

The two content tiers that proved to be problematic later on


British Gas was in the middle of a digital transformation project, trying to reduce operational costs and give customers a better experience at the same time. But as anyone who’s ever been in a digital transformation project knows, reducing costs often comes at the expense of the customer experience; at least until the organisation’s understanding of ‘digital’ matures. This doesn’t happen because people are ill-intentioned. It’s simply the cycle of taking a 105-years-old organisation into the new world.

Coming into this, I knew success would be helping the company reduce costs, but I didn’t want that to happen at the expense of tanking the NPS. With British Gas being the type of company it is, I knew that the keys for making this happen were using data smartly and managing up.


As I was entirely new to the team, I went on a Discovery adventure and listening tour for a few weeks, starting out with seeking data from the call centre. Since they only had basic analytics, in order to understand why our key metrics were doing poorly, I gathered as much insights as possible through a few different other methods.

Reports archive

Reading through the work done by previous teams helped me understand how they’ve tried to solve the challenges before I joined the team. Since there was only an overlap of a few days, this was the main way I got to learn about their work. The issues they identified were around four areas: content, find-ability, usability, and processes.

Analysing raw NPS data

While the NPS score is not necessarily the most reliable metric, and it’s debatable how useful it is to track the progress of the user experience, the raw data we extracted from it was a big help – it gave us access to large amounts of written feedback from our customers, which pointed our efforts in the right direction.

Usability testing

At British Gas we were fortunate enough to have an in-house testing lab and virtually an unlimited budget to recruit participants. Having this luxury allowed us to run several usability testing sessions to learn why our customers were struggling using Help & Support. Bringing senior stakeholders in the room, as well as the rest of the product team, allowed everyone to understand the importance of the project.

Running intercept surveys

Since we had a massive volume of visitors each month, we thought of using that to our advantage by running intercept studies. One study we ran gave us a massive amount of data that our Business Analyst helped make sense of. The survey appeared when the user showed exit intent, and asked a simple question: “What were you trying to achieve today?”

NPS comments

Comments straight from the NPS survey

Watching customers use the product

One way of watching Help & Support in action without putting up with the logistics of planning a full-day testing session was to install Decibel Insights. Decibel allowed us to analyse how people were using our product and to discover recurring bottlenecks, frustration drivers, and even technical bugs. This was a team effort, with everyone from the scrum master to our engineers taking the time to watch customers use Help & Support and helping gather feedback.

Other activities

We engaged in other activities over the course of a few months, including stakeholder workshops, card sorting exercises, desk research, interviewing customers, and talking to other product teams about how our redesign might affect them.

Since Help & Support sat at the core of British Gas’ website, it was important to hear everyone else out and understand their goals, so that we could help them too.

“I don't understand why it takes me so long to find a way to contact you. I'm paying through the nose to be your customer, and I need to get in touch with someone.”

Anonymous customerIntercept study answer

Main focus areas

After clustering all our research insights, we discovered these six major issues:

Customers couldn’t easily find a way to contact us

We exposed our business structure to visitors through our two content tiers

Navigating through our content was confusing

We had a technically inadequate search engine that was showing skewed results

Our single-page approach damaged the efforts of our SEO team

The content itself was outdated and not very helpful*

*The sixth issue we discovered, the content, was out of our hands. Each product team owned their FAQs, and it was their responsibility to keep them updated. We knew this was a fundamental part of Help & Support, so our Product Owner advocated heavily for the other teams to invest time in this, but at the end of the day, it was not something we could control.


In preparation for an ideation workshop, we’ve sorted all our learnings into themes and framed them as How Might We (HMW) questions. They helped us make sense of the research and kickstarted the upcoming ideation phase.



During the workshop we brainstormed ideas for the new design and ran a selection of ideation exercises. We agreed that we were tackling such a complex problem, plus legacy design language and tech debt, that it made more sense to start from scratch.

The workshop generated enough ideas for me to go do some work on my own. It’s been valuable to involve the whole team in the process; running an empathy-building session so early on made everyone feel ownership of the project and motivated to get involved over the upcoming months.


Testing various support models

After watching many users struggle to browse through our FAQs, I wondered whether a search-driven model was better suited for us. I shared some sketches with the team, but everyone raised the same concern — it’s been tried before, with little success. Previous usability testing reports I looked through led me to believe the experience was not the problem, but rather the implementation of it.

This was a stumbling block that I could only remove with evidence, so I ran a usability testing session, watching customers use various help models from other companies. We’ve learned that search-based support models are the most effective as long as the search functionality is performing well technically, so this confirmed my hypothesis.

Testing our own prototypes

With the stumbling block removed, I created high-fidelity prototypes and tested them in the lab. This is where I would usually use low-fidelity wireframes, but British Gas had a comprehensive pattern library already built, so it was easier, faster, and more accurate to ‘wireframe’ in high fidelity.

Testing went well the first time around, and as we kept ironing out more and more details and went back to test again, we felt we were getting closer to a prototype that would solve all the challenges outlined above. We knew that aligning with our senior stakeholders at this point would be crucial — they signed off on the project, but not on our solution.

Since we didn’t have quantitative data to show, we often invited them to the lab to watch customers use our prototype. When they couldn’t make it, we recorded key session highlights and shared those with them. This was a stressful time for our Product Owner and myself; we’ve spent countless days ironing out presentations and preparing to present our solution to senior stakeholders and other product teams. After months of back-and-forth, we were finally given green light.

Self-serving customers

In testing we’ve noticed time after time how customers would try to self-serve, and only contact us if they weren’t able to help themselves. This was a key find and shaped the strategy for the new design.

Hence, the new Help & Support model had to allow customers to help themselves as much as possible. Among others, we:

  • improved our search functionality using machine learning
  • moved to a search-driven design, which proved to be the most effective in testing
  • removed the confusing categories from the landing page
  • improved our SEO performance, so customers could find what they were looking for faster
  • pushed for a better management of the content library by creating analytics that would help other product teams analyse FAQ performance
  • placed contact options strategically so that customers would easily find them after self-serving.

Experimentation phase

During this period our analytics team brought some interesting insights to our attention. One of them was a common user behaviour they discovered — customers would navigate to a Help & Support FAQ only to find a button to a journey (say a ‘Pay my bill’ or a ‘Set up a Direct Debit’ journey). We wanted to reduce that friction, so we added a small feature which we called Search CTAs. We wanted to cut the middle man – the FAQ – and send customers to a journey directly from search.

We dismissed the initial low performance after launch, assuming that users were just not searching for the right key words and we should give it more time. During another lab session we discovered that customers thought the CTAs looked like titles, which is why they weren’t clicking on them. This is just one example of a change we thought was going to be a hit, but which required more thinking. Based on further testing, we also redesigned or removed other elements that didn’t improve the experience.

British Gas experiment
In the initial design, customers thought the Search CTA was a title, so they never clicked on it.
In the second iteration we changed the design and made the Search CTA look like any other search result.



British Gas uses a design system, so there was not a lot of wiggle room to be creative. However, the redesign required us to create a few new elements. Once tested, we were able to add them to the design system, to be used by the wider design team.

Final design
The improved search functionality not only understood what customers said, but also what they meant.
The most read articles were kept as well, since our analytics showed they were being very useful.

The new British Gas Help & Support landing page design

Final design
The search bar appears at the top of each article, for easy navigation between FAQs.
The help categories have been moved to the sidebar, taking a much less prominent place than before.

The new article view

Final design
Most of the content on the landing page sits above the fold on mobile platforms

The Help & Support landing page on mobile

Final design
The search bar above the FAQs is not visible at first, to keep the focus on the content. It becomes visible when the user scrolls back up, as that’s when they’re more likely to need it.

The article viewer built on solid principles of typography and legibility

Final design
The Search CTAs were just one of our successful experiments. Another one was adding CTAs on the categories page.

The categories page has been turned into a secondary way of navigating


The NPS score has increased by roughly 25% since we shipped, and customers stopped complaining about the issues we’ve tackled. Most problems highlighted in Discovery have vanished, and the senior stakeholders were pleased with us improving the brand affinity.

The redesign made big noise in the business because it helped cut a considerable amount of calls from the call centre — one of the key metrics we played on when we got the project signed off. The team managed to deliver a decrease in costs of £700k per year, which was way beyond anyone’s expectations. British Gas is currently looking at integrating the same search-driven model into other key parts of the business.

Final words and lessons learned

Although British Gas is not the most mature design organisation, the way the team was set up there and how Design was applied has taught me a lot. I also got to work with some brilliant people there, mentored younger designers, and learned the practicalities of balancing a good customer experience with the needs of a company to grow.

My experience at British Gas has taught me how to make Design matter in an organisation that inherently has other priorities. I’ve also learned how engineers can sometimes out-design a designer, how hearing ‘no’ many times over is the quickest way to the best solution, and how often putting products in front of customers is an eye-opening experience for the whole team.