What a Behavioural Concept Test Reveals That a Prototype Test Cannot

Teams building new products face a reliable fork in the road. On one side sits the behavioural concept test, which asks whether a product idea is worth building and whether it connects with the people it is meant to serve. On the other sits the prototype test, which asks whether a partly built thing works. Both are research. Both involve real users. But they answer fundamentally different questions, and running the wrong one at the wrong time is one of the most consistent ways we see product budgets spent on the right kind of learning at entirely the wrong moment.

The distinction matters because the order is not arbitrary. A prototype test assumes something worth building already exists. A behavioural concept test examines whether it does. Running usability testing before that foundational question is settled produces detailed, actionable findings about a product that might be solving the wrong problem, using the wrong emotional register, or positioned in a way that users will never find compelling enough to stay.

The Emotional State Problem

We have found that the gap between a test environment and a real-world moment of use is most visible in any scenario involving trust or financial commitment. In a usability session, users reviewing a checkout flow or a data-usage disclosure assess it rationally, because they are not actually parting with money. Live analytics then tell a different story: when the transaction is real, even a small element that looked fine in testing can erode enough trust to cause someone to abandon the flow entirely. The emotional state of a real moment of commitment is simply not reproducible in a prototype test.

Prototype testing has a boundary, and knowing that boundary is what allows you to use it well.

Why Emotional Attention Must Be Validated Before Usability

The case for running concept testing before prototype testing comes down to sequence logic. If users do not feel that a product is for them, they will not stay long enough for usability to matter. No amount of clear navigation or frictionless onboarding rescues a product that users do not feel connected to at the level of need and desire.

Emotional attention is the condition under which all usability decisions become consequential. When we design for how users feel, rather than only for what they do, every micro-interaction and piece of copy earns a reason to exist. Colours, transitions, the language of a confirmation screen, and the sequence of steps in an onboarding flow all carry emotional weight, but that weight only compounds correctly if the foundational emotional case for the product was validated first.

Think about what happens in the first few seconds of a new app. Users enter an orientation phase where they are trying to understand what space they are in, what the product does, and what they should do next. If those questions are not answered quickly through clear visual hierarchy, anxiety creeps in. But before that moment, there is an earlier threshold: the user deciding whether to open the app at all, whether to persist through a slow loading state, whether to give it their real attention. That decision is emotional and conceptual, not usability-based, and it is what concept testing examines.

Run your concept test before you have built anything substantial. The less you have invested in execution, the easier it is to act on what you find without the sunk-cost pull to defend what is already built.

The Cost of Skipping Concept Testing

Skipping concept testing is a bet that the idea is right, placed before the evidence exists to support it. According to G2, approximately 30,000 new products launch annually, with failure rates of 30 to 40% even for products that reach market. A meaningful proportion of those failures are products that were usable but unwanted, competently built around a proposition that users never emotionally engaged with.

The cost compounds over time. Engineers spend significant time fixing problems that surface late in development, problems that could have been identified and resolved earlier. When the foundational question of whether the emotional proposition works is never asked, those late-stage fixes address symptoms rather than causes. A product gets refined and polished in a direction users were never going to travel.

Feature Mapping Is Not Validation

We see founders in particular gravitate toward competitive feature mapping rather than user research. A spreadsheet of competitor capabilities provides something tangible and unchallenging to act on. It validates existing opinions without risking contradiction. The underlying concern, which Simon articulates directly, is that user research might reveal the idea is wrong or that nobody wants the product. Concept testing is what resolves that concern before the cost of being wrong becomes structural. Avoiding it does not make the risk go away. It defers it until the point where acting on it is much harder.

Feature Parity Is Not Enough: Why Context and Emotion Drive Adoption

There is substantial research showing that matching or exceeding a competitor's feature set does not, by itself, drive adoption. What matters is how users feel about a product in the specific context in which they encounter it, and whether the product speaks to the emotional state they are actually in at that moment. A feature that works in one context cannot simply be transplanted into a different scenario and expected to perform the same way.

This is a point about emotional fit, and it is what app user research in the form of concept testing is designed to surface. When we test a concept behaviourally, we are not asking users to evaluate features. We are placing the idea in the context of their real lives, their existing habits, their frustrations and their goals, and watching whether it connects. The answer to that question cannot be inferred from a feature comparison.

The Investor Alignment Gap

