Tag component: updated guidance

[frankieroberto]

This updates the Tag component guidance to reflect design changes made:

Changes made:

• removes the guidance about not mixing "solid colours" and "tints", as all the tags use lighter background colours now
• added some content to the Research section about why the design changes were made
• adds the new "light blue" tag colour to the example showing all the colour options

➡️ Preview of the changes

[netlify]

✅ You can preview this change here:

Built without sensitive environment variables

Name	Link
🔨 Latest commit	d02a406
🔍 Latest deploy log	https://app.netlify.com/sites/govuk-design-system-preview/deploys/6515a0fc0563040008d14254
😎 Deploy Preview	https://deploy-preview-2733--govuk-design-system-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[owenatgov]

Whilst we can't make these docs changes until 5.0 is merged, we can capitalise the content examples now in anticipation of the new design. @36degrees has thrown something together here #2809 which, when merged and this PR is rebased, should mean this PR is only handing guidance content changes.

[colinrotherham]

Hi @frankieroberto, would you mind rebasing this PR against release/5.0?

In preparation for pre-releasing govuk-frontend@5 we'd like to start previewing together all the GOV.UK Design System website changes that otherwise can't go into main yet whilst it's on govuk-frontend@4

Thanks

Update: Looks like I did this one already 🤦‍♂️

[stevenjmesser]

Can this move to Ready to release, @colinrotherham? It looks like it's ready to go but doesn't have open questions on it, unlike some of the other Task List related issues and PRs.

[colinrotherham]

@stevenjmesser Think it's still in review waiting for a content check?

Got the most minor of minor code tweaks then we can merge it into the v5 preview site

[stevenjmesser]

OK, thanks for letting me know. Like other task list PRs, there's low capacity for doing anything on this until Design System Day is out of the way – although I suspect the co-design group could give it a review. Provided it's broadly in line with the way we write content on the design system website, it should be fine. Is there anything special we're looking for Design System content designers to do or add?

[stevenjmesser]

It's worth adding any known research gaps (or where we need more evidence) to the 'Research on this component' section, so that other teams know the gaps and can add value by contributing evidence.

[frankieroberto]

@stevenjmesser I don’t think we know of any known gaps (but there might be unknown gaps)?

What do you think of the content added to the Research section to explain why the design was changed based on research?

[stevenjmesser]

@frankieroberto That content looks grand, thanks for adding it!

[stevenjmesser]

I’ve checked this and there are no glaringly obvious problems. It’s well written content in the style of our guidance.

[colinrotherham]

Nice, let's get it merged 🙌

(Confirming too that this is going into the v5 preview)

[steve-oconnor]

@frankieroberto Finally, my 2 cents ...

Task list pages help users understand:

It’s a pattern, not a page and pages are listed separately. Might better to say “The task list pattern helps users understand:”

the tasks involved in completing a transaction

Should it say "transaction"? We talk about transactional vs non-transactional services, and a lot of people take the wording on these pages literally.

How about "the tasks involved in completing a process"

the order they should complete tasks in

“the order in which they should complete tasks”

when they’ve completed tasks

“when tasks have been completed”
“They” might not have completed the tasks, they might be checking someone else has.

Task list pages use a Task list component for each group of tasks on the page.

The task list pattern uses a Task list component for each group of tasks on the page.

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

Only use a task list 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 task list page. If you’re able to reduce the number of tasks or steps involved, you might not need one.

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

You should show a task list page:

You should show a task list:

If you use a task list page in your service, you’ll need to:

If you use a task list pattern in your service, you’ll need to:

at the start of the transaction

at the start of a process

If you use a task list page in your service, you’ll need to:

If you use a task list in your service, you’ll need to:

group related actions into tasks

group related actions into a task.

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

If there are lots of tasks to complete, you might also need to group them further into sections or steps. The example at the top of the page has two sections.

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

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

• I still think ‘Completed’ should use #505a5f rather than black :p

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

They are listed as ‘Tags’ in components and the word ‘tag’ isn’t used here at all.

Clearest option would be to spell it out:

Make it clear to users which tasks they’ve completed and which still need their attention, by labelling them using [tags](link to component) for each task’s status.

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

In the design phase we had agreed not to specify which text status and which colour should be used together.

I would loosen this up by saying:

Our research so far has favoured highlighting task that are yet to be started as the most prominent. So in the example we have ‘Not yet started’ using the blue tag, and ‘In progress’ using the light blue tag. User research for your particular service may suggest the opposite. Use what is most appropriate and please share your research.

Marking tasks as completed

Does the text of the radios improve by being less personalised by removing ‘you’? In some scenarios the person checking the info didn’t fill it out.

Maybe:

Is this section complete?

• Yes, this section is complete
• No, this section is incomplete for now

and then:

Select whether this section is complete or not

as the error message.