We've long known, and long wanted, to link Prepare and Complete digitally.
The 2 products form the 2 halves of the process that happens in DfE when a school converts to an academy, or an academy move between trusts.
The overall process is a bit more complicated, but fundamentally Prepare helps DfE teams to get information to people who make decisions about whether a school should join a particular trust.
Once those decision makers approve the conversion or transfer, Complete helps teams in DfE make that conversion or transfer happen.
Both applications provide DfE with a level of oversight of the work.
Entering the same information
Because the applications are separate, users have to re-enter information the department already knows when they add that approved project to Complete.
This has been a long-standing frustration for those of us who work on Prepare and Complete, as well as those who use it.
A broad themes of the feedback we've had from users are that it's annoying, costly and confusing.
Manually entering the information makes it feel like a clunky, disjointed journey. The simple truth is that if we're asking for information we already had it makes us look daft and wastes the time of our delivery officers and caseworkers. Time they could spend working on the project, helping schools.
Time to iterate
Frustrating as the lack of connection is, this was the minimum viable solution considering the contraints that we had at the time. It very much was a first iteration and we knew we would have to join them up at some point.
Now, with these products live, in use and able to handle all projects types so we can get off the old technology, we're able to come back to this and begin work to remove this re-entering of data.
This will begin to make the applications function in a more joined up way and save delivery officers and caseworkers some time.
How projects get passed to Complete now
There are several steps a delivery officer must complete in Prepare before a project can be worked on in Complete.
Create the advisory board template
Delivery officers work through the task list, gathering the information they need to create the project template.
The project template is forms part of the information that advisory boards use to review whether a project should go ahead or not.
Decision made about the project
The advisory board give their advice to the decision maker, who then has the final say on if a conversion or transfer should go ahead.
The advisory board meeting and decision-making process happens offline.
Record the decision
Whatever the decision, the delivery officer then needs to come back to Prepare to enter it.
They answer a series of questions, review them and then record the decision.
If the project is approved then the project's time in Prepare over, however the delivery officer's work is not yet over.
Despite there still being actions for the delivery officer to take, they see a notification banner that tells them the decision has been recorded but provides no further instruction.
The next stage is managed through Complete.
Recreate the project in Complete
This is where the re-entry of information comes in.
To add the project to Complete to that they or another person can work on it, a delivery officer must log in to Complete, fill out the information in the relevant "Add a project" form.
Once the form has been completed, the user sees a confirmation page.
The project can now be assigned to another delivery officer or caseworker.
Delivery officers should also add contact details at this point, although it is not essential for the project to be assigned.
Mapping what Prepare already knows vs what Complete needs
At first we worked to understand where we asked for information in Complete that we also asked for in Prepare or Apply.
We also looked at information we knew Complete had and where we might be able to ask for that sooner. Contact details are a good example of this.
Sketches and prototypes
We sketched ideas for ways we could capture information about which team would manage the project next and who the contacts were in Prepare.
We designed a clickable prototype in Figma and shared it with the team.
One step at a time
After getting feedback from the team, we realised that collecting contact information earlier in the process was too complicated for a first pass at this work.
It would be great from a user experience and user time efficiency point of view, but we were getting ahead of ourselves.
There would have been too much development work required to bring that functionality in to Prepare at this stage, with just a couple of sprints left on this project before a new team came in.
What we needed to do was prove that we could pass information Prepare already has, before working out where and how to gather that information before the project gets to Complete.
We had to focus on how we could reduce the data entry required in Complete and streamline any data entry that would remain after this first iteration of the work.
Keep it simple. Share work early and often
There's a question we should always try to ask ourselves as designers when we work in Agile teams.
What's the most amount of value we can deliver for the least amount of cost?
It's so easy to lose sight of that, and that's what happened here with our first sketches.
Trying to find the right balance of something that makes a great user experience and something that is technically achievable in the time available is hard. You can see the possible flaws. You can see how we can make it really simple to use.
But with limited technical knowledge, it's hard to judge what is easily achievable and what is more complicated. What looks easy to use is not necessarily easy to code.
We are not developers. We don't see the complexity in the code. That's why it's so important to share design work with the team early and to design with developers.
On reflection, that's something we didn't do early enough on this piece of work.
Re-working the designs
We only had a couple of sprints left before the current incarnation of the team moved on to another project and handed this work over to a new team.
So we had to keep it as simple as possible. That would allow us to deliver value that would save users some time, without the implementation of the work being technically complicated and time consuming.
We focussed first on process mapping the way projects are currently handed over to Complete.
That really helped us to focus in on what was absolutely essential to do.
We looked at the "add a project" forms and project summary information that we knew people entered in Complete and looked for places in Prepare that already held that information.
We ended up with a list of data points that Complete needed to be able to create a project that could be assigned and worked on:
- school or academy URN
- advisory board date
- advisory board conditions
- provisional conversion date
- academy order type
- provisional transfer date
- incoming trust UKPRN
- name and email of the person who worked on the project in Prepare
- group reference number
- if a transfer is due to an Ofsted "inadequate" rating
- if a transfer is due to a finance, safeguarding or governance issue
- if outgoing trust will close
- new trust reference number (if being formed)
- new trust name (if being formed)
Not every project type needed every data point in the list. Some only applied to transfers. Some only applied to projects where a new multi-academy trust would be formed.
Regardless, if we had that information already then we could and should send it to Complete rather than get the delivery officer to enter it all again.
So, with that in mind, we designed some new ways of how the handover process might work.
Getting feedback from users
We got feedback on the sketches from delivery officers who work on projects in Prepare and hand them over to caseworkers in Complete.
We also got feedback from team leaders in Regional Casework Services who are involved in handover meetings to decide which projects get passed to their teams.
We updated the sketches based on that feedback we got and ran through it with the team.
The simplified version of project handover is going in to development now and will be released soon.
How the new handover process will work
After a decision to approve a project has been recorded in Prepare, users are presented with a confirmation page.
This page tells them the project has been automatically sent to Complete and that they need to add some remaining information before it can be handed over to another person.
When they arrive in Complete, the user will see a list of projects to hand over. They find the project they have been working on, add the missing details, and then the project will appear in the relevant team's project list.
This still requires some data entry, but it's the information that DfE already has about the project is automatically added.
What happens next
This is just the first step on the journey towards data exchange between Prepare and Complete.
There are some immediately obvious ways we could develop this further.
- Gather all information Complete needs to create a project earlier, in Prepare or Apply
- Include known contact details in Prepare. They could be entered by a person or imported from a central shared thing that all RSD's applications can access
- Pass information from Complete to Prepare. If a project does not convert or transfer for any reason, that can be automatically reflected in the Prepare project
Getting existential about the service and how people get between the products
All this had made us think about the end point of Prepare. There are some more questions we would love to explore.
- what is the value of Prepare and where should it end?
- should the recording a decision be its own application?
- should handing a project over also be its own application?
- is there is a need for us to think about how to guide users between the products as the service become more mature?
- will that provide more clarity to users on their responsibilities?
- will that help improve navigation?
- will it give users a better sense of a joined up and connected service?
Measuring success
We also need to look at how we prove that this work has saved the department time and, by extension, money.
We could use analytics to see what the average time a user spent on the "Add a project" forms in Complete was before the change, and what the average time spent on the page to handover the project is now.
This benchmark could be used in future to measure the successful of any further iterations too.