Every designer knows the cliché attributed to Henry Ford: "If I had asked people what they wanted, they would have said faster horses." Ford probably never said it. The line survives because it flatters us. Read it again, though, and the customers got it right: they told him the need was getting somewhere faster. The mistake would have been building the horse.
Ask a customer whether they want a feature and they'll usually say yes. That answer tells you almost nothing about what to build.
One of the most expensive research mistakes we've seen is asking customers to approve a feature the product team has already decided to build. "Would you use an online document center?" will often yield a "yes". Participants want to be helpful, it costs them nothing to endorse a hypothetical, and the question hands them the answer. The team logs the yes as validation, the feature moves up the backlog, and the problem the customer was trying to solve never enters the room.
The danger is that leading questions produce findings that look conclusive. A string of yeses reads like demand in a readout, so the feature gets funded on evidence that never tested whether the underlying problem exists. Research that holds up starts with the task the customer is trying to complete, and it anchors every question in an experience they've had:
Before the next round of interviews, run the discussion guide through three tests.
A question that fails any of these produces confirmation, and confirmation can look identical to validation in a readout. One more signal shows up after the fact: findings that line up neatly with the existing backlog deserve a second look.
Product teams and customers routinely describe the same problem in ways that point toward very different work.
Product team: "We need a better customer portal."
Customer: "I couldn't figure out how to update my address, so I called."
The first framing starts with a platform and invites a scope, a vendor, and a multi-quarter roadmap. The second starts with a task and a failure point, which means it can be measured, ranked against other failure points, and often fixed at a fraction of the cost. Research is how you translate the first sentence into the second before the budget gets committed.
Workarounds are some of the most useful evidence research produces. They're also easy to miss, because nothing looks broken: the task gets done, the metrics stay quiet, and nobody files a complaint. The customer finished it by email, through an agent, or over the phone. Walking through the steps someone took is what brings those detours to the surface.
Consider a carrier whose contact center fields a steady volume of calls from policyholders who want to make a payment. On paper the task is complete. Many of those policyholders won't tell you in an interview that they need a redesigned billing experience. Ask them to describe the last time they paid their bill, though, and the gaps appear: calling felt faster, they didn't trust the portal with their bank details, or they didn't know self-service payment existed.
That's where the conversation leaves the design team's vocabulary and enters the CFO's: avoidable call volume, longer queues for complex servicing needs, and cost-to-serve that climbs because simple tasks can't be completed digitally. The question becomes whether the task is frequent and important enough to move a number someone is accountable for. The most expensive tasks can be the ones that nobody escalates, because many customers have a workaround, and friction stays an annoyance until someone attaches a cost to it.
To help in product prioritization, consider scoring each task on four dimensions:
Add the four scores. The highest totals are the tasks worth solving for, and a task with an easy workaround can still land near the top when reach, frequency, and cost run high.
This is why CX Pilots treats UX as an extension of our CX practice. A voice-of-customer program built to listen for where people get stuck already shows you which tasks break down. The ones that matter surface in complaint themes, call drivers, and abandonment points.
The discipline lies in holding off on "let's build a feature for that" until two questions have answers: which task customers can't complete, and is solving it worth the investment.
By the time our engagements reach interface recommendations, we've already mapped where customers struggle, why, and how often. The design work inherits that evidence base, so every recommendation arrives with a rationale you can take to your leadership team and defend.
Before your next round of research, look at what your contact center already knows. Last month's call-driver report may not tell you why customers are struggling, but it will tell you where to look.
Call data shows you what customers do. It can't show you why they do it, or which fix would change it. That's the question research has to answer, and it's where a well-built interview guide earns its keep.
If the exercise surfaces a few tasks worth a closer look, our UX Starter Bundle is built for that moment. In 4 to 6 weeks, we run an expert review of your digital experience, benchmark it against your industry, and interview up to five of your customers. You come away with prioritized recommendations and the evidence leadership needs before approving a design budget.
Good research names the right problem before anyone opens a design file. Once it's named, the design direction tends to follow.
Every designer knows the cliché attributed to Henry Ford: "If I had asked people what they wanted, they would have said faster horses." Ford probably never said it. The line survives because it flatters us. Read it again, though, and the customers got it right: they told him the need was getting somewhere faster. The mistake would have been building the horse.
Ask a customer whether they want a feature and they'll usually say yes. That answer tells you almost nothing about what to build.
One of the most expensive research mistakes we've seen is asking customers to approve a feature the product team has already decided to build. "Would you use an online document center?" will often yield a "yes". Participants want to be helpful, it costs them nothing to endorse a hypothetical, and the question hands them the answer. The team logs the yes as validation, the feature moves up the backlog, and the problem the customer was trying to solve never enters the room.
The danger is that leading questions produce findings that look conclusive. A string of yeses reads like demand in a readout, so the feature gets funded on evidence that never tested whether the underlying problem exists. Research that holds up starts with the task the customer is trying to complete, and it anchors every question in an experience they've had:
Before the next round of interviews, run the discussion guide through three tests.
A question that fails any of these produces confirmation, and confirmation can look identical to validation in a readout. One more signal shows up after the fact: findings that line up neatly with the existing backlog deserve a second look.
Product teams and customers routinely describe the same problem in ways that point toward very different work.
Product team: "We need a better customer portal."
Customer: "I couldn't figure out how to update my address, so I called."
The first framing starts with a platform and invites a scope, a vendor, and a multi-quarter roadmap. The second starts with a task and a failure point, which means it can be measured, ranked against other failure points, and often fixed at a fraction of the cost. Research is how you translate the first sentence into the second before the budget gets committed.
Workarounds are some of the most useful evidence research produces. They're also easy to miss, because nothing looks broken: the task gets done, the metrics stay quiet, and nobody files a complaint. The customer finished it by email, through an agent, or over the phone. Walking through the steps someone took is what brings those detours to the surface.
Consider a carrier whose contact center fields a steady volume of calls from policyholders who want to make a payment. On paper the task is complete. Many of those policyholders won't tell you in an interview that they need a redesigned billing experience. Ask them to describe the last time they paid their bill, though, and the gaps appear: calling felt faster, they didn't trust the portal with their bank details, or they didn't know self-service payment existed.
That's where the conversation leaves the design team's vocabulary and enters the CFO's: avoidable call volume, longer queues for complex servicing needs, and cost-to-serve that climbs because simple tasks can't be completed digitally. The question becomes whether the task is frequent and important enough to move a number someone is accountable for. The most expensive tasks can be the ones that nobody escalates, because many customers have a workaround, and friction stays an annoyance until someone attaches a cost to it.
To help in product prioritization, consider scoring each task on four dimensions:
Add the four scores. The highest totals are the tasks worth solving for, and a task with an easy workaround can still land near the top when reach, frequency, and cost run high.
This is why CX Pilots treats UX as an extension of our CX practice. A voice-of-customer program built to listen for where people get stuck already shows you which tasks break down. The ones that matter surface in complaint themes, call drivers, and abandonment points.
The discipline lies in holding off on "let's build a feature for that" until two questions have answers: which task customers can't complete, and is solving it worth the investment.
By the time our engagements reach interface recommendations, we've already mapped where customers struggle, why, and how often. The design work inherits that evidence base, so every recommendation arrives with a rationale you can take to your leadership team and defend.
Before your next round of research, look at what your contact center already knows. Last month's call-driver report may not tell you why customers are struggling, but it will tell you where to look.
Call data shows you what customers do. It can't show you why they do it, or which fix would change it. That's the question research has to answer, and it's where a well-built interview guide earns its keep.
If the exercise surfaces a few tasks worth a closer look, our UX Starter Bundle is built for that moment. In 4 to 6 weeks, we run an expert review of your digital experience, benchmark it against your industry, and interview up to five of your customers. You come away with prioritized recommendations and the evidence leadership needs before approving a design budget.
Good research names the right problem before anyone opens a design file. Once it's named, the design direction tends to follow.
