By Brooke Nivens, UX Designer
Customers can tell you what they're trying to accomplish far more reliably than they can tell you how to solve it. That's the difference between a job and a feature. Confuse the two and research goes to waste. The deeper cost is what it does to the designer: build to the request instead of the job, and you've quietly handed away the actual problem-solving. Ask what someone is trying to do, not how they'd fix it, and you stay in a position to solve it yourself.
By the end of this article, you'll have a two-minute way to tell whether your team is chasing features or actually closing the gaps customers are stuck on, using data you already have.
People are good at describing friction, but only when you're asking questions built around the job, not the tool. Ask what someone is trying to accomplish and what the job actually requires, and the friction surfaces on its own. What tool could close that gap is a separate question. You can only answer it once you understand the friction, not before.
Here's a pattern worth watching for: a company builds a feature meant to solve a real problem, tracks low adoption, and assumes the feature failed. Dig into why usage is low, though, and often the job is still getting done, just through other tools. The feature exists. It isn't surfacing what people need fast enough, so they go around it. That context, not usage data alone, is what lets you evaluate how to actually improve the tool rather than assuming the feature itself was the problem.
Take an insurance carrier whose customer service line was flooded with calls just to make a payment. Technically, the job gets done. The customer pays. But sit down with that user and ask about the experience of making that payment, and a different picture shows up: calling in felt faster than whatever the alternative was, or they didn't trust the online option, or they didn't know it existed. Nobody's going to tell you "build us a self-service portal." Ask the right way, and they'll tell you calling in to pay a bill is more trouble than it should be. That's the gap a tool needs to close.
That's where the conversation shifts. It's no longer about whether to add another feature. It's about unnecessary calls into the contact center, longer wait times for customers, and operational costs that keep growing because people can't complete simple tasks on their own.
Which gets at the real question underneath every "we should build this" conversation: is the job important enough, and affecting enough people, that solving it actually matters? Some jobs affect almost everyone, but because people eventually find a workaround, they never seem urgent enough to fix. Those workarounds stick around for years. Not because nobody noticed them, but because "annoying" rarely feels urgent until someone puts a number on what it's actually costing.
Customers and project teams often describe the same problem in completely different ways.
Project team: "We need a better customer portal." Customer: "I couldn't figure out how to update my address, so I called instead."
Those sound like the same problem, but they lead to different solutions and a different approach to building the tool. One starts with technology. The other starts with understanding what people are actually trying to accomplish.
That's one reason we don't treat UX as something separate from CX. If you're already doing real CX work, actually listening to where people get stuck instead of just asking what features they want, you're already uncovering the jobs that matter. They usually reveal themselves.
The hard part is resisting the urge to jump straight to "let's build a feature for that" before you've asked what job is actually going unmet and whether solving it is worth the investment.
That's how we approach UX at CX Pilots. By the time we're discussing interface improvements, we've already spent time understanding where customers struggle, why they struggle, and how often those moments occur. Our UX recommendations grow out of the customer research and CX diagnostics we're already doing, so the design work is driven by evidence instead of assumptions about what people might want or what tool is most trendy.
You don't need a new research study for this. Last month's contact center log is usually enough, and the pattern tends to show up in the first ten rows.
It's a small shift in perspective, but it often changes the conversation from "what should we build next?" to "why are customers having to work this hard in the first place?"
If that exercise surfaces a few opportunities, that's often enough to start a conversation. We typically begin with focused, pilot-sized engagements because we'd rather help teams validate that they've identified the right problem before investing in the solution. If you want a second set of eyes on what the exercise turns up, reach out and we'll walk through it with you.
Good research reveals the right problem before anyone starts designing the solution. Once you've identified the right problem, the right design solution often becomes much clearer.
By Brooke Nivens, UX Designer
Customers can tell you what they're trying to accomplish far more reliably than they can tell you how to solve it. That's the difference between a job and a feature. Confuse the two and research goes to waste. The deeper cost is what it does to the designer: build to the request instead of the job, and you've quietly handed away the actual problem-solving. Ask what someone is trying to do, not how they'd fix it, and you stay in a position to solve it yourself.
By the end of this article, you'll have a two-minute way to tell whether your team is chasing features or actually closing the gaps customers are stuck on, using data you already have.
People are good at describing friction, but only when you're asking questions built around the job, not the tool. Ask what someone is trying to accomplish and what the job actually requires, and the friction surfaces on its own. What tool could close that gap is a separate question. You can only answer it once you understand the friction, not before.
Here's a pattern worth watching for: a company builds a feature meant to solve a real problem, tracks low adoption, and assumes the feature failed. Dig into why usage is low, though, and often the job is still getting done, just through other tools. The feature exists. It isn't surfacing what people need fast enough, so they go around it. That context, not usage data alone, is what lets you evaluate how to actually improve the tool rather than assuming the feature itself was the problem.
Take an insurance carrier whose customer service line was flooded with calls just to make a payment. Technically, the job gets done. The customer pays. But sit down with that user and ask about the experience of making that payment, and a different picture shows up: calling in felt faster than whatever the alternative was, or they didn't trust the online option, or they didn't know it existed. Nobody's going to tell you "build us a self-service portal." Ask the right way, and they'll tell you calling in to pay a bill is more trouble than it should be. That's the gap a tool needs to close.
That's where the conversation shifts. It's no longer about whether to add another feature. It's about unnecessary calls into the contact center, longer wait times for customers, and operational costs that keep growing because people can't complete simple tasks on their own.
Which gets at the real question underneath every "we should build this" conversation: is the job important enough, and affecting enough people, that solving it actually matters? Some jobs affect almost everyone, but because people eventually find a workaround, they never seem urgent enough to fix. Those workarounds stick around for years. Not because nobody noticed them, but because "annoying" rarely feels urgent until someone puts a number on what it's actually costing.
Customers and project teams often describe the same problem in completely different ways.
Project team: "We need a better customer portal." Customer: "I couldn't figure out how to update my address, so I called instead."
Those sound like the same problem, but they lead to different solutions and a different approach to building the tool. One starts with technology. The other starts with understanding what people are actually trying to accomplish.
That's one reason we don't treat UX as something separate from CX. If you're already doing real CX work, actually listening to where people get stuck instead of just asking what features they want, you're already uncovering the jobs that matter. They usually reveal themselves.
The hard part is resisting the urge to jump straight to "let's build a feature for that" before you've asked what job is actually going unmet and whether solving it is worth the investment.
That's how we approach UX at CX Pilots. By the time we're discussing interface improvements, we've already spent time understanding where customers struggle, why they struggle, and how often those moments occur. Our UX recommendations grow out of the customer research and CX diagnostics we're already doing, so the design work is driven by evidence instead of assumptions about what people might want or what tool is most trendy.
You don't need a new research study for this. Last month's contact center log is usually enough, and the pattern tends to show up in the first ten rows.
It's a small shift in perspective, but it often changes the conversation from "what should we build next?" to "why are customers having to work this hard in the first place?"
If that exercise surfaces a few opportunities, that's often enough to start a conversation. We typically begin with focused, pilot-sized engagements because we'd rather help teams validate that they've identified the right problem before investing in the solution. If you want a second set of eyes on what the exercise turns up, reach out and we'll walk through it with you.
Good research reveals the right problem before anyone starts designing the solution. Once you've identified the right problem, the right design solution often becomes much clearer.
