Quizzes
165,122 views
28 min · 2 min read
8 steps
Advanced

How to set up a multi-page quiz with progress saving for long assessments

Building a multi-page quiz that saves progress helps learners tackle long assessments without losing work. This guide walks you through planning, implementation, and testing steps so users can pause and resume reliably. Expect to spend 4–12 hours building a basic version and 1–3 hours testing and polishing.

Verified by pleasexplain editors
  1. Step 1: Define scope and flow

    Decide total length, page count, and navigation rules before coding. Aim for 6–12 pages or 30–100 questions, and specify whether users may jump between pages or must proceed linearly; this drives data structure and save points.

    [Illustration: wireframe showing pages and arrows for flow]

  2. Step 2: Choose storage method

    Pick where progress will be kept: localStorage for single-device saving, sessionStorage for short sessions, or server-side storage for cross-device resume. Plan for periodic server sync every 60–120 seconds if using server storage.

    [Illustration: icons for browser storage and server with arrows]

  3. Step 3: Design data format

    Create a compact JSON schema for answers, timestamps, and page indices. Include keys for question IDs, selected answers, lastSavedAt (ISO string), and currentPage to enable fast restores and conflict resolution.

    [Illustration: JSON file icon with fields and timestamps]

  4. Step 4: Implement autosave

    Add an autosave routine that runs every 30–60 seconds and on page changes, sending only delta updates to reduce payload. Provide a visual ‘Saved’ indicator and retry logic that attempts up to 3 times with exponential backoff.

    [Illustration: browser window showing saving spinner and checkmark]

  5. Step 5: Build resume logic

    On load, check storage for an existing session and validate timestamps; offer users options to resume or start over. For server-stored sessions, show lastSavedAt and page number and allow restoring answers for each question.

    [Illustration: modal dialog with resume and restart buttons and last saved time]

  6. Step 6: Secure and version data

    Encrypt sensitive fields or use HTTPS for server sync, and include a schema version number to handle future format changes. Keep stored answers for a minimum of 7 days or per policy and purge stale sessions after 30 days.

    [Illustration: lock icon over document and version badge]

  7. Step 7: Test edge cases thoroughly

    Simulate network loss, multiple devices, browser crashes, and large payloads for at least 2–4 hours of QA. Verify partial saves, conflict resolution (latest timestamp wins or prompt user), and accessibility of resume prompts.

    [Illustration: QA checklist with red flags and network icons]

  8. Step 8: Provide clear UX controls

    Add explicit save, manual submit, and clear-progress buttons and display progress percent and estimated remaining time (e.g., 20 minutes left). Communicate autosave frequency and how to resume in plain language.

    [Illustration: quiz header showing progress bar, time estimate, and save button]


  • Keep each page to 5–10 questions to reduce cognitive load and save size.
  • Use concise answer payloads (IDs instead of full text) to keep saves under 10 KB per page.
  • Expose a visible lastSavedAt timestamp so users trust the autosave feature.
  • Allow users to export their in-progress answers as JSON for backup in under 30 seconds.
  • Debounce rapid input to prevent excessive save calls (e.g., 500–1000 ms).
  • Provide a lightweight recovery mode that restores only question state without media to speed resume operations.
  • Log save failures locally for at least 7 days to help debug intermittent issues.

  • Avoid relying solely on client storage for high-stakes exams; users can clear local storage or switch devices. Use server-side backups when integrity is required.
  • Do not store sensitive personal data in plaintext in client storage; follow encryption and privacy rules to avoid leaks.
  • Be careful with autosave frequency — saving too often can overload the server, while saving too rarely risks data loss. Balance with 30–60 second intervals.
  • Test for race conditions when two devices update the same session simultaneously; implement clear conflict rules to prevent data corruption.

Was this guide helpful?