Whether completed steps are revisitable must be explicit
Aliases: wizard back · locked steps
What it is
After several steps are done, people often need to change a value already entered. Whether completed steps are revisitable must be readable from the stepper itself: which steps can be tapped to edit, which are already locked. When the policy is vague, some people dare not change an address for fear of voiding the order, and others hammer earlier dots and nothing happens. This is not “how many steps”. It is whether a commitment can be undone.
Why it happens
In a linear flow, later steps depend on earlier answers: change the shipping country and the freight-and-tax step may be void. If the system allows return, it must be ready to recompute the cascade and show “you changed this, the later work will be redone”. If it does not allow return, completed steps need a lock signal and another way out (cancel the whole order, contact a human). With no signal the stepper looks like navigation and is actually read-only progress; click expectations are betrayed.
Revisit can also differ by step: contact details editable, a signed agreement not. That mix most needs per-step marking, not a global rule written elsewhere. A Back-to-previous-step button and tapping a past node on the stepper should obey the same policy, or one path edits and the other does not, and the policy cannot be learned.
Where it stops holding
After a successful payment, an electronic signature, or a regulated irreversible confirm, revisit should close even if the stepper is still on screen. Long draft forms should almost always be revisitable; a lock turns one mistype into doing the stretch again. When a branch skipped a step, revisit must not walk people into a step that never applied. Read-only review (a submitted application) may let people tap steps to look; that is viewing, not editing, and needs different copy.
Applying it
- Completed revisitable steps look activatable on the bar; a tap returns to that step with values kept. Non-revisitable steps look locked or like pure status; a tap gives a reason rather than silence.
- If a change will invalidate later steps, say which steps will be redone and confirm before clearing.
- Clicks on the stepper and the Previous button obey the same revisit policy.
- How to check: on the last step, try to change a field from the first. If revisitable, it should succeed and later effects should be visible; if not, the reason should appear at the click. No response, or silently dropped data, means the policy was not expressed. Then check that Previous and tapping a node agree.