Up to this point our work and research had been focussed on the first few groups of tasks. As we spoke to more users about the later part of the process, we understood more about how the conversion is completed and what that meant for the content and design patterns we'd created.
Not all documents are equal
We already knew that some documents are always used on every conversion.
Those documents are:
- Land questionnaire
- Land Registry title deeds
- Supplemental funding agreement
The rest are dependent on the school's situation.
Church schools may need some documents that non-Christian schools don't, such as the Church supplemental agreement.
Caseworkers may add documents where they realise a particular document is needed.
Solicitors might decide certain documents, such as the direction to transfer, are required.
Document statuses vary
Those documents that are used, do not necessarily all go through the same stages.
Documents can be:
- Received by the caseworker
- Cleared by the caseworker
- Cleared by the legal advisers office
- Signed by the school, trust or their solicitors
- Saved to SharePoint
- Signed and sealed by the Secretary of State or their representative
- Redacted by the caseworker
- Uploaded to GOV.UK
But while most documents need to be “cleared” (language caseworkers use to describe a document being checked and agreed), not all of them have to be.
Similarly, not all documents need to be signed and sealed by the Secretary of State or their representative.
Deciding how to include signing and sealing actions
Initially we wondered how users thought about signing, sealing and redacting documents.
We spoke to some users to understand this. Through that research it became clear that users think of redacting the documents as separate to the rest of the document tasks.
They do these tasks after the school has opened, and they set aside time to redact them all at once.
Other document tasks are done as and when the information is available, and they must be done before the academy can open.
This meant that we'd need a separate task on the task list for redaction. Would we need a separate task for signing and sealing documents too?
Discussing the changes as a team, we felt there were two options.
- Add the signing and sealing actions to the existing clearing document tasks
- Create another section of tasks for signing and sealing documents
Adding the actions to the existing tasks would mean some refactoring for the developers in the work they've done in the build.
Creating another section of tasks would be less effort from a development point of view, but the benefit of putting the additional actions in with the existing document steps is that the user will see the document as being “complete” in the status tags.
Conceptually, the users see the document as done when it has been signed by the school and the Secretary of State. Our hope and expectation is that this method fits with the users' mental models.
As we currently understand the process, we felt it would be most useful to go with the first option. We iterated the document task design to include the signing and sealing actions.
How adding signing and sealing tasks changed our current design
Adding the signing and sealing of documents to the current design meant creating a second list of checkboxes in the current design.
The pattern for these actions is like the existing one we've used for documents, so there's no major redesign required.
However, we did try to clarify the difference between “signing” (done by schools after the document is clears) and “sign and seal” (done by/on behalf of the secretary of state when the school is ready to convert).
Testing if the design made sense to users
After designing the new actions and adding them to the prototype, we tested it with 3 users as part of a round of user research.
They expected to find tasks around the signing and sealing documents in an additional section of tasks in the task list. However, when they saw the actions in the existing document tasks, they felt that made sense.
They did emphasise that for that design approach to work, they would need additional status tags that reflect whether a document had been cleared, signed and sealed, rather than the current “not started”, “in progress” and “complete” status tags.
This feels entirely logical, but it's something we'll need to explore further to understand what it is the status tags need to communicate and the best language and colour to use for these additional statuses.
However, content in the prototype that describes the document tasks had not been updated ahead of the research. The heading for that section said, “Clear legal documents”, which could have, understandably, caused users to think that section had nothing to do with signing and sealing.
What we'll do next
We need to fully understand if placing the signing and sealing tasks in the legal documents section makes sense to users.
The initial feedback gave us a sniff of how users might feel about it but was only a small sample of users. We hope that we'll learn more about whether this design works for users during private beta.
We need to find out if the additional status tags used to describe document status give users a clear understanding of where that document is up to and what remains to be done.
We need to think about the naming of the “Clear legal documents” section. This collection of tasks no longer just focuses on clearing documents, but can include other statuses too. Should it be renamed “Clear and sign legal documents”, which could imply that all documents need clearing and signing when not all do, or something else?
We'll make any necessary changes before private beta and look forward to what we can learn from that.