Talking to users
As always, we wanted to start by understanding how the process currently works, and what users need to do when they assign a project to another person.
We already knew from earlier research that there are several different ways a project progresses from the advisory board stage to the Complete conversions transfers and changes build.
After the advisory board says a school can convert to an academy, that project can:
- remain in the Region with the delivery officer who prepared the project for advisory board
- stay with the Region, but be assigned to a different delivery officer
- get passed over to a caseworker in the Regional Casework Services team
We spoke to users about how decisions are made about who will pick up a project after advisory board.
From that we learnt about and observed meetings that the Regions team leads have with the Regional Casework Services team lead where they discuss projects that are due to go through advisory board in the following month.
They talk about those projects and agree what work will be passed to the caseworkers and what work will stay with the delivery officers.
They also discuss any complicated projects and how that complexity could be reduced. This could include things like taking steps to contact a local authority that is known to move more slowly than others much earlier than they typically would, or change the date of the conversion to allow more time.
What we designed
As a group of user centred designers, we sketched some initial ideas and discussed what we thought was sensible and achievable.
We did this sketching both together and individually. We combined those sketches into and end-to-end assignment journey.
We also ran our development colleagues through our design ideas to understand where they felt technical realities might constrain our thinking and their expertise could help guide us to a focussed idea that we could deliver and iterate.
In hindsight, we should have worked more closely with the developers to understand technical circumstances and get their valuable insight and perspective from the start.
These ideas included:
- the ability for delivery officers creating a project in our application to select which team would continue the project after advisory board
- a third view of the project list showing project to assigns
The project list currently shows two views. One of projects being done, and another of projects that are complete.
The concept of third view of the project list that only team leaders so is a simple one. It shows a team leader only unassigned projects.
Projects in the unassigned list display the same kind of information as the other lists, but they also feature a button that says "Assign".
Using this button takes the team lead to a screen that allows them to enter the name of the person they want to give the work to.
Starting small
That collaboration with developers was crucial in helping us to build an assignment experience in the prototype that we could begin to interact with and see working in a visual way.
The version of assignment in the prototype demonstrates how a:
- delivery officer can confirm which team will pick up the project after advisory board
- caseworker team lead logs that a caseworker has been given a project to work on
There are more things that happen outside of the digital part of the service to make these decisions, such as conversations and meetings between people in the regions and the caseworker team lead, and the team leaders and their team members.
Those conversations and examples of "soft intelligence" as the users refer to it, such as workload spreadsheets and tables, are too complex for us to recreate in the digital part of the service right now.
First we're going to try and create a simple assignment function that logs, or at least represents, decisions that people have made.
Once we have understood how that works and the user needs for that, we can start to think about how we might enable the whole discussion to take place in the product - if that's even necessary or helpful for users.
Changing the words we use for project roles
When we began designing for delivery officers as well as caseworkers, shortly before public beta, we learnt that delivery officers used different language and phrases to describe and understand who caseworkers are.
Up to that point, we had used job titles and team names as the way to identify the person responsible for a project at a particular point.
However, the department had changed the structure and names of teams and roles in Regions Group during the design and build of our service.
Clearly not all people involved in the process of converting a school to and academy had learnt or heard of those new names.
Delivery officers used a combination of names and phrases to refer to the team and job roles now known as Regional Casework Services and caseworkers.
Instead, delivery officers in the regions often said:
- project lead
- operational delivery officer
- operational delivery team
All of these were outdated ways of naming the team and the people in it.
This meant that when delivery officers would hand the project over in our build, they did not always recognise or understand the language used. In research, they often asked who caseworkers referred to, or expressed that they didn't know what that term meant.
It was not the first time, and certainly will not be the last time, that the department make changes to team names and job roles.
So, to try and solve this comprehension problem without risking it happening again in the future, we decided to switch from team and job specific descriptors to language that described the thing a person would do.
For example:
- Regional delivery officer became Person who prepared project
- Caseworker became Person completing project
- Team lead became Project assigned by
This may not be the exact language we use in the live service, but the intent to describe an action rather than name a job or team will be implemented.
We expect that this will help users understand the role of other people and who they need to assign a project to and why.
What we'll do
Now that we're in public beta, we're able to add this functionality to the build and get feedback on it as it gets used in the real world.
We will learn from that user feedback and iterate from there.