1 of 55

BaT: Find & Apply – show and tell

Find Beta and Apply Beta – 20/03/2019

Becoming a teacher service line

2 of 55

The format

  • Quick recap 2 minutes
  • Find 15 minutes
  • Q&A from the room and on Skype 10 minutes
  • Apply 15 minutes
  • Q&A from the room and on Skype 10 minutes

3 of 55

Context

4 of 55

Where we fit into a candidate’s journey:

Explore

School experience

Choose courses

Apply

Track and interview

Make a decision

Meet conditions

Prepare and train

“I need to find teacher training courses that fit my interests, abilities and circumstances”

“I need candidates to know about my courses”

C

P

Find and Publish Courses

5 of 55

Where we fit into a candidate’s journey:

Explore

School experience

Choose courses

Apply

Track and interview

Make a decision

Meet conditions

Prepare and train

“I need to apply for teacher training courses, so I can qualify as a teacher”

“I need to assess applicants efficiently and accurately so I get the right people for my course”

P

C

Apply and Manage Applications

6 of 55

Find

7 of 55

  1. What we’ve done
    1. List of orgs on the rails
    2. UCAS settings
  2. What’s next?
    • Transition timeline update
    • Transition scope
  3. Q&A

8 of 55

  • What we’ve done
    • List of orgs on the rails
    • UCAS settings
  • What’s next?
    • Transition timeline update
    • Transition scope
  • Q&A

9 of 55

Orgs on the rails

10 of 55

Orgs on the rails

11 of 55

Orgs on the rails

12 of 55

Orgs on the rails

C#

Rails

13 of 55

Making sense of the Apply settings

In UCAS web-link there are:

  • settings that affect UCAS Apply
  • contacts that UCAS use for different purposes

These live in the part of web-link that UCAS will turn off.

UCAS can’t easily move or build these features themselves.

For UCAS Apply to continue working, we need to support these features too.

14 of 55

Settings that affect �UCAS Apply

The settings look cryptic.

Only 2 matter:�UTT application alerts�Type of GT12 required

UCAS provides a handbook to explain these settings.

Providers set these when they join and rarely alter them.

15 of 55

Decoding the settings that matter

Type of GT12 required

GT12 is a letter that’s posted to successful applicants. Providers can pick from different templates – choosing whether applicants need to confirm or not.

About 70% of providers ask applicants to confirm if they will or will not take the place. Where applicants reply to is set in another part of UCAS.

UTT application alerts

A provide can choose to get email alerts whenever a new application comes in.�Where those emails are sent to is also set in another part of UCAS…

16 of 55

Contacts that UCAS

ask for

Providers manage a “Contacts list” in UCAS. It’s cryptic too.

It’s here that they set:�- where applicants respond to�- who gets the application alerts

They also add:�- finance contact�- fraud contact�- web-link contact

17 of 55

Putting these settings and contacts in Publish

We needed to explain:

  • why these settings are in publish
  • what each setting was for
  • what each option meant
  • what each contact is for, and what UCAS will contact them about

And there’s one more complication: GDPR.

UCAS don’t have permission to share their existing contact data with us. So we can’t show providers what they’ve already set. We needed to explain that too.

Demo

18 of 55

  • What we’ve done
    • List of orgs on the rails
    • UCAS settings
  • What’s next?
    • Transition timeline update
    • Transition scope
  • Q&A

19 of 55

  • What we’ve done
    • List of orgs on the rails
    • UCAS settings
  • What’s next?
    • Transition timeline update
    • Transition scope
  • Q&A

20 of 55

Doing the transition

Transitioning in 3-4 batches from 10 April to 29 April

21 of 55

Pre-transition

Testing API integrations

Scheduling research

Providing guidance on the new features

22 of 55

Batch 1 transitioned

‘You have been transitioned’ confirmation email

Testing API integrations with real changes to course info

23 of 55

Review batch 1 transition

Time for integration changes / improvements to the API

24 of 55

Scale and repeat processes

25 of 55

How we’re going to be working with UCAS

Support

BAT will support all providers who require new courses through Google Forms and Zendesk

Testing

BAT and UCAS will use the first two batches to ensure that the integrations are working and nothing is affecting UCAS Apply

Research

BAT will research with the first two batches of providers to ensure transition has run smoothly

Comms

