The task list did not reflect the way our users work.
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:
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.