Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task list #72

govuk-design-system opened this issue Jan 12, 2018 · 64 comments

Task list #72

govuk-design-system opened this issue Jan 12, 2018 · 64 comments


Copy link

@govuk-design-system govuk-design-system commented Jan 12, 2018

Use this issue to discuss this pattern in the GOV.UK Design System.

Copy link

@abbott567 abbott567 commented May 30, 2018

Thought I'd just weigh in with a tweak we have had to implement for this pattern.

We are currently using it in a case working system and we had an issue where if one agent went in and chose some options that meant the task was not complete, to other agents it looked like no work had been done at all.

So, we needed a way to differentiate between a section that had not been looked at and a section that could not be completed. So we have added a grey 'not complete' badge to say 'yes, i've looked at it, but it's missing some information' vs 'nobody has looked at this section at all'.

screenshot-localhost-3000 2018 05 30 12-41-14

Copy link

@peteblakemore peteblakemore commented Jul 2, 2018

Interesting to see you've also removed the numbers from the side of each task, @abbott567 . On the service I'm working on we will also use a task list, but the tasks needn't be completed in order, so this approach would work well for us.

Copy link

@kubabartwicki kubabartwicki commented Jul 18, 2018

We just finished a mission in which we worked on a part of Digital Marketplace where users can search for cloud hosting, software and support. We redesigned an existing task list and put it at the start of the service:

Things we knew before

  • Users aren't aware of how the service works which results in non compliant behaviour
  • Some use the service twice a week, some will only ever use it once
  • Tasks in the service include complex interactions, such as searching and filtering
  • Tasks need to be completed in order

Things we learned

Put a static version of task list at the start of the service

screenshot-www digitalmarketplace service gov uk-2018 07 18-15-09-43

We had a hypothesis that task list would be a great way to explain how to use our service. To test, we replaced our old start page which had a search bar on it, with a task list.

This performed really well: it made the process transparent and cleared up a few confusions. We previously tried doing this with a start page pattern, but users found it annoying and a barrier to search.

Our static task list has no badges and is treated as static content rather than something users can interact with.

Put guidance alongside tasks

We modelled our task list around the idea that each step has a single task associated with it and some guidance. This is different to the task list in GOV.UK Elements, which assumes that each step consists of a bunch of tasks.

Doing it this way ensures that users can access guidance at all times but they don’t to tell us they read it each time they use it.

Use badges

“Completed” and “Can’t start yet” worked really well. They helped users realise what to do next and a few times made them realise that the page they are looking at is interactive and changes as they walk throughout the process.

screen shot 2018-07-18 at 15 08 19

It’s not always obvious what the steps are

The hardest part of this work was getting the steps right – we tested 5 different iterations of the task list before we ended up with the 5 steps we have now.

The most interesting one here is step 3, which refers to a lengthy offline process which a lot of our users currently get wrong. Returning users found it annoying to have to confirm "I've done this" each time, so we had to tweak the way the step is explained and acted upon.

We went with “Confirm you have read and understood how to assess services”. This means that the step is about reading our guidance about a process, rather than completing the process, which can take weeks and has very blurry edges as to where it ends and begins.

Copy link

@PeteWilliams PeteWilliams commented Aug 15, 2018

Thought I'd log a couple issues we've seen In the Civil Money Claims project. The first of which has had quite serious consequences for the user involved, and led to a complaint.


'Completed' marker misleading
A defendant in the live service was responding to a claim saying that they owed some money. They completed the required task in order to defend their claim, then were returned to the task list where that task was marked ‘completed’. The user thought this meant they’d filed their response, so they didn’t continue to the ‘Check and submit your response’ task. As a result they were issued with a CCJ for not responding.
This user was partially sighted and using a screen reader, but we think that may be a red herring, as apparently this has come up in testing with sighted users too.

Users not completing all sections
Over 20% of users in our live service got the error telling them to complete all tasks before continuing.
We've seen a few causes of this in testing:

  • Some users skip anything in 'Before you start'
  • If a task is phrased as a question, and the user's answer is 'no', some will think they don't need to fill it in
  • When the task list is dynamic - ie new tasks appear when you select certain things in other journeys - users often don’t see the new task and just skip it, especially if it was at the end of a section
  • Some users simply do not realise that they have to complete all the tasks before they can continue

Any thoughts on how to resolve these issues would be much appreciated. My current thinking is to try adding 'You must complete all tasks before continuing' to the top, which may help both issues if people actually read it.

Copy link

@kr8n3r kr8n3r commented Aug 15, 2018

