The first page delivery officers and caseworkers see after logging into the Complete conversion, transfers and changes application is Your projects in progress.
This view's key purposes are to:
- display the projects assigned to the current user
- place these projects in priority order
In release 40 we introduced 'transfers' into the application. Prior to this, 'conversions' were the only project type supported.
Transfer projects involve academies transferring from one trust to another. Conversion projects involve schools converting to become academies. Both project types have slightly different data structures.
For example, conversions have a conversion date and an incoming trust, whereas transfers have a transfer date and incoming and outgoing trusts.
Following release 40, each project within Your projects in progress attempted to provide an at a glance summary for each project consisting of the following data points:
- URN (caption text)
- school or academy name (heading text)
- project type (summary list item)
- incoming trust (summary list item)
- conversion date (summary list item)
- all conditions met (summary list item)
After discussing which data points made the most sense for understanding both project types, we sketched 4 new page options for feedback.
Options 1 and 2 used the following data points to summarise each project:
- school or academy name (heading text)
- project type (tag)
- school or academy URN (summary card/list item)
- incoming trust (summary card/list item)
- outgoing trust (transfers only) (summary card/list item)
- local authority (LA) and region (summary card/list item)
Both options were a small departure from what already existed in terms of the user interface.
Option 1 used project type tags for better visual differentiation but maintained the summary list formatting already in use.
Option 2 used type tags and also moved each project into a card component for better semantic and visual delineation. This made the information easier to identify and understand.
Tables feature on the majority of pages throughout the application. We therefore introduced them in options 3 and 4 for a more consistent user experience.
Option 3 separated conversions from transfers onto different pages for reduced columns and improved readability. Option 4 consisted of one unified table made up of all data points shared across both project types so that everything could be visible at once.
Option 3’s tables consisted of the following columns:
- school or academy
- URN
- incoming trust
- outgoing trust (transfers page only)
- local authority
- region
- conversion or transfer date
Option 4’s unified table consisted of:
- school or academy
- URN
- project type
- incoming trust
- outgoing trust
- local authority
- region
- conversion or transfer date
Feedback
Users felt the data points we’d used in all four options worked well towards identify projects quickly.
When asked which data points were critical and which could be removed, most identified region as the least important, followed by local authority and, lastly, outgoing trust.
Tables were preferred over the summary list and card options in general as users found them clearer, easier to scan, and reduced the need to scroll.
Some felt the tags used in options 1 and 2 also aided scanning by visually differentiating project types.
Some users felt option 3 worked better than 4 for readability due to the fewer number of columns and less text wrapping.
Some preferred version 4 due to the visibility of all projects in one table.
Grouping by date was viewed favourably by certain users who felt seeing projects chunked up in this way helped them to see what was left to do from one month to the next.
However, other users expressed confusion around precisely what the date in the heading referred to.
Decisions
Based on the feedback we received, we decided to go with a modification of option 4 for the following reasons:
- all projects could be scanned at a glance
- a single table was more consistent with the way users currently consumed data in spreadsheets and legacy systems outside of the application
- a tabular approach created a more consistent user experience due to tables existing in many places elsewhere in the application
- the date column reduced confusion around what the date referred to due to the description in the column heading
We opted to remove the region column to aid readability, lessen text wrapping and reduce cognitive load.
We chose not to group by date due to the confusion around what the date referred to, but noted that we would revisit this for future feedback.
Similarly, we omitted tagging in this update, as tags were not being used for project type elsewhere as yet, but we planned to revisit tags in a future iteration.
