Survey Skip Logic: How to Design and Test Branching Paths

Skip logic, also called branching or conditional routing, lets a survey show each respondent only the questions that apply to them. Someone who says they have never used a product skips the questions about how satisfied they are with it, and someone who says they manage a team sees a section about managing a team. Done well, branching makes a questionnaire shorter, more relevant, and less tiring to complete, which tends to be good for both the respondent and the data.

The cost is that every branch is a separate path through the survey, and every path is something that can break. A condition that points to the wrong section, a route that never reaches the submit button, or a follow-up that fires for the wrong group will not raise an error on the screen. The survey will simply collect the wrong answers, or none, from whoever happens to take that route.

This guide covers how to plan branching before you build it, what branching does to the data you collect, and how to test every route before real respondents arrive.

Plan the paths before you build them

It is tempting to add conditions directly in a form builder as you go, but branching is much easier to reason about on paper first. Write down each question that controls routing, each possible answer, and where that answer should send the respondent. A simple table with one row per condition works well, and a flowchart helps once there are more than a few branches. The exercise usually exposes problems straight away, such as an answer option with no destination or two conditions that contradict each other.

Keep the rules as simple as the research question allows. Routing that depends on a single earlier answer is easy to explain, build, and verify, while routing that combines several answers multiplies the number of paths you have to test. Make sure every path ends at the submit button, and decide deliberately where each branch rejoins the main questionnaire, because a branch that never merges back can quietly skip later sections that everyone was supposed to see.

Pay particular attention to the question that does the routing. If it is ambiguous, people will misroute themselves, and no amount of correct logic downstream will fix that. A filter question such as whether someone has bought anything from you in the past year needs a clear time frame and clear answer options, including a way out for people who are unsure. This is also where a pretest with real respondents pays off, since it shows whether people interpret the filter the way you intended.

Branching also shapes the experience of moving through the survey. The W3C's guidance on multi-page forms recommends splitting long forms into logical steps and telling people where they are in the process. With branching, the total number of pages differs from one respondent to the next, so a progress indicator that counts pages can jump or stall, and it is worth checking that yours still makes sense on the shortest and longest routes.

Understand what branching does to your data

A survey with skip logic produces data with deliberate gaps. A blank answer can mean that the respondent never saw the question or that they saw it and skipped it, and those are very different things. Decide before launch how each case will be recorded and coded, so that "not asked" does not get counted as "no answer" in your analysis. It also means the number of people answering a question varies from question to question, and any percentage you report should be clear about which group it describes.

Branching can change the context in which a question is asked, too. Pew Research Center notes that answers can be affected by the questions that precede them, which is why it randomizes the order of some questions and answer options. When one group reaches a question after a block about problems they have had and another group reaches it directly, a difference between the groups may partly reflect that different path. That does not make branching wrong, but it is worth keeping in mind when you compare groups that took different routes.

Test every route before launch

Start with the table of conditions you drew up during planning and walk through each route by hand, on both a desktop browser and a phone. For each route, confirm that the right questions appear, that the wrong ones do not, that required questions can actually be answered, and that the survey ends where it should. Then go back partway through and change an answer that controls routing, since respondents do this, and check that answers entered on the branch they abandoned are not still recorded when they submit.

Hand testing is good at catching obvious breaks, but it rarely covers every combination of answers, and it only produces a few rows in the results. Volume testing fills that gap. Autofiller can submit a batch of generated responses to a copy of a form you own or are authorized to test, with answers chosen at random or weighted towards the options you specify. Weighting is useful here because it lets you make sure that uncommon answers, and therefore uncommon branches, appear often enough in the batch to be checked.

The results are where logic errors become visible. For every branch, check that some responses reached it, and that responses which took one route have nothing recorded for questions on another. A single row with an answer to a question its respondent should never have seen points to a condition that is wired incorrectly. Checking the export this way also tests the other end of the process, since you can confirm that the not-asked codes you planned are what actually appears in the file.

These submissions exist only to test the survey. They are not respondents and must never be analyzed or reported as though they were, so run them on a copy of the form or remove them completely before launch. Autofiller's Terms prohibit using it to skew or interfere with genuine surveys or research.

Finally, retest after every change. Moving, deleting, or duplicating a section can change where an existing condition points, and it is easy to fix one branch and break another without noticing. A quick pass through the route table, followed by a fresh test batch on the revised copy, takes far less time than cleaning up after a broken branch in live data. Once the survey is live, the guide to survey response quality covers how to screen the answers that come in.