User needs

When assessing whether a school/academy should join a trust,

I need to know the history of the trust including how many schools they have taken on recently and whether these are due to 2RI (they have received two or more consecutive ‘requires improvement’ judgements),

So that I can find a trust with the capacity to support new schools.

--

When assessing whether a school should join a certain trust,

I need to know how many and the type of pipeline academies that are joining the trust,

So that I know if the trust has capacity to take on any more schools.

Introduction

Pipeline academies are establishments still in the process of joining a trust. They could be:

  • schools becoming academies
  • academies transferring to another trust
  • free schools joining a trust

Conversions and transfers are processed through Prepare (pre-advisory board - where people create a project template to take to advisory boards) and Complete (actions done post-advisory board).

Free school projects are processed through the Manage free school projects product.

People don't need to make comparisons or assess what's happening with the academy as a decision has already been made about them joining a trust and which trust they are joining.

TRAMS currently provides users with this information. No other product currently exists, which brings together the data users need for pipeline academies in one place. This data was collated in KIM, however KIM is no longer in use since 16 October 2024. The pipeline that fed this data to TRAMS was turned off, however another product team within RSD (Regional Services Division) is reinstating it. Users can also get the data either via the Project Finder or an existing PowerBI Tool.

Data analysis

Analysis was conducted on fields which had previously been identified by users during a workshop to outline the key pipeline data points they would require.

To identify where we would obtain the data, these fields were matched against the equivalent data points in the Academies Database, populated by the respective service.

Route data

Initially, the data identified included reference to the ‘route’ of the project. This is data that identifies if a project is 'voluntary' or 'sponsored'.

The analysis uncovered some inconsistencies specifically in this data between Prepare and Complete, and then between conversion and transfer projects. For example, ‘Project type’ in Prepare displayed data around it being voluntary or sponsored conversion, whereas ‘Project type’ in Complete indicated if the project was a conversion or transfer only. Terminology around what is voluntary and sponsored also varies across the department and is also in flux due to changes to what constitutes one or the other.

For this reason, it was agreed that route data would not be part of the initial Pipeline build. A ‘Project Type’ field would be present in the design, displaying either ‘conversion’ or ‘transfer’, helping us reduce the number of splits in data we’d need to display in the design.

Obtaining the data

Following conversations with the Common Architecture Team (CAT), it was agreed that a new table would be purpose built in the Academies Database containing all the fields pertaining to Pipeline data which we could pull directly from. This reduces the need to pull data from multiple database locations and tables, simplifying the coding process.

Solution

Initial release

The final design for the MvP of pipeline academies in FIAT was loosely determined by the updates to the “navigation UI”, which was built last sprint.

This gave our technical team more time to determine how the system could pull in pre-advisory board data from Prepare and post-advisory board data from Complete.

In turn, this allowed us to split the academy lists into three tabs a user could cycle through, rather than displaying them in a single table.

It also gave us the scope to tweak the column headings in each table. Especially where proposed pre and post advisory board dates were displayed versus provisional opening dates for Free schools. MvP.png

Design thinking - Tables or lists

The original mock created during the FIAT Alpha phase followed a list format in line with the vertical side navigation.

An old design, showing an the information of an academy in a list format.

In some cases, users would conduct an initial visual scan of a page to try and identify which academies would be worth further investigation.

We wanted to find out which pieces of information users would be looking for in this case, especially on a page with lots of pipeline academies on. To do this, we first needed to check if research carried out by the previous team was still up to date and relevant. We ran a quick card sorting exercise with SMEs, asking them to identify which pieces of information they would be looking for first.

A screenshot of a card sorting exercise conducted with SMEs.

Whilst we asked users what their critical information would be, we knew that any information not chosen still needed to be provided in other ways. As such, we spent time considering components from the various GOV.UK libraries that could hide or show additional detail at the user’s discretion. Some components included accordions, details and tabs.

Chinwag 24:09 png.png

We created 3 basic wireframe mocks in Lucid, to use as discussion aids with users. Two options followed previous mocks designed by the original team, whilst a third moved towards a traditional table. We wanted to see how users felt about seeing another table, given that most of the other information surfaced in FIAT is presented in the same way.

Quick mocks.png

Users were undecided about whether they preferred pipeline academy information to be displayed as a list, or within a table.

Some said that the table view was clearer at a glance and ideal for comparison, as well as how the information was grouped. Others said that there wouldn't be many pipeline academies on a page, so having a list was ideal given they liked being able to view the information vertically.

With the split of opinion from research participants, Rachel and Alex considered what this meant for design consistency within FIAT generally, especially in light of the (what was then) upcoming navigation changes.

We decided that the table format made most sense to develop.