Timeline (illustrative list)

[davidhunter08]

What

Use this issue to discuss the NHS App timeline component.

Journeys used on

1. Request repeat prescription
2. Waiting times

Related

GOV.UK Design System discussion

[davidhunter08]

Team Compass are looking at using a timeline on referrals.

Screenshot

Key areas to test

Wait times

• Flipped the timeline and removal of current status from within the graphic, instead placed as regular text beneath.

Can users still identify what is currently required from them? Do they know they have no actions to take?


• Title changed from ‘wait lists’ to ‘treatment wait lists’

[davidhunter08]

User research from Team Compass...

[davidhunter08]

Example from prescriptions...

[davidhunter08]

Examples

Timelines out in the wild:

GitHub

BBC News

HMRC Design Patterns

https://design.tax.service.gov.uk/hmrc-design-patterns/timeline/

Adidas App

The colour contrast 😢

[michaelgallagher]

@davidhunter08 we only ever tested this with staff (in internal-facing services, e.g. case management), but we did quite a lot work on timelines when i was working in hackney

see here

[growe88]

More examples

Some more examples of timeline components out there.

Trainline

CityMapper

DHL

Amazon

IKEA

TFL Go

[Tosin-Balogun]

Prescription and medicines team use this component to inform user the stages their medicine will go through before it reaches them

[growe88]

Collection of assorted information pertaining to Timeline Component

Insights:
[Kainos] Participants think of their appointments and healthcare in the immediate sense, “what is the next step and when will that be”. Hence a visual timeline component was used.
[Kainos] All users understood where they were and found the timeline useful, and also correctly identified what the dates were referring to
[Kainos] Participants likened the visual to amazon deliveries and found it easy to identify where they were and what was next in the journey
[Compass] The page was deemed to be particularly text heavy. Having the visual graphic helped to break this up and provide additional context through a means separate from text content.

/

Quotes:
"Having the visual really helps"
"Having a visual puts a map in your mind that it's coming up. Be less prone to forget about it."
"It's reassuring, even if it's a rough month. Nice to know."
"I'd like to see all my appointments on my timeline, even if they had been cancelled"
/

Pain points since identified:
[Compass] Participants expect the graphic to be dynamic; moving along and changing as they progress through the presented pathway. The timeline is static and generic, and so this does not meet user expectations.

(creds to Joe Galliford)

[davidhunter08]

Design update

HTML prototype (u: app / p: redesign)

Design decisions

From @growe88

We have reduced the variations of the nodes on the timeline.

• By having two variations of node, and two variations for line, we have reduced the cognitive load on users when trying to understand the component.
• This should make the timeline, and therefore the information it represents, easier to interpret.

We have identified two different uses in which our interaction designers use this component.

• Some use cases have the timeline component used as a visual list, using the nodes to depict next steps in a static component.
• Other use cases utilise the component as a progress indicator, making the nodes and corresponding lines blue to display current status and progress made.
• Both examples of usage are valid forms of interpreting the Timeline component.

Design work in Figma

Research questions

• Do users understand where they currently are in the timeline? Including users with visual impairments.

[davidhunter08]

The contrast ratio between the timelines's grey line and page background colour is 1.84:1. The timeline is not interactive so it technically doesn't need to meet the 3:1 but we need to make sure this works for users with visual impairments.

[davidhunter08]

Note: The current design is overriding heading styles (changing font weight to normal with only the current item being in bold)... is this ok?

This is how it looks without overriding the heading styles...

Easier to scan?

[Graham-Pembrey]

Is it possible that users might think there's a correlation between the amount of space between nodes, and the relative amount of time that step will take?

So for example, in the attached image, there is more space between 'Pharmacy processing' and 'Collect' than there is between 'GP approval process' and 'Pharmacy processing' because of the extra line of body text. That could be seen as representing a greater length of time.

This might just be something that we want to include in our guidance, as a possible perception to be aware of and to test for?

[jjulier]

Quick question just to check my understanding - is the content in the screenshot included on your comment above @Graham-Pembrey the actual content a user would see? To me it looks like a user would see 'Awaiting approval' OR 'Rejected' not both simultaneously? Same for the content under 'Pharmacy processing'.

[Graham-Pembrey]

Yes really good point @jjulier and something I had overlooked. I think you're right: for the example I shared, in actual usage, users would actually only see one of the pieces of body text beneath the headings. That would make the line length more consistent. It might just be something for teams to consider if one stage in the process has more body content than others.

