CONCEPT DESIGN PROTOTYPE BUILD LAUNCH CONCEPT TESTING happens here testing here: inexpensive testing here: expensive concept-testing · validate before you design · cheap questions now · expensive answers later

Concept Testing

Show the idea before you build it — and find out if users actually want what you think they want.

User Research Concept Validation Product Discovery Desirability Testing Early-Stage Research Idea Validation

Two sentences.

Concept Testing is a user research method in which a proposed product concept — expressed as a description, a storyboard, a mock advertisement, a rough sketch, or a low-fidelity mockup — is presented to representative users before the product is built, with the goal of determining whether users understand the concept, find it desirable, see themselves using it, and interpret it in the way the design team intended. For product teams, Concept Testing addresses the most costly failure mode in product development — building something users do not want or do not understand — by surfacing desirability and comprehension problems at the stage where they are cheapest to address: before any engineering investment has been made and before the design has progressed beyond the conceptual stage.

The method is distinct from usability testing in its focus and its stimulus: usability testing evaluates how well users can accomplish tasks with an existing or prototype interface; Concept Testing evaluates whether users want the thing the interface enables, whether they understand what it does, and whether the value proposition is clear. The stimulus in Concept Testing is intentionally low-fidelity — sketches, descriptions, storyboards, or concept boards — because high fidelity would invite users to focus on interface details rather than on the core question of whether the concept serves a real need they have. The deliberate rough quality of the stimulus signals to users that the idea is still being formed and that their input can genuinely influence the direction, which produces more candid and more actionable feedback than testing a polished prototype.

Apply this when…

A product team has one or more concepts for a new product or feature and needs to understand which resonates most strongly with target users before committing to detailed design and development
The team disagrees internally about which direction to pursue and needs user evidence to break the deadlock rather than continuing internal debate
A concept has been developed based on assumed user needs and the team needs to verify that the assumption is accurate before investing further
The value proposition of a concept is unclear — concept testing evaluates whether users understand what the product does and why it would be valuable to them, the most critical question before design investment
Multiple user segments are being considered and the team needs to understand which segment finds the concept most relevant
A concept has been developed in response to a user problem and the team needs to verify that users recognise the problem and find the proposed solution approach relevant

When NOT to apply it

Skip it when the team needs to evaluate usability of an interaction — concept testing evaluates desirability and comprehension; usability testing evaluates task completion and interaction quality. Skip it when the concept is already committed to and the question is implementation — if the business has already decided to build, concept testing adds delay without changing the outcome. Skip it when the concept is too abstract or too early-stage to be communicable to users — if the team cannot articulate the concept clearly enough to show it to users, the concept needs more internal development before it is ready for testing.

The mechanism

Concept Testing works by separating the desirability question ("do users want this?") from the usability question ("can users accomplish tasks with this?") and answering the desirability question first, when it is cheapest to answer. The method creates a controlled situation in which users encounter the concept with minimal bias from working functionality or high-fidelity design, producing feedback about whether the core concept resonates before the team has invested in the implementation details that usability testing would evaluate.