BAT and UCAS sharing responsibility for communicating the transition of providers

26 of 55

Features we’re adding for transition

  • Manage course vacancies (Prototype)
  • Manage provider locations (Prototype)
  • Request new courses using a Google Form

27 of 55

Request new courses using a Google Form

In our prototype we’ve built and researched a flow for adding new courses.�It’s tested well, but we don’t have time to build it for transition.

Research tells us that only a few courses will be added to the current cycle at this time of year. The new course flow is most important around rollover.

Before rollover we can use a Google Form as an MVP for adding new courses.�We can ask the same questions, but will need to manually create the course.

We will have an SLA of 1 day to get courses added.

The full course flow will be ready for rollover.

28 of 55

29 of 55

Google Forms

Google Forms allow us to use our “one page per thing” design pattern.

We are testing the form with users to make sure it collects the right information.

We need to ask Universities and SCITTs slightly different questions, so we have two forms.

If you’re a Uni or SCITT: Form

If you’re a School Direct: Form

30 of 55

  • What we’ve done
    • List of orgs on the rails
    • UCAS settings
  • What’s next?
    • Transition timeline update
    • Transition scope
  • Q&A

31 of 55

Apply

32 of 55

  • Team news
  • Product strategy
  • Vendor engagement
  • Prototyping
  • What’s next?
  • Q&A

33 of 55

Welcome Fred!

...sorry Fred.

34 of 55

  • Team news
  • Product strategy
  • Vendor engagement
  • Prototyping
  • What’s next?
  • Q&A

35 of 55

Work with vendors to allow data to be extracted from our system and made available for upload into each SRS, understanding more about context and constraints

Start by prototyping and testing elements of an end-to-end minimum viable product

-ISH

36 of 55

  • Team news
  • Product strategy
  • Vendor engagement
  • Prototyping
  • What’s next
  • Q&A

37 of 55

Vendor engagement

We can engage with all vendors in a reasonable timeframe

We’ve spoken to all but one vendor on the phone

Hypothesis: We can work with vendors to allow data to be extracted from our system and made available for upload into each SRS, understanding more about context and constraints

We can work with vendors to agree viable mechanisms to get data into their SRS’

We’ve started to have workshops with major vendors (Tribal & Oracle) to conceptually agree integration approaches

We can work with at least one HEI to co-design and test a service that enables their admissions workflow this year

We’ve identified Sheffield Uni as a potential co-designer, and explored tactical transfer mechanisms that can enable us to start testing quickly.

38 of 55

What we’ve learnt so far

  • Most Vendors would prefer to integrate via REST APIs �Tribal & Oracle have informally committed to working with us to deliver a REST API integration within our timescales (as long as their customers demand it). We are in the process of prototyping what an API might look like, and have received feedback on our initial spec.�
  • Vendors consider working on our service as a statutory requirement�Many have contractual obligations to enable their customers to “access ITT data”. Some vendors may seek to charge their customers for the move to Apply.
  • There are very few “Product-level” Data constraints�Any “hard” constraints are likely to be imposed by HEI’s customised admissions workflows and business processes. We need to conduct more analysis with universities.�
  • HEIs may struggle to consume their vendor’s integration with Apply. �Some vendors will attempt to use the need to integrate with Apply as leverage to force their customers to upgrade to the latest version of their product. We may need to consider tactical solutions ��

39 of 55

Sheffield University- Internal Processes

Automatic

Manual

Application download

Application review

Interview logistics

Offer communications

Post-offer

Tool

UCAS Teacher Training

In-House Portal

E-mail�Paper

Excel

UCAS applications sync to portal daily

Tutors download applications on Weblink, or via portal

E-mail template used for Interview comms

Decisions manually logged on UCAS

Application notification to tutors via e-mail

Action

Application decisions synced to portal daily

Data extracted for “HESA reporting”

Interviews arranged offline

40 of 55

Implications for our HEI Hypothesis

Sheffield would be willing to manage ITT applications in the short-term, without a real-time data integration with their in-house portal ���Whilst there may be some smaller HEIs that may be in a similar position to Sheffield, we know that some universities have complex admissions business processes within their student record systems. ���We’re aiming to work with some of Tribal’s customers next, to prototype an end-end solution, to fully satisfy our hypothesis.

