How to test an idea before you build it

To test an idea before you build it, list what must be true for it to work, pick the belief that is both most important and least proven, and run the cheapest test that could show it is wrong. Decide in advance what result counts as a pass, run the test with real people in real conditions, then choose to continue, change or stop. You are not testing whether people like the idea. You are testing whether the riskiest thing you believe about it holds.

Why "we showed it to people and they liked it" is not a test

The most common validation is a presentation followed by applause. People are polite, especially to colleagues and especially when the idea is presented with care. What people say they would do and what they actually do are often far apart.

A real test has three features. It targets one specific assumption. It has a pass line agreed before anyone sees results. And it asks people to do something, such as give time, give information, change a habit or commit, rather than to give an opinion. If your test cannot fail, it is a demonstration.

How to test an idea: seven steps

1. Write the idea as one sentence with a who and a change

"A mobile app for students" is a category, not an idea you can test. "First-year students who miss lectures can catch up within 24 hours through a short recorded summary from the lecturer" is testable. Name who it is for, what they will do differently, and what improves for them.

2. List every assumption behind it

Ask the team: what has to be true for this to work? Push for at least fifteen beliefs. Group them under three questions often used in design practice: do people want it (desirability), can we deliver it (feasibility), and can we sustain it (viability)? Teams usually list feasibility risks first because they are comfortable to discuss. The risks that sink ideas are more often in desirability and viability.

A premortem, Gary Klein's technique of imagining the project has already failed and asking why, is a quick way to surface assumptions people are reluctant to say aloud.

3. Find the riskiest assumption

Place each assumption on two axes: how important it is to the idea, and how much evidence you already have. This is assumption mapping, popularised by David J. Bland. The top-left corner, critical and unproven, is where you test first. Pick one, two at most. Everything else waits.

A useful check: "If this turns out false, does the idea die or just change?" Test the ones that would kill it.

4. Turn it into a hypothesis with a pass line

Write it as a hypothesis in this shape: We believe that [who] will [do what] because [reason]. We will know this is true if [measurable result] within [time].

Set the pass line before running the test, and write it down. "At least 8 of 20 students who missed a lecture open the summary within a day" is a pass line. "Students respond well" is not. Also agree what you will do if the result falls short or lands in between. Teams that skip this always find a way to read the result as good news.

5. Choose the cheapest test that could prove you wrong

Match the test to the assumption, not to the tool you like:

• Do people want it? A fake door (offer the service or button and count who tries to use it, then explain honestly), a sign-up page, or a pre-commitment such as booking a slot.
• Will they use it the way we expect? A paper prototype or a moderated usability test on a rough version.
• Does the value hold up in real use? A concierge test: deliver the service by hand to a few people, openly, before you automate anything.
• Does the experience work before the technology exists? A Wizard of Oz test: the user interacts with what looks like a working service while a person does the work behind the scenes. The term was coined by John F. Kelley in human–computer interaction research around 1980.
• Which of two versions works better? An A/B experiment, once you have enough traffic or users to compare.

Cost is measured in days, not money. A good first test takes one to ten days. If it needs a budget approval, you are probably building, not testing. For ideas on making the test artefact itself, see the cheapest prototype you can make this week.

6. Run it with real people, and watch

Test with the people the idea is for, not with colleagues standing in for them. Keep the conditions as close to real as you can: their place, their device, their time pressure. Watch what they do more than what they say.

Capture what you see on a feedback capture grid: what worked, what did not, questions raised and new ideas. Note surprises immediately; they fade by the next day.

If a test involves the public, tell people plainly what is being tried and get any approvals your organisation requires. Testing does not excuse misleading anyone.

7. Decide: continue, change or stop

Compare the result to the pass line you set. Then make one of three decisions out loud:

• Continue: the assumption held. Move to the next riskiest one.
• Change: it partly held, or held for a different group. Adjust the idea and test again.
• Stop: it did not hold. Record what you learned and close it. Stopping an idea after a two-week test is a good outcome; stopping it after a year of building is not.

Write a short note: what you tested, what happened, what you decided and why. This record is what lets a team learn across ideas instead of starting again each time.

Illustrative example

Illustrative. A university in Australia wanted to build a peer-tutoring app for first-year engineering students. The draft plan was a six-month build.

The team listed 22 assumptions. On the assumption map, the riskiest was not technical. It was this: "Second-year students will give an hour a week to tutor first-years for course credit rather than pay." If that failed, the app had nothing to connect.

Their hypothesis: "If we offer course credit, at least 15 second-year students will sign up for a tutoring slot within one week." They put a simple sign-up form in the second-year course newsletter, ran it by hand as a concierge test, and matched tutors and students by email.

Nine signed up, below the pass line. But the follow-up conversations were revealing: several said they would tutor in pairs, not alone, because they were unsure of their own knowledge. The team changed the idea to paired tutoring, ran the form again, and got 21 sign-ups. The app was still not built. The next test was whether first-years would actually turn up.

Do's and don'ts

Do

• Test one assumption at a time and name it in the test plan.
• Set a pass line and a decision rule before you see results.
• Prefer tests where people act over tests where they comment.
• Keep the first test under two weeks.
• Treat "stop" as a useful result and record why.

Don't

• Present the idea and count compliments.
• Test with colleagues when the idea is for customers or citizens.
• Build a polished prototype to test whether anyone wants it.
• Move the pass line after the results arrive.
• Mislead participants; a fake door must end with an honest explanation.

Questions people ask

What is the fastest way to validate an idea? Find the one assumption that would kill the idea if false, then run a test that asks real people to act, such as booking a slot, signing up or using a hand-run version. Many such tests can run in a week.

What is the difference between a concierge test and a Wizard of Oz test? In a concierge test, people know a person is delivering the service by hand. In a Wizard of Oz test, the service looks automated to the user while a person works behind the scenes. Concierge tests value; Wizard of Oz tests the experience of a future system.

How many people do I need to test an idea? For early tests that look for problems in an experience, a handful of participants often surfaces the main issues. For tests that measure demand, set a pass line in numbers first, then reach enough people for that number to mean something.

Where to go next

Start with assumption mapping and the hypothesis test guide, then pick between the concierge test and the Wizard of Oz test depending on what you need to learn. If you are still choosing which ideas to test, read how to prioritise ideas, and for the full set of methods see which innovation tool to use.