What is induction data?
Statutory induction serves as the transition from initial teacher training (ITT) to a teaching career, helping early career teachers (ECTs) develop the skills they need to succeed.
Induction data was held on the Database of Qualified Teachers (DQT) and contained a teacher's overall induction record, including:
- induction status
- start and completion date
- any exemption reason (if applicable).
These are the only data points which migrated to TRS other than person data.
Why we did this work
The induction data 'bucket' was one of the groups of data being migrated from DQT to the Teaching Record System (TRS).
The TRS console will show the status of a teacher's induction and capture a reason for any change in that status. It will also capture:
- start and completion dates
- whether they have an exemption from induction
- the reason for that exemption.
Changing to and from particular statuses would trigger subtly different yet explicit journeys, requiring either updating or capturing some of the data points mentioned above.
A positive outcome would be more timely handling of support queries and up-to-date teaching record data.
What we did
We took a pragmatic approach where we:
- created an initial concept based on the possible flows which are fairly rigid as they depend on the current status
- collaborated with stakeholders and SMEs to refine the concept
- undertook multiple iterations based on stakeholder feedback
- ‘built at risk’ as the flows were predefined and time was short
Being restricted by time, we decided to lean into the expertise of a couple of our SMEs and potential users, iterate our concept with them, then 'build at risk'.
Furthermore, the design work centered around changing a status which, on change, triggers a relatively short, linear journey based on the new status.
Some usability testing will be done in the future in the pre-production environment.
How we worked together
We collaborated with the Record Inductions as an Appropriate Body (RIAB) service team to establish a seamless data-sharing process between the two services.
To maintain data integrity and reduce redundancy, we implemented restricted functionality when inductions are managed by the RIAB team.
Since induction period data is now correctly stored within the RIAB service, the overall induction record (held in TRS) can be updated by both TRS support users and Appropriate Bodies via the RIAB service.
By limiting duplicate data storage, simplifying technical complexity and introducing appropriately restricted functionality, we ensured a more efficient and reliable system.
Managing risk
Due to the significant dependencies between the RIAB team and our team, we had weekly meetings which included stakeholders and SMEs, as well as users of the service.
The RIAB team needed to build a service for users to manage induction periods, which were no longer going to be owned by TRA. The linked functionality between the consoles required significant collaboration on business rules.
These meetings enabled us to manage and mitigate risks as they came up, and coordinate between the two teams on the design and functionality of the console.
Flows
The graphic below shows the available initial pathways for any current status changing to another induction status.
Screenshots
The images below are from the journey where an induction status is changed from Required to complete to Exempt
Landing page
What is their induction status?
Why are they exempt from induction?
Why are you changing the induction details?
Check your answers
Landing page with success flash message
Prototype
The prototype can be found here.