Has anyone tried/tested by moving the tag to the left, below the task description?

Copy link

@charge-valtech charge-valtech commented Aug 15, 2018

Working on the "Apply for a Blue Badge" service.

We started testing with this in our prototype from last week. Overall, it's tested really well - it helps users realise how far along the application they are, and prepares them for what is coming up. We take users to the task list for the first time after they complete the "Check eligibility" section. 5 out of 5 users understood this on first land, they see the "Completed" tag and understand what the next section is that they need to complete.

One issue we did see though, was once a few tasks had been completed in the list, it becomes more difficult to see the sections that are incomplete. The page becomes more difficult to scan.

We are toying with the idea of a subtle "Not started" tag which is a light blue or something.

All users spotted and understood that they needed to hit "Submit and pay" at the end of the list for the application to be submitted.

Copy link

@anna-kayPA anna-kayPA commented Aug 15, 2018

We use the tasklist in the probate service.

User needs

  • Know where I am and what is coming up
  • Take breaks if required

Differences between ours and the beta tasklist

including why and how we've tackled it

Users can't complete items in any order. They can't for example pay before they've filled in the application.

  • we use a start button per section rather than a text link. Users understand green buttons as it provides clear guidance of what to do next. If they return to the service mid task, the button says "continue"
  • we use the lozenge "can't start yet" (replicated from the digital marketplace design by @kubabartwicki) so users know that they can't skip ahead - they can't skip ahead because we use information from earlier questions to decide what to ask in later sections.

Our service is in public beta and we have had a tasklist in our service for over a year.


Users will have been screened and created an account before they land on the tasklist.

Ongoing challenges

For some users, there is a step in the process where they need to wait for someone else's response before being able to proceed to the next task. When this happens, we do not show the green button. Instead we include content below that section header informing the user that they can't proceed yet. We believe this causes users confusion until they read the content. We are working on a way to help users easily understand that they need to pause for now.

Copy link

@kubabartwicki kubabartwicki commented Aug 15, 2018


That's a really interesting issue – I wonder if it's to do with users recognition of the steps as things they need to do? That's what we struggled with the most on Digital Marketplace (#72 (comment))... eg maybe if "Submit" was more about "Submit response" and "Respond to claim" about "Prepare response" it could be more effective and clearer to users what the badges mean and refer to? 🤔

Copy link

@helenadt helenadt commented Aug 22, 2018

@PeteWilliams it seems like there may have been a number of things at work there. I have not used this pattern so can only add some thoughts.

I wonder if it is worth trying to reintroducing the green button for the final task? I.e. for 'Check and submit a response'. Might make it clearer how you finish. Has anyone tried this?

It also feels like there might be something about the first set of tasks being 'Before you start'. By being at the task list am I not already started?

Copy link

@sunilkathare sunilkathare commented Aug 28, 2018

We are using the task list pattern to design an online version of the C110A application, which is 22 pages long, where local authorities can apply for a care, supervision or emergency protection order.

Local authority solicitor or legal assistant can use this application to start the process to place a child at risk of harm under the care of the local authority.

Why we are using this pattern?

  • Users can see the whole form, not just the parts they’ve answered

During user research we found users liked to see all the sections in the application in the form. One question per page pattern, shows just the first few questions. You must answer these before moving to the next section. It can be reassuring to know all the questions. So, you know what to do. It helps to know what information you need to gather if you know that questions.

  • Users can answer questions in any order

If you can’t yet answer question 3 – maybe you are still gathering information – you can still answer question 8. One question per page pattern online forms progress linearly – you must answer one question before seeing the next. With the task list pattern you can answer question in any order.

  • Save and restart applications

With the task list pattern you can add information as and when you get it. For example, in international cases, you have to wait till you get important information. As it is not linear, you don’t have to enter all information in one go.

  • Save time

Users don’t need to go through all the questions in the application form and can skip entire sections like the international section. Users don’t need to waste time saying no to questions that they don’t need to answer and fill only sections they need to. Fewer pages to load and fewer buttons to click means that they end up saving time!




Copy link

@quis quis commented Aug 30, 2018

We’re trying this variation of the task list pattern on GOV.UK Notify:


There’s some more detail in this pull request: alphagov/notifications-admin#2250

I’ll update this comment once it’s been live for at least a month and we can measure how effective it’s been.

Copy link

@charge-valtech charge-valtech commented Aug 31, 2018

We noticed screen reader users getting a bit frustrated by having to tab through every section each time they came back to the task list.

