Concept testing: find out what is worth building

A concept test investigates how a proposed product or service is understood, evaluated or used before a larger development commitment. The most useful starting point is not “Do people like the idea?” It is “What decision must this test help us make, and what evidence could change that decision?”

A paper description can reveal confusion about a promise. A prototype can reveal trouble completing a task. A carefully designed choice study can examine trade-offs within the options presented. These are different contributions. None, by itself, proves that people will buy repeatedly or that the business can deliver reliably.

Consider a fictional laundry shop exploring a collection notification. Customers would receive a message when their entire order is ready, rather than visiting on an estimated date. The team has a concept brief and wants to decide whether the promise is clear enough to investigate further.

Start with the decision, then the question

Write the upcoming commitment in plain language. The laundry team is considering a small service rehearsal, not a full messaging platform. Its immediate question is whether customers understand “ready” to mean the complete order is available, and whether the proposed notification would help them arrange collection.

Separate that question from other uncertainties. Can staff accurately establish readiness? What happens when a garment needs rework? Will customers prefer a message to a phone call? How much would operation cost? Listing these questions prevents a convenient test from becoming the supposed answer to all of them.

GOV.UK’s guidance on planning user research recommends turning assumptions into research questions and choosing activities around what the team needs to learn. For this test, write down what misunderstanding would require revision and what finding would justify a further investigation.

Avoid inventing a universal approval threshold. “Most people liked it” is not a decision rule if the main risk is a misunderstanding that causes wasted journeys. One serious interpretation problem can be worth fixing even in a small exploratory round.

Choose enough realism for the question

Use a representation that exposes the relevant uncertainty without introducing distracting detail. For the laundry service, a realistic message shown in a plausible collection situation may be enough to explore comprehension. A paper journey showing preparation, notification and pickup can reveal missing steps.

GOV.UK’s prototyping guidance describes different forms of prototype rather than requiring production-ready software. The practical choice is about the question. A polished interface may be unnecessary for testing a service promise, while a static picture is insufficient for testing keyboard navigation.

Keep different concepts comparable. If one has warm photography and a confident brand name while another is a rough paragraph, you may be testing presentation quality. Give each the same essential information: who it is for, what happens, what is required from the customer and any relevant limits.

Do not conceal that the offer is a concept. Participants should understand what is real, what is simulated and whether their actions will have consequences. A realistic test does not require a misleading sales encounter.

Recruit for the situation, not convenient agreement

The useful participants are people who encounter the problem, including those whose circumstances could expose weaknesses. For the laundry shop, that might include customers collecting several garments, people who send someone else to collect, and people unable to check messages frequently. Employees’ friends are not automatically a suitable substitute.

Start with recent behaviour. Ask how the person arranged their last collection and what happened when timing changed. This gives the concept a context and reduces the temptation to treat an imagined ideal day as ordinary life. Our customer interview guide explains how to explore such situations without leading the answer.

Plan access needs and informed participation before the session. Explain recording, observers and use of notes. Avoid collecting personal details the research does not need. For a prototype, use clearly fictional order information unless there is an appropriate, secure reason to use real data.

There is no single participant count that makes every concept test valid. A small qualitative round can expose misunderstandings; it cannot support precise market percentages. Estimating preference across a population requires a different sampling and analysis plan.

Let the participant show their interpretation

When the question concerns different kinds of customer expectations, the Kano model offers a separate way to investigate requirements. Its paired questions address satisfaction with a feature being present or absent; they do not replace checking whether this service promise is understood.

Introduce the situation neutrally, then show the concept. Ask the participant to explain what they think would happen. “What would you expect to be ready?” is more informative than “Is it clear that all your garments are ready?” The second question supplies the desired interpretation.

Follow with a realistic task: “You receive this while planning tomorrow. Show me how you would work out when to collect.” Watch what information they look for and where they hesitate. Record any assistance you provide rather than counting a rescued attempt as independent understanding.

GOV.UK’s moderated usability-testing guidance emphasizes believable tasks and neutral instructions that do not reveal the answer. Its approach is useful when your concept includes an interaction. A conversation about preference alone is not the same as observing task performance.

Ask about apparent contradictions with curiosity. Someone may praise the message but still telephone because they do not trust a completion status. That is not necessarily resistance to innovation. It may reveal a history of partial orders or an ambiguous promise.

Keep different kinds of evidence separate

Use a simple record so the team can see what the test did and did not establish. The entries below are invented examples, not results from research.

Evidence	Fictional observation	Reasonable interpretation	Not established
Comprehension	A participant assumes one garment is ready	The scope of the message is ambiguous	Market demand
Task performance	A participant cannot find collection hours	The concept omits needed information	Long-term usage
Stated preference	A participant prefers a phone call	That person reports a channel preference	What all customers prefer
Operational rehearsal	Staff disagree about when to send the message	Readiness needs a shared definition	Reliability across busy weeks

GOV.UK’s analysis guidance separates observations from findings and actions. Apply that distinction literally: preserve what happened, then state your interpretation and the change it suggests. Keep contradictory observations visible rather than smoothing them into a neat success story.

If you compare several concepts, record order and presentation conditions. A participant’s preference after seeing every option is different from their reaction to one offer in isolation. For formal preference modelling or conjoint analysis, use qualified research design; a quick workshop ranking is not a replacement.

Test the work behind the promise

A customer-facing concept can be understandable and still impossible to deliver consistently. After the first round, the laundry team rehearses a complete order with staff. They follow the items through cleaning, inspection, packing and placement on the collection shelf.

The rehearsal reveals a possible exception: one garment is complete while another needs rework. The team must decide whether the order remains unready, who maintains that status and what customers are told. A clearer message cannot solve an undefined operating rule.

This is where assumption mapping helps choose the next test. If the greatest uncertainty is staff coordination, another customer preference survey may add little. If customers misunderstand the promise, a larger operational trial may simply expose more people to the same confusion.

A later live trial needs its own boundaries, monitoring, support and stopping conditions. Do not turn a prototype session into a customer commitment by accident. Nor should a successful rehearsal be described as proof of sustainable service economics.

End with a bounded conclusion

A useful report says what was tested, with whom, under which conditions, what happened and what the team will change. Include the concept version and unresolved questions so the finding does not lose its boundaries when shared.

For our fictional shop, a defensible decision might be to revise the completion wording and clarify the staff rule before another round. That is meaningful progress even if no development has been approved. The test has reduced one kind of confusion and exposed another.

Concept testing is less useful when it becomes a ceremony to approve an already funded solution. Its limitations include selective recruitment, artificial settings, social desirability and the gap between stated intentions and costly real choices. Treat the results as evidence for the next commitment, not a permanent label saying “validated.”