Multi-tech tool for heating manufacturer
Rethinking recommendations for a high-stakes home decision
Overview
How do you help someone trust a recommendation for a £5,000+ home improvement they may know very little about?
I worked with a UK heating and cooling manufacturer to bring separate boiler, heat pump and air conditioning journeys into one guided experience.
What started as a product finder became a decision support tool. Research showed that people did not simply need help finding the right product. They needed confidence that the recommendation was right for their home, their situation and their needs.
I helped reshape the recommendation logic across three iterations, moving away from questions that asked people to define their own priorities and towards signals the system could infer. We removed priority weighting and budget questions from the recommendation logic, using concrete inputs such as timing and automated eligibility checks instead.
12 usability sessions changed the direction of the product.
Every participant said they would not feel confident booking an installation through the tool alone. That finding shifted the focus from making the recommendation more personalised to making it more trustworthy.
The problem
The client's boiler, heat pump and air conditioning journeys had grown up separately.
They had different layouts, different questions, different recommendation logic and different tools, despite sitting under the same brand.
The initial brief was straightforward: bring them together into one guided product finder.
But the more we explored the existing journeys, the less this felt like a conventional product discovery problem.
Choosing a heating or cooling system is an unfamiliar and high-stakes decision. It can involve significant cost, disruption to the home and technical considerations that most people are not expected to understand.
The experience therefore had to do more than match answers to products.
It had to help people feel confident that:
they had provided the right information
the recommendation made sense for their home
they understood why something had been recommended
they knew what would happen next
they could safely move towards installation
This led us to reframe the brief from "product finder" to "decision support."
The central question became:
How might we help people make a complex home heating decision without asking them to become experts first?
What discovery told us
What discovery told us
I started with a heuristic audit of the existing journeys and a benchmark against six competitors, including Octopus Energy, Heatable and British Gas.
The findings pointed towards a common direction:
Reduce cognitive load rather than adding more information.
Give people opportunities to review and amend their answers.
Explain recommendations more clearly.
Set better expectations about what happens next.
Treat accessibility as a baseline.
Stakeholders agreed that the destination should be one consolidated, needs-led journey.
Where opinions differed was how much information the journey needed to collect before making a recommendation.
The three product categories had different requirements, so the temptation was to ask more questions upfront.
Instead, we started exploring a different principle:
What does the user genuinely need to tell us, and what can the system work out for them?
We tested the prototype with 12 homeowners.
The experience already automated several parts of the decision. Eligibility checks ran in the background, property information could be pre-filled, and users could identify their existing boiler using a photo rather than describing it manually.
These patterns performed well. Photo identification in particular was one of the few areas that testing confirmed rather than challenged.
The bigger issue was the information we were asking people to provide about themselves.
The prototype asked users to select what mattered most to them, including low cost, long-term savings, environmental impact, space and new technology. Those choices were then weighted behind the scenes to influence the recommendation.
Users were also asked to provide a budget range.
Both approaches seemed reasonable from a product logic perspective.
But users did not trust their own answers.
Choosing between competing priorities required people to make an abstract judgement about themselves, then trust that judgement enough to use it as the basis for a major purchase.
Every participant said they would not feel comfortable booking an installation independently through the tool.
We also found that several people questioned why a system was being recommended before they knew whether their home was eligible.
Collecting an address early in the journey created another trust issue. Users were being asked for personal information before the experience had established enough context about why it was needed.
The problem was not simply that there were too many questions.
It was that some questions were asking users to know things about themselves that they could not confidently know.
Rebuilding the recommendation logic
I helped develop and assess three iterations of the recommendation logic in response to what we learned.
The biggest change was removing two inputs entirely.
Priority weighting
Users no longer had to rank abstract values such as cost, sustainability or new technology.
Budget
Self-reported budget ranges were removed from the recommendation logic rather than asking people to make a financial judgement before understanding their options.
Instead, we looked for more concrete signals that could support routing.
One of these was urgency.
Rather than asking someone what they cared about most, we asked a simpler question about when they needed the work completed.
That distinction mattered.
Someone might struggle to decide whether environmental impact matters more than cost. They can usually tell us whether they need a solution immediately or have time to consider alternatives.
Urgency could therefore do more of the routing work without asking users to make an abstract judgement about themselves.
Six routes, one experience
Behind the interface, the recommendation model evolved into six distinct routes based on what could be reliably inferred versus what genuinely required user input.
Shorter timelines could push the journey towards a boiler-only recommendation, while longer timelines opened up heat pump and hybrid options.
Eligibility also became part of the experience rather than a dead end.
If a heat pump or hybrid option failed a space eligibility check, the journey could dynamically explain why and redirect the user either to the boiler route or directly towards survey booking.
The experience was no longer simply telling someone:
"You can't have this."
It was helping them understand:
"Here's why, and here's what you can do next."
The turning point
The most important insight was not that people wanted fewer questions.
It was more specific.
People struggled with questions that required them to make confident judgements about themselves.
"What do you care about most?" was one of those questions.
"When do you need it done?" was not.
That distinction changed how we thought about personalisation.
Instead of making users responsible for supplying every input needed by the recommendation engine, we started asking:
What can the system reasonably infer, and what does only the user know?
That became a more useful design principle than simply reducing the number of questions.
The trade-off
Removing priority weighting reduced one form of personalisation.
Someone who genuinely prioritises environmental impact over upfront cost now has less direct control over the recommendation.
That was a deliberate trade-off.
At this stage of the journey, we prioritised reducing uncertainty and building confidence over giving users fine-grained control over a recommendation they did not yet fully understand.
But this remains a hypothesis.
The simplified version had not launched when the project ended, so we had not yet tested whether users would feel sufficiently represented by an inferred recommendation in a live environment.
What would I do differently
If I ran the project again, I would test the confidence of the question itself much earlier.
Rather than only asking whether someone can answer a question, I would want to understand whether they believe they are qualified to answer it.
"How confident are you answering this about yourself?"
That could have exposed the weakness in priority weighting before we built multiple iterations of logic around it.
The earlier logic work was not wasted. It created much of the routing infrastructure that the final approach still relied on.
But the key lesson was specific:
Good decision support is not about asking fewer questions. It is about knowing which questions people can answer reliably, and taking responsibility for the rest.