Complete multiple tasks

Problem Context

• The user is completing an application, registration, onboarding, claim, setup, renewal, disclosure, case file, or other transaction made of several sections.
• Some sections may be independent while others depend on eligibility, identity, previous answers, uploaded evidence, payment, review, or approval.
• Users may need to stop, return later, edit completed sections, complete tasks in a personal order, or share work with another contributor.
• The product must store progress and expose the difference between not started, in progress, completed, blocked, changed, stale, and ready to submit.
• The final action may have legal, financial, service, or operational consequences, so completion state must be accurate before review or submit.

Selection Rules

• Choose complete multiple tasks when users need a saved progress hub for several meaningful task sections in a transaction.
• Use the task list component inside this pattern for row-level task names, hints, links, and statuses; the pattern owns grouping, session return, dependency, edit, and submit readiness behavior.
• Use step navigation when the service must be completed in a strict linear order and users should continue one page at a time.
• Use process list when users need public guidance for an ordered journey outside the active saved transaction.
• Use multi-step form when the work is one guided form path rather than independent sections users can complete in different orders.
• Use draft state to describe the persisted incomplete record; use complete multiple tasks to navigate and update the sections inside that record.
• Use review before submit after every required task is complete and users need to check answers before the final action.
• Use confirmation page only after the final action has succeeded.
• Group related actions into tasks that match user goals, not internal data models, and split tasks that are too broad to name clearly.
• Show unavailable task dependencies before users open the task, such as Complete identity check first or Upload evidence before review.
• Keep statuses few and research-backed; completed tasks should draw less attention than tasks needing action.
• Always allow users to reopen completed tasks to edit answers and return to the hub with the updated status.

Required States

• First visit state with task groups, task names, initial statuses, and start guidance.
• Returning session state with saved progress and resume cue.
• Not started task state.
• In progress task state.
• Completed task state.
• Cannot start yet or dependency-blocked task state.
• Needs attention, changed, or stale task state.
• Optional task state that does not block final action.
• Task reopened for edit state.
• Task completion question or explicit return-to-hub state when needed.
• All required tasks complete state.
• Final review available state.
• Final action disabled or blocked state with reasons.
• Submitted handoff state to confirmation page.

Interaction Contract

• Selecting a task row opens that task and returns users to the same hub with updated status after save, skip, or completion.
• Task statuses are stored from canonical task data, not inferred only from visited pages or client-side progress.
• Changing an answer in one task updates dependent task statuses, warnings, and final action readiness.
• Blocked tasks remain visible with the reason and the task that unlocks them.
• Completed tasks remain editable, and edits can move dependent tasks back to needs attention when necessary.
• The final review or submit action is disabled or replaced with a clear blocked reason until all required tasks are complete.
• Returning sessions show saved progress, first incomplete task, changed tasks, and any expired or stale evidence.

Implementation Checklist

• Define transaction tasks, task groups, required versus optional tasks, dependencies, completion rules, status vocabulary, resume behavior, edit behavior, review readiness, and final submission rules.
• Build task status from server-side saved answers, uploads, verification, payments, approvals, and dependency state rather than page-visit history.
• Design task rows with short names, optional concise hints, text statuses, whole-row links, unavailable reasons, completed count, and first incomplete shortcut when useful.
• Add return paths from each task to the hub, including saved, skipped, incomplete, completed, changed, error, and edit outcomes.
• Update dependent statuses when an answer changes, evidence expires, a required task becomes optional, or a previously completed section needs attention.
• Gate review and final submission against canonical required task completion and show exact missing or blocked tasks.
• Test first visit, returning session, mobile wrapping, long task names, screen readers, keyboard row activation, completed edit, dependency changes, stale evidence, optional tasks, final gating, browser Back, and saved-progress recovery.

Common Generated-UI Mistakes

• Using complete multiple tasks for a service that can be simplified into a single short flow.
• Using it as an answer summary instead of a progress hub.
• Showing a task list when the user must complete every step in one strict order.
• Letting the final action proceed while required tasks are incomplete or stale.
• Making status tags look like clickable buttons while the task row is the real link.
• Using too many statuses so users cannot remember what each one means.
• Hiding locked tasks or dependencies until after users click them.
• Preventing users from reopening completed tasks to edit answers.

Critique Questions

• Do users need to complete this transaction over more than one sitting or choose the order of sections?
• What are the real task groups, required tasks, optional tasks, dependencies, and final submission rules?
• Which statuses are necessary for users to plan their work, and which create noise?
• How does the hub change when users return, edit a completed task, or change an answer that affects another section?
• What exact task blocks review or submission, and can users see how to fix it?
• Is this page a progress hub, or is it being misused as an answer summary or process guide?