Shane Ian Murphy: UK digital journeys need task labels that mean the same thing to everyone

A task list can make a complicated process look manageable. Several headings appear on one page, each with a short status label. Yet the list becomes less useful when the word complete means one thing to the interface and something else to the person reading it.

This company-origin editorial features Shane Ian Murphy and considers a service-design question for UK readers following Global Secure's planned product development. The stated launch plan is 2027. The example concerns a hypothetical non-financial profile task, not an available service or an existing customer process. AI assistance was used in preparing the article.

Define what the task includes

Imagine a prototype asking someone to add a contact preference, check a profile description and read an explanation. A dashboard lists those as separate tasks. Before assigning status labels, the team needs to define what finishing each task actually requires.

Opening a page does not necessarily mean its information has been reviewed. Entering text does not necessarily mean the change has been saved. A task label should describe the state the service can support rather than infer an outcome from the simplest event it happens to record.

The GOV.UK Design System provides guidance on task lists and completing multiple tasks. Those resources offer a public-service reference for this discussion. They do not establish that a commercial prototype has received government approval or that the same pattern is appropriate in every context.

Make the next action understandable

A list should help the person decide what to do next. If a task cannot be started, the explanation should make the relevant condition clear. If a task has been started but remains unfinished, the person needs a useful route back to it.

For the hypothetical profile task, the team could examine whether the label and link describe the same action. A label that says review while its link begins an unrelated step creates uncertainty. Clear wording connects the summary page to the actual journey behind it.

The right answer depends on the task. The article does not propose a universal set of labels for every product. It proposes that each label be defined and checked against the behaviour it is intended to describe.

Separate a person's action from another decision

Some processes involve a person supplying information and a separate party reviewing it. The first activity may be finished while the second remains unresolved. Combining both into a single completed label can misrepresent the state of the overall process.

A useful interface would explain the distinction where it matters. The person should be able to recognise whether they need to do something else or whether another step remains outside their control. That wording should be based on the actual operating arrangement, not added as a reassuring phrase without supporting evidence.

This is especially important in company communication. Completing an information form should not be described as acceptance, approval or activation unless that is genuinely what the process has achieved.

Check the return visit

A person may leave a multi-step journey and return later. The summary needs to make sense without requiring them to remember the previous session. A proposed review would examine saved information, changed requirements and any explanation of work that remains.

A prototype exercise could ask a participant to begin several sample tasks, leave the journey and return to explain the current state. The observer would record which labels helped and which required additional explanation. No results from such testing are claimed here.

A shared definition helps the team too

Writers, designers, developers and support staff need a consistent description of the task states. Otherwise, the same label may acquire different meanings in the interface, event records and help material. A short shared definition can make those differences easier to identify before launch.

For UK readers interested in Shane Ian Murphy's product work, the useful principle is that a task list should explain progress rather than merely decorate it. The labels should help someone understand what they have done, what remains and which next action is actually available.

A readable status is therefore a small promise about the state of the journey. It should be precise enough for the person using the service and supported by the process behind the screen.

References: GOV.UK Design System, Task list — https://design-system.service.gov.uk/components/task-list/

Complete multiple tasks — https://design-system.service.gov.uk/patterns/complete-multiple-tasks/

Professional information: https://shanemurphy.co.uk/

LinkedIn: https://www.linkedin.com/in/shanemurphy101