Across the surveys we run, a linear questionnaire that asks everyone the same twenty questions tends to bottom out at a completion rate in the low twenties. The same survey with branching, where each respondent only sees the questions that apply to them, frequently clears the sixty-percent mark. The same data, several times the responses.

Branching is the single highest-leverage thing you can do to a survey. It is also where most surveys go wrong. This is the working guide to conditional logic that respondents actually finish.

Why does branching beat just making the survey shorter?

The intuitive fix to a low-completion-rate survey is to make it shorter. That works, but it loses data. A better fix is to make it personal — to ask the same person fewer questions, but ask each person the right questions.

The example that makes this concrete: a customer feedback survey for a tool with three plan tiers (Free, Pro, Team).

The linear version asks twenty questions, ten of which are irrelevant to most respondents. A Free user is asked about the team admin panel they have never seen. A Team admin is asked about onboarding friction they passed two years ago. Both groups bail at question eight because they are answering questions that do not fit them.

The branched version asks five questions to figure out who you are (plan, role, tenure, primary use case, last feature touched), then routes each respondent to a tailored set of six follow-up questions. Same total signal collected, but each respondent only spends three minutes instead of fifteen. The completion-rate uplift is consistent with the Pew Research Center's web survey design guidance, which finds question count to be one of the strongest predictors of drop-off.

Which branching patterns actually work?

In our experience, three patterns cover the bulk of useful conditional logic.

Pattern 1: Skip by qualifier. A screening question early in the survey routes respondents around irrelevant blocks. "Are you a customer of ours?" → if no, skip the customer satisfaction section. "Did you complete onboarding?" → if no, skip the onboarding feedback section.

This pattern is cheap to design and the highest-impact one to start with. Even one skip rule can cut average survey length in half.

Pattern 2: Branch by score. A scoring question (NPS, CSAT, a 1–5 rating) routes respondents to different follow-up questions based on the score. Detractors get "what would you fix first"; passives get "what would have made this a 9 or 10"; promoters get "what would you tell a peer". Three branches, three different conversations, no respondent sees the wrong one.

Pattern 3: Loop by attribute. "Which of these features do you use? Pick all that apply." For each selection, ask one follow-up question about that feature. The respondent who picks two features answers two follow-ups; the one who picks five answers five. The survey adapts to the breadth of their usage.

Beyond these three patterns, branching usually gets more complex than it is worth.

What should you avoid branching on?

Two anti-patterns to avoid:

Don't branch on demographics if they don't change the question. Asking different questions to "marketing" and "engineering" only makes sense if the questions are actually different. If the next question is "how satisfied are you, 1–5?", both groups can answer it. Splitting them by role just makes the survey harder to maintain.

Don't branch on the previous answer's exact value. "If they said '3' on question 4, ask question 7." That works for two questions. By question fifteen, the branching graph is unreadable and nobody knows what flow a respondent actually took. Branch on ranges (low/mid/high), not on exact values.

The rule of thumb: if you cannot draw the branching graph on one page of paper, the survey is over-engineered.

How do you keep a branched survey maintainable?

A survey with five branches is easy to maintain. A survey with twenty branches and three years of history is unmanageable. Three habits that keep the maintenance cost down:

  1. Name every branch. Not "Branch 1", "Branch 2" — names like "Detractor follow-up", "Free user onboarding", "Team admin feature deep-dive". When you come back six months later, the names tell you what the branch is for.

  2. Document the entry condition. For each branch, write one sentence explaining who lands on it. "Respondents who scored 0–6 on the NPS question." When you change the upstream question, you immediately see what downstream branches break.

  3. Audit the unreachable branches. Twice a year, look at the response counts per branch. If a branch has zero responses in six months, either the upstream condition is broken or the branch is no longer needed. Delete or fix it.

The first two are five minutes of work when you design the branch. They save hours every time the survey is touched.

Page breaks and progress bars

A subtle UX point: in a branched survey, the progress bar lies. The respondent does not know how many questions they will see, because that depends on their answers. A standard progress bar shows "Question 5 of 20" when in reality, due to skips, they will only see 10.

Three options, in order of how much they help:

  • Hide the progress bar entirely. Counterintuitively, completion rates go up. Respondents stop calculating whether the remaining time is worth it. The effect is documented in Nielsen Norman Group's progress-indicator research — accurate progress signals help, misleading ones actively hurt.
  • Replace it with a step indicator: "Almost done" / "Just a few more". Vague, but not misleading.
  • Show estimated time remaining instead of question count. "About 2 minutes left." More honest if you can compute it.

The classic "5 of 20" progress bar is the worst of all three options on a branched survey. It promises a length the respondent will not actually see, and they stop trusting it.

When is a linear (non-branched) survey still the right choice?

Branching is not always right. Two cases where a linear survey is still the better tool:

  • Very short surveys (5 questions or fewer). Branching overhead exceeds the benefit. Just ask everyone everything.
  • Standardised research where you need every respondent to answer every question for statistical comparability. Branching here introduces selection bias that breaks the analysis.

For everything else — feedback, lead qualification, application forms, onboarding — branching is the default that wins.

Related from this desk

The shape of a branched survey that ships

  • Five or fewer screening questions at the start to figure out who the respondent is.
  • Three or four branched sections, each tailored to the screener's answers.
  • One open-text question at the end for everyone.
  • Named branches, documented entry conditions, audited twice a year.
  • No progress bar showing question counts.

Built that way, in our experience, a survey that used to land a couple of hundred responses often clears several times that. Same questions, asked of the right people.