I've prototyped this solution to see if it helps things. A hidden link similar to the "Skip to main content" that takes the focus to the first incomplete link on the page.

Screen recording of it in action

Copy link

@timpaul timpaul commented Sep 1, 2018

Great idea @charge-valtech ! If you try it out in research let us know how it performs.

Copy link

@joelanman joelanman commented Sep 17, 2018

@sunilkathare thanks for sharing that! Do you have any findings from user research? Are you finding any of the same problems as some other teams? For example users not realising which sections they have to complete

Copy link

@sunilkathare sunilkathare commented Sep 17, 2018

Copy link

@phillipsr phillipsr commented Oct 2, 2018

Hi everyone - just thought that it might be useful to contribute to this chat. We've been working on Register as a Childminder for a while at Ofsted (in private beta) and have gone through multiple iterations of the task list. Our complicating factor is that we can have 6 legitimate statuses of a task (Done, Started, Waiting (to progress the task someone else has to do something), Flagged (a reviewer has flagged a problem they need to correct), To Do, and Do Last). The image below shows how we've created new statuses in a similar vein - although its not actually possible to have all of them shown at once, so take that with a pinch of salt.


In our testing these have all worked really well, and now that we have tweaked the colour scheme for some earlier contrast issues we would pass our accessibility audit (combining the statuses with alternative descriptions). Without being able to use the task list pattern, our application is very long and involves lots of different areas - so this brings them together nicely. We also have the challenge that tasks can be done in any order (except for the last one), and users frequently (want and need to) complete the form over multiple visits and over a long period of time. So having the task list as a check point of where everything is up to is incredibly useful for them.

We'd be really happy to share any of our findings with anyone that is interested, or to hear any other observations.
Rich - richphillips_ofsted on slack

Copy link

@joelanman joelanman commented Oct 24, 2018

We've heard a lot of research to say that some users don't know they have to complete all tasks. It's also the case that screen reader users can't easily get an idea of their progress, whereas sighted users can get an impression by seeing the 'completed' tags.

So, we'd like to suggest a change and get some research on it:

Once a user has completed at least one task, add a summary line above the task list to say how many tasks have been completed.

"You have completed 2 of 6 tasks"

Copy link

@PeteWilliams PeteWilliams commented Oct 24, 2018

One potential problem with that is that, in our case at least, the number of tasks can be dynamic.
You might start with 'You have completed 1 of 4 tasks', which then becomes 'You have completed 3 of 7 tasks'. So it could be quite misleading - though that may be better than the alternative.

Copy link

@marthaboggins marthaboggins commented Oct 24, 2018

Have performed two sets of tests with this pattern being part of the flow. The numbering left user's thinking they had to do the tasks in order - which is not the case. Otherwise they had no issues with it.

From my POV I'd like to see how you intended the links to work once the user has Completed a section. Do they simply go back to same pages with the fields pre-filled?

Copy link

@phillipsr phillipsr commented Oct 24, 2018

I think that's an interesting question. In our register as a childminder service, we had a summary page at the end of each task. Therefore, if the task was complete, clicking the link would take them to the completed summary page - thus allowing users to select which question they need to revisit. We found this to be better than navigating users to the beginning of the task.
Has anyone else tried any other approaches?

Copy link

@stevenaproctor stevenaproctor commented Oct 24, 2018

@marthaboggins A couple of services in HMRC removed the numbers when the sections could be completed in any order. The order they appear in the list should be based on user research and what makes sense to users.

@phillipsr When a section is incomplete, the services I mentioned take people back through pre-populated versions of the screens they have seen. This was because partially completed check answers pages confused people and also to remove the task-list-inside-a-task-list feeling.

When a section is complete, when they go back in it is to a complete check answers section that allows them to change their answers. If this leads to a change in journey, they would be taken through the screens in the normal way and given a new check answers page at the end.

From what I understand, this has tested well with users in different services.

Copy link

@joelanman joelanman commented Oct 24, 2018

@PeteWilliams hmm good point, though isn't that already implied by the task list itself, even without a summary?

Copy link

@chrisadesign chrisadesign commented Oct 30, 2018

We've heard a lot of research to say that some users don't know they have to complete all tasks. It's also the case that screen reader users can't easily get an idea of their progress, whereas sighted users can get an impression by seeing the 'completed' tags.

So, we'd like to suggest a change and get some research on it:

Once a user has completed at least one task, add a summary line above the task list to say how many tasks have been completed.

"You have completed 2 of 6 tasks"

