Multistep Forms and Context Preservation

1) Principles

1. One goal is several natural steps. Divide not by database tables, but by user logic: "Data → Confirmation → Completion."

2. Each step is a complete meaning. Do not crush too finely: 3-5 steps are optimal.
3. Transition should not reset context. All fields, selections, and files are saved.
4. Let me go back. Back - no data loss.
5. Track progress. Progress bar, step header and clear CTAs.
6. The user can leave and return. Draft - locally or on the server.

2) Multi-step architecture

Client state: local store (for example, React Context/Redux/Signal) or temporary storage ('sessionStorage', IndexedDB).
Server state: create a draft with 'draft _ id', save after each step.
Security: 'draft _ id' is associated with the user and expires in N hours; data is encrypted at rest.

• 'currentStep '- index of the current step;
• 'completedSteps' - list of completed;
• 'errors' - per-step errors;
• `progress = current / total`.

js const formState = {
draftId: "d-84f...",
currentStep: 2,
steps: [ { id: "personal", completed: true }, { id: "kyc", completed: false } ],
data: { name:"", idPhoto:null },
lastSaved: Date. now()
}

3) Step and layout design

Structure: vertical navigation (desktop )/progress bar from above (mobile).

The visible name of the step is "1. Personal data," "2. Proof of identity."

• The main one is "Next "/" Continue. "
• Secondary - "Back."
• At the last step - "Complete "/" Send. "

• Use' aria-current =" step"'.
• Show% if steps are uneven.
• Add a "Can come back later" prompt.

4) Save context and data

Autosave

• field change (with a debunk of 500-1000 ms);
• Move to the next step
• loss of tab focus.

• locally ('localStorage '/IndexedDB) - if the form is short;
• server - for CCM/payments/questionnaire.

js const saveDraft = debounce(async (data) => {
await fetch('/api/draft', { method:'POST', body: JSON. stringify(data) });
}, 800);

Recovery

When opening the form, look for a draft ('draft _ id' or local key).

• In case of conflict (new fields) - "update draft" with highlighting of changes.

5) UX transition patterns

Go forward only after local step validation.
Back - without confirmation if there is no data loss.

In case of a network error, save it locally, show "Restore at the next connection."

Do not change the URL arbitrarily: '/form/step/2 '→ is convenient for navigation/recovery.
Support'Ctrl + Enter'for a quick transition to the next step.

6) States and visual cues

In progress: gray/active indicator, the step is clickable only if the previous one is completed.
Completed: green tick/icon; can be opened for editing.
Error: red outline, text under the field and in the progress line.
Disabled - Steps after the current one are hidden or unavailable.

html
<nav aria-label = "Progress">
<ol class="steps">
<li class = "done "> <span> 1 </span> Data </li>
<li class = "current" aria-current = "step "> <span> 2 </span> Documents </li>
<li> 3 Verification </li>
</ol>
</nav>

7) A11y and availability

'aria-current =" step"' for the active step.
The step change is voiced by 'aria-live = "polite"'.
Keep focus within the current step; during transition - move to the header.
Tab and Enter navigation is predictable; Esc should not lose context.
For step-by-step progress bars, use 'role = "list"', 'role = "listitem"', and 'aria-label' for the step.

8) Error and interrupt behavior

Network failure: "Connection lost. The data will be saved locally.
Timeout: repeat automatically in 3-5 s; on failure - offline draft.

Session break: after login → "Continue from the last step."

Step error: save partially filled fields, highlight problematic ones.

9) Parallel sessions and security

'draft _ id'is unique per user.
When opening a new tab - suggest "Another session is open. Update or continue here.
For CCM/financial forms, the data is encrypted on the client (AES/GCM) before saving the draft.
Delete drafts by TTL (for example, 7 days of inactivity).

10) iGaming Scenario Examples

10. 1 CCM/verification

1. Personal data → 2. Documents → 3. Check → 4. Completion.

Autosave after uploading a photo.
Recovery from the test step after a break.
Status "waiting for confirmation" with indicator.

10. 2 Payment/deposit

Steps: 1. Amount → 2. Method → 3. Confirmation.
Method data is stored between sessions.
You can return to the method selection without clearing the amount.

10. 3 Setting limits

The steps are limit type → value → confirmation.
Progress shows the remaining steps.

After completion - the screen "Will take effect in...."

11) Metrics and control

Completion rate:% of users who have completed all steps.
Drop-off per step: at what step they leave.
Average time per step и Time-to-Complete.
Auto-save success rate.
Error recovery rate - The percentage of successful recovery after a failure.

12) Antipatterns

Hard navigation without "Back."

Loss of input on reboot.
Jumping over steps without context.
One common submit per 10 screens.

Step error - and "Start again."

Blank screen after network failure.
Progress bar without semantic names ("1/4/7...").

13) Design system tokens (example)

json
{
"steps": {
"radius": 10,
"gap": 8,
"barHeight": 4,
"activeColor": "#2B9F5E",
"inactiveColor": "#E0E0E0"
},
"autosave": {
"debounceMs": 800,
"retryMs": 3000,
"ttlDays": 7
},
"a11y": {
"ariaLive": "polite",
"focusBehavior": "scrollToTitle"
}
}

CSS presets

css
.steps { display:flex; gap:8px; list-style:none; counter-reset:step; }
.steps li { position:relative; flex:1; text-align:center; }
.steps li::before { counter-increment:step; content:counter(step); display:block; width:24px; height:24px; line-height:24px; margin:0 auto 4px; border-radius:50%; background:var(--inactive); color:#fff; }
.steps li. done::before { background:var(--success); }
.steps li[aria-current="step"]::before { background:var(--primary); }

14) QA checklist

Saving and restoring

• A draft is created and updated at each step.
• On reboot, recovery is available and correct.
• Version conflict is being handled (old/new format).

Navigation

• "Back" does not lose data.
• The URL corresponds to the current step.
• Progress bar synchronized with status.

Network and offline

• Offline saves locally and restores online.
• Failure messages are understandable and non-destructive.

A11y

• ' aria-current =" step"', 'aria-live = "polite"' work.
• Focus moves to the step header.

Performance

• Transitions are instantaneous (≤ 100 ms).
• Asynchronous saves do not block UIs.

15) Documentation in the design system

Компоненты: `StepIndicator`, `MultiStepForm`, `AutosaveBanner`, `DraftRecoveryModal`.
Guides for storing context (local vs server), A11y and ARIA attributes.
UX templates: KYC, deposits, limits, questionnaires, return after an error.
Do/Don't with examples of network failure and successful recovery.

Brief Summary

The multi-step form should feel like a continuous process, even if the user is distracted, rebooted the page, or lost the network. Auto-save, recovery, visible progress, and secure retrays turn complex scenarios (KYC, payments, limits) into predictable and trusted experiences.