Redesigning support forms
We are redesigning our support forms to meet the user needs of our support staff.
Additionally, we can better set expectations of SITs who intend to make a change in their training circumstances.
Why we did this work
Current procedures require school Induction tutors to notify the DfE of intent of any changes via support forms.
These existing support forms to request changes need to be fixed because users don’t provide the correct information, and what they send isn’t clear or relevant.
This means it takes a long time for support staff to chase up further information to respond to the queries in the forms.
User need
As a user support admin,
I want support requests to contain clear, complete information
So that I can resolve the ticket in one touch.
It is noteworthy that changing lead provider and delivery partner requests makes the bulk of support form requests
However, it is important to note that the support forms cater to the need of the internal team and the business and not the induction tutor.
This means inherent challenge still lies in the schools’ understanding of the process.
There is a widespread misconception that submitting the support form equates to the immediate implementation of the requested change, rather than just being a preliminary notification of intent.
The actual change process requires schools to communicate directly with their current providers, who in turn liaise with the DfE to confirm the transition.
This misunderstanding represents a significant disconnect between user action and service expectation, leading to direct impact on induction and training process, ECT and mentor access to the training material and administrative inefficiencies.
The new design aims to ensure that schools are made aware of the distinction between informing DfE and still having to contact their current provider for change to be initiated, acted-upon and then reflected on the relevant platforms.
Our approach
To improve the support forms we would ask induction tutors for more targeted information, with the intent to reduce ambiguity and improve efficiency of the support team’s response
Referring to the stats in the admin console, we can see that users sent some forms far more than most others. The numbers in which they were sent dropped off significantly after the list’s top 4 or 5 forms.
(screenshot of admin console forms data)
The team concluded that these should be the initial focus as they were the most widely used by some distance.
The second most widely used was a generic, freeform text style in the footer. The support team confirmed that although users often sent it, it was always one of the least useful to take action on.
So, rather than redesigning the generic form, the team decided to do the other forms first. This meant the generic form could be a branching point for navigating the newly redesigned forms.
The other redesigned forms would negate many of the requests sent in the generic form, requiring less design effort.
Workshops with the Support team, UCD, BA and engineering
The workshops were structured to capture perspectives to inform the revised support forms.
Our rationale was to ask SITs some simple questions about their intent, nudging them towards clear and actionable support requests.
We explored:
- What must the user know/do to send a meaningful support query?
- What details do the support team need to help with the request efficiently?
- What will the support agent do as a result of the request & what actions will they be able to take?
Next steps
The UR has compiled research objectives and written the discussion guide.
The prototypes contains four of the most widely used forms.
- Change lead provider academic year
- Change lead provider for an individual
- Change delivery partner
- Change programme for an academic year
However there is still some minor adjustments in terms of content that need to be addressed
The prototype can be found here
Support forms prototype
Password is ‘ect’ (without the quotes).
The team is in a good place for testing work to be picked up by the new user researcher when they roll on to the team.