This tool simulates survey branch logic before launch. You write routing rules in plain lines — Q1=yes goes to Q3, Q1=no goes to Q2 — then feed in a set of simulated answers and watch the exact question path a respondent would follow. Branching bugs are the most embarrassing survey errors: a respondent who answers “no” to owning a car and is then asked which car they drive, or a path that loops forever, or a question nobody can ever reach. Simulating every answer combination before launch catches those bugs while they are still cheap to fix, in a text file, instead of after hundreds of respondents have met them.
How to use it
- Write your rules, one per line, as Question=answer -> NextQuestion.
- Write a set of simulated answers, one per line.
- Click Simulate path and read the question order.
- Repeat with every answer combination that matters.
- Fix dead ends, loops, and unreachable questions before launch.
Worked example
A screening survey asks Q1: do you own a car? If yes, Q3 asks about mileage; if no, Q2 asks about public transport. Simulating Q1=yes gives the path Q1 → Q3, and Q1=no gives Q1 → Q2 — both correct. But a second simulation with Q1=yes and a rule typo, Q1=yes -> Q2, sends car owners to the bus questions, a bug visible in one second here and invisible until complaints arrive in a live survey. A third simulation with no answer for Q1 shows the path stopping at Q1, revealing that unanswered questions need a default route in the real survey tool.
Honest limits
The simulator tests logic you wrote, in a simplified form: it does not run your actual survey platform, so a rule that works here can still fail there if the platform’s syntax or question IDs differ. It follows one path per simulation, so covering all combinations is manual work — list them systematically, especially edge answers like “prefer not to say” and blanks. Loop protection stops infinite paths in the simulation, but a loop in a real survey traps real respondents, so treat any loop the simulator flags as a must-fix, not a curiosity.
Who it is for
This tool is for survey designers, researchers building screening questionnaires, and anyone who has ever launched a survey and discovered a routing bug from an angry respondent. Use it as a pre-launch checklist step, alongside a real pilot with five friendly testers who answer in unexpected ways.
Going further
A systematic test plan beats random simulations. For each branching question, simulate every answer option once, plus a blank, and record the path each produces in a small table — that table becomes your routing specification and your test evidence in one document. Pay special attention to questions reached from multiple paths: a question that two routes can reach may need different wording depending on how the respondent arrived, and some platforms handle that badly. Also test the end of the survey: every path should reach a defined end, a thank-you page, or a clear termination, because a path that simply stops feels broken to respondents and inflates drop-off in ways that look like disinterest but are really design failure. Pilot the survey with real people after simulation, because logic is only half the experience. Five pilot respondents answering aloud — saying what they think each question means — catch wording problems no routing table reveals: a question everyone misreads, an answer option nobody picks, a scale whose middle point means different things to different people. Fix wording first, then re-simulate the routing, because a changed question often changes the branches that follow it. Simulation plus pilot is the pair that makes a launch safe.
Related tools
Versión en español · Effect Size Converter · All free online tools.
Embed this tool on your website — free
Copy the code below to add this working tool to your own page. A small credit link stays with it — that’s all we ask.
