Display logic and conditional questions in SurveyEngine

Display logic makes surveys adaptive - showing only the questions relevant to each respondent. Without it, respondents see questions that do not apply to them.

How to implement display logic in SurveyEngine for conditional question display and branching.

Ben White, 08.07.2026

The problem with one-size-fits-all surveys

Display logic conditions a question or page's visibility on the responses to earlier questions. A screener question that asks 'Do you currently take medication for your condition?' can then trigger different question sets depending on the yes/no response.

Without display logic, surveys present every question to every respondent. This increases survey length, reduces data quality, and creates data with missing values that must be handled in analysis.

Display logic in DCE research

Display logic reduces respondent burden by showing only relevant questions. A 40-question survey with well-designed display logic may present only 20 questions to any individual respondent.

Display logic also ensures data quality by preventing logical impossibilities - for example, questions about dosing frequency appearing to respondents who have not yet confirmed they are taking the relevant treatment.

TLDR Quick links

Survey building tutorial

Software documentation

Open a free account

Setting up display logic in SurveyEngine

Step 1: Map the branching logic before building the survey. Draw a decision tree showing which questions are conditional on which responses.

Step 2: Write display conditions using SurveyEngine's expression language. The syntax {Q1} == 'Yes' shows a question only if Q1 was answered 'Yes'.

Step 3: Test every path through the logic using the preview mode. Do not assume logic works correctly without testing each branch.

Step 4: Document complex logic in the analysis plan. Logic that took time to implement will need explanation when the data is analysed months later.

Step 5: Keep logic as simple as possible. Complex nested conditions are harder to test and more likely to contain errors.

Worked example - health DCE with eligibility screening

A patient preference study screens for disease severity using a validated score. Respondents with mild disease (score < 10) see a different attribute set from respondents with severe disease (score >= 10). Display logic routes each respondent to the appropriate choice task version.

The two choice task versions share common attributes but differ in the severity-specific attributes included. The branching is documented in the analysis plan and the logic is tested with 30 internal test completions before pilot fieldwork.