41 of 55

  • Team news
  • Product strategy
  • Vendor engagement
  • Prototyping
  • What’s next
  • Q&A

42 of 55

Hypotheses:

A simplified Apply service does not impede provider decision-making

We can meet safeguarding requirements without full references

43 of 55

Research questions

Are providers able to make a decision to invite for interview based on the information provided by the application form?

Does the information provided on the form meet providers’ need to do an initial assessment of candidates?

Is there any critical information missing?

Why is this information critical, and what won’t providers be able to do without this information?

How usable is the form for review and decision-making? (For example, layout and visibility of information)

44 of 55

To test these hypotheses

We identified a minimal and viable application dataset based on previous research

We created realistic-looking application forms, representing a mix of personas, giving providers a holistic view of the applicant (link to the folder)

We tested with a representative range of providers (mix of HEI, SCITT, SD)

45 of 55

Research approach

Invitation sent out to providers to take part

4 applications attached for feedback

Providers asked to review, make decision and provide feedback

Phone interview

Providers who responded:

  • 2 SD
  • 3 HEI
  • 2 SCITT

46 of 55

Findings: overall look and feel

Clearer and more straightforward

“...the form appears to be much clearer and more straightforward and therefore much more user-friendly”

“exactly what you need when you do an initial sift”

To be improved:

Efficiency of scanning

“Tabulated data is easier to skim (for example, around work history)”

“It would be nice to have all related things grouped on one page”.

47 of 55

Findings: required information

UK nationality and status

Providers need to know if a candidate’s status gives them the right to live, study and/or work in the UK, and if they are eligible for financial support

Team to do:

Investigate exactly what information is needed to establish candidate status, and the questions to ask to get it

Use ‘branching’ in the design of the application form to cater for international candidates and establish their status, without disrupting UK candidates

48 of 55

Findings: required information

Education (academic qualifications)

Education information required to assess eligibility and subject knowledge

There are cases when providers need an overall picture of a candidate’s education (especially tertiary) to establish eligibility

When the subject a candidate wants to teach and their degree subject are not aligned, providers need to assess the level of knowledge

Team to do:

Present education information as a whole and let providers select relevant info

Explore design solutions to tease out a candidate’s subject knowledge, when degree and subject are not aligned

Explore options to assess subject knowledge

49 of 55

Findings: required information

Equivalencies

Equivalencies are a “grey area” that providers describe as “the most complicated part of the process”

In some cases candidates sit equivalences multiple times

Currently on UCAS, providers can select if they want to receive applications from applicants who haven’t sat equivalencies yet, and what kind of equivalencies they want to accept

Team to do:

Investigate equivalences (work with policy and Find data)

Explore design solutions so that when we need to ask for equivalencies, it does not distract the “happy path” user journey

50 of 55

Findings: required information

References

Providers express strong views that references should be part of the service

References currently used for: assessing candidate character (personality, resilience, reliability), to satisfy safeguarding requirements

While providers appreciate it’s an extra burden on candidates, and often are of little use, in some borderline cases (1-5%) references provide vital information

Concerns: if left to the end of the process, it places a greater burden on providers and could waste a huge amount of recruiting time

Team to do:

Investigate safeguarding requirements and come up with a clear statement

51 of 55

Success indicators (hypothesis)

Are you able to make decision based on the information provided?

Four out of 5 providers were able to make a decision on all applications;

Does the form allow you to assess if candidate:

meets basic eligibility requirements or has a potential to meet them

has teaching potential

has suitable subject knowledge

is eligible to study on TT program in the UK (UK status)

is eligible for financial support

is safe to be a teacher

is suitable for the training program offered by the provider

is committed and ready to go into teaching career

get a feel of applicant character (ability to express himself)

52 of 55

  • Team news
  • Product strategy
  • Vendor engagement
  • Prototyping
  • What’s next?
  • Q&A

53 of 55

Next steps

  1. Working with various policy and ops teams to bottom out need for references in safeguarding (‘law vs. lore’)
  2. Research rules around overseas applicants (right to work and study, fees and funding etc.)
  3. New iteration of provider data research
  4. Building a Prototype API to start testing with Vendors
  5. Research with Universities around their ITT admission workflows and data constraints

54 of 55

55 of 55

  • Team news
  • Product strategy
  • Vendor engagement
  • Prototyping
  • What’s next?
  • Q&A