Reflect how providers work through the task list

The task list did not reflect the way our users work.

An image of the previous iteration of the task list. It was not in keeping with user behaviour.
We tested this iteration of the task list with users and found that it was not in keeping with their behaviour.

In this entry we explain why, and how we changed the task list to better accommodate providers’ already effective processes.

Put tasks in a useful order

Although ‘Personal details’ was not the first section in the list, one user completed this task first.

This would allow her to find the record later, she explained. If she was interrupted and had to leave the record unfinished, she’d search for the trainee name.

Hypothesis

If we move the personal details section to the top, then it’ll be easy for users to complete this section first and find an unfinished draft.

Use precise language

One user did not understand the difference between ‘Type of training’ and ‘Programme details’, saying that it would “become clear” once she clicked into the sections.

Hypothesis

If the task names better summarise the content therein, then users will know what to expect from each task; they should not have to guess.

Use fewer sections

Several subheadings (‘Route into teaching’, ‘Trainee details’, ‘Education’) split the task list into sections.

This echoes the task list design for Apply for teacher training, where tasks are broken up into small sections to help the user work through their time-consuming application in digestible chunks.

However, our provider users have a different task to complete. Registering a trainee is usually done in one clean sweep.

Providers are efficient; they have their data ready and input it quickly, in one go.

Hypothesis

If we use fewer sections, then we’ll better reflect how our users actually work; quickly, without stopping and starting.

Use meaningful categories

The section categories (‘Route into teaching’, ‘Trainee details’, ‘Education’) are also not particularly meaningful.

Splitting the task list into 2 sections - one about the person and one about their training - would better reflect what users are likely to do later with the information in each section.

They are likely to complete the personal details section and then leave it alone.

However, they’ll come back to review and update training information.

This is reflected in later aspects of the user journey, where personal details and training information are separate:

Detail of a training record after it has been created. Personal details and training details have separate tabs.
A trainee record after it has been created: personal details and training information have separate tabs.

Hypothesis

If we split the task list into 2 sections, one focussed on the person and one focused on the training, then we’ll create a meaningful distinction between different types of trainee data.

Do we really need a task list?

One user questioned the purpose of the task list, explaining that she’d prefer to skip from task to task without interruption.

Piloting the service in real life scenarios, when users have multiple trainees to register, will help us establish whether the task list is fit for purpose.

For now, the above changes may help make the task list feel less burdensome.

The task list now

The new iteration of the task list.
The task list now uses more precise language and has more meaningful categories. It has fewer sections, reducing it’s length and the need to scroll.