Each page in our task list is based on a relevant section in Free Schools Store (FSS).
The pages generally follow this structure:
- yes or no question. For example, 'Final version of detailed curriculum plans submitted' (yes or no)
- forecast date - when the project lead / delivery officer expects the task to be completed
- actual date - when the task was completed
- comments on decision to approve (if applicable)
- link to a Microsoft SharePoint file
When designing our financial plan task, we wanted to confirm with our subject matter experts (SMEs) whether this page structure was useful.
Analysis
Yes or no question
After several conversations with SMEs about different FSS sections, it seems that these questions have 2 purposes:
To confirm:
- that the project lead has completed a task which needs completing. For example, a kick-off meeting has been completed
- what decision a third-party has made. For example, whether the academy trust wants to opt-in to a risk protection arrangement (RPA) or not
For the first purpose, a no answer did not make sense to the SMEs. This is because tasks need completing by project leads, unless we indicate the task is not applicable. A yes answer is the correct answer.
For the second purpose, yes and no are both valid answers. In the RPA example, it is valid for a trust not to opt-in to this.
Forecast date and actual date
Not all tasks need a forecast date and actual date. Only certain tasks do, such as the 'key milestones' in the pre-opening timeline for free school projects.
Comments on decision to approve (if applicable)
A comments field will not meet the need for every FSS section.
For example, SMEs saw repeatedly in the finance plan task that users inputted into the comments field whether the local authority had underwritten school places. Note that local authority underwriting places does not apply to all free school projects.
SharePoint link
Some SMEs felt that the benefit of a SharePoint field is to confirm whether the project lead has saved the file in SharePoint. It's not important what the file's URL is.
They also felt that SharePoint was the wrong word and we should instead use Workspaces.
The word Workspaces appears throughout some chapters of the free schools guidance that project leads should refer to when managing projects - not SharePoint.
First iteration
Based on the above analysis, we have created an iterated design for a task page.
This iteration includes:
- a checkbox for the user to confirm whether they have completed a task
- no forecast date
- an actual date, but re-worded to 'Date agreed' to be more specific
- a question called 'Local authority agreed to underwrite pupil numbers', with yes, no and not applicable options
- a Comments box, to be consistent with other task pages
Second iteration
When we played the first iteration back to the team, the word 'Done' did not feel intuitive to them. This was especially the case when Done was presented on the summary list for tasks.
The team suggested we should look at designs from Complete conversions, transfers and changes which project leads also use.
We created a second design without the 'Done' checkbox, and instead use the task as the checkbox label. For example, "documents saved in Workplaces folder".
Next steps
Test these task page iterations with users, to validate which one meets user needs.