Page task lists and overviews
Task List pages help people complete a longer service in meaningful sections. They show what is available, what is in progress and what is complete. Configure the tasks only after the associated pages and end points exist, then test the status and return route for every task.
Build the task structure first
Each task needs a stable ID, a clear task name and an end-page ID. The end page must already exist and be a Check your answers page, a marked task overview page or the final acknowledgement page. Each task must span at least two pages.
Group related tasks into steps only when the group heading helps someone understand the work. A step can have a visible name and concise help text. Avoid creating nested labels merely to make a long list look organised.
flowchart TD
A["Create the pages for a task"] --> B["Add a review, overview or acknowledgement end page"]
B --> C["Define task name and end page"]
C --> D["Group related tasks into steps"]
D --> E["Create the Task List page"]
E --> F["Test status, dependencies and resume routes"]Configure the task-list page
Use a helpful reference-number prefix only where a reference is shown and useful. The Sections name should match the language of the service, such as Parts or Stages. Choose whether to show a reference number, task progress and a Delete and start again link based on what a person needs to understand and the consequences of restarting.
The Return to task list link text appears across task pages. Make it consistent and clear, for example Return to task list. It should not be hidden unless a stronger, tested alternative makes the route clearer.
Make task names actionable
Task names should tell someone what they will do, not the internal process stage. Examples include Tell us about the property or Upload supporting evidence. Help text can explain what is needed before they start, but do not put essential instructions only in help text that may be skipped.
Each task can take the person to its first page, first unanswered page or Check your answers page. Use the route that supports real return behaviour:
| Route | Suits |
|---|---|
| First page | A task that is normally started from the beginning. |
| First unanswered page | A task people often leave part-way through. |
| Always return to Check your answers | A completed task that people primarily revisit to review or change. |
Use dependencies only for prerequisites
A task can depend on another task or step. This prevents it starting until the prerequisite is complete. Only add a dependency when the person genuinely cannot begin the later work without that outcome. Unnecessary dependencies make a service feel blocked and prevent useful preparation.
Test what happens when a prerequisite is returned for changes, becomes not required or has an error. The later task should never look available if its required input is no longer valid.
Understand task states
Tasks can be not started, in progress, completed, unavailable due to a dependency or not required. A task is automatically not required when every page in it has page-level visibility conditions and all are false for the person. Field visibility alone does not create that status.
Use incomplete and complete Task List content to explain the current state in plain language. After completion, tell people what happens next and whether they can still change any task.
Test the whole list
- Start each task from a new journey.
- Leave a task incomplete and return to the list.
- Complete a prerequisite and confirm the dependent task becomes available.
- Use answers that make a task not required.
- Complete and then reopen a task through its configured route.
- Test Delete and start again if it is shown.
- Complete the entire service and check the final content in QA.