Concept testing: validating an idea before building it
Concept testing checks whether a product idea resonates with users before you design or build it. What to show, what to ask, and which mistakes to avoid.
What is concept testing?
It tests the idea, not the interface. Maze describes it as a way to evaluate the feasibility, appeal, and potential success of a product before building it, using surveys, interviews, or A/B tests. Userlytics defines it as an early method that collects feedback on an idea before it is fully designed or built.
Its central question is simple: is this worth building? If the answer is no, you have saved weeks. If it is yes, the next step is testing how the experience works.
Why does it matter to a designer?
Because many well-executed designs solve problems nobody has. An elegant flow for a feature users do not need is wasted work, no matter how good it looks. Concept testing lets you find that out before the team commits to a screen.
It also forces you to put the value proposition into words. If you cannot describe the idea in three sentences that someone understands, it is probably not ready to show.
What to show, and when?
Maze notes that a concept can be evaluated during ideation, during design (from low-fidelity to high-fidelity prototypes), or before launch. Userlytics lists the common formats: written descriptions, storyboards, sketches, wireframes, mockups, or simple prototypes.
A cheap, common option is a landing page with a headline, value proposition, and call to action, with no real functionality. It measures interest without building anything, although you should treat that signal as a first hint rather than a decision.
| Phase | What to show | Question it answers |
|---|---|---|
| Early | Text, sketch, or landing page | Do they understand the idea and find it interesting? |
| Middle | Wireframes or a low-fidelity prototype | How do they imagine using the product? |
| Late | High-fidelity prototype | Which part of the proposal matters most to them? |
What should you ask?
Userlytics suggests concrete questions: whether users understand the idea, whether they need it, whether they would use it, and what they like or dislike about it. Maze adds interest, comprehension, and likelihood to purchase, along with perceived value and price sensitivity.
One warning is worth keeping in mind: stated intention does not always match actual behavior. Saying you would use something does not prove you will. So ask about past situations (“how did you handle the last time…?”) as well as future intentions.
Avoid questions that push the answer. “Don’t you think this button is useful?” invites a yes. “What would you do on this screen?” gives you information.
How does it fit in a process?
Concept testing sits in the research sequence. It comes after problem interviews, which explore the need without a solution, and before usability tests, which evaluate a concrete interface. Looppanel sums up the difference: concept testing validates the idea and its market fit, while usability testing evaluates how well people can use the product. They are different questions, so do not mix them in the same session.
Sample size depends on the kind of study. Looppanel says that quantitative concept tests typically use 30 to 100 participants per concept. For qualitative work, it is common to start with a small group and repeat as patterns emerge.
When should you NOT use it?
Do not use it to find out whether people have the problem. Discovery interviews are the right tool for that. Nor is it useful when the decision is already made and only execution remains; a concept test then becomes a ritual.
It is also not a way to measure the usability of a screen. If you need to know whether people complete a task, run usability tests, not a concept test.
Example
Illustrative example: an education platform team wants to launch a group study mode. Before designing it, they publish a landing page with the headline “Study with your classmates without leaving home” and a button to join a waitlist. In two weeks, out of a hundred visitors, only twelve click the button. They then run five interviews with those who clicked and find that most people think of in-person study groups, not video calls. The concept changes before a single screen of the feature is drawn.
Common mistakes
- Asking whether people like the idea, an answer that guides no decision.
- Presenting the concept with a sales tone, which biases the response.
- Trusting stated intention without looking for evidence of behavior.
- Mixing concept testing with usability in the same session.
- Using a landing page as the only test and treating one click as real commitment.
- Running it after the decision is made, with no room to change anything.
Before this test, desk research helps you learn what already exists. If the concept rests on a simulated interaction, Wizard of Oz lets you test the interaction without building it. And to combine the answers with other methods, triangulation explains how to trust the result more. For the interview that comes before this test, see user interviews.