Hey @joelanman how does this work with sections? What counts as a task here, the numbered items or the sub-items within?

Copy link

@joelanman joelanman commented Oct 30, 2018

@chdesign it would be total number of sub items - the rows that eventually get Completed tags

Copy link

@chrisadesign chrisadesign commented Oct 30, 2018

Brill, we're looking at one at the moment, I'll test it out.

Copy link

@frankieroberto frankieroberto commented Nov 15, 2018

Has anyone considered whether COMPLETED should be displayed in block caps or not? Some of the variants above use title case instead.

Our content designers have heard of some research suggesting that block caps present accessibility issues, but I don’t know whether that still applies for single words, as in this context?

The GOV.UK Style guide only suggests not using block caps for large amounts of text.

Copy link

@dashouse dashouse commented May 8, 2019

Example from Blue Badge service

Screen Shot 2019-05-08 at 08 53 02

Copy link

@charge-valtech charge-valtech commented May 8, 2019

Cheers @dashouse - our most notable iterations through research were:

  • include the first "Completed" tag for check eligibility, as even though it's not part of the application exactly, it helps understand the functionality of the page
  • include "Not started" tags as we had the issue I mentioned earlier with users completing "Personal details" and then thinking they'd done the whole "Prepare application" section
  • increased the hit area so that you can click on the whole line item as we found users, particularly on iPad, trying to click there

We're also due to introduce "Save and return" imminently, which will vastly improve the service and goes hand-in-hand with the task list.

I have to say the task list has been one of the most well-received/understood patterns I've ever seen. Well done to everybody involved.

Copy link

@edwardhorsford edwardhorsford commented Jul 29, 2019

The patterns team at GDS (inc me) did some exploration of the task list 2 years ago. It wasn't finished, but here's some screen shots which others might find useful.

Some aims / things we were looking at:

  • Support for tasks / sections that need to happen in series rather than in parallel
  • Making the next section more obvious
  • Some notion of started / in progress

2019 07 29-16-16-16-https-govuk-temporary-event-notice herokuapp com-local-council
2019 07 29-16-17-05-Task list

Copy link

@edwardhorsford edwardhorsford commented Aug 19, 2019

We've added a task list for our latest round of testing.

v1 looked like this:
Screenshot 2019-08-19 at 12 10 23

Notes on implementation:

  • After completing a task, we brought the users back to the task list, rather than taking them to the next task. I was worried they'd get annoyed by the length of the service, but they didn't seem bothered.
  • At the end of each section, when returning to the task list, we scrolled them to the completed section (this was problematic, see below).
  • I gave one task Can’t start yet - partly just to see what people would say.


  • Sections can be done in any order, but in practice all the users just went through them in turn.
  • Some of our sections are optional (group 3, not in screenshot) - but in practice the participants went in to each section regardless. At least part of this might be because they were new to this service so wanted to see what was in each example.
  • Users didn't comment on the Can’t start yet badge - mostly as they just went in order - and by the time they got to this section, they could start.
  • I felt our users had a generally high confidence with using this, particularly by the end. There's a consistency to it such that when they've got 'completed' badges on all items, they were confident they were done.


  • One user completely missed one of the tasks. I think there are three main causes for this:

    • As you fill up with tasks 'completed' it becomes harder to see which haven't been completed. This has been reported above by others I see. Fundamentally the current pattern highlights more the ones you'e done than the ones you need to do - I feel like this balance is off.
    • Scrolling to the section you've just done - the user didn't realise this had happened, so knowing they'd done some sections already, when they returned to the task list, they scrolled a bit more to where they thought the next task would be.
    • The draw of the 'completed' badges and doing them in order means that the users mostly just scroll to where they see the completed badges stop, and then do the next task from there. This means if the user misses a task and does one after it, they're less likely to see it's missing as they look to the next item after the bottommost completed one.
  • One user got completely stuck at the beginning when first shown the task list - she just didn't make the connection that you needed to go in to the item to do it. When she finally did one and was brought back to the task list, she was surprised and thought her data had been lost.

Things I want to try next:

  • Make the tasks to be done clearer / more explicit.
    • I like what digital marketplace does to show tasks that have been prefilled with previous years, are still to answer, haven't been answered yet - may explore something similar.
  • Our groupings of 'mandatory' and 'optional' didn't really get seen - so we may try grouping by theme.
  • Most sections are optional, but a few are required. I'd like to explore how to make it clear which are required.
    • Most users went through every section - but they were new users so they were exploring. We'll have users in the future using this several times a day - and sometimes will only have data for 3 sections - they should be able to look at the page and know what needs to be done - this isn't the case right now.
