How to test your new feature idea with real users
The fastest way to test a new feature idea is to put a concept — a short description or mockup — in front of 6–8 target users and probe whether they understand it, want it, and would use it over what they do today. If you have a clickable prototype, add a task and watch them try it.
There’s a ready-made template for this — skip to itThe method: a 15-minute concept test (with an optional prototype task)
Most feature ideas die one of two deaths: nobody wanted them, or people wanted them but couldn't figure them out. A concept test — showing someone a description or mockup of the feature and asking structured questions about it — catches the first death. A prototype test — giving them a clickable version and a task — catches the second. You don't have to choose upfront: start with whatever you have. A paragraph and a screenshot are enough for round one; the clickable prototype can be round two.
The honest caveat: a concept test measures what people **say**, not what they **do**. Participants are polite, and "I'd definitely use that" is the cheapest sentence in research. The method below is built to discount that politeness — you ask about their current behavior first, make them rank the idea against alternatives, and treat enthusiasm without a specific use case as a no. Six to eight interviews won't give you a demand forecast, but they will reliably tell you whether the idea is understood, whether the problem it solves is real, and what would make someone switch.
Write the concept as your users would meet it
One or two sentences plus a visual — a mockup, a Figma frame, even an annotated screenshot. Describe what it does for them, not how it works internally. If you can't write the concept in two sentences, that's finding #1: the idea isn't sharp enough to test yet.
Recruit people who live with the problem today
Screen for people who currently do the thing your feature improves — manually, with a competitor, or with a workaround. Screen out anyone who has never faced the problem; their opinion of your solution is noise. 6–8 participants is enough to hear every major reaction twice.
Ask about their current behavior before showing anything
Spend the first five minutes on how they handle the problem now: what they use, what it costs them, when it last hurt. This is your baseline — later, "would you use this?" gets checked against what they actually do, not against their politeness.
Show the concept and probe comprehension before desirability
Reveal the concept, then ask them to explain it back in their own words before you ask whether they like it. If half your participants describe a different feature than the one you meant, you've learned something cheaper to fix than code.
If you have a clickable prototype, add one real task
Give a single task the feature is supposed to make easy and watch them attempt it, thinking aloud. Don't demo it first — the stumbles are the data. This upgrades "they say they want it" to "they can actually use it," which is a different and better claim.
Score reactions against behavior, not enthusiasm
For each participant, note: did they get it unprompted, did they name a specific moment they'd use it, and what would they give up or pay to have it. Count specifics, not smiles. Three of eight naming the same concrete use case beats eight saying "cool."
What to measure
- Comprehension — can they explain the feature back correctly, unprompted?
- Problem resonance — do they describe the problem it solves as one they actually have?
- Current workaround — what they use today — the thing your feature must beat
- Specific use moment — can they name a real, recent situation where they'd have used it?
- Switching intent — what they'd stop doing or pay to get it — vague "yes" doesn't count
- Task success (prototype only) — did they complete the task without help or a demo?
- Hesitation points (prototype only) — where they paused, backtracked, or asked what something meant
- Objections and dealbreakers — the "yes, but…" — pricing, trust, missing pieces they raise unasked
- 1. Walk me through the last time you dealt with [the problem this feature solves]. What did you do?— Asked before the concept is shown — it anchors everything that follows in real behavior instead of hypotheticals.
- 2. In your own words, what does this feature do?— The comprehension check. If they describe something you didn't build, the concept — not the participant — failed.
- 3. Who do you think this is for? Is that you?
- 4. Thinking about the situation you described earlier — would this have changed what you did? How, exactly?— "Exactly" is the load-bearing word. People who really want a feature can describe the moment they'd use it; people being polite can't.
- 5. What would you stop using, or stop doing, if you had this?— Every feature competes with a current habit. If the answer is "nothing, I'd just add it," expect low adoption.
- 6. What's missing? What would stop you from using this on day one?
- 7. If this appeared in the product next week, what's the first thing you'd try to do with it?
What’s in the ready-to-run study
This is the exact study Sera drafts when you paste a mockup, Figma link, or landing page below. Every piece is editable before launch.
Feature idea usability test
Moderated · Think-aloud · Live URL or Figma prototype
Screener
4 questions that admit people who face the problem today (via a current-behavior question, not a "are you interested in…" giveaway) and reject professional testers and anyone who's never hit the problem.
Tasks
Concept-only studies get a structured reveal — read, explain back, react. If you attach a clickable prototype, the template adds 1 primary task with think-aloud instructions and a conditional follow-up that triggers on abandonment.
Interview questions
7 questions ordered behavior-first — current workaround, then comprehension, then desirability — with probe instructions so the AI moderator digs into vague answers ("tell me about a specific time") instead of accepting polite enthusiasm.
Participants & timing
N = 8 recommended; 10–15 minutes per session for concept-only, ~20 with a prototype task. Recruit-to-readout is typically 24–72 hours on the Sera panel, same-day with your own list.
Try this template
See your feature idea through your users' eyes
Paste a link — the AI drafts your full study in ~2 minutes. You review everything before it runs.
- Works with live URLs and Figma prototypes
- First 7 interviews free
- No credit card required
How it works in Sera
1 · Paste your flow
Drop in the live URL or Figma prototype. Sera reads the flow, drafts the screener, tasks, and questions, and shows you the whole study for review.
2 · Interviews run
Participants attempt the task on their own device while the AI moderator watches, listens, and probes hesitations in real time. You can sit in on any session.
3 · Readout, cited
Friction moments ranked by how many participants hit them, each linked to the exact clip. Share the readout; skeptics can click through to the evidence.
Frequently asked questions
How do you validate a feature idea before building it?
Show the idea — as a description, mockup, or clickable prototype — to 6–8 people who face the problem it solves, and probe three things: do they understand it, do they have the problem, and can they name a specific moment they'd use it. Behavior-anchored answers beat surveys and upvote counts for ideas this early.
What is a concept test in UX research?
A concept test shows participants an early version of an idea — a sentence, a mockup, a storyboard — and asks structured questions about comprehension and appeal before anything is built. It's the cheapest way to kill a bad idea: no code, no design system, just the idea in the form a user would first meet it.
How many users do you need to test a feature idea?
6–8 from your target audience. Patterns repeat fast at this stage — if four of eight people misread the concept the same way, a ninth won't change the conclusion. What matters more than N is the screener: eight people who genuinely have the problem beat eighty who don't.
Can you test a feature that doesn't exist yet?
Yes — that's the whole point of a concept test. A two-sentence description plus a mockup is enough for round one. When you have a clickable Figma prototype, run a second round with a real task; that upgrades "they say they want it" to "they can actually use it."
What's the difference between a concept test and a usability test?
A concept test asks "should we build this?" — it measures comprehension and desire using a description or mockup. A usability test asks "does what we built work?" — it measures whether people can complete tasks in a prototype or live product. For a new feature you usually run them in that order, often two rounds a week apart.
Do people say they'd use a feature and then not use it?
Constantly — stated intent overshoots real adoption, and no interview method fully fixes that. You can discount it heavily, though: ask about current behavior before showing the concept, require a specific use moment, and ask what they'd give up. Treat enthusiasm without a concrete use case as a polite no.
Keep reading
Find out why people abandon
your new feature idea — this week.
Paste your URL, review the study Sera drafts, and watch the first interview yourself.
Your first 7 interviews are on us — no credit card required.