Changes to the team

During May and June, the make-up of the team changed. We said goodbye to existing team members and welcomed new ones.

This meant there was a period of newcomers understanding the problem we're trying to solve, the team evaluating what had been learnt and designed so far, and what we would do next.

First slice of value to users

While the initial concept had some validation, we felt it was important to begin investigating how true that was through user research.

That would mean we could observe them using a thing, and we could learn from that.

This would help us to deliver our first slice of value - helping users keep track of a project - as quickly as possible.

The plan was for us to then learn what users thought about those designs, and the task list in particular.

Those findings would then feed into iterations and next stages.

Creating and iterating the Figma screens in code

Using the GOV.uk prototype kit, we started building the task list first.

Taking the list from the Figma screens we created the list of things users need to do, as we understood them at the time.

Tasklist sections

This was broken down into sections that were grouped based on the orders delivery officers created in the co-design session we had with them in May 2022.

The sections were:

  1. Project kick-off
  2. Clear legal documents
  3. Get ready for opening
  4. After opening

Tasks in each section

We also began to create the tasks that would sit in each section, starting with the handover task.

The plan was to present this to users as a journey, so we could learn whether the concept was right and how we'd need to update and change it to meet their needs.

Users would be able select a task from the section list.

Once they opened the task, they would be asked a short series of questions that would act as prompts to take action or checks that the right documents had been received and information or data was correct.

Testing the prototype with users

We wanted to test our assumption about the task groups, the title and information in each task.

To do this, we ran a closed card sorting exercise.

This meant we could learn if:

  • users understood the language used to describe the tasks
  • the groups of tasks made sense to their mental models

There's a complex web of legacy systems, shadow systems and supporting documents that delivery officers use to do their work.

We know that our MVP won't replace the need for all these, but we wanted to get feedback on our first version of the prototype.

This would help us learn how valuable it is now, and which features in our roadmap we should prioritise next.

Research findings

From that research, we found:

  • The task list is valuable. Right now, there is no single way to capture all the tasks delivery officers need to do
  • The task list needs to be flexible as there is flexibility in how users complete tasks. Some tasks depend on the type of school or project, and some must happen at a specific time relative to the opening date.
  • Delivery officers need to be able to add comments to keep track of project progress The legacy systems don't capture all the information DfE needs. Delivery officers must fill in lots of separate documents to provide this. This is time consuming and repetitive
  • The data DfE needs is not always useful to a delivery officer's completing a project

We will use these findings to inform the next round of changes we make to the task list.

We also learnt that:

  • A shared task list would be useful as external stakeholder management takes up a lot of time. Delivery officers have created tools outside of the current legacy system to help manage these actions
  • Delivery officers have created work arounds to help keep track of all their projects. If we don't provide a status overview of all projects, delivery officers will carry on using their workarounds

We need to consider these findings in future phases of the project.

Share this page