We worked with a pre-investment client whose investor conversations were thorough on technology, market size, and marketing, but never touched on how the product would feel or what user retention looked like. The silence was read as approval. What it actually indicated was that investors had not grasped the emotional dimension of the product at all. We had to go substantially deeper on the emotional case for the product rather than accepting the absence of questions as confirmation. Concept testing would have given that team the language and the evidence to make that case clearly, before the gap became visible in a funding conversation.

When investors stop asking questions, do not read that as alignment. Ask directly whether they understand how users will feel about the product, and what will make them return.

How to Run a Behavioural Concept Test

A behavioural concept test works with stimuli that represent the idea without requiring a functioning product. That might be a visual proposition, a short narrative description, a static mockup, or a combination. The goal is to show enough of the concept for users to form a genuine emotional response, without testing usability, which is a different exercise entirely.

Participant selection matters more than volume. According to Nielsen Norman Group, testing with around five users is sufficient to surface the core patterns in qualitative research, because after that point you are largely seeing the same responses repeated. What matters is that those five users represent the actual target group, not a convenient approximation of it.

What to Look For

The structure of a behavioural concept test follows a clear sequence.

1. Establish the emotional context the user brings to the category before showing them anything.
2. Introduce the concept and observe immediate reactions: what they notice first, what draws them in, what creates hesitation.
3. Explore the emotional dimension: does this feel relevant to their life, and does it connect to something they actually feel?
4. Test the value proposition: can they articulate what this product would do for them, and does that match what you intend?
5. Assess motivation to use: not stated preference, but genuine expressed desire to try the product in a real context.

The debrief after the sessions should map responses against the emotional problem the product is designed to solve, not against the features it contains. If users cannot identify the emotional problem the product addresses, the concept needs work before any prototype is built.

How Concept Test Findings Should Shape What Gets Prototyped

Concept test findings do not just tell you whether to proceed. They tell you what to prototype, which is a different and more useful output. When users respond strongly to a particular aspect of the proposition, that is the thing the prototype needs to deliver clearly. When they express confusion about the value or hesitate at a specific moment, those are the design problems the prototype must solve.

This is the practical link between the two methods. Concept testing identifies the emotional territory the product must occupy. Prototype testing then checks whether the execution actually occupies it. Without concept testing upstream, prototype testing proceeds without a clear definition of what success looks like emotionally, and that makes its findings harder to act on.

Prioritising What Gets Built

We run a debrief process after concept testing that maps findings against business value and user uptake potential, then applies an effort-versus-impact lens to determine what gets built first, what gets deferred, and what gets dropped. This process only works if the concept test has generated clear signal about which aspects of the proposition users actually respond to emotionally. When concept testing is skipped, that prioritisation becomes opinion rather than evidence, and the prototype ends up testing execution assumptions that were never grounded in validated emotional need.

After concept testing, list the three things users responded to most strongly and make sure the first prototype makes all three immediately apparent. If any of them take more than a few seconds to find, the prototype has not served the concept.

When to Use Each Method, and in What Order

The sequencing question has a clear answer, and it follows from what each method measures. Concept testing comes first because it validates the emotional proposition before any investment in execution. Prototype testing comes second because it examines whether the execution delivers on the proposition that concept testing confirmed.

Some teams use both in an iterative cycle, returning to concept-level questions when prototype testing reveals that users are completing tasks but not returning, which is a signal that the emotional proposition was not fully resolved the first time. The two methods inform each other over a product's development, but the first pass must begin with the concept before the prototype exists.

Conclusion

The distinction between a behavioural concept test and a prototype test is not a methodological footnote. It reflects a fundamental difference in what you are trying to find out and when you need to find it. Concept testing asks whether the emotional case for a product holds up with real users before anything is built. Prototype testing asks whether the built thing is navigable and clear. Running them in the wrong order, or treating one as a substitute for the other, produces confident findings about the wrong question.

Getting the sequence right means arriving at prototype testing with validated emotional foundations. The usability questions become easier to answer because you already know what the product needs to make users feel, and you can check whether it does. Without that foundation, even a well-run prototype test is measuring execution against an undefined standard.

Product decisions made without concept testing rest on assumptions about emotional fit that may never have been tested. Those assumptions compound through every sprint, every design decision, and every piece of copy, until a product launches into a market that was never emotionally reached in the first place. The research exists to prevent that outcome, and using it in the right order is what makes it work.

Let's talk about your concept testing approach and make sure you are asking the right questions before the build begins.

Frequently Asked Questions