Up to this point Complete conversions, transfers and changes was only able to help users manage conversion projects.

This is because they are the majority of work that is done in this area.

With the bulk of conversions well established, our focus shifted to transfers.

Launching a pilot first

On 4 October 2023, we launched our pilot for transfer projects.

Delivery officers are now able to add transfers they're working on to the product.

As with conversions, for now they still need to use KIM - the application we're replacing - too.

This ensures that the projects continue to happen and are updated and completed in functioning official systems, while also helping us learn from users so we can improve the product.

It also helps users familiarise themselves with the new tools they will use when the organisation is confident that KIM can be turned off.

The Regional Casework Services team will start using Complete to work on transfer projects in November.

This pilot, where real users are working on real transfers, will help us to learn and iteratively improve.

Differentiating between the 2 types of project

Introducing a new project type to the product delivers great value to users. However it can also pose complications.

Now that their transfer projects will appear in their project list, do they need to be able to differentiate the types of work they do?

Showing the difference in the project list

If all the projects appear in 1 project list, is that overwhelming for them or is it helpful? Is it easier for them to have a project list for conversions and another for transfers?

We asked users these questions in research and tested early sketches with the to understand what they needed.

The findings showed that users think of their workload as a to do list of all project types, so that’s what we designed.

Using a similar approach to previous designs on the project list, we list projects in order of expected conversion or transfer month, using the school or academy name as the main identifier.

Under the school or academy name, we list other information that users have told us they need to make sure they know which project is which. Name alone is not always reliable as there can be multiple schools with the same name.

In the summary information beneath the name, we list:

  • project type
  • incoming trust
  • conversion or transfer date
  • region the school or academy is in

This helps users identify which project they are looking for.

The project type is displayed as plain text.

project-list-summaries.png

We felt we should take this approach first as it was the simplest thing to do.

This may be enough for users to be able to differentiate between a school called St Peter’s Primary converting to an academy and an academy call St Peter’s Primary transferring to a different trust, for example.

We will see what feedback we get from users on this now that they are able to use it in the real world.

How we show the difference inside a project

Once a user opens a project, we have tried to make it immediately obvious what kind of project it is.

We’ve used status tags to indicate whether it is a conversion or a transfer.

These appear at the top of the project page, alongside other critical information like the school or academy’s URN (unique reference number) and its name.

The idea is that this being a different colour to other items on the page will draw the user’s attention and make it immediately clear which type of project they are working on.

This should serve to confirm to the user whether they have opened the project they intended to or not.

transfer-project-tag.png

We chose to take this approach here as it aligns with the use of coloured status tags as indicators of progress in the task list.

While the colour is different to the blue, grey, orange and green status tags is the task list, users are now familiar with them indicating important information about the status of a task or project.

Again, we will listen to user feedback and iterate according to what users tells us.

Adding a transfer project to Complete

To add a transfer project to Complete, a user goes through a very similar process to adding a conversion.

There is now a second button, labelled “Add a transfer”, which a user clicks to add a transfer to Complete.

A second primary action button has been added to the project list page. It says "Add a transfer".

They then fill out a form that asks for information, including:

  • academy URN
  • incoming and outgoing trusts' UKPRNs
  • links to SharePoint folders containing important documents
  • advisory board meeting date
  • conditions from the advisory board
  • provisional transfer date
  • which team will complete the project

A form asking for information about an academy transfer project, including reference numbers, advisory board meeting date and advisory board conditions

However, we currently use a primary action button for both project types. This has been done so that we can deliver something of value to users quickly.

Ideally, we do not want to have 2 primary action buttons on a page. There are more accessible and graceful ways to handle this and we will look to iterate based on user feedback on this minimal viable approach.