Give the interface a consistent, predictable structure

What it is

In cognitive accessibility, “consistent structure” first means this step still looks like the same kind of page as the last one. People can find the primary action by place instead of re-parsing the layout every time the screen changes. Predictable structure parks title, progress, primary action, and back in a stable skeleton so comprehension is spent on the current task, not on inventing the page grammar again.

It is a tactic, not the whole argument about same-name-same-place, navigation mental maps, or the cost of breaking habits across releases. Stable names and positions across pages also cut learning cost, but that is a different layer of support. This leaf only requires that the skeleton inside a flow be expectable.

Why it happens

Re-parsing a new layout spends the same executive resource the decision needs. Once the skeleton holds still, location becomes a recognition cue: primary still lower-right, back still upper-left. Users with cognitive disabilities lean on that shortcut because reconstructing structure from labels is expensive and the goal is easy to drop mid-parse.

Content should change (identity on step one, address on step two). What changes is the field in the slot, not the slot. Swapping “Back / Next” left-to-right between adjacent steps looks like visual variety; it deletes the location cue just built—and the adaptation fails.

Studying it

Stack five consecutive steps of the same flow and look at the skeleton, not at whether the visual style feels “on brand.” Cognitive-accessibility heuristics check whether primary action, back, and help sit in the same relative region. A template probe is harder than a questionnaire: show step 3 to someone who has never used the product and ask where back and submit live. If they have to read the whole screen to guess, the skeleton is not doing the predicting.

Do not treat “did a redesign destroy returning users’ habits” as the main test for this leaf—that is a cross-version maintenance question. Test whether structure is predictable inside the current version.

Where it stops holding

One-off campaign landings were never a wizard skeleton; do not grade them as one. Fields inside a wizard should differ, or the steps are pointless; what must stay consistent is the chrome, not a photocopy of every form. Responsive breakpoints may reflow, but relative positions should stay stable within a viewport class. Personalisation that slides the primary action around undoes the adaptation directly.

Applying it

• Give the flow a fixed shell: title, step indicator, primary, secondary, and exit each own a dead slot. Do not swap them between steps.
• Do not put continue at the top on one step and the bottom on the next. Do not call back “Previous” on some steps and leave only the browser back button on others.
• Verify: align screenshots of consecutive steps and check that primary and back occupy the same region. Then show a middle step to someone who has not seen the rest and ask which control finishes the step and which reverses it. A wrong point means the skeleton is not predictable.

Related

• Same group: J4.07.1 Reduce the number of choices shown at once · J4.07.3 Restate and confirm before critical actions
• Nearby: J4.11 Consistency as cognitive support · J4.09 Reducing memory load · G2.01 Hierarchical navigation
• Search terms: predictable structure · cognitive accessibility · consistent layout