Start with decisions rather than screens
Write the user decision for each stage in one sentence. For a video workflow, choosing a character and arranging scenes are distinct decisions even if both use a grid. If a stage contains several unrelated decisions, the layout needs a stronger hierarchy or the workflow needs a different boundary.
The output of this exercise is a small map of decisions and dependencies. It is a design tool, not a promise that users will follow the same route every time.
What happens when an earlier decision changes?
Consider a hypothetical creator who changes the narrator after reviewing scenes. The interface should explain whether the change affects only future generation or also invalidates existing output. That rule belongs next to the action, before the user commits.
Document the effect of each backward transition. A simple review sheet can record the changed input, the affected output, the preserved work and the action required next. Missing entries often reveal an ambiguous product rule.
- What changes immediately?
- What remains valid?
- What must be generated again?
- Can the user review or cancel before replacing an output?
How do you make waiting understandable?
Name the operation that is running. If the system does not provide a trustworthy percentage, avoid presenting one as exact progress. A state such as processing is more honest than an animated counter that has no relationship to completion.
Keep completion and failure understandable when the user returns to the step. A transient toast may help at the moment of completion, but it cannot carry all the information needed to resume work later.
Keep the recovery path inside the task
For each failure, identify the smallest action that can recover the task. A retry should have a clear scope; a request to change an input should name that input. Preserve the user’s editable work where the product rules allow it.
Status messages can be announced with a polite live region without moving keyboard focus. Use this for meaningful changes rather than a constant stream of progress announcements. The MDN reference explains the underlying announcement behaviour.
Review a round trip before shipping
Test one realistic round trip: complete a stage, move forward, return, change an input and continue again. Repeat the sequence after a failed operation and at a narrow viewport. Record what the user can see, not just what the application stores.
The goal is a predictable set of consequences. A polished forward journey is incomplete if revisiting a decision leaves people unsure which work is still usable.