Copy link

@grahamharper grahamharper commented Aug 20, 2019

Has anyone included or experimented with a way to navigate directly to the task list from within a task? This would be as a way to allow a user who has realised they made a mistake in a previous task and want to jump back to correct the mistake.

Copy link

@phillipsr phillipsr commented Aug 20, 2019

I've been involved in a couple of services now that have used a link below the continue button to allow users to return to the task list. This presents two questions though:

  1. What do you call the page that the user is returning to in the link text - we haven't always found that users naturally call that task list page the task list or anything else (we're currently asking users this in some UR at the moment)
  2. Do users expect any data that they have entered on the page to be saved? If they do and what they have put in does not comply with validation - should you stop users from navigating to the task list if form validation fails.
Copy link

@edwardhorsford edwardhorsford commented Aug 20, 2019

@grahamharper I added this link below the continue button, which takes the user 'up' on level. So where they're just in a wizard it takes them back to the task list. Where they're in a nested thing, it takes them to the next category up.

Screenshot 2019-08-20 at 11 43 57

It's something I feel should be there - but didn't see users use it much - I think we'd have to craft a careful task to see if users saw it.

Edit - actually we did see one user use it when they got stuck on something.

Copy link

@grahamharper grahamharper commented Sep 5, 2019

Thanks for sharing!

Any rationale about your chosen location for the link? i.e. why at the bottom of the page as opposed to the top?

Thinking out loud about the reading order here, when the user gets to the bottom of the page, is returning to a level up a likely choice they'll make? I guess maybe in a documentation page they're done reading and maybe want to go back to an index page to read something else. If they've just filled in a form, it might be an unlikely choice to make?

Copy link

@edwardhorsford edwardhorsford commented Oct 2, 2019

Thanks for sharing!

Any rationale about your chosen location for the link? i.e. why at the bottom of the page as opposed to the top?

Thinking out loud about the reading order here, when the user gets to the bottom of the page, is returning to a level up a likely choice they'll make? I guess maybe in a documentation page they're done reading and maybe want to go back to an index page to read something else. If they've just filled in a form, it might be an unlikely choice to make?

A few reasons:

  • Practically, it adds clutter at the top of the page for an uncommon action.
  • There's a small chance users might read it as an instruction (more likely if it's the first thing on the page vs the last).
  • It's available on the page for users who want to look for it - but we're intentionally not making it especially prominent as its an uncommon action.

Thus for me it's less about 'will they need this action when they're done with the page' and more that it's an uncommon action and I don't want to give it too much priority or confuse the page. With that in mind, it could have gone in the right hand column - but thus far I've avoided putting anything there.

It's essentially similar to a breadcrumb - but as my service already has back links (which are more commonly used) having both breadcrumbs and backlinks didn't seem right. If someone came up with a design that worked well with both breadcrumbs and back links we'd certainly consider it.

Copy link

@edwardhorsford edwardhorsford commented Oct 21, 2019

Here's how I iterated the task list for round 2 of testing:
2019 10 21-15-13-32-Make a report - Product safety database - GOV UK


  • Make action to start a task a more explicit link Add details rather than linking the name of the section.
  • Make link Review answers once you've been in to a section - to distinguish it from sections you've not done.
  • Mark sections you've not done as well as sections you have done.
  • Mark sections as required or optional.
  • Mark sections you can't start yet.

For this round, we tested with 4 officers - none of whom had much prior knowledge of our service.

