Recording when a date changes
We learnt fairly early on that the date a project is expected to convert or transfer is important to a number of people.
The conversion or transfer date is not just a useful thing for caseworkers to manage their workload.
The date defines when certain legal steps need to have been completed and when grants must be paid.
Because of that, it's crucial that changes to the date are captured and communicated to all the teams who depend on that information.
Changing the dates
We have written an earlier design history post that shows how we previously captured the changing dates.
Why reasons for date changes are important
What we have learnt since then is more about why those date changes happen, and why those reasons are important to the department.
Teams use date change reasons to report on problems
We learnt that the Data Analytics Unit are particularly interested in understanding changes to dates, especially delays to conversions where the school was required to convert due to poor performance.
They need this information for analysis they carry out and reports they give to ministers.
This work helps the department to spot consistent patterns or issues causing delays to projects. That work can help to make the process more efficient.
Most importantly, it can help DfE learn how to better progress complicated cases so that academies and trusts can can get to work on improving learning outcomes for pupils sooner than they might now.
This data is available in KIM
We learnt that reasons for data change are already captured in KIM, the existing technology that we are trying to replace.
We need to make sure that everyone who gets data out of KIM to use for funding, reporting and other necessary processes can get the information they need from Complete.
We can only fully transition away from the old technology when that is possible.
Making date change reasons available in Complete
We used the list of reasons already captured in KIM as a starting point.
From there we added other reasons we learnt about through discussions and user interviews with caseworkers, delivery officers and data consumers.
Research and sketches
We used those research findings to sketch up some prototype designs.
We made prototype designs in Figma and in Lucid.
Designing something better than before
In KIM, a user would record the date in one area, then enter the reason for a date change in another.
That took extra time than it needed and meant that 2 conceptually linked pieces of information were split up. That made it easier for the information to get out of sync or one part to be forgotten about.
We made the decision in Prepare and Complete to place these bits of information together. So, when a user changes the conversion or transfer date, they also enter why this is happening at the same time.
The intention is that asking about this conceptually linked information at the same time, in the same place, when the user is actively thinking about it will reduce the cognitive load on them.
How the designs work
Our initial designs were simple.
When users enter a new conversion or transfer date, they are asked why the date is changing. They a list of checkboxes to select any applicable reasons.
The list of reasons change depending on whether the date moves forward or backward.
We wanted to make sure we were able to provide the data to users in a format we knew would work in the timeframe we had.
This meant taking the reasons from KIM mostly at face value, knowing that changing them would mean mapping new or merged reasons onto existing data in the back end that was live and in use. We also added other reasons that we learnt about through research.
We knew the list was far from ideal. It was vague, non-specific and at times confusing. Certain categories felt like they might duplicate each other.
However, it does the job for now.
What we'll do next
We know that the reasons are vague and unclear. They are poorly defined and in most cases just lift and shift what already existed.
The next thing to do is to work with users and stakeholders to understand how to improve the list.
We want to:
- confirm which reasons are used
- remove unused reasons
- learn about what users understand the reasons to mean
- group the reasons more logically
- work with users to co-design a clear, definitive list that uses plain English