[davidhunter08]

The team working on 'Apply for proxy access' tested a timeline on a confirmation page...

[joejulier-nhs]

As part of their work on a new prescription journey the team ran some usability testing with people who had access needs but did not use assistive technology. The testing included this confirmation page which included a timeline page and card link in the ‘What to do next’ section.

Across the 5 research sessions:

• participants weren’t always confident they’d completed the task
• at times they felt that it was difficult to interpret the timeline and they were confused about whether they were supposed to be coming back here to check progress of their medicines
• the idea that a request could be rejected introduced some nervousness and raised questions for participants

Related quotes:
‘Maybe just have a done section, this box is a little confusing, is there another step? Just something that clearly says it’s done’
‘I think actually because this dot is filled that means it’s done, and because this is empty it means it’s not done, but technically that’s incorrect because I’m currently waiting for approval so it’s not been complete’
‘Why wouldn’t the GP contact you? It should say your GP will contact you, because they have rejected they need to give a reason’
‘It says wait for approval but then there’s that button to check if it’s been approved, so do I wait or do I check, and if I wait how long do I wait? I don’t think I’d know what to do with this. I think I would just sit and watch this.

Reflection:
The purpose of a confirmation page is to reassure users they’ve completed a transaction. In this case, the inclusion of a timeline and card link components in combination with the content used within them, meant the page no longer met that primary need, and instead raised doubts and questions for users.

[anna-rigo]

The Health Choices and Prevention team completed a round of moderated usability testing, using prototype and semi-structured interviews in Aug 2024. One of their objectives was to evaluate screening feature designs by gathering feedback from users to investigate pain points. Participants were shown 2 slightly different screens as the team wanted to test how the timeline was perceived in this context.

Key findings:
Most users preferred the inset text over the timeline
• Only 1/5 users preferred the timeline view whilst 4/5 preferred the text version only stating the date their next screening invitation was due
• Users thought the text rather than the timeline was simpler and the date of their next screening invitation was clearer, which was important information
• They felt the timeline repeated information by restating when their last screening was despite this information already being visible within their records

Some users liked the age specific text informing users of eligibility
• 2/5 users liked the text in the timeline which referred to people over 71 years can still request a screening through
their GP, but the date given in the app timeline won’t necessarily be the date of their next screening. 1 of these
users wanted the age specific info included in the inset text of the most preferred version.

Users preferred expanders for more complex information
• For displaying results or if there were details, users preferred expanders because they could hide record information if they were showing their record to others
• Most users preferred the expanders for their screening record if there was more details such as results or additional screening information (6/6 users)
• They felt the design was cleaner and simpler if they had lengthy screening records
• For information such as date and location some users felt expanders were not required as only date and location
would be visible

Quotes:
“page is more simple, don't need the last one, more important when next screening is”
"Want information on what age cutoffs are important e.g. at 80, less important
to get screened"

Reflection:
The team has recommended to remove the timeline component from their journey. As in this context the information felt repetitive to participants, and found the expanders easier to use. With the timeline component, there seem to have been more content/text added onto the page, which cause the message to be unclear and slightly harder to digest. The 2 main points that were important to participants was the date and the age cut-off, which seem to be better presented in an inset text.

[MaryHarmon-ID]

The proxy team have completed a round of moderated and several rounds of unmoderated testing over July and August.

These tests included a timeline shown when people submit their application to give or get access to someone else’s medical services through the app. We needed to effectively communicate that the information submitted is reviewed by the GP surgery before approval is granted.

During the moderated usability testing of our html prototype, we found that people attempted to interact with the timeline, mistaking the dots for radio buttons.

To address this issue we tried adding a complete step to the top of the timeline showing that the user had submitted their initial application that day. We then carried out the unmoderated testing using a Figma prototype type that included both the complete first step and the latest version of the timeline where the dots are smaller.

There were no reports of participants attempting to interact with or select a timeline step during these rounds of testing. Participants were also more likely to comment on the usefulness of the timeline.

[anna-rigo]

Rationale & guidance migrated from the NHS App Figma file

[vickytnz]

Reviewing this and the examples from other places, this isn't a timeline so much as a status tracker?

• a timeline starts from the latest action and works backwards (for example this one from DWP https://design-system.dwp.gov.uk/components/timeline and most of the others mentioned earlier)
• a status tracker shows what will happen from start to end and the status changes as tasks are completed

[davidhunter08]

Great point @vickytnz we should look at changing the name of it.