Outschool is an educational platform that offers a variety of engaging, small online instruction for K-12 learners. Their users include teachers, learners, parents, and organizations (schools, businesses).
In Marketplace team (Educator Pod), I was the sole product designer and working on this project with the product manager and engineer. In addition to design, I shared researcher responsibilities with the PM.
Timeline was approximately three weeks.
Like similar projects, I researched common design patterns and gathered research that we had for existing pain points.
Iteratively, I shared versions with our stakeholders, and tested it with users for feedback in order to understand the mental model parents have for scheduling.
For parents, choosing a class time from the card carousel can be difficult and discourage bookings if they do not find a class time that works for them. With auto-scheduling, this increased the pain point by causing the user to flip through endless cards.
How might we make it easier to book a time that works for a family?
In discovery research, we knew that there were two key pain points to address:
- On mobile, the carousel interaction is less discoverable to users on how to for more class times.
- For auto-availability, if there are numerous sections, this increases the pain point of viewing each card in order to book.
With the product manager, we focused on developing the key requirements:
- Support auto scheduling on/off
- Support the varied class types (+ section metadata)
- Support desktop and mobile
- Support rescheduling UI
Measure: Time to complete class choice; Purchase conversion in A/B testing on mobile first.
- Scheduling with lots of availability is often shown as a calendar where the user chooses a time slot.
- Most apps require their educators to have broad availability - Outschool does not, so we may have limited available time slots.
- Sometimes teachers will not use auto-availability because it will not show the time slots in an easy way to view and book.
- Teachers use a mix of manually made sections to increase visibility of their class sections.
I investigated the known research on our users and researched scheduling design patterns. I quickly saw two major patterns: calendar grid or two step (day, time) selection.
The Product Manager and I interviewed some teachers to better understand why they do not use auto-scheduling and we also interviewed parents to understand what they are looking for when searching for class time.
- Users prefer a calendar view when selecting a time slot
- Our current users often use filters to narrow their results
- Users were confused on the colors and that they needed to select a time in grid layout.
- It is difficult to translate the grid calendar for mobile.
I did some lo-fi brainstorming and solicited feedback from Product and Engineering. Based on their feedback, I created two higher fidelity mock ups to get feedback from our users. I was curious to validate the user's mental model.
I shared an interactive prototype in our discovery research calls with parents and asked for asynchronous feedback as well.
I couldn't reconcile the preferred design with the loss of metadata and class formats, so I pursued two routes depending on whether auto-scheduling is on or off. I applied it to desktop exploration and rescheduling UI.
While my PM was away, the lead engineer and I worked with the Marketplace Lead PM to deliver the project.
- Let's choose the design that works for all class types (List View)
- Let's do iterative rapid prototyping with engineering so that we can learn quickly about user behavior and interaction with real data.
- Let's narrow the scope and punt desktop until we have learnings from mobile.
- Users first filter in search to narrow their day and time choices. However, in mobile, it was not easy to come back to these filters. This validated the idea to add filters.
- Success! All users (20) completed the usability test successfully; all but 2 rated the interaction 10 ("very easy") to complete.
- Viewing the review app with real data allowed us to smooth some edge cases before implementation.
I worked with our engineer to create a rapid prototype to test the interaction of the design on mobile. While the engineer built the review app, I created an unmoderated usability test.
We then ran variants on keeping or removing the card carousel on mobile in order to see if there was value to maintaining the section.
While we rolled out a scaled down version of what we set out to accomplish in the PRD, this project reinforced the concept to solve for the 90% use case and deliver quick follow-up improvements to satisfy 100%. We rolled out the design for mobile and while there is a slight improvement for conversion, it was not statistically significant. Up next: to apply the design and lessons from mobile for desktop! See a video of the review app.
As a designer, I set out to solve for a specific use case: classes with auto-availability on. I learned that while a design may be preferred by users, it may not be the best solution at this time or if is applied broadly. Auto-availability was used by 10% of our teachers. In this case, Educator's Pod benefited from solving a broader issue, preserving class metadata, and enabling filtering for complex use cases.