Notes on implementation:

  • When creating a new case, the first thing we ask is the case type, then we show the the task list, with the first section marked as completed. Depending on the case type, different sections are shown or not shown, or put in the mandatory area or optional area.


  • Overall, usability and confidence was improved.
  • Compared to previously, users were more confident on what they needed to do when they first came to this page. Last time we had a user get very lost - not being clear they needed to click the link for the section. I've got a strong feeling having a more active link text helps here.
  • 1 or 2 users (I forget) were a little confused why a section was already completed when they got to this page. They then opened that section and were returned to the case type page, realising they'd done this. They self corrected and were able to use the service fine. For 'set up' type questions my temptation is now to not show it as a completed step, but instead with some other design.
  • Users had a high confidence in navigating the prototype. They could all use it easily. When a user realised she'd made a mistake on a previous section, she was easily able to navigate back to fix it, then pick up where she left off.
  • All users went through steps in order.
  • Some users realised that some steps were optional, but our findings here were ambiguous.
  • Some users didn't like the word 'optional' - they thought those bits should be required. They're optional in our service because not all completing users will have all types of data - so it's more 'if available' than it is 'optional' - this is something we will work on in the future.
  • My sense was it was less likely users would miss sections (unlike default design), but I did still see one user miss a section. In reality this would be caught by validation - though you wouldn't be able to catch a missed optional section.
  • No one commented on Can't start yet - largely because they did sections in order, and by the time they got to those sections, they could start.
  • One user got to the end and wanted to see a summary of their answers before finishing. We don't have this. I've thought about replaying some of their answers on the task list page itself (similar to Digital Marketplace), but have concerns about the page getting very long.
  • Unlike the last round, our users universally felt like this was a very long process. Nothing much as changed from the last round in this regard. I think one issue we have is that the first task is rather long, and the others rather short. But on the basis of the first task they worry all tasks will be very long.
    ** We currently bring them back to the task list at the end of each section - although this helps them track their progress, it might contribute to the flow feeling lengthy.
  • No users commented on the link at the bottom Save report as draft and finish later - though our tasks didn't test this. We don't know / didn't test whether users thought they could save and return.

Things we may try later:

  • Optional sections and not having users go in to every section if they don't need to - continues to be an issue. I see two ways of tackling this:
    ** Asking up front what types of data they have, and then only showing those sections. We could still include the other sections in a collapsed area Sections you've said you don't have data for
    ** Showing all sections (like currently) but explicitly requiring users to go in to each. Once in the section have the user mark off Nothing to provide or similar.
  • Rather than bring the user back to the task list after each task, we may just advance them to the next task - and provide a link somewhere where they can get to the task list.
  • Promote the Save report as draft and finish later more prominently - perhaps on the right hand column.

Completing multiple sections at once

In a future version, whilst in one section we may ask details other details which end up completing other sections. For example - whilst adding details of products, we may ask if they have test results for those products. We can then mark the test results section as complete. I'll need to think how I can display this.

Copy link

@Guillermoreno Guillermoreno commented Dec 10, 2019

We had a lot of problem with users not recognizing the task list pattern as such so we decided to add some "TO DO" labels, at the moment we have 4 different statuses:

  1. TO DO: User can start the task
  2. IN PROGRESS: User has started but not finished the task
  3. DONE: User has completed the task
  4. CANNOT START: User needs to complete another task to get it to "TO DO" state

It has tested extremely well with users

CGTPD November 2019 task list_v2

Copy link

@gonogo gonogo commented Dec 18, 2019

We used a modified version of the Task List indicator 'tags' in the UK Emissions Trading Registry project. We changed the appearance of the indicators based on feedback from user testing. When lots of these indicators appeared together in a table two things tended to happen:

  • Users talked about it looking too 'bright' or 'dazzling'.
  • Users found it hard to tell which of the items in the table were urgent and required their immediate attention and which items were less important. All tags had white text on a bold-coloured background (blue or black initially) and so looked equally important. We suspected colour-blind users would struggle even more to differentiate between items.

We redesigned the buttons and made the following changes:

  • we used a box with a white background, and text based on high-contrast primary colours in the design system. The border matches the text colour.
  • to aid colour-blind users who are less able to distinguish between colour coding, we used a bold font weight for more important items and a lighter font-weight (of 100) for less important items. The lighter font-weight passes accessibility testing with browser plugins, but needs further accessibility testing with the DAC (or similar) to assess whether the text can be read comfortably.
  • the buttons are very slightly rounded to reduce visual noise when presented in a table.
  • three button styles were developed.
    -- red/bold: indicates urgent
    -- green/light: indicates less important, situation normal.
    -- grey/light: indicates inactive or complete
    -- blue/light: indicates in progress or pending

When these were tested, users no longer commented on the buttons being 'dazzling' and were able to accurately identify the different types of items when asked. The 'urgent' styling helped them quickly identify things that needed their immediate attention amidst a larger table of mixed items.

Prototype and code available here:

Screenshot 2019-12-18 at 16 01 56

Copy link

@gonogo gonogo commented Dec 18, 2019

Our team also used a modified version of the Task List indicator 'tags' in the DfE Apply to Convert a School to an Academy project.

In user testing, users told us they felt 'overwhelmed' by the list of tags. One user described it as 'garish'. Similar to the ETS project I've referred to in a previous comment on this thread, I think it's the bold text and high-contrast that gives this element a tendency to dazzle when lots of them are presented together.


We borrowed from the UK Emissions Trading Registry project and developed a set of icons to replace the defaults:

