Use dependent questions only to omit follow-up steps that are demonstrably irrelevant. Keep the logic one level deep, make conditions visible to administrators and test what happens to an earlier answer when the main choice changes.
Conditional forms feel shorter but can become unpredictable. If question C depends on B and B on A, clients do not understand why information appears or disappears. Administrators also struggle to explain which route someone followed.
State the condition in ordinary language
Alongside the technical relationship, write a sentence: ‘Show the drainage question only if the dishwasher option is selected.’ A process owner can then assess the rule without IDs or a configuration screen. Yindle Portal can make a question depend on one selected option in another question.
That single level is a useful boundary. If deeper decision trees are needed, consider separate steps or forms. More logic does not automatically improve the experience.
Decide what happens to hidden answers
Suppose someone selects ‘yes’, answers a follow-up question and then changes back to ‘no’. The earlier answer must not silently continue counting towards pricing or processing. Choose deliberately between deleting it, retaining it temporarily but excluding it, or requiring confirmation again after a change.
Retained information may help auditing and support, but the active submission must use only visible, valid answers. Tell clients when a choice clears other input.
Worked example: fictional conference organiser
In this fictional example, conference agency Samenkomst asks whether an attendee is booking a stand. Floor area and electricity connection appear only after ‘yes’. The question about three-phase power does not then depend conditionally on the electricity connection; that complexity sits within one clear stand step with an explanation.
Attendee Mei first selects a twelve-square-metre stand and later changes to ‘no stand’. The floor area no longer counts and the final check shows no stand costs. If she selects a stand again, Mei is asked to recheck the details.
Draw a small rule card
For each dependent question, create a card with:
- the parent question and exact activating option;
- the reason the follow-up question is otherwise irrelevant;
- the behaviour when going back or changing a choice;
- the effect on required fields, price and progress;
- the wording administration and support can use to explain the route.
If the reason does not fit in one sentence, you are probably trying to capture several processes in one form.
Test journeys, not isolated fields
Create a test route for each combination: no immediately, yes and fully complete, yes then back to no, save a draft and change it later, and open on a second device. Check the final overview, total, required fields and administration view.
Do not simply report ‘question unanswered’ when its condition was never active. Use an applicability column in exports or deliberately omit the question. This prevents support from asking clients about an invisible field.
Circular logic is another pitfall. Question A must never depend on an option in B if B itself appears through A. Block this in administration and visualise the relationship as a simple arrow. Many arrows probably mean the form is too complex for a single screen journey.
Pay attention to required fields. A follow-up question may become mandatory when visible, but must not block a hidden draft. Validate using the same conditions as the interface. Check on the server too; a hidden HTML element alone is not a reliable rule.
Provide support with a readable route summary. For example: ‘Three-phase power appears after stand = yes and power supply = heavy-duty.’ Do not share technical IDs. Staff can then explain why an attendee did or did not see a question without recreating the form.
During the pilot, measure how often people go back after a follow-up block appears. Frequent returns may mean the main option inadequately explains the additional information or costs involved. Put that consequence earlier alongside the choice so clients are not surprised only after clicking.
If logic differs by customer group, consider separate questionnaires instead of dozens of exceptions. The shortest configuration is often easiest to test and explain later.
Read how forms fit within a broader customer portal journey and explore Yindle Portal. To simplify a complex decision tree, walk through both the longest and shortest routes with Yindle.