Concept Testing
Show the idea before you build it — and find out if users actually want what you think they want.
01 — TL;DR
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.
02 — When to Use
Apply this when…
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.
03 — How It Works
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.
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.
04 — Real Example
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.
05 — In the Wild
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.
Seen a feature that clearly came from validated concept testing — or one that shipped as an untested assumption? Help grow the evidence base.
06 — Common Mistakes
Where teams go wrong
07 — Variations & Related Principles
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.
08 — 10-Min Exercise
Run it right now
⏱ 10 minutes · Solo · No prep
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.