Conditional logic: show the right question to each participant

A survey becomes tiresome when it asks for details about experiences a person has never had. Conditional logic allows you to direct participants based on previous answers. It reduces irrelevant questions but also makes the study harder to review if rules grow without organization.

Design the paths before configuring

Imagine a hypothetical survey about importing contacts into a CRM. Those who have imported can report on the experience; those who have never done so can explain how they currently add contacts.

Start with an experience question. Design two short sequences and determine where they meet again. This map can be a simple list, as long as it allows all paths to be identified.

Avoid creating a rule for every detail without checking its usefulness. If the two branches end up asking the same question with minor changes, it might be possible to simplify the script.

Differentiate skip, completion, and disqualification

A skip leads to another relevant part of the study. A completion ends the expected participation. Disqualification indicates that the person does not meet the required profile.

In UXTap, conditional logic accounts for these actions according to the configuration. They should not be used as equivalents, because they change the interpretation of participation and can affect the return to a recruitment panel.

In the CRM example, never having imported contacts does not mean being outside the target audience. It might precisely be a condition the survey wants to understand.

Be careful with multiple-choice answers

Questions that allow multiple options require attention to the rule used. “Selected import” is different from “selected exactly import and manual entry”.

UXTap includes conditions for the presence of an option and set comparisons. Check if the configuration represents the script's intention.

Prepare cases where the person selects one option, several, or a combination you didn't expect. An exception path might only appear in these situations.

Test as different participants

The preview should be traversed more than once. Make an attempt for each branch and record what was seen.

Use a simple matrix:

Add the boundary cases of your study. If there are multiple rules for the same question, review the priority and avoid relying on combinations that are difficult to explain.

Analyze each question with its own base

Someone who didn't see a question didn't necessarily fail to answer it. They might have followed another path.

When communicating a result, identify the exposed audience and the number of valid responses. Do not automatically use the study's total as the denominator for all blocks.

If the logic was modified during data collection, keep the versions identified. A change in the path can alter the composition of responses even when the question text remains the same.

Design the paths for an import survey

In the hypothetical CRM, the first question identifies whether the person has imported contacts. For those who answered yes, investigate the last import and the difficulties encountered. For those who answered no, ask how contacts are added today. Afterward, both groups can arrive at a common question about the need to keep the database updated.

Write this design in sentences before configuring rules. For each question, record who should see it, which answer determines the exit, and where the path continues. A useful rule should be explainable without relying on the visual position of blocks in the editor.

Add less obvious situations: the person tried to import but didn't complete it; another team member did the import; the participant doesn't remember. Decide if these cases belong to an existing path or need a clarifying question. Do not classify lack of experience as disqualification when it is part of the audience you want to understand.

Review multiple-response conditions

Imagine a question about how contacts are added, with options like spreadsheet, manual entry, and integration. A person can select more than one. “Selected spreadsheet” and “selected only spreadsheet” represent different conditions. The first includes combinations; the second requires a specific set.

Write examples of answers that should activate each condition. Then, also test answers that should not activate it. If two rules can be true at the same time, check the order and the effective destination in the preview. Do not rely on an intuitive reading of labels when the effect changes the entire path.

If you change options or remove a question, review the related rules. A branch might still appear correct in the overall design and yet point to a condition that no longer makes sense. Use instrument review as part of any script change.

Assemble a path testing table

Create a row for each relevant scenario: imported successfully, attempted without completing, never imported, uses various registration methods, and doesn't know how to answer. Record the first answer, the expected questions, and the correct termination. Execute each row as a participant, without adjusting the configuration in the middle of the attempt.

Check that no path presents impossible-to-answer questions, such as asking the reason for an error to someone who has never attempted an import. Also observe if any combination terminates too early or repeats a question unnecessarily. The table makes the review more objective than just clicking through the most frequent path.

In the analysis, report the base of who received each question. If only people with import experience saw an open-ended question about errors, the total for that question does not represent all participants. The absence of a response from someone who followed another path is not abandonment. Relate the logic to quotas and recruitment returns when there are specific terminations.

Review the necessity of branches

After the pilot, remove rules that do not contribute to the decision. A short and understandable script tends to be easier to maintain and explain.

To get started with UXTap, choose a single question that determines different experiences. Design the two paths, configure the conditions, and execute both in the preview. Before publishing, confirm that each participant receives relevant questions and reaches the correct termination.

Align the script's outputs with the quotas and recruitment plan. Check the results resources to keep the base of each question understandable.

Frequently asked questions about branching

Is skipping a question the same as ending the study?

No. A skip directs participation to another point in the script; a termination ends that path. A disqualification still indicates a different condition from completion. Choose the action based on the meaning of participation and test how it appears to the person and the recruiter.

Can I analyze all open-ended questions with the same denominator?

Only if all were presented to the same eligible base and you have defined a coherent inclusion rule. In a questionnaire with different paths, each question may have a specific audience. Present who had the opportunity to answer before comparing frequencies or absence of response.

When is it worth simplifying the logic?

Simplify when the branch does not change the necessary information or when the cost of testing and interpreting paths outweighs its usefulness. A well-contextualized common question can resolve the case. Preserve branches that avoid irrelevant activities, without creating an extensive tree just because the editor allows you to configure it.

Create your UXTap account to prepare your first study.