For Free Schools Store projects, there are a total of 15 statuses.
We know we need statuses in Manage free school projects (MFSP) to meet these user needs:
As a School Places Analysis (SPA) team member, I need to know the status of a free school project so that I can product accurate reports for stakeholders and ministers.
As a team leader, I need to know the status of a free school project so that I can support project leads in my team with their projects (if needed) and report on specific projects in monthly programme delivery meetings.
As an Education Estates comms teams member, I need to know the status of a free school project so that I can issue accurate comms to the public on upcoming free school openers.
Creating a design
We did some research with our subject matter experts to understand whether all 15 FSS project statuses are needed. From this, we had the confidence to reduce the number of statuses to 10.
We then discussed as a team which statuses we need for presumption route (local authority) projects, which is the focus of our MVP. This further reduced the list of statuses to 5:
- Cancelled - the project was cancelled in pre-opening
- Closed - the school has closed
- Open - the school has opened
- Pre-opening - the free schools project stage after the application stage
- Withdrawn in pre-opening - for example, the trust withdrew in the pre-opening stage
We used these tag component classes for project statuses:
- govuk-tag--orange for Cancelled
- govuk-tag--blue for Closed
- govuk-tag--turquoise for Open
- govuk-tag--yellow for Pre-opening. This was based on a similar status called Pre-advisory board in Prepare conversions and transfers
- govuk-tag--orange for Withdrawn in pre-opening. We used the same class as the Cancelled status as the contexts felt similar
Ideally a project's status would change automatically based on user behaviour. For example, if a user tells us that a school has opened, the project status would change from Pre-opening to Open.
This approach would prevent any status changes that do not reflect real-life scenarios. For example, if a school has closed, we don't think that it will open again.
Due to time constraints in getting ready for public beta, we decided to allow users to change the status manually using a change link and radio buttons. Manually changing a status is consistent with how statuses are updated in FSS.
To do
- test whether our MVP design meets user needs
- ensure the operational SharePoint guidance is clear about who will update project statuses in MFSP
- revisit the project status design in future, to consider the implications of automating status changes
- upgrade our GOV.UK Frontend package, so our status tag casing matches the tag component in the GOV.UK Design System