01
The underlying practice — concept boards, storyboards, and the RITE method
Concept Testing draws from multiple research traditions. The concept board approach — presenting a product concept as a visual description combining imagery and copy, similar to an advertisement — comes from market research and consumer products testing, where concept boards have been used since the mid-twentieth century to test new product ideas before manufacturing investment. The storyboard approach — presenting a concept as a sequence of illustrated scenarios showing a user encountering a problem and using the product to solve it — comes from film and animation pre-production adapted to UX research. The Rapid Iterative Testing and Evaluation (RITE) method, developed at Microsoft, combines concept testing with rapid iteration — testing a concept, identifying the most significant comprehension problem, fixing it, and testing again, sometimes within the same research day.
02
What it means in practice — four concept testing approaches
Concept Testing is conducted through four primary approaches depending on the concept's maturity and the questions being asked. Description testing presents the concept as a written or verbal description and evaluates whether users understand it and find it relevant — useful for the earliest-stage concepts where even visual representation would be premature. Concept board testing presents the concept as a visual description (image plus copy) and evaluates desirability and value proposition clarity — the standard approach for new product and feature concepts. Storyboard testing presents the concept as a sequence of illustrated scenarios and evaluates whether users recognise the problem being solved and find the solution approach relevant. Comparative testing presents multiple concepts simultaneously and evaluates which resonates most strongly and why — useful when the team has developed several competing directions and needs to select one.
03
The counter-intuitive nuance — negative reactions to the concept are the most valuable data
The most practically important and most frequently undervalued aspect of Concept Testing is the diagnostic value of negative reactions. When users respond negatively to a concept — expressing confusion, scepticism, or indifference — the team's instinct is often to discount the feedback as misunderstanding or to defend the concept. But a negative reaction from a representative user is evidence that the concept has a communication or desirability problem that will manifest at scale when the product launches. The specific nature of the negative reaction is the valuable data: confusion indicates a communication problem (the concept is not being understood); scepticism indicates a credibility problem (users do not believe the concept will work as promised); indifference indicates a relevance problem (the concept does not address a problem users actually have). Each type of negative reaction implies a different design response — and discovering the negative reaction in a concept test costs a fraction of discovering it after launch.
04
How to measure it — comprehension rate and desirability score
Concept Testing produces two primary measurable outcomes. Comprehension rate measures whether users can accurately describe what the concept does after being exposed to it — a concept that five participants describe accurately in five different ways has a comprehension problem; a concept that five participants describe consistently and accurately has been communicated effectively. Desirability score measures whether users express genuine interest in using the concept — rated on a scale or captured through purchase intent questions, the desirability score indicates whether the concept addresses a real need strongly enough to motivate adoption.

Concept Testing vs Prototype Testing — different questions, different stages

Concept Testing and Prototype Testing address different questions and should be used at different stages. Concept Testing asks "do users want this and do they understand it?" — answered before significant design or engineering investment. Prototype Testing (usability testing on a working prototype) asks "can users accomplish tasks with this and where does the interaction fail?" — answered after the concept has been validated and the design has progressed to implementation. Running prototype testing before concept testing is the most expensive sequence error in UX research: it evaluates the implementation quality of a concept whose desirability has not yet been validated, potentially producing high-quality usability data for a product nobody wants. The correct sequence is concept testing first, prototype testing second.

Intercom's storyboard concept test and the product direction that changed before a line was coded

Intercom's product team was evaluating two competing directions for a new product feature in their customer messaging platform: Direction A was an AI-powered response suggestion system that would automatically generate draft replies for support agents; Direction B was a routing intelligence system that would automatically route incoming conversations to the most appropriate agent based on content and agent expertise.

Rather than building prototypes of both and running comparative usability testing — which would have required significant design and engineering investment — the team used concept testing with storyboards. Each direction was expressed as a four-panel storyboard showing a customer support manager's working day: the problem they experienced, how the new feature appeared in their workflow, what it produced, and the outcome for their team. Twelve customer support managers at companies with 10-50 person support teams were shown both storyboards in randomised order. The results were decisive in a direction the team had not anticipated: Direction A generated strong interest from agents at companies with high-volume repetitive queries but strong resistance from managers at companies with complex, consultative support — who expressed concern that AI suggestions would reduce the quality and personalisation of their team's responses. Direction B generated consistent interest across both groups with no expressed concerns. The concept testing identified not only which direction to pursue but a specific segment problem with Direction A that would have been discovered at launch rather than before a line of code was written.

Intercom · 2 directions · 12 support managers · storyboard concept test
Storyboard concept testing reveals segment-specific desirability problem before any engineering investment
TWO STORYBOARDS · 12 PARTICIPANTS · DECISIVE FINDING DIRECTION A · AI SUGGESTIONS 1 · problem query volume 2 · feature suggestion appears 3 · output draft reply 4 · outcome agent reviews · sends ✓ high-volume teams "finally — saves us hours" ✗ complex / consultative teams "would reduce response quality" DIRECTION B · ROUTING INTELLIGENCE 1 · problem wrong-agent queries 2 · feature routing rule UI 3 · output routed to expert 4 · outcome faster resolution ✓ consistent across both segments "this would just be useful — no concerns expressed" Direction B selected · zero engineering investment to this point Intercom · storyboards · 12 participants · segment-specific desirability finding · direction changed before any code written
Direction changed before any line of code was written

Test yourself & see real examples

No examples yet — be the first.

