Why B2B UX features fail
The one question you always need to keep in mind for B2B projects
Photo by Bujar Islamaj: https://www.pexels.com/photo/people-standing-around-sunken-suv-in-water-15630993/
Imagine you followed all the right steps, and users still didn’t use the product.
You talked to users. You ran the research. Created prototypes, did user testing and iteration, and shipped a solution you thought might genuinely solve the problem.
But then it launches, and six weeks later, nothing’s changed. When you go back to find out why, you discover the workaround: a word-of-mouth process, an unofficial channel, a habit so ingrained that nobody thought to mention it.
Nobody hid this from you. It just never came up — because you asked about the feature and they answered about it. The workaround was so normal to them it didn’t register as something worth mentioning.
This isn’t a research failure. It’s the question that was never asked:
How are users currently seeking help with this?
If you’re working in B2B design, this is one of the most important questions you can make a habit of asking.
What “Seeking Help” Actually Looks Like in B2B
This is a more common problem in B2B environments, because employees don’t choose their tools: they’re required to use them. When software is mandatory but confusing, users can’t give up. So they build structures around it.
It’s rarely dramatic. It’s usually friction that people have quietly learned to absorb.
Someone hits a wall and pings the one colleague who’s been on the product longest. That person answers again and loses twenty minutes. The knowledge lives in their head, not the product.
Or there’s a shared doc somewhere. A “how we do things” guide that was accurate eighteen months ago. Users find it, half-trust it, and proceed anyway because it’s better than nothing.
Or they follow a workaround their manager taught them in their first week: a sequence of steps that gets the job done without ever understanding why it works.
None of this shows up in your analytics as help-seeking behavior. The only things that show up are delays, lower productivity, and flat adoption of whatever you just shipped.
There’s another wrinkle: users often won’t volunteer this information. Partly because the workaround feels normal to them. But partly because they’re not sure they’re supposed to be using it.
If there’s any ambiguity about whether a shortcut reflects negatively on them (or if they’re breaking the law), users will answer your questions about the feature without ever mentioning the thing they actually do.
You have to go looking.
This is critical data that doesn’t show up on a dashboard
Workarounds don’t appear in dashboards, but they’re as real as any funnel metric, and often more informative. They tell you what users need badly enough to solve on their own, what they trust, and what bar any new feature has to clear.
As one designer, who worked in hospitality management, told me:
“I often get stuck with solutions. Even when I might have a better solution, users resist it because they’ve spent years building trust and familiarity in a 30 year old system.” — Senior UX Designer
That’s what asking about current help actually surfaces. Not more dashboard data: the data that exists outside it. And without it, you’re designing against a bar you can’t see.
Once you can see it, two things get easier.
You know what to prioritize. Most B2B roadmaps include features and requirements. Asking about help tells you which ones are load-bearing (i.e. the primary drivers that determine whether users actually switch) vs requirements that are nice to have.
You have a stakeholder conversation instead of a design opinion. “Users are currently solving this by asking one person, who’s spending eight hours a week fielding the same questions,” lands differently than “I think we need better onboarding.”
They might involve the same exact design idea or solution. But when you can speak directly to the cost of the current workaround — in time, in productivity, in risk — you’re not asking stakeholders to trust your design judgment.
You’re showing them what the problem is actually worth solving.
How to Actually Use It
You don’t need a formal research plan. You need to know which version of the question fits where you are in the project — and then go ask it.
Discovery — before anything is defined
This is where the question does the most work. You’re not asking about the feature yet. You’re asking about the behavior that exists without it.
Walk me through what you do when you get stuck on [task].
Who do you go to when you can’t figure something out?
Is there a doc, a channel, a person, or a process you rely on that isn’t officially part of the product?
How long has that been the way you handle it?
What you’re building here is a map of the existing help infrastructure, the one your feature will have to displace or absorb.
Design iteration — mid-project, active wireframing
Now you’re testing whether your design actually closes the gap you found in discovery.
The question shifts from “what do you do” to “would this change what you do.”
If you hit this situation and the new feature was available, what would make you use it instead of [the workaround]?
What would have to be true about this for you to trust it the first time?
Is there anything here that would make you go back to [the old way] instead?
This is where you find out whether you’ve actually earned the switch—or just designed something that coexists with the workaround.
Pre-launch / stakeholder alignment
You’re not asking users here: you’re translating what you found into language that moves prioritization decisions.
Here’s the current behavior: [X]. Here’s what it costs: [time, errors, dependency on one person]. Here’s what our feature needs to do to replace it: [Y]. Here’s what’s currently missing from the roadmap to get there.
It’s more about reframing a solution instead of asking a question.
But it comes directly from asking the question earlier, and it’s what turns user research into a prioritization argument rather than a design recommendation.
Post-launch / adoption troubleshooting
If adoption is flat, the workaround will probably work. The question now is which one and why.
What do you do now when you need to [task] — are you using the new feature, or something else?
When did you last use [the new feature]? What made you use it then?
What would have to change about it for it to become your default?
The answer will almost always point back to something the workaround still offers that the feature doesn’t. Which is fixable — but only once you know what it is.
One Question. Every Project.
Sometimes B2B projects fail, not because of craft. The interface might be clean. The team was aligned. The solution was ‘technically good’.
What was missing was an understanding of what users were doing before the feature existed — and what it would actually take to make them stop.
That’s what this question gives you. By getting in the habit of asking this, at every stage of the project, you can always keep track of the user workarounds.
The workaround is always there. Someone built it, someone taught it, and someone is using it right now instead of whatever you shipped. The only question is whether you found it first, and if your design can replace it.
Kai Wong is a Design Educator and author of the Data and Design Newsletter. He teaches a course, Data Informed Design: How to Pitch Why Your Work Matters, on how to explain why your design work matters to businesses.