We’ve released new patterns and guidance to help design services. You can find them on the Service Manual. Previously we talked about the naming your service guide and the check before you start pattern.
This blog post is about the task list pattern. A list of tasks that users will have to do in order to get the thing they need.
Understanding the ‘application process’
Nearly all government services have criteria that mean some users are eligible to use the service and some are not eligible. Navigating these criteria and getting all of the things done that need to be done in order to apply to do something – whether that’s applying to become a childminder or getting a small business loan – can be a challenging, stressful experience for users.
During our research, we spoke to a government agency where over 60% of user support is attributed to queries about the application process.
Different types of applications involve different sets of tasks. From those that can be completed quickly in one sitting, to those that require supporting documents to be prepared over a period of weeks or even months.
People’s individual circumstances too can have a huge effect on the usability of this vital part of the service, as users invest different amounts of emotional and mental energy depending on what they are trying to do. From an office worker whose job it is to apply for export licenses, to someone requesting the right to live and work in this country.
Giving the right guidance
Most services will have some kind of guidance available for users to describe what they need to do to use a service. Sometimes this guidance shows a step-by-step guide of all the things a user needs to do, but more often they’re long, confusing documents that can be difficult to relate to a user’s personal circumstances.
Overall, the experience can be time-consuming and stressful. As one aspiring childminder told us during user research: ‘It feels like you’re being judged rather than helped sometimes.’
Through listening, designing, testing and iterating we identified the following group of common needs that we have attempted to address through the task list pattern:
- know what tasks a transaction involves at a glance
- know what order to do tasks in, if any
- plan time to do each task
- know which tasks are done and are left to do
All the tasks – the whole service
During research we learned something important; users need to know all the tasks required to do something. Not just the online tasks, but an overview of everything they need to do.
This meant a task list ideally would need to include:
- online tasks, such as 'book a test’
- offline tasks, such as 'take a test'
- non-government tasks users must do, such as 'get insured'
This got us thinking. At least from a design point of view, a service is a group of tasks that you complete to do something. As a designer or service manager you need to know what all these tasks are. And what order they need to happen in.
Collecting and comparing examples
Many services already use lists of tasks. Such as Digital Marketplace.
We collected and compared these examples. This involved discussions on mailing lists, speaking to the teams that designed them and sticking screenshots on a wall.
We did this for a couple of reasons. First was to check all the examples were designed to meet the same user needs. They were.
The second was to find the things each example had in common. Our reckon was that this would lead us to the pattern.
We found that there were some features that all the examples had:
- users can see all tasks in advance
- content is grouped into themes, for example questions about money
- the name of task describes itself, for example ‘give medical information’
- there is a suggested order to do tasks in
- task status is labelled, for example ‘completed’
- answers can be edited for each task
Iterating the pattern
We built prototypes then tested them with with 34 users over 5 rounds of research. Users becoming childminders, learning to drive and transporting goods. After each round of testing, we iterated the pattern.
These observations contributed to subsequent design iterations - such as enabling users to save and return to the service at a more convenient time, or reducing users' cognitive load by splitting up task lists into sections.
At first tasks were just one ordered list:
Users were unsure what order to do tasks in or if some tasks could be done at the same time as each other. So we changed this, putting tasks into numbered groups:
This made the page faster for users to scan and it made it clearer what order to they must do tasks in.
We made ‘read declaration’ one of the first tasks you do. At the moment, reading and agreeing to a declaration is one of the last things a user does. However we found users wanted to know these rules upfront, as they might affect the decision to do something in the first place.
What statuses to give tasks was something we tested. The examples we compared had several: A tick, ‘done’, ‘started’, ‘not started’, ‘finished’, ‘not finished’.
The first iteration with a tick proved ambiguous.
For the next iteration we showed the status as a word and gave it it’s own column to make it easier to scan. We chose ‘COMPLETED’ as this was consistent the language we already use in confirmation pages.
The next iteration was using users’ language for statuses; changing ‘COMPLETED’ to ‘DONE’. The feedback was that this didn’t feel authoritative or definitive enough, so we went back to ‘COMPLETED’.
For the following iteration we labelled tasks ‘not started’. This proved harder for users to scan. Users also told us they only cared about knowing what tasks they had completed and they wouldn’t start an task unless they could finish them.
The latest iteration we’ve made it blue, as some uses saw black as an indication that there was a problem.
The pattern is now in the latest version of GOV.UK prototype kit. Either update your version of the prototype kit or download a new one to try it out. There is Service Manual guidance for when and how to use the pattern.
This is a ‘beta pattern’, which means we’ve tested it in prototypes but that it needs more research.
So we’re keen for teams to try the pattern with their users. For example research on how users return to a task list they’ve already started, which only can be tested in a live service.
We’ve provided a coded pattern. Meaning teams can quickly try it with their users and help refine the pattern further. Please provide feedback on the design patterns wiki.