Tutor Auto-Swap
Helping tutors and pupils match-up automatically online
In this case study, I'll go over the business context and problem and describe the initial solution spec the Ops team created. I'll then explain how I divided the project into 3 mini-sprints: Research (discovery), Design (discovery + validations) and Delivery (speccing and testing)
MyTutor
Product Designer
January 3, 2019
MyTutor's School-focused business suffered due to poor tutor attendance on their Schools programmes. As a Product Designer, I led a cross-functional design project that solved that problem with an automatic matchup feature.
MyTutor is an EdTech company offering 1:1 tuition to students via an online Lesson Space (think Skype with an interactive whiteboard). Students are typically between the ages of 12-16. The tutors are students themselves, studying at UK's most prestigious universities.
As a business, MyTutor offers its services in two distinct markets: Private and Schools. Private revolves around an online marketplace where parents find a tutor for their child. Student and tutor meet after schools hours in MyTutor's Lesson Space.
As a business, MyTutor offers its services in two distinct markets: Private and Schools. Private revolves around an online marketplace where parents find a tutor for their child. Student and tutor meet after schools hours in MyTutor's Lesson Space.
Schools, on the other hand, works a bit differently. Instead of relying on paying parents, Schools secures its revenue from signing contracts with UK-based schools for tailored tuition programmes. Funded by government schemes aimed at improving the attainment of disadvantaged children, these schools buy a set amount of tutorials typically spanning 10 weeks to a select group of their students. MyTutor and the school agree on a weekly tuition slot for each student and MyTutor then assigns a tutor to meet the student every week throughout the programme.
The Schools programme has a track record of delivering outstanding results to the disadvantaged students. That result, however, hinges on both the student and the tutor log in to the lesson space.
Every weekday, hundreds upon hundreds of Schools sessions occur on MyTutor's platform - pupils and tutors sign-in to meet each other. The system relies on both parties to meet up on time. Things start to go bad when a tutor doesn't show up: The pupil will feel abandoned, the School is understandably angry and more likely to churn. The ops team will have to deal with angry teachers on the phone and will scramble through low-performing databases to find a suitable replacement for the pupil.
"A key contributor to churn is the effort and stressfulness, for the teachers, of managing a MyTutor programme. In particular, problems during a session are difficult to manage. Tutors failing to attend tutorials is perhaps the biggest headache. Aside from this, because we have a forecast to deliver a very large number of schools lessons, we are concerned that our support team will be unable to effectively handle every inbound call from our schools. This would probably have a severe effect on our client reputation"
In a nutshell, the business problem can be boiled down to the following equation: Tutor no show > Angry calls from frustrated schools > Schools cancel or don't renew their contracts
When I got involved with the project, my job was to execute on a specific solution spec created by the Ops team. Reading through the spec, I was impressed by the level of detail and consideration the team had put into the process.
In a nutshell, the Ops team wanted a more efficient backend system with some additional columns and features to help them keep on top faulty lessons.
However, given my years of design experience, I was wary of accepting a solution at face value. More often than not, I've found that we have to do a bit of digging to get the deeper problem underneath before we can conjure up the right solution.
As the project revolved around business processes and involved stakeholders I didn't have any familiarity with, I took out some time to go over the existing business documentation and did stakeholder interviews to learn people perspectives and thoughts on the problem.
Each stakeholder held interesting and unique perspectives on what the problem was and how we might solve it.
Journey mapping allowed us to get a visual overview of each users journey through the problem space. Based on our map, we were able to identify crucial pain points in each user's journey.
The journey map also helped us articulate hypotheses around how we might solve the issues we identified. Based on the identified pain points, we brainstormed formulated solution ideas into a hypothesis.
Since we had a tight deadline, we needed to single out a few we wanted to validate. So together with the team, we plotted out our hypotheses on an impact/effort matrix.
After much consideration about the perceived viability and effectiveness of our hypotheses, we chose the following one to validate:
"We believe that by matching lone pupils with lone tutors, we'll ensure the lesson goes through, thus lowering angry calls and churn"
Since we were dealing with a complex system involving multiple stakeholders, I ran a session with our product manager, defining an updated journey map based on the established workflows. This was a great way for us to explore different scenarios will ensure that we kept a birds-eye-view on how our changes would affect the entire system.
After drafting a couple of different flows, we landed on a solution where the pupil would see a modal popping up in the lesson space if their designated tutor was more than 5 min late. The pupil could then click through, activating a re-routing to another session where a tutor sat waiting for their designated pupil that hadn't shown up.
I drafted a quick prototype and ran it by the management to gauge their feedback. They liked the idea but wanted the re-routing of the pupil to happen automatically. In other words, if the tutor didn't show up, the pupil didn't have to do anything but wait until they met their cover tutor.
I went back to the drawing board.
To find out of the if our idea would be doable, we needed to consider several factors:
Firstly, we wanted to learn if pupils would interact with the widget. However, approaching pupils directly is a risky business so we opted for the next best thing: Their teachers.
We ran a couple of prototype sessions with teachers. Primarily, we wanted to gauge if they were turned off by the prospect of letting other tutors meet their pupils online.
The second part of the equation was the tutors, the ones covering the lessons. Again, we sat up prototype testing sessions spread over 2 days. We learned something new at each session and iterated on the design and copy til we until we felt a good conviction about the concept.
Good copywriting is extremely important to me. Through experience, I know that how you communicate in the product, massively affects user perception and behaviour.
Since this project is all about automation and dealing with pupils (a potentially vulnerable user group), I wanted to nail the copy down. Therefore, I set up a copywriting workshop with our Product Manager and our in-house copywriter. I was pleased with the outcome.
I have a keen interest and good understanding of how micro-interaction can be leveraged to enhance the usability of a product. Specifically for this project, we were dealing with an automated system dialogue. I knew I needed to consider a proper build-in sequence as well as consider how much time we gave the users to actually read a message before the next message built-in.
Testing the feature turned out to be the most difficult aspect of releasing the feature. Due to the complicated intricacies of MyTutor's test environment and working with off-shore developers, we ended up spending a bit longer in this phase then initially estimated.
Ultimately, we achieved what we set out to do: Bring down the number of angry calls due to tutor no-shows to virtually zero.
The release of the feature immediately freed up the Ops-team time so they could on being proactive about keeping the system running smoothly rather than reactively putting out fires.
The overall churn rate amongst Schools decreased but it is difficult to tell whether the feature had a direct impact on this positive development or not.
