Help users to Complete multiple tasks

Help users understand:

  • the tasks involved in completing a transaction
  • the order they should complete tasks in
  • when they’ve completed tasks

Complete multiple tasks pages use a task list component for each group of tasks on the page.

When to use this pattern

Only use a complete multiple tasks page for longer transactions involving multiple tasks that users may need to complete over a number of sessions.

Try to simplify the transaction before you use a complete multiple tasks page. If you’re able to reduce the number of tasks or steps involved, you might not need one.

How it works

You should show a complete multiple tasks page:

  • at the start of the transaction
  • at the start of each returning session

If you use a complete multiple tasks page in your service, you’ll need to:

  • group related actions into tasks
  • show the status of the tasks

If there are lots of tasks to complete, you might also need to group them further into steps.

Group related activities and questions into tasks, for example, ‘Provide financial evidence’ and ‘Give medical information’. This will help users understand and plan what they need to do.

Where possible, task names should:

  • describe what the task or activity will involve
  • start with verbs, for example, ‘check’, ‘declare’, ‘report’

Show the status of the tasks

Make it clear to users which tasks they’ve completed and which still need their attention, by labelling them using statuses.

Statuses should be helpful to users. The more you add, the harder it is for users to remember them. Start with the smallest number of different statuses you think might work, for example ‘Completed’ and ‘Incomplete’, then add more if your user research shows there’s a need for them.

Once the user has completed the task, the status should show as ‘Completed’ and be black text with no background colour. This will draw more attention to tasks that require action.

Tasks that are in progress

You may find you need additional statuses if your user research shows that users want to be able to distinguish between the tasks they haven’t started at all, and those they’ve started but not completed.

In this instance, instead of ‘Incomplete’, you may want to use ‘Not yet started’ to show which tasks they are yet to start. You should then use ‘In progress’ for tasks they have started but are yet to complete.

‘Not yet started’ uses a blue background, and ‘In progress’ uses a light blue background.

Tasks that cannot yet be started

If the user cannot start the task yet, for example because another task must be completed first, use the ‘Cannot start yet’ status. This should be grey text with no background colour, and the ‘task row’ should not be linked.

Tasks containing an error

You should avoid tasks having an error status by using the error summary and error messages displayed at the point that the error is made, so that the user can fix it straight away.

If it is unavoidable that a task may end up saved but containing an error, use the status text ‘There is a problem’ and a red background.

Do not use the red background colour for any status text except errors.

Status text

Although we recommend using consistent wording across task lists, you can change it if research shows that different text is more suitable to your service or users.

If you are creating your own statuses, use adjectives rather than verbs. Use sentence case, and keep it short, so that it can be easily read and understood.

Additional statuses

If your user research shows that there is a need for additional status tags, you can use other colours to help distinguish between them.

Group tasks into steps

If your transaction involves lots of tasks, make it manageable by splitting it up into steps that represent stages in the process.

For example, you could group all tasks which help users find out if your service is right for them in a step called ‘Check before you start’.

Where possible, allow users to complete tasks in any order. This will help them plan their time and complete sections as and when they can.

Marking tasks as completed

Sometimes, it’s better to let the user decide when a task is completed.

This can be helpful when a task involves:

  • some questions that are optional
  • writing a long answer (such as in a textarea)
  • looking up information, such as details about previous jobs
  • answers that need to be checked carefully with someone else

Do this by asking a radio question at the end of the task — either as the last question (if the task is a single page) or on the ‘Check answers’ page (if the task uses multiple question pages).

Ask ‘Have you completed this section?’ with the radio options ‘Yes, I’ve completed this section’ or ‘No, I’ll come back later’.

If the user selects ‘No, I’ll come back to it later,’ mark the task as ‘Incomplete’ or ‘In progress’.

If the user selects ‘Yes, I’ve completed this section,’ mark the task as ‘Completed’.

Always allow users to go back into a task to change their answer.

Error messages

If the user does not select an option, show an error message to say: ‘Select whether you’ve completed this section’.

Research on this pattern

This pattern was previously named ‘Task list’ and was developed by a team at the Government Digital Service (GDS).

It was then iterated by a cross-government collaboration and published as a new task list component with updated guidance and research.

See the research on the new task list component for details of research done, and known issues and gaps.

Help improve this pattern

To help make sure that this page is useful, relevant and up to date, you can:

Tell us if your service uses this pattern

Take part in our usage survey (opens in a new tab) to help us improve this pattern to better meet the needs of the services that use it.

Need help?

If you’ve got a question about the GOV.UK Design System, contact the team.