Conversions and transfers by month
We heard from delivery officers, caseworkers and team leaders that a way of seeing which projects would convert or transfer in the next month would help them to manage their workload.
We used a table to try and show this.
This table showed all projects in Complete that were due to convert or transfer in the next calendar month.
This was important because it helped to see which projects had reached certain milestones and were ready for funding to be prepared or sent to the incoming trust or the academy.
While caseworkers and delivery officers don't process that funding themselves, there are tasks they need to do before funding teams can send the money.
Proceeding as planned and revised date
We created one table to show which projects were proceeding as planned.
Then, we made a second table that showed projects that were initially planned to convert or transfer on one date but for some reason had been changed to a different date. We referred to this as the revised date.
We used the MoJ's sub navigation component to enable users to navigate between the 2 tables easily. While they load different pages, they function like tabs, allowing users to flick from one table to the other.
Difficult language choices
The decision to choose the word revised came from necessity rather than anything informed by user feedback.
We were limited in what terminology we could use to describe the concept of a date being agreed, then changing to another date.
The language our users used was "slipped", but that was problematic.
Firstly, it was not plain English, so new users had to learn what it meant. That is not a huge issue in itself - it's always a good principle to use the language your users recognise.
However, "slipped" only refers to projects that have changed date because of a decision by DfE. Users said a project had been "delayed" if the date changed because of a decision by the school, academy or trust.
The 2 specific meanings for those words made it difficult to reappropriate one of them to use ubiquitously.
Also, on rare occasions, projects can be brought forwards. "Slipped" and "delayed" implied the conversion or transfer date getting pushed back. There was no common term we heard to reference bringing the date forwards.
One obvious option was to refer to a "changed" date, but that felt too casual. Like the date was open to further alteration. We opted for "revised" as that felt more official.
None of these are great reasons for making that choice, but our view was to say something at first, then get feedback from users so we could learn and improve it.
Users found the initial design confusing and unclear
After the tables had been live for a while, we heard from users that they weren't working well for them.
Since we initially designed the tables we had learnt more about the needs of the funding and teams too. They also told us that this table did not work for them, so we knew we needed to change the approach.
The general consensus from the users was that the idea of having a table for projects that were on track was good and easily understood.
However, the table showing projects that had changed their target conversion or transfer date was confusing and not much use to them.
Organising the information by project type instead of date
To try and resolve this, we decided to split the information in the tables by project type instead of date.
One table contained information about conversions, the other about transfers.
Chunking information for caseworkers and delivery officers
We knew that caseworkers and delivery officers can have 20 or more projects assigned to them at once.
We are trying to solve a problem where users need to quickly see a reliable overview of their projects and progress. This is something that they use their tracker spreadsheets to do at the moment.
With the quantity of projects a person could be working on at any one time, we felt that listing all projects in the same table could make it challenging to get a view of progress at a glance.
We thought that this split by project type might better fit the metal models for caseworkers and delivery officers.
We'd often heard that they work on projects in chunks. So they might update all their conversions one morning, and transfers in the afternoon, for example.
Chunking information for data consumers
We felt that splitting the tables by project type could also help other user groups. The service team refer to these users as data consumers.
Data consumers are the people and teams who use the data that the delivery officers and caseworkers enter into Complete conversions, transfers and changes.
These consist mostly of teams who manage funding for trusts and academies, but also includes other teams who do work to update and assign names, unique identifiers and other information about new or moving academies.
We need to provide those teams with the projects that are relevant to them.
Some teams only deal with either conversions or transfers, so we thought that splitting the projects up like this could help them too.
We also knew that they needed more information than we could practically show in the tables.
So, we gave these funding team users the ability to export a CSV file of all the data we believed they needed for the projects listed in that table.
Iterating the design to show the change of date more clearly
We've changed the way we show when a project is aiming to convert or transfer and when it was originally planned to complete.
We have a column in the tables that shows the current planned conversion or transfer date. It also shows the original date in brackets.
We hope that this helps to quickly see which projects have been postponed or brought forward from other months.
This replaces the concept of 2 tables based on which projects were converting or transferring as planned, and which had had their conversion or transfer dates revised.
Adding a date picker for some data consumers
Caseworkers and delivery officers only usually need to see projects due to convert or transfer in the next month.
However, funding teams need to see projects over a longer time period.
We've added the ability for users in teams who handle funding to use a date picker.
This means they can see projects over range of dates covering the past, present and future.
What we'll do next
KIM, the system we are replacing, will soon become read-only.
This means delivery officers and caseworkers will not be able to use it to manage their projects. Instead, they will use the new products we're building.
As a result, we are about to have a large influx of users. While many people have been using Prepare and Complete already, they did not have to. Those that did have had to maintain their projects on KIM and the new products.
Listen to our users
As more delivery officers add their projects to Prepare conversions and transfers and Complete conversions, transfers and changes, we hope to get much more feedback from them.
We expect people using the redesigned By Month table, and the data exports that come with it, to give us more insight.
As we hear more from the different types of users, we're adapt and iterate the designs to meet their needs.
Feed back to design systems
We'll also feedback to the design system teams in DfE and GDS on the date picker we have created.
In the near future the GDS team will start looking into the use cases for different ways of choosing dates and what guidance can be added and components created to meet these needs.