We recently did some very similar work to capture reasons for conversion or transfer date changes in Complete. You can read that update to help get context on this work we have done in Prepare conversions and transfers.
Recording when and why a date changes
Knowing when and why a proposed conversion or transfer dates changes is important in Prepare. However, it is less immediately impactful if they change before an advisory board meeting than if they change after.
The conversion date or transfer date is something that DfE teams and the schools, academies, local authorities and trusts involved all agree to work towards.
It is discussed at the advisory board meeting as proposed date. It can change following those discussions with the board.
Helping teams plan their workload
Whether it changes or not, it's a useful date for the teams who prepare funding, legal documents and other parts of the conversion or transfer processes.
It helps them to understand what projects are in the pipeline and likely to need their input over the coming months.
Knowing when and why the date changes can help them plan their workload.
Reporting on date changes
As is the case in Complete, the Data Analytics Unit use the information about changes to the conversion or transfer date to investigate and report on those delays.
These reports help the department understand possible recurring problems and complexities and how those might be solved. The reports are also given to ministers.
This data is available in KIM
Because this data is already available and used in KIM, we needed to make sure it was available and usable in Prepare.
If the teams who need that information cannot get it from Prepare then the department cannot transition away from KI, the outdated technology that we are trying to place.
Making date change reasons available in Prepare
As we did for 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.
Making designs consistent
This was an opportunity for us to make design consistent across Prepare and Complete, so we deliberately worked on a design that could work very similarly on both products.
The value of this is that users only need to learn one way to do a thing, and we do not need to spend time, effort and money solving the same challenge in different ways.
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
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