How to plan survey skip logic before you build it

Skip logic lets each respondent see only the questions that apply to them. A current customer skips the questions meant for people who left; someone who has never used a feature is not asked to rate it. Done well, branching makes a survey shorter and more relevant for everyone who takes it.

Built straight into a survey tool, one rule at a time, it tends to grow into something nobody can hold in their head: routes that end nowhere, pages nobody reaches, and follow-ups that depend on an answer the respondent never gave. The fix is to plan the flow first, on paper or a whiteboard, and build from the plan.

Decide whether you need a branch at all

Every branch is another route to test and a set of questions some people will not answer, which you then have to account for in the analysis. Before adding one, check whether something simpler does the job:

• A “Not applicable” or “I have not used it” option handles a single question that does not apply to everyone.
• A question that only a few people will want to skip can simply be optional.

Branch when a whole group of questions only makes sense for some respondents, or when different groups need genuinely different questions.

List the groups, then what each should see

Start with the respondents, not the questions. Write down the groups the survey has to treat differently: current and former customers, managers and individual contributors, people who attended the event and people who registered but did not come.

For each group, list the questions it should see, in order. The questions every group sees are the shared trunk; the rest are branches. If a group's list turns out to be the trunk and nothing else, that group does not need a branch.

Draw the flow as pages

Now draw it. Each box is a page, a set of questions shown together, and each arrow is a route between pages. Label every arrow with the answer that sends people along it. A few conventions keep the drawing honest:

• Put the deciding question before the branch. The answer has to exist by the time the route is chosen.
• Give every page a default way out. When no rule matches, respondents go on to the next page in order, so make sure that is somewhere sensible.
• Draw where every route ends: the normal ending, an early end, or, for a study with eligibility criteria, a screen-out.

This page-by-page shape matches how Plumeform routes people. Jumping to another page and ending the survey early are available on every plan. Showing or hiding a single question within a page, and screening people out, are Pro features.

Write every rule as a sentence

Before building anything, write each arrow out in words: “If the answer to question 1 is ‘I have never bought’, go to page 4.” Rules written as sentences are easy to read aloud and easy to check against the drawing.

Two details deserve a sentence of their own. The first is when a rule is checked, and what happens when more than one could apply. In Plumeform, a routing rule is checked when the page holding the question it tests is submitted, and the first matching rule wins, so the order of competing rules matters and should be written down. The second is combined conditions. Decide whether a rule needs all of its conditions or any one of them, because “all” and “any” can send the same respondent to very different places.

A worked example

Take a short customer survey for three groups: current customers, people who cancelled, and people who never bought. Page 1 asks “Which best describes you?” with those three answers. Page 2 holds the questions for current customers, page 3 the questions for people who cancelled, and page 4 the questions for everyone.

Written as sentences, the first rules are:

1. 1If the answer on page 1 is “I cancelled”, go to page 3.
2. 2If the answer on page 1 is “I have never bought”, go to page 4.

Current customers match neither rule, so they carry on to page 2. The drawing shows what the two sentences hide: when current customers finish page 2, the next page in order is page 3, the questions for people who cancelled. They need an arrow of their own, from page 2 to page 4.

Because a rule is checked when the page holding its question is submitted, that arrow has to be a rule on page 2 itself. One way to write it: if the first question on page 2, a required one, is answered, go to page 4. None of this is difficult once you see it. The point is that the drawing shows it, and a list of rules does not.

Trace every route for four mistakes

With the drawing and the sentences side by side, trace each group through the survey and look for these:

1. 1A loop. Two pages that jump back to each other can trap anyone who matches both rules.
2. 2A dead end. A route that stops before reaching any ending, or a page that no route leads to.
3. 3A missing answer. A rule, or an earlier answer inserted into later wording, that depends on a question this respondent skipped or never saw.
4. 4A stale reference. A rule written against an answer option you later reworded or deleted.

Plumeform's builder catches some of these as you edit. Its pre-flight check warns when logic can send respondents round in a loop, and it stops a publish when a rule points at a question or page that no longer exists. What no checker can tell you is whether a route does what you meant, which is what the drawing is for.

Plan the analysis with the flow

Branching creates missing answers by design. If only current customers see the renewal questions, the renewal results describe current customers, and the base for every percentage is the people who were shown the question, not everyone who took the survey.

Write the base next to each branch on the drawing, so nobody later reads a percentage of a subgroup as a percentage of all respondents. In Plumeform's results, a question counts a blank only when the respondent was actually shown it, so questions hidden by logic do not inflate the number of unanswered. The help article on reading results explains how each count is made.

Turn the drawing into a test table

Make a table with one row per route: the answers that trigger it and the pages it should show, in order. Walk each row in the preview and tick it off. Add rows for someone who matches no rule at all, and for someone who goes back and changes an earlier answer: both are easy cases to forget when you designed the routes yourself.

Once the survey is published, run the most important routes again on the live link in test mode, by adding ?test=1 to the survey's address. The runs are flagged as tests and kept out of your results. The pre-launch checklist covers everything else worth checking before the link goes out.

Then build it

With a plan in hand, building is the quick part. In Plumeform, rules live in the builder's Logic tab and read as sentences: when a condition holds, then do something. The help article on setting up branching walks through each action, and a survey that repeats questions for each item someone selected is covered in repeated groups.