Branching logic: how to ask the next question

Branching logic is the rule that decides where a form sends someone based on what they answered. Switching it on takes a minute in any tool. Designing it well is a different job, and it is where most funnels break without anyone noticing.

Search for conditional logic and you will find click instructions: which button to press, how to enable it in your builder. None of those pages cover what goes wrong afterwards, when two rules overlap or when a carelessly chosen greater-than silently drops half your respondents.

This guide is about the design. How a rule is built, which comparison fits which situation, the four mistakes that show up in real funnels, an accessibility rule almost nobody follows, and how to verify the branching does what you intended.

What is conditional logic in a form?

Conditional logic is a set of rules that compares an answer against a value and changes the form's path depending on the result. Without it, everyone sees the same questions in the same order. With it, the form adapts to each person.

The three names you will meet mean roughly the same thing in different contexts. Skip logic usually describes skipping irrelevant questions. Branching logic describes sending people down different paths. Conditional display means showing or hiding a block within the same screen. In practice all three are the same engine applied to different decisions.

The idea is neither new nor a marketing invention: it comes from interface design. Jakob Nielsen named the pattern progressive disclosure in 2006, and his definition is the shortest one available: "initially, show users only a few of the most important options. Offer a larger set of specialized options upon request" (Nielsen Norman Group, 2006). A form with conditional logic is that idea applied to questions.

Cutting questions matters more than splitting steps

This is the part that changes your priorities. Baymard Institute's research on e-commerce checkout is blunt: "the number of form fields in a checkout impacts overall usability far more than the number of steps". The average flow they measured in 2024 has 11.3 fields when 8 would be enough for most sites (Baymard Institute, 2024).

That is checkout research, not lead capture, so the conclusion should not be stretched. But the direction is useful: breaking the same form into five screens solves nothing by itself. What solves it is the person answering fewer things, and that is exactly what conditional logic delivers when designed well.

How is a branching rule built?

Every rule has three parts: a left side (what you are checking), a comparison (how you are checking) and a right side (what you are comparing against). The left side can be a stored answer, an accumulated score, or even a calculation done on the spot.

A single rule solves little. Grouping is what solves. Several conditions inside one group work as AND: all must be true. Several groups work as OR: one match is enough. The first group that matches wins, and the rest are never evaluated.

That structure is what lets you write a rule like "send to the proposal screen if budget is above ten thousand and the timeline is this month, or if the company has more than five hundred employees, regardless of the rest".

Which comparison should you use?

Picking the wrong comparison is the most common mistake and the quietest one, because the form keeps working. The seven available cover every case, and each has its own trap:

The practical rule: whenever you think "above X", ask whether someone who landed exactly on X is in or out. When unsure, use the inclusive version. An exclusive cutoff at 100 silently discards everyone who scored exactly 100, and that group tends to be large precisely because 100 is a round number you picked.

The four mistakes that break branching

Overlapping groups. If two rules can be true at the same time, order decides the outcome. The form does not warn you. You find out when a lead lands on the wrong screen and nobody can explain why. The fix is making conditions mutually exclusive, or putting the most specific one first on purpose.

Orphan branches. A screen no rule can reach. It exists, it was written and reviewed, and nobody ever sees it. This happens every time you rewrite a funnel and forget to update the old rules.

Conditions on questions that can be left blank. If the question is optional and a rule compares its answer, whoever skipped lands in a state you did not plan for. Either make the question required, or write a rule for the empty case.

Comparing text when you meant numbers. "10" and "9" compared as text behave differently from 10 and 9 compared as numbers. If the field accepts free typing, the odds of dirty input are high. Use numeric fields with a declared type when the value is a number.

The accessibility rule almost nobody follows

If your form jumps to the next screen on its own when someone picks an option, you are doing what accessibility guidelines call an automatic change of context. And there is an explicit criterion about it.

WCAG 2.2, criterion 3.2.2, states: "changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component" (W3C). It is Level A, the most basic of the three, and the stated intent is to ensure that filling a field has predictable effects.

In practice it means two simple things. If you use auto-advance, say so beforehand, with a line like "choosing an option takes you to the next question". And if your builder lets you delay that advance by a few seconds, use it: it gives people time to register what they picked.

How do you verify the branching is right?

Test by path, not by screen. List the possible outcomes of the funnel, usually three or four, and walk one complete path for each. It is faster than it sounds and catches nearly everything.

Then test the edges on purpose. Answer the exact value of every cutoff you wrote. That is where a wrong comparison shows itself. A funnel with three cutoffs has three edges, and testing all three takes under five minutes.

Finally, look at the distribution after a few days. If one outcome has almost nothing in it, its rule probably never matches, or matches after another rule that swallows it.

When branching logic is not worth it

Short forms do not need it. If there are three fields and everyone answers the same three, branching adds maintenance and returns nothing. Conditional logic pays off when there is more than one kind of respondent and you treat each one differently afterwards.

It also does not pay when you will not use the information. Branching to show a slightly different closing message is decoration. Branching to change who receives the lead, which offer appears, or which follow-up fires is what justifies the work.

Design the rule before you configure it

Branching logic is cheap to switch on and expensive to fix once traffic is flowing. Before opening the builder, write one line for each outcome the funnel needs, then build the rules that lead there. Check the comparisons at the edges and walk one complete path per outcome.

FoxForm, a builder for quizzes and lead capture funnels, treats this layer as the product itself rather than an upgrade: conditions group with AND inside a group and OR between groups, and the same engine controls both navigation and the display of blocks inside a screen.

We checked the list of comparisons against the product's public API contract before writing this piece, and it matches the table above exactly.

Start free on FoxForm, no card, and build the whole branch before you send traffic.