5 new posts about adding an ECT (#345)

* Create add-an-ect.md

* made format changes

* added drafts

* Update correcting-names.md

* added start date

* added remainder of posts

* Apply suggestions from code review

Co-authored-by: Claire Hughes <93539621+claire-hughez@users.noreply.github.com>

* Update assigning-mentors.md

* Update saving-default-choices.md

---------

Co-authored-by: Claire Hughes <93539621+claire-hughez@users.noreply.github.com>

app/posts/ecf-v2/asking-for-lead-provider-and-delivery-partner.md

@@ -0,0 +1,60 @@
+---
+title: Asking schools for an ECT or mentor’s lead provider and delivery partner
+description: "We've designed a journey to ask schools for the lead provider and delivery partner for their ECT or mentor."
+date: 2024-11-05
+---
+
+## Why we’re doing this
+
+Currently in ECF1, the lead provider submits a ‘partnership’ over the API that connects them with a school. This will mean they’re responsible for training that school’s ECTs and mentors for that academic year. In this partnership, the lead provider states the school, delivery partner and lead provider combination.
+
+Lead providers have told us it’s sometimes tricky for them to set up these partnerships. We wanted to consider asking schools to tell us the lead provider and delivery partner because:
+
+- sometimes schools don’t inform lead providers they’d like to work with them, which can lead to delays in training for ECTs and mentors
+- schools also get confused about the partnerships process, and expect to be able to submit or change these details like they do during rollover
+- we receive support tickets from schools regularly to make changes to partnerships
+
+## What we tested with users
+
+In the first round of testing, we asked schools who their delivery partner was. We deliberately avoided the phrase ‘delivery partner’ as we heard anecdotally schools weren’t familiar with this terminology.
+
+![A screenshot of the first prototype we tested with to ask users for delivery partner.](/ecf-v2/asking-for-lead-provider-and-delivery-partner/screenshot1.png)
+
+We didn’t ask for the ECT’s lead provider. This is because, in the vast majority of cases, we could infer the lead provider for an ECT or mentor based on their delivery partner. Delivery partners typically only work with 1 lead provider.
+
+However, this tested very badly.
+
+Users were confused. They had previously given their appropriate body, and often this was the same organisation as their delivery partner. The question was too ambigious - ‘provide training’ did not give them any clarity. Some users thought we were asking for their lead provider.
+
+No users clicked into the details component to find out more about the delivery partner organisation either. Potentially this would change outside of user testing sessions, but it felt important to expose some more information about the organisation outside of the toggle.
+
+## How we iterated the questions
+
+We decided to ask schools directly for their lead provider. We thought this was a good idea because:
+
+- lead provider was more important to get right, as they would see the information over the API depending on this question being answered correctly
+- whilst schools struggled to always understand the different roles in ECF, they could clearly recognise the name of which of the 6 lead providers they were working with
+- we could ask schools for their delivery partner from the list of eligible delivery partners working with that lead provider for that academic year
+
+We also iterated the content for asking for lead provider and delivery partner, bringing out one of their key responsibilities to the main question.
+
+![A screenshot of the second round prototype we tested with to ask users for lead provider.](/ecf-v2/asking-for-lead-provider-and-delivery-partner/screenshot2.png)
+
+We also decided to ask schools if their delivery partner was the same as their appropriate body. This is because in around 80% of cases, it is the same organisation. Users in our first round of testing were confused why we asked for the same organisation twice.
+
+![A screenshot of the second round prototype we tested with to ask users for delivery partner.](/ecf-v2/asking-for-lead-provider-and-delivery-partner/screenshot3.png)
+
+This tested much better with schools in our second round of testing. They successfully answered each question. However, it’s worth noting we only tested with users where their delivery partner was the same as their appropriate body.
+
+When we tested this, schools also said it would be more helpful to see guidance or information about the 3 different organisations in ECF in 1 place. Learning about a delivery partner in isolation was less helpful to them than comparing that organisational role with that of a lead provider or appropriate body.
+
+## What we need to do next
+
+Whilst these iterated questions tested much better with schools, we still have more to think about.
+
+We still need to think about:
+
+- how we’ll surface this over the lead provider API
+- if we can get the organisation data for delivery partners and appropriate bodies to match up correctly
+- researching with schools where their appropriate body is different to their delivery partner
+- how we can help schools better understand lead providers, delivery partners and appropriate bodies and the differences between them

app/posts/ecf-v2/assigning-mentors.md

@@ -0,0 +1,35 @@
+---
+title: Assigning mentors through the ECT record
+description: "Why we've changed the way we ask for who is mentoring the ECT"
+date: 2024-11-05
+---
+
+## Why we’re doing this
+
+In ECF1, there are existing mentor records without assigned ECTs within the service. This is a problem as a mentor is not eligible for funding or training until they are assigned.  It also means we might hold personal information for a mentor when this data isn't always being used for the purposes of training or funding.
+
+We also want to make sure schools fully understand their ECT registration responsibilities. We wanted to make sure school users knew to assign a mentor to their ECT record for the registration process to be complete.
+
+## What we tested
+
+We contemplated different ways to solve this problem. 
+
+Our first option was beginning the ‘add a mentor’ journey with selecting which existing ECT record(s) they will be assigned to (see screenshot below). This would mean mentor records could not be created without an already registered ECT connected to them.
+
+![A screenshot of a journey where we ask which ECT is being mentored when adding a mentor.](/ecf-v2/assigning-mentors/screenshot1.png)
+
+However, this was later iterated to be added to the end of the ‘add an ECT’ flow. This way the user could select already existing mentor records. In the case of a new mentor, they will select ‘someone else’ and be prompted to begin the flow of adding a mentor once the ECT registration is complete. We hoped this would help speed up assigning mentors to ECTs, where the mentor record already exists.
+
+![A screenshot of asking who will be mentoring the ECT.](/ecf-v2/assigning-mentors/screenshot2.png)
+
+![A screenshot of giving the user next steps if they choose to not assign a mentor.](/ecf-v2/assigning-mentors/screenshot3.png)
+
+The user will have the option to return to their ECT list if they don’t want to add the mentor. If they do this, the ECT record is incomplete and will have a prompt beside it to assign a mentor (see below). We’re hoping by flagging to users that to finish registering the ECT, a mentor needs to be assigned, that the school user has a clearer idea on when they’re done and what’s needed of them.
+
+![A screenshot of assigning a mentor after adding ECT.](/ecf-v2/assigning-mentors/screenshot4.png)
+
+## How it tested and next steps
+
+In the case of selecting ‘someone else’ for their ECT’s mentor, users expected to be then asked for the name and details of that mentor. Instead, the flow continues to a final check your answers page which left users confused around when they’d add a mentor, despite getting the ‘what you’ll need to next’ page directly after.
+
+We’ve decided to remove the mentor selection page within the add an ECT flow. Instead,  we'll direct school users to assigning an existing mentor or adding a new mentor once their ECT is registered as this  better fits their expectations on the journey. It allows schools to give all the information for a mentor at once, or later, if they need to.

app/posts/ecf-v2/correcting-names.md

@@ -0,0 +1,58 @@
+---
+title: Improving how we gather an ECT or mentor’s name
+description: "Why we wanted to change how we find a participant's teaching record and how this changes the name we collect from schools."
+date: 2024-11-05
+---
+
+## Why we’re doing this
+
+In ECF1, school users are asked to give an early career teacher or mentor’s TRN, date of birth and name when registering them.
+
+When this is done, we check the Teaching Regulation Agency’s teacher records to make sure that person is eligible to become an ECT or mentor.
+
+For example, we check that the early career teacher has qualified teaching status.
+
+In ECF1, we ask for the name, but this isn’t actually needed. We can make the check based on either TRN and date of birth, or TRN and national insurance number. This would still be compliant with data security.
+
+But in ECF1, the name is largely asked for because:
+
+- to validate that the person being registered with that TRN has the same first name as on the official teacher record
+- to make sure the name we have for that person is up to date, as we know sometimes the official teacher record might be outdated
+
+This name is then passed on to lead providers and informs how they set them up with training and learning materials.
+
+However, in ECF1 this results in support tickets and users being blocked from registering where the first name being entered in registration doesn’t directly match the name held on the official teacher record. For example, the user is entering ‘John’ instead of ‘Jonathan.’
+
+It can also waste a school’s time giving us a name when technically we already store a name for that ECT or mentor in their TRA teacher record.
+
+## What we tested with users
+
+![A screenshot of the asking users for an ECTs TRN & DoB.](/ecf-v2/correcting-names/screenshot1.png)
+
+We decided to ask school users for the ECT or mentor’s TRN and DOB.
+
+We would then show them the name of that individual stored in the TRA’s records.
+
+![A screenshot of giving users the option to review the name which is returned.](/ecf-v2/correcting-names/screenshot2.png)
+
+This tested well with schools. They liked that it made sure they were registering the right person and saved them time entering the name.
+
+It also helped them realise it was connected to that individual’s TRA teacher record. We hope this will prevent schools from entering a completely different person’s name when registering an ECT.
+
+Schools said if the completely incorrect person showed, they’d go to their school office to check. They ignored the content there. We only anticipate this happening when schools might accidently mix up who they’re registering – it should be impossible unless they have the TRN and date of birth for that person.
+
+In testing, schools understood they should only give us a more up to date name for a significant reason. For example, if that person’s surname had changed after marriage.
+
+![A screenshot of giving users the option to edit the name which is returned.](/ecf-v2/correcting-names/screenshot3.png)
+
+We also had to make clear that the corrected name would only be used for the purposes of ECF training. It wouldn’t update that ECT or mentor’s TRA teacher record. To do this, the actual ECT or mentor needs to go to the Access your teaching qualifications service with legal proof of a name change. Users typically understood this well, and that changes here wouldn’t impact anything other than the Register ECTs service. However, 1 user thought it might ask ECTs or mentors to update this themselves later.
+
+## What we need to do next
+
+We should think about removing the content on what to do when the person shown isn’t the individual they intended to register.
+
+Longer term, when we launch Register early career teachers, we should monitor what names schools give when they correct an ECT or mentor’s name from their TRA teacher record.
+
+If they are giving corrections that are changing the name to a different person, we would need to rethink this design.
+
+We might also want to explore how the TRA Digital team can try to encourage individuals with TRA teacher records to keep their details up to date. This would mean it doesn’t need correcting in our service.

app/posts/ecf-v2/ects-start-date.md

@@ -0,0 +1,29 @@
+---
+title: Asking for an ECT's start date
+description: "Why we've added a question to ask schools for an ECT's start date."
+date: 2024-11-05
+---
+
+## Why we’re doing this
+
+We want to ask for the school start date so that we can:
+
+- surface to the lead provider a start date for the ECT, so that they can make sure that the ECT starts training at the right time
+- show the correct lead provider, delivery partner and appropriate body organisations to the school user – ones that are working within the early career framework for that academic year
+- know what funding that the ECT is entitled to
+
+## What we tested with users
+
+![A screenshot of the start date question in the prototype.](/ecf-v2/ects-start-date/screenshot1.png)
+
+We tested a page where users could input a month and year for when the ECT had started with the school.
+
+Users suggested they’d have no issues providing this information. However, we’ve noted we can iterate the heading to better clarify the ask – by changing the heading to ask when the teacher ‘started as an early career teacher’.
+
+In rare circumstances, the date they started may be different to the contract start date. In those circumstances, users stated they’d use the date that the ECT started rather than the contract date.
+
+In the previous service, we had asked users to select from a list of terms, which could be confusing when ECTs were starting in between academic years. We only asked this at certain times of the year, and asking always will make sure that we hold an accurate date.
+
+## What we need to do next
+
+We’ll progress adding this journey to the development of the service build and keep monitoring in further rounds of research to ensure issues aren’t flagged.

app/posts/ecf-v2/saving-default-choices.md

@@ -0,0 +1,26 @@
+---
+title: Default choices for the add an ECT journey
+description: "How we want to make it easier to add ECTs for schools by allowing users to save default programme choices."
+date: 2024-11-05
+---
+
+## Why we’re doing this
+
+Currently in ECF1 school users set up the programme type, AB and training details which are then applied to all ECTs and mentors that they register going forward. The problem is that there are cases in which ECTs and mentors will have different training details and there currently isn't a way of specifying this difference in the add ECT journey (they would need to edit details once record is registered).
+Therefore we've introduced the default programme choice as an alternative to setting up school-level details for AB, LP, DP and programme type, as we know there may be ECTs and mentors within a school that differ.
+
+## What we tested
+
+When a school user registers their first ECT's details, they will be prompted to input the:
+- programme type
+- appropriate body
+- lead provider
+- delivery partner
+
+Once they provide their details for the first ECT they register, we  asked if they would like to save the details provided for future registrations of ECTs and mentors. This doesn’t block users in future if they have an ECT or mentor with differing programme details to the default choice. They will have the option to manually input these details, but in most cases, schools will have consistent details for the majority.```
+
+![A screenshot of the asking users if they'd like to save their choices as defaults.](/ecf-v2/saving-default-choices/screenshot1.png)
+
+## How it tested and next steps
+
+Research found that this feature mainly tested well, and school users knew what to do when interacting with the screen. However, some users mistook it as a ‘check your answers' page so we are looking into iterating the heading to make the purpose clearer for our users.