A fake door test (also called a painted door test) is a way to validate a feature before building it. You add a real entry point to something that does not exist yet, such as a button, a menu item, a pricing tier or an add-on, and count how many of the right users click it. Everyone who clicks sees an honest screen that says the feature is not built yet and asks one short question. You set your pass or fail number before launch, run it for one to two weeks with a capped group of users, then build, shrink or kill the idea based on who clicked and what they told you.
The startup in the worked example below is made up, and so are its numbers.
What is a fake door test?
A fake door test is a small, honest experiment that measures demand by behaviour instead of opinion. Optimizely's glossary entry on the painted door test describes it as an experiment where a feature is advertised to users before it exists, to gauge demand and interest. A clickable button or link stands in for the feature, users who click learn it is not ready yet, and the number of clicks measures interest.
Asking "would you use this?" gets you polite yeses. Watching whether someone reaches for a button in the middle of real work gets you much closer to the truth. But a click is cheap, and a door that leads nowhere feels like a trick if the reveal is handled badly. This guide is about making the click mean something and the reveal feel fair.
How is a fake door test different from a survey, an A/B test or a waitlist?
A survey asks people what they think they want, and people are generous with hypothetical yeses. A fake door test starts from real behaviour, and the one question on the reveal screen adds the "why" back in.
An A/B test compares two working versions and needs enough traffic to detect a difference. A fake door test asks a cruder question: does anyone care enough to click at all? That is why it suits small products. For the comparison version, see this guide to running A/B tests when your product has low traffic.
A waitlist page tests interest in a whole product from strangers. A fake door test usually lives inside a product people already use and tests one feature, plan or add-on with people who already trust you.
When should you run a fake door test, and when should you not?
Run one when building the thing would take more than a week or two, you genuinely do not know whether people want it, and you have users who would see the door in their normal flow. Good candidates:
A feature a few people asked for loudly, where you cannot tell if the quiet majority cares.
A new plan or tier, such as a team plan, before you build seats and billing.
An add-on or integration that would mean weeks of work and ongoing maintenance.
Do not run one when:
The door sits in a core flow. A dead end on a screen people rely on costs real work and real trust.
It involves money, health, safety or legal obligations. ProdPad's fake door testing overview warns that in heavily regulated industries, non-functional UI can cause confusion or compliance issues.
Users already expect the feature because you announced it. ProdPad notes that a fake door in place of a promised feature can damage trust.
You would never build it anyway. If a great result would not change your plans, you are only collecting clicks.
How do you write the hypothesis and pass or fail threshold before launch?
Write it down before the door goes live, because once numbers arrive, every result starts to look like a yes. Optimizely makes the same point: know what a positive, negative and neutral result looks like before you start. Amplitude's guide to painted door tests also says to set clear success criteria upfront.
A good hypothesis fits in one sentence and names the people, the door and the number: "Teachers with five or more students will click 'Send progress report' at least twice as often as 'Export lesson notes', and at least 4 in 10 clickers will tell us who they would send it to."
Then track three numbers, counted as unique people, not raw clicks:
Exposed users: people who actually saw the door, not everyone who logged in.
Click rate: unique clickers divided by exposed users.
Answer rate: people who answered the reveal question divided by unique clickers.
Exposed users times click rate times answer rate equals the number of people who wanted it enough to tell you why. If that number is 3, you do not have a decision yet.
How much you can conclude depends on how many people saw the door. These are rules of thumb, not statistics, and small numbers are directional at best:
People who saw the door | What you can honestly conclude | How to set the threshold |
|---|---|---|
Under 50 | Almost nothing from the click rate. The answers are the result. | A minimum number of useful answers, for example 5, instead of a percentage. |
50 to 200 | Only big gaps mean anything: roughly double or half your comparison button. | A multiple of a baseline button, plus a minimum answer count. |
200 to 1,000 | Click rates start to settle. Differences of a few points are still noise. | Baseline multiple plus answer rate, split by user type. |
Over 1,000 | You can compare door wording or placement variants. | Consider a proper split test of two doors, sized in advance. |
There is no universal good click rate, which is why you compare against a button of your own.
Which kind of door should you build?
Put the door as close as possible to the moment someone would need the feature. A door in the wrong place measures curiosity about your menus, not demand.
Door type | What it measures | Risk |
|---|---|---|
In-product button on the relevant screen | Need at the moment of the task | Low, if it sits beside the main action rather than replacing it |
Menu item | General interest in a new area of the product | Medium: new items attract curiosity clicks |
Extra tier on the pricing page | Who reaches for a bigger or different plan | Medium to high: the reveal must come before any payment step |
Add-on offer at the upgrade step | Willingness to pay for something on top | High: never let it touch checkout |
Call to action in a product email | Interest from people not logged in right now | Low, but email clicks skew toward your most engaged readers |
Label the door with the outcome, in the plain words your product already uses. "Send progress report" tells people exactly what they would get. "Insights" invites curiosity clicks that flatter your idea.
What should the reveal screen say?
The reveal screen decides whether the test feels honest or sneaky. It appears right after the click and does four things: says plainly the feature is not built yet, apologises for the detour, asks one question, and gets the user back to their work in one click.
Part | Weak | Better |
|---|---|---|
Headline | "Coming soon!" | "We have not built progress reports yet." |
Why you are seeing this | Nothing | "We are checking whether teachers want this before we spend a month on it. Sorry for the detour." |
The question | "How likely are you to use this from 1 to 10?" | "Who would you send a progress report to, and how often?" with a short text box |
Follow-up | Email required to close the box | Optional checkbox: "Tell me if this ships" |
Exit | A small X in the corner | A clear "Back to my student" button |
Ask one open question about their real situation, not a rating. It gives you use cases and the exact words people use. If you can, give something back, such as a manual workaround or a first look at an early version.
What are the ethics and trust rules for fake door testing?
A fake door test is fair when the user loses a few seconds and learns the truth immediately. It becomes a trick when they lose money, data or work, or find out late.
Never take money for something that does not exist, and never build a fake checkout that charges a card. If the door is a paid tier, the reveal comes before any payment field.
Tell the truth on the first screen after the click. No forms first, no fake loading spinner.
Cap exposure. ProdPad suggests starting small, for example 5% of your user base. At tiny scale, a defined segment works better than a percentage.
Keep it short, with the end date set before you start, and run one door at a time.
Remove it promptly when the test ends, whatever the result.
Close the loop. Tell everyone who ticked "tell me if this ships" what you decided, even if the answer is no.
A simple check: if a user asked "was that button fake?", could you happily explain exactly what you did? If not, change the test.
How do you track a fake door test?
You need three events, and any analytics tool that records custom events can handle them:
door_viewed: fired when the door is actually visible, with the user or account ID and the door name.door_clicked: fired on click, with the same properties.door_answered: fired when the reveal question is submitted, with the answer text and the "tell me if this ships" choice.
Fire the same view and click events on your comparison button, so the baseline comes from the same weeks and the same users. Count unique users; one curious person clicking six times is still one person. To show the door to a capped group and switch it off instantly, put it behind a flag, as in this walkthrough on shipping risky changes behind feature flags. Then click through the whole path on a test account and check all three events land.
How long should a fake door test run, and how many people should see it?
Run it for one to two full weeks, so weekdays and weekends both show up, and stop on the end date you wrote down. Stop early only if something breaks.
Aim for enough of the right people, not as many people as possible. "Right" means the users who would get the feature if you built it: accounts on a paid plan, people who used the related feature this month, teachers with five or more students. If your segment is small, run longer rather than widening it. Fifty exposures from the right segment beat five hundred from everyone.
How do you read the results and decide to build, shrink or kill?
Read three things, in order:
Click rate against your baseline. Compare with a button of similar size and placement from the same period. Well above it is a signal; near it may be ordinary curiosity.
The answers. Read every one, looking for specific situations, repeated words and surprises. Amplitude's guide flags the risk that people click out of curiosity without serious intent, so specific answers count for more than the click total.
Who clicked. Split by plan, account age and usage. Ten clicks from your best accounts can outweigh fifty from yesterday's free signups.
Then make one of three calls:
Build when you passed the threshold, the answers describe the same job, and the clickers are people you want more of.
Shrink when interest is real but the answers point to a smaller or different version than you imagined. This is the most common good outcome.
Kill when you missed the threshold or the answers are vague. Write down why, so the idea does not return in six months without new evidence.
What should you ask the people who clicked?
Clickers who ticked "tell me if this ships" are the most valuable output of the test. Within a few days, email five to ten of them personally and ask for fifteen minutes:
"What were you doing right before you clicked?"
"How do you handle this today, and what does it cost you?"
"What would make it useless to you?"
Listen for workarounds: someone who rebuilds this by hand every month has a real need. In B2B, if a few clickers keep coming back with detailed opinions, consider something more formal, like running a design partner program.
What are the most common fake door test mistakes?
Vague labels that inflate curiosity clicks. Name the outcome.
Showing it to everyone, which spends trust across your whole user base and dilutes the signal.
No baseline. Without a comparison button, a 6% click rate means nothing.
Running forever. A door left up for months becomes a broken promise.
Deciding the threshold afterwards, when every result looks like a pass.
Worked example: a fake door test at Corkwhistle
Corkwhistle is invented for this example: a two-person booking and invoicing tool for independent music teachers, with about 600 teachers using it each week. Several teachers had asked for "progress reports for parents", estimated at three to four weeks of work.
The hypothesis and threshold
Written before launch: "Teachers with five or more active students will click 'Send progress report' at least twice as often as 'Export lesson notes' on the same page. At least 40% of clickers will answer the question, and we need at least 10 specific answers to decide. The test runs 10 days for half of eligible teachers." The baseline: about 6% of eligible teachers who opened a student page clicked "Export lesson notes" the previous month.
The door and the reveal
The button sat beside "Export lesson notes" with the same size and look. The reveal used the "better" copy from the table above, with an optional "Tell me if this ships" checkbox and a "Back to my student" button.
The results and the decision
Exposed: 212 teachers saw the button at least once.
Clicked: 31 teachers, about 15%, roughly 2.4 times the 6% baseline.
Answered: 18 teachers (58% of clickers); 14 ticked "tell me if this ships".
What they said: 11 wanted a short monthly email to parents listing lessons attended and pieces practised; 4 wanted a printable end-of-term summary; 3 were "just curious".
It passed, but the answers pointed to something much smaller than the report builder the founders had sketched. After six short calls with clickers they chose shrink: an automatic monthly parent email built from data Corkwhistle already had, about one week of work. They removed the door on day 10 and emailed the 14 teachers to say what was coming.
A 7-day fake door test plan
Day | What to do | Output |
|---|---|---|
1 | Pick one idea, the target segment and a comparison button. Write the hypothesis. | One-sentence hypothesis |
2 | Set the threshold: baseline multiple, minimum answers and end date. | Build, shrink and kill rules |
3 | Design the door with an outcome label. Write the reveal screen and its one question. | Door and reveal copy |
4 | Add the three events and the flag. Test the whole path on a test account. | Events confirmed |
5 | Launch to the capped segment. Note anything else shipping that week. | Door live |
6 | Check only that events flow and nothing is broken. Do not read results yet. | Health check |
7 | Draft the follow-up email to clickers and the closing note. | Follow-up ready |
On the end date, read the results, make the call, remove the door and send the closing note.
Fake door test FAQ
Is a fake door test unethical?
Not when you tell people the truth on the very next screen, never take money, cap who sees it and remove it on schedule. It becomes unethical when it costs users money, data or work, or when the truth arrives late.
How many clicks do you need from a fake door test?
There is no universal number. Decide in advance using a baseline button and a minimum number of useful answers. With fewer than about 50 people seeing the door, treat the answers as the result and the click rate as a hint.
What is the difference between a fake door test and a painted door test?
Mostly nothing. Optimizely treats the two names as the same method. ProdPad describes the painted door as a lighter cousin, such as a homepage banner or email placeholder rather than a button inside the product. The honesty rules are the same.
Can you run a fake door test without a product?
Yes, but it becomes a smoke test of a whole offer, usually on a landing page, rather than a test of one feature with existing users. The same rules apply: be clear about what exists and never charge for what does not.
When the feature you validated ships and you want new people to find it, you can launch it on EarlyHunt and show it to early adopters.