Spotted a product feature that clearly went through a concept validation process — where the value proposition is immediately clear and the feature feels like it solves a real problem that users actually have — or one that feels like someone's idea of what users need rather than something grounded in what users actually expressed wanting? Submit what you observed.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen a feature that clearly came from validated concept testing — or one that shipped as an untested assumption? Help grow the evidence base.

Where teams go wrong

Testing comprehension of the concept rather than desirability. The most common Concept Testing mistake is designing the session to verify that users understand the concept rather than to evaluate whether they genuinely want it. Sessions that ask "do you understand what this product does?" will almost always receive a yes — users rarely admit confusion — and the team leaves feeling validated. Sessions designed to evaluate desirability ask different questions: "Would you use this? What problem would this solve for you? Can you describe a situation where this would have been useful?" These questions reveal whether the concept addresses a genuine need users have, not merely whether they can grasp the concept intellectually. A concept that is clearly understood but not desired is as problematic as a concept that is misunderstood.
Using high-fidelity materials that shift focus to interface details. When concept testing stimuli are too polished — detailed wireframes, high-fidelity mockups, or working prototypes — users engage with interface details rather than with the core concept question. They comment on button placement, colour choices, and typography rather than on whether the concept solves a real problem. The deliberate roughness of concept testing stimuli (storyboards, sketches, written descriptions) is not a production constraint — it is a research design decision that keeps users focused on the question being evaluated. If users are commenting on design details during a concept test, the stimulus is too polished and needs to be made deliberately rougher.
Treating positive initial reactions as validated desirability. Participants in concept testing sessions are often polite, and the social dynamics of a research session create pressure toward positive responses — users do not want to be discouraging about an idea that the researcher clearly has invested effort in. "That sounds useful" or "I can see how that would be helpful" in a concept test is not evidence of desirability — it is a social response. Validated desirability requires specific, unprompted evidence: a user spontaneously describing a specific situation where they would have used the product, expressing genuine frustration with the current alternative the product would replace, or demonstrating willingness to pay through a purchase intent question. Generic positive reactions should be probed with "can you tell me about a specific time when you would have used this?"
Running concept tests too late in the design process. Concept Testing is most valuable at the very beginning of the design process — before detailed design work has been invested. Teams that run concept tests after weeks of design work have already made significant investments in a specific direction, which creates unconscious pressure to interpret test results favourably and reduces the team's practical ability to pivot based on negative feedback. A concept test run on the first sketch of an idea produces feedback that can genuinely change the direction; a concept test run on a polished six-week design produces feedback that arrives too late to change the fundamental direction without discarding significant work. The test should happen as early as the concept can be communicated — which is much earlier than most teams think.

Connected ideas

Concept Testing is the desirability validation method that precedes all other design validation activities. Its closest relationships are with the research methods that precede it and the design activities that follow it.

The most important pairing is Concept Testing with genuine scepticism about the concept being tested. Researchers who are invested in the concept — who have spent weeks developing it and believe in it — unconsciously bias their session design toward confirming the concept rather than genuinely evaluating it. The best concept tests are run by researchers who are genuinely curious about whether the concept is valid and who treat negative results as valuable findings rather than disappointing setbacks. If the team running the concept test cannot maintain genuine openness to a negative result, the test should be run by someone with less investment in the outcome.

Run it right now

⏱ 10 minutes · Solo · No prep

The Concept Description Test

1. Write a two-sentence description of a product concept you are currently working on or evaluating — as if you were explaining it to a potential user who has never heard of it. Do not use any product jargon, feature names, or technical terms. Write it in plain language that a non-designer would understand.

2. Read your description aloud to yourself as if you were hearing it for the first time. Ask: Does this description clearly communicate what the product does? Does it communicate who it is for? Does it communicate why someone would want it? If any of these three questions cannot be answered from your two-sentence description, the concept has a communication problem that concept testing will surface with real users.

3. Write down the three questions you most need users to answer about this concept: the three things you most need to know to decide whether to invest further in it. These should be specific behavioural questions — "Would they use this?" requires evidence; "Do they understand it?" requires evidence; "Do they already have a solution they are happy with?" requires evidence.

4. Identify one person in your network who represents your target user — someone in the right role, industry, or context — and plan to show them your two-sentence description in the next 48 hours. Note their response before they know what you want them to say. This informal concept test will tell you more about your concept's clarity and relevance than any amount of internal team discussion.

10 minutes