Progress indicator

[sarawilcox]

We get occasional requests for a progress indicator component. At the moment, we have no plans to add a progress indicator to the NHS design system.

Instead, we recommend referring to the GOV.UK question pages component which has a section on progress indicators: https://design-system.service.gov.uk/patterns/question-pages#using-progress-indicators

If you do build an indicator, please share use cases, design thinking, screenshots and user research insights.

[sarawilcox]

See also our step by step navigation issue.

[lasara-d]

What: An indicator that identifies at what stage a participant episode is to inform next steps and assist with team workload management (for clinical staff not for public) This would be a part of the participant episode which includes important information about the participant including their test results, contact details and episode history.

Why: For the MCBT (Multi cancer blood test) pilot system we had a need to display the progress of a participants episode so that the clinical users could see what had been done in order to understand what was left to do to complete the episode. The test team (Team of users who worked on the test release) had been using a similar idea with a “numbered checklist” progress indicator that they advised helped them to manage workloads as a team, for example if another user had handled an episode the next user can see what stage that episode is now at, what had been completed and what was yet to be done to make the episode ready for referral.

We have gone through various iterations and tried multiple different ways of displaying this, here are a couple that we tried that didn’t exactly work for us but were still interesting to explore:

Checklist progress iteration For this version we had used expandable cards displayed in a list from 1 - 5 (showing the five different stages) within each step there was tasks that the user would need to complete. We used the pattern from GOV UK (task list) to display this within the cards so the user can see if those tasks were complete, in progress or not started. We used link text so that the user could go straight to the action they needed to complete.

The reason we chose not to progress with this was because of the amount of space this feature took up on the participant episode screen and in relation to the hierarchy of the page; ideally it would need to be at the top but that would have resulted in important participant information being pushed down the screen. This design also just added too much complexity.

Progress bar iteration We also tried a “progress bar” type of progress indicator using the carbon design system as an example to work from https://carbondesignsystem.com/components/progress-indicator/usage/

The steps 1-5 are displayed horizontally with a description of that step in link text. The user could click the link and a summary element would display below with a list of the tasks to complete and their current status. We used colour - Green = complete, Blue = in progress, white = not started’ but also backed this up with content below each of the numbers for non sighted users.

We chose not to proceed with this as again their was the issue around hierarchy and where this element should best sit on the participant episode screen but also we worked with the users and programme to reduce the steps that the user needed to keep track of.

Final choice

Our final design choice for progress indicator was to use tags to indicate the current status of the episode along with a “Last activity” element so that the user could see the status and the last activity along with other information such as who created the last activity and if there would be any notes. This way the users are able to see what has happened, we understand that we removed the ability to view the next steps however because of the nature of the process we could not guarantee that the steps would always be the same. As we used “tags” we were able to add these into a table view so that users could filter episodes by status, see how many episodes they had by status, assign workload dependent on status and highlight any concerns such as too many episodes with the stars of escalation.

We have tested this thoroughly with proxy users in another screening service (we do not have any hired staff for this pilot yet) and also the test users to ensure that they can understand the meaning of the statuses and also what they would expect to do next based off the status and the last activity.

From a content perspective we have aimed to keep the content as simple as possible for the statuses so as not to cause confusion.