Screenshot 2019-12-18 at 16 39 27

The 'Completed' state actually is technically WCAG AA compliant, but uses a lighter font weight of 100. Given that this state uses a combination of grey text and a lighter font weight it requires further testing with a range of people with different visual impairments to ensure it's readable.

The visual hierarchy of the indicators aims to give 'Not started' sections priority over completed or in-progress sections that are less important to the user since we assume they have these in-hand.

An example of these indicators working together is shown here:

screenshot-localhost_3000-2019 11 08-19_28_14

Presenting data within each task list 'section'

Screenshot 2019-12-19 at 16 12 31

When clicking on a link to one of the sections, the user sees a page with the section questions presented in the style of a Check your Answers page. This is so that users can see in advance what information they will be asked for, and see answers previously given so they can more easily review responses provided by other collaborators on the application form.

When we followed the 'Check your Answers' pattern exactly, users missed the 'change' link on the right hand side of a question, and even when they did see it found it confusing if they hadn't already provided any information to 'change'.

Instead we provided a secondary button to instruct users to start a section which would take them into the page containing the questions to answer. After completing the questions on the page and returning, the button is replaced with a link 'Change your answers'. Users understood what they needed to do on these pages and no longer missed the buttons or links to navigate to the question pages.

'Secondary' style buttons were used instead of the primary button style because in many cases we needed to present several pages of questions like this. A large number of primary buttons overwhelmed users, and it also distracted from the primary button at the bottom of the page which is used to return the 'task list' page showing the sections that need to be completed. By making sure this was always the only primary button on the page, we found this was the main way users chose to navigate back to the major sections in the application form.

Copy link

@adamsilver adamsilver commented Jan 8, 2020

When and how to mark tasks as complete

I thought I'd share my thinking around when and how to mark tasks as complete.

When to mark a ‘basic’ task as complete

If a task consists of a list of questions—either on the same page or a number of pages—you can mark the question as complete as soon as those questions have been answered.

When the user clicks on a completed task you can show them a slightly adapted check answers page a bit like this:


When to mark an ‘add to list’ task as complete

On Apply for teacher training, for example, we let users apply for up to 3 courses (and they have to choose at least 1).

There are 2 main approaches I can think of for when and how to mark this sort of task as complete. (Apply for teacher training currently uses option 2)

Option 1: automatically mark ‘add to list’ tasks as complete as soon as the task is technically complete

This option works like a ‘basic’ task in that as soon as it’s technically complete (or valid), it’s marked as complete.

For Apply for teacher training, the task would be marked as complete as soon as the user chooses 1 course.

But if the user gets distracted and intended to add a second course, some users could forget to do that because the task is marked as complete like this:


I think most users will remember to check their answers, either by clicking into each task or checking everything on a separate review page for the entire application.

Users on the Apply for teacher training service will see the review page when they click the ‘Check your answers before submitting’ task at the bottom of the task list like this:


See how the review page highlights incomplete tasks.

We could highlight tasks that are not as complete as they could be. For example, if the user can choose another 2 courses.

(Note: Apply for teacher training has a task which lets users add as many qualifications as they like. It’s probably a bad idea to prompt users to add additional qualifications just because the system recognises they can.)

Option 2: let users explicitly mark ‘add to list’ tasks as complete

Alternatively, you could let users mark tasks as complete so the system doesn’t have to infer it. But this could cause the following problems:

1. Users might be confused by the inconsistency

Having a mix of automatically and explicitly completed tasks could be confusing due to the inconsistency. (We’ve not got any evidence of this to my knowledge.)

Alternatively, we could also get users to mark ‘basic’ tasks as complete. But that seems unnecessary.

2. Users might forget to mark the task as complete

The user needs to know they have to explicitly mark tasks as complete. Depending on the implementation, users might forget. (More on this at the end of this comment.)

3. Users might worry that they won’t be able to make changes after marking the task as complete

The task list pattern lets users change their answers up until submission.

But asking users to mark the task as complete could make users worry that they won’t be able to make changes later. (More on this at the end of this comment.)

Possible ways to let users mark ‘add to list’ tasks as complete

Use a checkbox and two calls to action

Currently Apply for teacher training lets users mark ‘add to list’ tasks as complete using a checkbox:


Our research shows that several users (both with and without disabilities) click the checkbox and then click ‘Back to application’ in the top left without clicking the green continue button. This fails to mark the task as complete as the user intended.

Possible additional downsides are that users:

  • might not spot the checkbox
  • need to choose between 2 calls to action which could take longer

