In recent sprints we've created tables of information that help caseworkers, delivery officers, line managers and other user groups understand a project's status so they can prepare for the academy to open and get funding.
Expanding our user groups
So far, we've designed just for the delivery officers and caseworkers who manage projects. That has focussed on the task list and the task they complete to complete a conversion.
With caseworkers and delivery officers largely engage and using the task list successfully, we're able to widen our focus. Now we're exploring the needs of users who do important work to update academy information in Get information about schools and prepare funding for new academies.
They currently use Knowledge and Information Management (KIM) and other workarounds to do this. It is critical that we meet their needs in the new product to support the full process in the new service and decommission KIM.
The users we've been working with and designing for are from inside and outside DfE. They are:
- Service Support
- Academies Operational Practice Unit
- Education and Skills Funding Agency (ESFA)
Designing for Service Support
Service Support team need to use the product to create and add the new academy's Unique Reference Number (URN) to Get information about schools.
They also need to manage contact information for the Director of Children's Services at each local authority so that paperwork relating to the conversion is sent to the right place.
Designing for Academies Operational Practice Unit
Academies Operational Practice Unit are experts in policy. They provide policy guidance to caseworkers and delivery officers.
They need to use the product to check the progress of projects so they know when to prepare and send legal documentation and notifications to the school, trust, local authority and other stakeholders.
Education and Skills Funding Agency
The ESFA is an executive agency, sponsored by the Department for Education. They are responsible for providing funding to academy trusts, local authorities, colleges and training providers.
The use the product to organise how much funding and how and when to send it to the school or trust.
Presenting relevant information to the different user groups
Our typical users, caseworkers and delivery officers, manage projects using a task list to tick off tasks as they complete them.
The new user groups we’ve been designing for update and check information in other parts of the product.
They do not use the product to manage multiple tasks. They do not need a task list or to tick off tasks and actions. They mostly need to check and understand information quickly and clearly.
Why we need navigation
We have spent a lot of time working with and designing for these additional user groups.
The functionality we’ve developed for them was already in the application, but only accessible to people if they had the link.
That, obviously, is not very useful. We needed to enable users, including delivery officers and caseworkers, to get to these features and use them so we can learn how to improve them.
We have the concept of navigation already between project lists for caseworkers and their team leaders. Now we need something more high level to meet the needs of other user groups like service support who need to access data in the product.
Initial ideas
The navigation ideas were sketched out and prototyped in Figma.
Splitting projects out by type
We thought about whether navigation should split projects into groups by type.
This would mean separate project lists and information for conversions, transfers and changes.
While this might add clarity, we knew from research that delivery officers and caseworkers can work on several different types of project at once.
While only conversions are in the application right now, we will soon bring transfers in. The concept of clicking between different project lists and datasets for those different project types instinctively felt like it would cause the users more frustration as they move between several projects every day.
Grouping all project types together
When looking at how users currently monitor their project progress through the existing tracker spreadsheets, we saw that they mix all project types together.
We decided to implement a navigation that grouped project types together.
This means users can see all the types of projects they’re working on at once and should make it simpler for them to move from work on a conversion to work on a transfer.
Our assumption is that this will fit their mental model better, but we’ll see how it tests and how users respond to in when they use it and iterate if necessary.
3 levels of navigation
We’ve created 3 levels of navigation.
The highest, both structurally and visually, is made up of 2 options: “Your projects” and “All projects”. These are placed in the Ministry of Justice’s (MoJ) header component. That currently uses the standard GOV.UK black in the banner but we will soon change to the DfE front end.
Beneath the header are further menu options, presented in the MoJ’s primary navigation component.
Your projects
Here caseworkers and delivery officers can see any project they are directly involved with.
Users then navigate between 3 options contained in the MoJ’s primary navigation component.
- In progress: projects you are working on
- Added by you: projects you have handed over to another person
- Completed: projects where the school has converted and all relevant tasks have been done
All projects
Here any user can see tables showing information about all the projects in the application.
Users then navigate between several options contained in the MoJ’s primary navigation component.
These options show project information broken down into several different segments.
- In progress: all projects being worked on by a caseworker or delivery officer
- Opening: schools due to convert to academies in a particular month
- By region: number of projects in progress in each region
- By user: number of in progress projects assigned to each user
- By trust: number of in progress projects involving each trust
- By local authority: projects in progress involving a particular local authority
- Completed: projects where the school has converted and all relevant tasks have been done
- Statistics: a breakdown of all the projects in the application including how many of each type, how many each team are working on, how many in each region and academies due to open in the next 6 months
Navigation within the “openers” and “slippers” lists
The list of academies opening in a particular month has a partner list of schools that were planned to open in a particular month but have been delayed.
This provides the third level of navigation.
Users can select between two options “Opening as planned” and “Revised conversion date”. They are contained in the MoJ’s sub navigation component.
Colloquially known as the list of "openers" and "slippers", we want to use less jargonistic language. This helps to make the product more accessible and simple to understand for all users, especially those new to the job.
Navigation for users who are not delivery officers or caseworkers
There are different views available to different user groups, depending on their needs.
Regional Casework Services (RCS) team leader
The RCS team leader has a slightly different set of menu options. They have:
- Unassigned: projects handed over from the regional teams that must be assigned to caseworkers
- In progress: projects being worked on by caseworkers
- Completed: projects where the school has converted and all relevant tasks have been done by caseworkers
Service support
Service support only see the list of projects on track to convert as planned or those that have had their conversion date changed.
What we'll do next
As ever, next we will get user feedback, understand how the navigation works for users and iterate where we need to.
There is a further thing we need to think about with navigation as we bring more project types in to the build however.
How navigation and multiple project types will impact language
Building to meet the needs of users working on conversions has meant we’ve had a very narrow focus on the language used in those projects.
We have developed a concept of what is colloquially known as an “openers list”. This is a list of all the schools on track to convert to academies in a particular month.
This is a useful bit of information for the delivery officer or caseworker managing the project day-to-day, but also shows the teams who organise funding for new academies when they need to prepare grants to be sent to new academies.
Now that transfers are coming, this language is not as accurate.
If we are presenting a list of projects that are about to convert, transfer or change, they can’t all “open”.
We will need to try to understand what the list of academies expected to open in a particular month can and should be renamed to.