Rebecca Chan (Project Manager)
Gavin King (Client CPO & UI Design)
The Problem
Organising teaching cover has historically been stressful for all parties. With schools typically learning of a staff member’s absence on the morning in question, a significant rush ensues to phone supply agencies that are expected to identify, secure and deliver a suitable candidate to the premises all before the school day begins.
Project Overview
During four weeks of discovery and six weeks of UX design I was tasked with:
1. Increasing platform engagement and adoption
2. Reducing friction & fatigue for hiring managers
3. Championing product development agility through rapid prototyping
Who are Opogo?
Their twin platform consisted of a client-facing web app and a native mobile app for the candidates, each providing a wealth of functionality for their respective user.
Legacy feature set
- Search for & book supply teachers
- Add favourites to a Talent Pool
- View Recommendations from Opogo
- Manage live jobs or sent offers
- Sign off Timesheets
- Connect with other teachers via a Community social platform
- Watch Tutorials
- Chat with Opogo Customer Service
- Setup a profile
- Set availability to teach
View & Search for Jobs (live, history & matched)
- Upload ID and other compliance documents via Opogo Pass
- Complete Timesheets
- Chat with Opogo
- Connect with other teachers via a - Community social platform
- Set personal preferences (max journey time, preferred travel method & notifications)
Discovery
Google Analytics or Firebase hadn’t been setup on either application meaning my four weeks of in-depth, largely qualitative research involved:
- Exploratory internal interviews with the senior client team and customer service consultants
- Wide-ranging discussions with non-Opogo teachers
- Task-based testing sessions with clients and candidates across their respective interface
The resulting stakeholder and user pain points helped refine a holistic experience map which isolated the morning rush between 6am and 9am as the key source of insight and opportunity.
.jpg)
Prioritising the numerous user challenges identified revealed three design epics that would add the most value in six weeks.
1. Supercharging the schools’ dashboard to focus on booking candidates
As a significant friction point for hiring managers during the morning rush, refining the web-app home screen would remove ambiguity, prevent decision paralysis and lessen manual CS requests over the phone.
2. A fully transparent & connected candidate journey
Installing new features focussed on transparency and trust would help manage client anxiety around candidate arrival, encourage candidate app interaction and reduce reliance on Opogo Customer Service as the middle men.
3. Installing a standardised candidate review system
Placing consistency and honesty at the centre of Opogo (and teaching supply in general) using commonly understood attributes to vet both user groups.
Taking concepts from paper to Figma prototype I proceeded with three 2-week sprints, conducting user testing with a mix of existing customers and non-Opogo school staff to validate each design decision.
UX Sprints
Sprint 1: Finding & Booking Candidates
Schools users were hesitant about which path to “Book Supply” when tasked to do so.
The Schools booking dashboard offered multiple paths to search for potential candidates. Conflicting feature and CTA terminology such as ‘Quick Book’, ‘Add a Job’ and ‘Talent Pool’ was causing decision paralysis meaning that during the morning rush the platform was falling at the first hurdle.
Simplifying the nav, I ported the web-app core functionality into two channels; Book Supply & Manage Jobs. Beneath, a search bar & filter-powered candidate dashboard replaced the convoluted, multi-path, mixed terminology booking journey to allow for immediate comprehension.
All customers and external testers found the revised home screen IA & filtering intuitive & swift to use.
“If this is taking me too long, I pick up the phone.”
- Chris (Supply Manager)
The slow process finding a suitable candidate and sending a job offer out often caused users to default back to calling the Opogo CS team.
To lessen this habit the booking journey needed to be seamless. My design implemented a 3-click job offer flow whereby the user would select the date the candidate(s) were needed, click ‘check and confirm’ on the bottom screen overlay, and then simply review the job summary screen before sending the offers out.
All testers found the revised journey intuitive.
Each hiring manager assessed a candidate's viability differently.
Schools have specific expectations when filling a role. Questions around available budget, whether the candidate will arrive on time, if they are a good personality fit, and will they do a good job need to be answered efficiently and concisely in order for a satisfactory decision to be made.
Displaying key top-line attributes (day rate, response time, journey time, an Opogo score and % of schools that would re-book) within the candidate card furnished each user with sufficient detail to quickly deduce suitability based on their needs. Should they require further detail, an overlay would launch upon click revealing a candidate video snippet, qual school feedback quotes and six personality traits scores which made up the Opogo score.
1. The feature & CTA terminology needed some tweaking with ‘Preferred list’ reverting back to the learned ‘Talent Pool’.
2. The five day week calendar picker wasn’t obvious to some as being an interactive booking function. So instead, only the date(s) selected would show and a ‘Book’ checkbox on the far right hand side proved to be clearer to the testers.
Sprint 2: A transparent & connected candidate journey
“If one person doesn’t accept the job offer, what's gonna happen?”
- Daniel (Deputy Head)
As a common use case, the legacy industry behaviour saw the supply agency source a new candidate as soon as a job offer had been declined. Equally, we’d heard from both clients and the Opogo team that inaccurate candidate availability setting was a common problem, and so providing visibility into job offer status, being accepted, or declined, was paramount if the new platform design was to effectively manage anxiety.
A date-ordered job offer management page with a specified response count down timer, an additional prompt function, and the ability to add more candidates to a job without a new search would give the clients full visibility and control over sent offers.
Schools’ testers were unaware of the prompt function due to the use of a lightening bolt icon in the wireframe. Upon being told, they suggested it would be a useful feature meaning Gavin simply amended the icon when applying the UI.
“If they're not on time and you don’t know where they are its hugely frustrating.”
- Danny (Supply Manager)
A major pain point for the clients was waiting for the candidate to turn up, whilst being concerned whether they would arrive on time, or even at all. This in turn placed pressure on the Opogo customer service team as it would stoke the very behaviour the platform was attempting to limit - inbound phone calls from clients.
In order to drive a user behaviour change away from picking up the phone to check on a candidate’s status, new features were needed to help manage client anxiety and take the pressure off the Opogo team. Upon a job offer being accepted, the school interface would reveal:
- A system-estimated arrival time based on distance and journey time to school.
- Geo-fenced candidate check-in to update when on school premises.
- Live GPS candidate location tracking via Google map integration.
- A two-channel chat window to facilitate direct client-candidate comms with a toggle for Opogo team assistance if required.
Being used to the likes of Uber & Deliveroo, existing users and prospective Opogo customers were excited by the new features and displayed no issues in completing tasks during testing. Concerns around privacy and device battery drain were managed by applying back-end logic that only on the first day of live bookings, before sufficient client / candidate trust is established, would GPS tracking be activated.
Sprint 3 - Timesheets & Reviews
Timesheets are traditionally viewed as a hassle.
“I’d want a review system to be 2-3 clicks, tops.”
- Client survey response
All research participants agreed that timesheet sign off at the end of each week was a far from enjoyable task. Also, whilst there was some hesitation around installing a standardised candidate rating system, it was largely considered to be a beneficial feature as long as it required minimal additional time or effort to complete.
Opogo’s timesheet process was popular with customers due to its minimal-step simplicity, and so retaining their existing mechanism, all recent and archive bookings were re-housed within one ‘Completed Bookings’ area.
The date-ordered dashboard clearly displayed required actions of completing timesheets & leaving a review in expanded and minimised views. Using consistent and familiar design patterns of checkbox followed by the confirmation overlay bar, a two-click approval for all candidates in a week was achieved.
To establish candidate feedback as an automatic client behaviour, I piggy-backed it on the existing weekly habit of signing timesheets every Tuesday. If the candidate was being used for the first time by the school, a 3-step feedback flow would launch upon signing their timesheet:
1. A binary ‘Would you hire them again?’ Yes or no.
2. A five star rating for the three most commonly described attributes of punctuality, professionalism & communication.
3. An optional free-text review.
- Tasking testers to sign off a timesheet and leave a review met no complications.
- From a visual perspective, the 'Completed Bookings' screen was tidied through removing iconography and excess copy in favour of a simple tick & cross.
- Some suggested concern during our Discovery around the rating parameters being too granular, or irrelevant, for certain schools was mitigated through using three attributes raised by all participants as important.
Outcomes & Learnings
This project was strengthened by functioning as an in-house consultant with constant client access however, lacking quantitive analytic data, assumptions were made during our discovery phase that needed validating in order to efficiently challenge some engrained client beliefs.
Ultimately, no project is perfect and a flexible mindset is needed when working on early stage platforms. For instance, gaining insight from robust testing rather than legacy user interaction data, and switching the final sprint focus mid-project from gamifying candidate availability setting to refining a notification matrix.
Following launching the new design & features, the Opogo team hit their biggest quarter of sales to date further supporting their initial delight with the project outcome. I’m set to continue working with them later this year to focus on the candidate app which we didn’t have time to look at.
View another?
Other projects
get in touch
Follow
