Multi-step wizard / checkout

Multi-step flows — checkouts, onboarding, signup wizards — are the cleanest place to apply predictive preloading. The user's path through the steps is mostly linear; the next step is highly predictable from the current one. Fetching the next step's bundle and data while the user is filling the current one collapses the perceived transition time to near-zero.

This scenario sits in the 1 – 10 S band on each step, but the perception layer pushes most transitions into the 0 – 100 MS Card-Moran-Newell perceptual frame. Fitch's Fitch form-step preloading framing is the canonical reference; Miller 1968 Miller 1968 sets the budget the perception layer is collapsing.

What is happening

The list-fetch demo stands in for the step-to-step transition. For a real wizard, the tuned flow stacks several patterns:

1. Predictive preload of the next step's bundle and data once the user is ~70 % through the current step (matches the predictive-preloading pattern).
2. Optimistic step transition on submit — render the next step's layout immediately, validate in the background.
3. Skeleton fallback if the prefetch missed.
4. Preserved state on rollback — if validation fails on the previous step, return to it with the user's input intact.

What to tune

1. Pre-action — Next button echo within ~50 ms. The button doesn't wait for validation to acknowledge the press.
2. Predictive preload — once the user is ~70 % through the current step, the next step's bundle and data begin loading.
3. Step transition — optimistic redirect to the next step's layout. Skeleton fallback if the prefetch missed.
4. Validation — runs in the background. On failure, return to the previous step with all user input preserved.
5. Completion — focus lands on the next step's first input or main heading; step indicator updates with aria-current="step".

When perceived performance hurts you here

Predictive preloading on a wizard with a high abandonment rate is wasted work. If 40 % of users abandon between step 2 and step 3, half your prefetched bundles for step 3 are bytes the user never sees. Tune the trigger threshold against your funnel data — a steeply-dropping funnel argues for less aggressive preloading.

The other failure: optimistic step transitions on validation-heavy steps. If a step has a 30 % chance of server-side rejection (address validation, payment screening), the optimistic redirect rolls back visibly often. Skip optimism on those steps; show determinate progress instead.

Accessibility

1. Focus management on step transitions — focus the next step's first input or main heading.
2. Step indicator with aria-current="step" on the active step.
3. Preserve form state on rollback — never clobber user input.
4. prefers-reduced-motion for the step transition animation.

References