Why Your AI Project Needs User Research Before It Needs a Model
Before building an AI feature, understand the people, workflows, and problems you’re actually designing for.
The corporate world expects rapid integration, and the pace of enterprise AI adoption reflects it. Neuron’s 2025 UX Trends Report found that 95% of U.S. companies now use generative AI. However, a paradox lurks within that speed: 74% of those organizations struggle to achieve measurable value from their chosen tools.
That disconnect reflects less on the state of AI models and far more on how B2B teams implement them.
Most AI project playbooks begin with vendor evaluation, feature scoping, or model evaluation. IF user research happens at all, it’s essentially a validation step after a working prototype already exists.
That order is backward. Understanding what users actually need is more likely to determine whether an AI project succeeds than the technology itself. That’s why user research should happen at the beginning of the project, before teams decide what to build or which technology to use.
Why Product Discovery Suffers in the AI Race
The competitive urgency to ship AI products cultivates increasing pressure in businesses to rush from ideation to development without a discovery phase. For many companies, taking the time to conduct user research feels like an unjustifiable delay.
Part of the problem is that many teams conflate model complexity with product complexity, spending the bulk of their cognitive budget on architectural decisions rather than solving user pain points. This is how teams spend months fine-tuning a feature only to discover at rollout that their users never wanted it.
A persistent (and perplexing) misconception is that AI’s novelty obviates the need for normal product discovery. You can’t research something your users haven’t experienced before, many companies reason. That presumption is blatantly false; there are research methods designed to do exactly that:
Studying current workarounds
Mapping broken workflows
Testing low-fidelity concepts
Focusing on the user’s actual goals
Foregoing user testing frequently results in demos that are technically impressive but fail when dropped into real workflows.
What User Research Reveals That Technical Scoping Misses
In rushed product development, there’s a chasm between the actual problem and the assumed one. Technical scoping can tell you what a system needs to do, but it can’t tell you whether you’re solving the right problem. It’s surprisingly common for a team to solve a problem the customer isn’t even experiencing.
With AI, the cost of that misalignment is higher. Course-correcting requires more than tweaking a few lines of code: dismantling deeply embedded architecture, retraining models, rebuilding data pipelines, and hemorrhaging time and capital.
The McDonald’s AI Catastrophe
McDonald’s learned this the hard way, in the public eye. In 2021, the company piloted an IBM-built AI voice-ordering system at more than 100 drive-thru locations. The intention was to streamline operations with automation. The results were something else entirely.
The system’s accuracy hovered in the 80% range. Viral clips showed the system behaving in unexpected ways: incrementally adding 260 chicken nuggets to an order, ringing a customer up for nine iced teas instead of one, and topping ice cream with bacon. By mid-2024, the company announced the end of its partnership with IBM.
McDonald’s and IBM conducted extensive user research over three years in a lab setting. They didn’t conduct real-world research to determine whether the system could handle regional dialects, phrasing variations, or the acoustic chaos of a drive-thru lane.
Lessons Learned
Testing with real users in real drive-thru lanes would likely have surfaced these issues well before launch. That research reveals something that technical scoping alone can’t: what users actually expect from AI.
People have preconceptions about what AI technology can and can’t do. Untested, those expectations can become product assumptions. Research can uncover those expectations before they become baked into the architecture.
It also demonstrates how much automation users will accept, which varies dramatically depending on context, user, and stakes. A patient interacting with a clinical system has a different tolerance for AI mistakes than an employee using an internal analytics tool or an online shopper receiving product recommendations. Designing around the wrong trust level undermines adoption even when the technology works as intended.
There are also edge cases to consider: strange phrasing, unusual requests, unexpected self-corrections, and failure scenarios that rarely appear in a controlled demo. Real users bring those situations to the surface. Without research, you may discover them only after launch, when correcting them is much costlier.
All Products Have Different Research Questions
With traditional software, you ask users if the program works. With AI, the question is more about how the product feels than how it performs. Those are two different research questions, and they require different methods.
This is because AI introduces a layer of uncertainty that non-automated software generally doesn’t. Users need to know when the system might be wrong, when they should verify an output, and what they can do when it whiffs the ball. Research can determine how much guidance users need in a particular context, rather than forcing every AI into the same warnings, explanations, and confirmation steps.
Explainability also differs between users and domains. What one considers a useful explanation, another may find superfluous. A data analyst might need to understand why a model flagged a specific result, while a frontline worker may simply need to know what to do next. Research identifies which user you’re designing for and, from there, reveals what that user needs to understand in order to trust the system and use it appropriately.
Failure Looks Different With AI
Research exposes how users respond when AI gets something wrong. In traditional software, bugs tend to feel like isolated technical problems: A button doesn’t work, a page fails to load, or a calculation produces the wrong result. With AI, a bad output can feel catastrophic; if the system confidently provides incorrect information, the user may question the reliability of the entire product rather than treating the mistake as a one-off glitch.
This is what makes feedback mechanisms vitally important. Users need to know how to correct an output, provide feedback, or take the reins when the system reaches its limit. However, what forms those mechanisms should take depends on the product, the user, and the stakes involved. Research can identify where users lose confidence, what they need when that occurs, and how the product can provide a path forward without wresting control out of their hands.
AI doesn’t require an entirely new approach to user research. It requires asking questions specific to a product that can make decisions, generate information, and be wrong in ways users may not anticipate. Before you choose a model or design a UX interface, you need to understand what your users need from the system when things go right — and when they don’t.
What Pre-Build AI Research Looks Like in Practice
Pre-build research doesn’t need to entail a six-month study with dozens of participants. Instead, you need structured discovery designed to reduce the risk of building the wrong product, and it needs to occur before you train a single model. The goal is to establish what problem you’re solving, what users expect from an AI system, and where and when they’re willing to relinquish control.
Four research methods can answer those questions: problem-framing interviews, mental model mapping, Wizard of Oz (or concept) testing, and trust threshold assessment.
1. Problem-Framing Interviews
Understand how users currently handle the task, when the workflow stops working, what workarounds they’ve devised, and what takes the most time. Don’t even mention AI yet. Let the problem and potential solutions surface organically rather than as a response to a proposed solution.
2. Mental Model Mapping
Determine what users expect AI to do in this specific context. Where do they trust it? Where does it make them nervous? How much autonomy are they comfortable giving it? The answers will differ across products, even when the underlying technology is the same.
For example, a user might gladly allow AI to summarize a document but balk at letting it send an email on their behalf. Every user’s trust threshold will be different.
3. Wizard of Oz (Concept) Testing
Simulate the proposed AI experience with a human behind the curtain. During this testing, users interact with what appears to be an AI-powered feature while a researcher or team member manually produces the responses behind the scenes. Using this method, you can test whether people actually want the AI experience, what they expect from it, and where, if anywhere, the interaction falls apart.
The best part is getting those questions answered without spending months building a model first.
4. Trust Threshold Assessment
Map the autonomy spectrum for your use case, observing how much control users are willing to give the system and what conditions the system must meet before they’ll surrender control. Users don’t necessarily need an AI system to be perfect before they’ll use it, but they do need to feel confident about when to trust an output, when to verify it, and when the system should return control to them.
The result is more than a design note; it’s a model requirement: The AI must reach a defined level of confidence or accuracy before it can act without user confirmation.
From Research to Model Requirements
This phase results in a validated problem statement, an understanding of the user’s trust floor, and a requirements specification that any model you choose must meet. Instead of first asking which model you should use, you can ask the much more useful question: What does the model need to be capable of for your product to work?
Making the Case Internally
You’re probably already dreading the objection you know you’ll face again and again: We need to move faster. On the surface, adding a research phase sounds like a deliberate impediment to speed.
AI projects, however, have more moving parts than traditional software. Clutch’s 2026 research on AI maturity among small businesses found that while 59% of SMBs already using AI qualify as “leaders,” only 54% have a formal AI strategy. That suggests adoption alone isn’t the same as having a solid plan for how and when your organization will use AI.
When a post-launch discovery forces a team to rethink an AI product, changing an interface or rewriting a feature may not be enough. You may also need to change the model, training data, prompts, and workflows along with that interface or feature. In a situation like this, what looked like a shortcut at the beginning — skipping research — becomes months of expensive rework and an even longer delay.
Instead of framing research as a delay before the “real” work begins, position it as a model requirement specification. When you enter the build with a known problem, a validated user expectation, and a defined trust threshold, model selection becomes more focused. Knowing the capabilities you need and the performance level the product requires can actually hasten the technical work.
Explain research as a risk reduction, not dead time. A two-week discovery phase that prevents months of rework and potentially astronomical costs isn’t a tradeoff; it’s part of the project.
Start With the Problem (Not the Model)
The teams that experience the most successful AI outcomes aren’t those that ship the fastest but those that understand the problem before they start building — and recognize user research as a prerequisite rather than an afterthought.
As AI tooling becomes faster and less expensive, access to increasingly capable models will become less of a differentiator. The longer-lasting competitive edge is knowing exactly what your users need and how AI will genuinely solve their problem.
That knowledge doesn’t come from choosing the better model. It comes from asking the right questions before you start building.
That’s the thinking behind Neuron’s UX Design for AI-Driven Products & Intelligent Interfaces: putting the user’s needs and expectations at the center of AI product decisions from day zero.
About Us
Neuron is the leading San Francisco–based UX/UI design agency specializing in product strategy, user experience design, and DesignOps consulting. We help enterprises elevate digital products and streamline processes.
With nearly a decade of experience in SaaS, healthcare, AI, finance, and logistics, we partner with businesses to improve functionality, usability, and execution, crafting solutions that drive growth, enhance efficiency, and deliver lasting value.
Want to learn more about what we do or how we approach UX design? Reach out to our team or browse our knowledge base for UX/UI tips.
