Conditional reveal must be predictable; fields must not appear or vanish without warning

What it is

Checking “Need an invoice” and seeing a title field, choosing “Other” and seeing a note box—those are conditional fields. The rule must be predictable: at the moment of the choice, people can guess what will be asked more or less, and the field appears or disappears in the same viewport on the same beat. Sudden means: the result of a choice happens off-screen, inserts after a delay of seconds, or a seemingly unrelated dropdown pulls away a whole block already filled. Whether hidden values still submit, whether reader order breaks, and whether nested branches become undebuggable are the next three steps.

Why it happens

People treat the currently visible field set as the map of the task. A conditional insert changes the map. If the change is advertised by the semantics of the choice (“Need an invoice” advertises an invoice block), the update is read as cause and effect. If it cannot be advertised—half a second after picking a country, three never-mentioned tax boxes appear below the fold—people treat it as a broken page or a mis-click. A second layer: disappearing hurts more than appearing. Appearing adds an ask; disappearing takes away answers already paid for and their spatial anchors. People still remember “that item was below,” scroll to find it gone, compensate by changing other items, or toggle the condition repeatedly. A long animation, or an insert far below the fold from the choice, breaks the causal chain in working memory. Predictable means choice, consequence, and place can be seen in one look.

Studying it

Before a choice, have people predict what happens next, then watch the actual reveal. Compare immediate nearby insert, delayed insert, insert below the fold, and pulling away a filled block.

Independent variables: reveal delay, distance of insert from the trigger, whether the disappearing block already has values, whether trigger copy advertises the consequence. Dependent variables: prediction hits, treating reveal as a fault, scrolling to hunt a vanished field, toggling the condition.

Lab tasks are short; a 300 ms delay may not show. Use a long form that must scroll. Do not count a scrambled reader announcement as “unpredictable”—that is reading order.

Where it stops holding

A legally or risk-required insert (a statement only allowed after a country is chosen) may not spoil the content in advance, but should still appear nearby and immediately, with “your choice requires this extra step.” When only a server computation can decide reveal, show “updating the form from your choice” first; do not wait in blank and then dump. Print has no dynamic reveal. Experts use conditions as shortcuts; instantly pulling an unsaved block still angers them. Experts need causality too, not teaching copy.

Applying it

• Write the consequence into the trigger (“Need an invoice; we will ask for a title”). Reveal in the same viewport next to the trigger; do not wait for scroll or a silent API insert.
• Do not pull a block that already has values unless the person clearly cancels that condition. On cancel, confirm or collapse the values in place so they can be opened again.
• On API delay, use in-place “updating this form,” then put new fields under the trigger.
• Verify by asking “what will happen” before the click, then clicking, and checking the field appears where guessed. Delete a filled invoice block because the country changed as an unpredictable counterexample. Insert below the fold after two seconds and confirm causality cannot be told.

Related

• Within the group: H1.14.2 When a filled field is hidden, say whether its data will still be submitted · H1.14.3 Dynamic reveal scrambles screen-reader linear order · H1.14.4 Too many nested branches make form logic hard to debug
• Adjacent: J4.11 Consistency and predictability as cognitive support · H1.02 Field order and grouping · E4.07 Accordions
• Search terms: conditional fields · progressive disclosure · predictability