The first version of an idea is usually a bundle of assumptions. Someone has the problem, the problem matters, the proposed solution fits and the audience can use it. A small test helps separate those assumptions so that you can learn before investing in a complete product or programme.
Choose the uncertainty that matters most
Write a sentence beginning “We are assuming that…” and finish it in concrete terms. A new workshop might assume that first-time managers struggle to prepare useful feedback. A digital guide might assume that customers cannot find existing instructions. These are different questions and need different evidence.
Choose the uncertainty that could change the project’s direction. Testing the colour of a signup button is unlikely to help if you do not yet know whether the workshop solves a meaningful problem. Start close to the audience’s situation, then move towards the proposed solution as the evidence becomes clearer.
Ask about real experience
Talk to people who actually encounter the situation. Ask them to describe a recent example, what they did and where they became stuck. Avoid pitching your idea before you understand the current behaviour. Enthusiasm for a friendly conversation is not the same as evidence that someone needs your offer.
The Nielsen Norman Group introduction to user interviews describes interviews as a way to explore people’s experiences through questions and follow-up. Interviews can inform your understanding, but stated intentions do not prove future behaviour. Treat a promise to use a product as a clue to investigate, not a completed validation.
Build only what the question needs
If the uncertainty is whether an explanation is understandable, a short document may be enough. If the question concerns navigation, a simple prototype with realistic labels may help. If it concerns the practical delivery of a service, a clearly described small pilot may reveal operational constraints.
Do not misrepresent a mockup as a finished service. Tell participants what exists, what is being tested and what will happen to any information they provide. Avoid collecting personal data that the exercise does not need. When an experiment involves real customers or commitments, obtain the appropriate organisational approval before running it.
Decide what evidence would change your mind
Before the test, write what you will observe and which outcomes would lead you to continue, revise or stop. These can be qualitative observations: people repeatedly misunderstand the same instruction, or the proposed workflow requires information they do not have. You do not need to invent a numerical success threshold just to make the exercise look scientific.
Keep the scale of your conclusion proportional to the test. A few conversations can reveal useful questions but cannot establish the preferences of an entire market. A successful prototype task does not prove willingness to pay. Record the limits alongside the findings so they remain visible when enthusiasm grows.
Turn findings into a next decision
Separate observations from interpretations. “Two participants asked where the file was saved” is an observation. “We need automatic cloud storage” is one possible response. There may be a simpler explanation or fix. Discuss alternatives before treating the first proposed feature as the inevitable result.
Close the test with a decision, a reason and the next uncertainty to examine. Sometimes the right outcome is a smaller idea. Sometimes it is a clearer problem and a different solution. Both are useful progress when they prevent a larger commitment built on a weak assumption.
Put the result into your project brief and use a decision log to preserve the reasoning. Future collaborators should be able to see what the test established and what remains unknown.
Keep a simple evidence note
Use a small record for each session: the question, what you presented, what happened and what surprised you. Separate direct quotations, with appropriate consent, from your interpretation. Do not include identifying details unless the work requires them and the participants understand how those details will be used.
Review several notes together before declaring a pattern. An unexpected comment may be important, but it may also reflect a particular context. Look for explanations that fit the observations and identify what additional evidence would distinguish them. The discipline is to make the next question more precise, rather than to collect supportive comments until the original idea feels safe.