Branching

Two ways to build a branch

The word covers two mechanisms that behave very differently once a survey gets long.

Jump targets

An answer carries an instruction: "if they pick C, go to page 7". The path is explicit and easy to draw on a whiteboard. The cost is that the structure is now load-bearing — insert a page, and every jump that pointed past it may now point at the wrong thing. Surveys built this way tend to rot when edited by someone who did not build them.

Visibility rules

Each question carries its own condition and decides whether to appear. There is no path; there is a set of questions whose conditions are currently true. Reordering is safe, deleting a question breaks nothing else, and you can read any single question and know exactly when it shows.

NumoForms uses the second model. Practically that means there is no "jump to section" action to configure and no routing map to maintain — you write a conditional logic rule on each question or section you want gated, and the branch is whatever those rules add up to.

A worked example

A staff survey needs three different middle sections depending on role. Expressed as jumps, that is a three-way switch plus three "jump to the end section" instructions to stop people falling into the next block. Expressed as visibility rules it is three section rules:

• Section "Clinical" — show when Q1 is "Clinical".
• Section "Corporate" — show when Q1 is "Corporate".
• Section "Estates & facilities" — show when Q1 is "Estates".

Nothing else needs to know about the branch. Add a fourth role in six months and you add one section and one rule, rather than re-checking every jump in the survey.

Common mistakes

• Branching on something you have not asked yet. A rule can only read an earlier answer. If the branch depends on information you do not have, you need a screener first.
• Over-branching. Every branch splits your sample. Four branches on a survey with 200 responses gives you four sets of 50, and any cross-tab within a branch is smaller still. Branch on things you will genuinely analyse separately.
• Forgetting the branch in the analysis. A question only shown to one branch has a smaller base than the survey total. Reporting it as a percentage of all respondents is wrong, and it is an easy mistake to make from a spreadsheet where the blanks look like non-response.
• Branching where a filter would do. If everyone can answer the question and you only want to analyse part of the sample, ask everyone and filter afterwards. Branching throws data away permanently.

Branching and the respondent's experience

In the classic single-page layout, branches open and collapse in place, so people watch the survey shorten as they answer. In the conversational layout, one question at a time, a branch is invisible — a hidden question is simply never presented, so there is no sense of being skipped past anything. In the paged layout, a section whose questions are all hidden is not a screen anyone has to click through.

Because scoring only counts questions that were actually shown, a branch never costs a respondent points they had no chance to earn. See also completion rate, which is usually the metric that improves when branching is done well, and the conditional logic feature page for how rules are written.