DfE’s 9 regions consist of a list of authorities. Each authority has a team lead who is responsible for assigning applications to become an academy to delivery officers (DO).

Given team leads assign projects to DOs in the as-is process, it made sense to introduce a project assignment feature in our service.

Understanding the problem

We collated our user research findings about assigning projects on a Lucidspark board. We then thought of possible solutions and problems with assigning projects in our service.

A series of digital post-it notes about assigning an academy conversion project to delivery officers.

A series of digital post it note questions about assigning projects.

Design provocations

We compared our notes with other project assignment designs in DfE. We also reflected on the as-is process for assigning projects to DOs.

Screenshots from the Get help buying for schools service and the Complete conversions, transfers and changes service.

Guidance on assigning conversion projects in KIM and TRAMS.

Our interaction designer used these points of reference to create 2 design provocations:

  1. Choose from a pre-populated list of DOs. This was based on the designs of other DfE services, including our sister service Complete conversions, transfers and changes.

  2. Enter the email address of the assigned DO. A text field option if we couldn't pull users' names from a user management system. We believe it's easier to identify someone using their unique email address than it is their first name and surname.

Screenshots of two options: 1, choose from a list of delivery officers; 2, offline communications and entering email address (the as-is process).

We discussed the 2 options as a team and considered the pros and cons of each one.

Questions and feedback sticky notes about options 1 and 2.

This prompted a follow-on discussion about how we would maintain a list of users. We considered different approaches and the implications of each approach.

A digital whiteboard that shows a list of possible solutions based on options 1 and 2.

A set of questions and feedback sticky notes about some design solutions.

After a technical spike from both teams, we agreed on approach one: choose from a pre-populated list of DOs.

Instead of presenting a list of all DfE users, we decided to use DfE Active Directory to provide a list of users with access to our service. We believed this would include all the DOs currently using our service, as well as some irrelevant users (data experts in the Regional Services Division for example).

Prototype design

We created a prototype design considering everything that we discussed as a team. We included the autocomplete component used by the Complete team to create a consistent user experience.

We used the select component as the non-JavaScript solution and applied the autocomplete user interface as a progressive enhancement. This is recommended on the README in the autocomplete component.

A list of academy conversion projects. The first project displays an EMPTY tag next to delivery officer.

A conversion project for Bristol Gateway School. It has an EMPTY tag for delivery officer.

A page asking the user to assign a delivery officer to a project.

A dropdown list of names to select from to assign a project.

A page asking the user to assign a delivery officer to a project. Adrian Horan has been selected.

A conversion project for Bristol Gateway School. A success banner shows that the project is assigned and Adrian Horan is the delivery officer.

Both team leads and DOs will be able to assign projects using this feature. Whilst we believe that team leads are the primary users of this feature, there's no evidence to suggest that DOs being able to assign projects is a risk.

Next steps

We'll test our prototype with team leads and DOs in user research sessions.