Use radio buttons and 1 call to action

Alternatively, we could use radio buttons like this:


I think this design would help users:

  • spot the question and options
  • understand their options more clearly as they form part of the same question
  • learn about how this interaction works thanks to the label text
  • know they need to click the continue button to submit their answer
Copy link

@timpaul timpaul commented May 20, 2020

As part of our work to improve this pattern we have recently reviewed the statuses used on all the examples posted here.

We found that:

  • 'Completed' is by far the most popular label for tasks that had been completed
  • 'Incomplete' and 'In progress' are both equally popular choices, but there is evidence that some screen reader users find the word 'Incomplete' hard to distinguish from 'Complete'
  • other common status labels are 'Not started' and 'Can't start yet'

Because of this we'd like to propose that people should:

  • use 'Not started' (in grey) if the user can start work on the task, but hasn't done so yet
  • use 'Can't start yet' (in grey) if the user can't start the task yet - for example, because another task must be completed first
  • use 'In progress' (in light blue) if the user has started but not completed the task
  • use 'Completed' (in dark blue) if the user has completed the task
Copy link

@joelanman joelanman commented May 20, 2020

sorry just reminded me to post the version I worked on recently. We used 'To do', 'Done' and 'Can't start yet' - they all tested well.



Copy link

@ladine-cook ladine-cook commented May 26, 2020

HMRC did quite a bit of work looking into the status tags as part of this pattern

The content style guide says to avoid negative contractions. Is there any reason you propose to use 'Can't start yet' over 'Cannot start yet'?

Copy link

@timpaul timpaul commented May 26, 2020

Thanks for the feedback @ladine-cook - that's a really good point. I'll double-check with a content designer here and we'll change it, unless there's a good reason not to.

Copy link

@timpaul timpaul commented May 28, 2020

Hi @ladine-cook - I double checked and yes, we'll change it from 'Can't' to 'Cannot' - thanks for pointing this out!

timpaul added a commit to alphagov/govuk-design-system that referenced this issue May 28, 2020
These are based on an analysis of examples from the backlog, here: alphagov/govuk-design-system-backlog#72 (comment)
Copy link

@vickytnz vickytnz commented Jun 2, 2020

sorry just reminded me to post the version I worked on recently. We used 'To do', 'Done' and 'Can't start yet' - they all tested well.



how does the 'can't start yet' information work for screen readers? I'm curious as to how the page is marked up to make it that clear (is there hidden text after '0 of 3 sections' saying that they cannot start 2)?

Copy link

@tempertemper tempertemper commented Aug 24, 2020

There was some discussion on Slack recently about implied hierarchy when using the status tags in this pattern. I had the same issue and ended up going minimum viable product, stripping the tags back to plain old text. This solved some readability issues, some issues where users went to click the tags, thinking they were buttons, and the fact that the blue background, high contrast tags look more important than outlines or tags with a different colour.

Here's the pattern that @lisadunn577 and I employed on our previous service to great effect, now in as an experimental pattern in the HMRC Design Patterns: Doesn't look all that glamorous, but it tested beautifully with users.

For a bit more detail, I wrote up a case study that expands on the iterations we made and fleshes out some of the rationale.

Copy link

@oceannee oceannee commented Mar 9, 2021

Just thought I'd share the comments and tweaks we've made to this pattern that has worked for us.
We've been testing this pattern with users who need to check and confirm information is correct before being able to proceed.
Users preferred "checked" over "completed" as there aren't any actions to complete. Users also found it confusing if "confirm and submit" was included in the sections to be completed as they wouldn't be returning to this page to see the sections fully completed.
Screen Shot 2021-03-09 at 11 31 28

Copy link

@CharlotteDowns CharlotteDowns commented Apr 28, 2021

Summary of conversation on x-gov slack 28-04-2021


Some Assistive Technologies have started removing the list role from lists that don’t have markers (bullets / numbers), so in some cases you do now have to set role="list" explicitly.

An accessibility audit at the Department for Education (DfE) recommended the use of dl for the task list rather than li. This recommendation could be based on the contents of the task list. The GOV.UK Design System team would be interested to know why they think this particular type of data suits a description list, rather than a standard list.

The dl element is commonly used to implement a glossary or to display metadata (a list of key-value pairs). From the HTML spec for the dl element: "Name-value groups may be terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data."

Semantically it feels more appropriate to represent the task list as a list of steps that the user needs to work through, rather than representing the steps as key-value pairs.

Further reading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet