A customer-facing application that allows Cluey Learning customers to reschedule upcoming learning sessions.
Cluey Learning delivers a personalised tutoring experience for students in Years 2-12, across Maths, English and Chemistry.
Our main product is our Learning Platform, which is used by individuals and groups of students in tandem with a tutor to have learning sessions. We have an in-house Customer Care team that handles customer inquiries and any scheduling requests the customer might have.
To take the load off of the Customer Care team and give more control to the customer this year, we designed and launched a rescheduling platform for customers. Rescheduling is the first feature that will be part of a larger Session Management platform.
✓ Designing a concept based on early requirements
✓ High-fidelity design & user testing
✓ Designing for mobile
✓ Designing for the exception cases
✓ Implementation & metrics
Designing a concept based on early requirements
We had an understanding of the necessities that our initial product needed to have so that customers could quickly reschedule an individual learning session.
Families and households have complex schedules that, to a large extent, cannot be predicted. Homes may include one or many children that have learning sessions. The children may take part in extracurricular activities or have other unknown constraints that impact their schedule and when they can participate in learning sessions.
For this reason, one of my main goals was to show customers all the time options available. It should go without saying, but we needed to make navigating and pinpointing a time in a sea of options, very easy.
At this stage, we were not doing anything too dynamic such as suggesting times based on previous time bookings because, as previously mentioned, it’s difficult to make reliable and meaningful suggestions based on household schedules.
I designed a concept around the basic features and initial requirements, which acted as a realistic working model of the rescheduling platform.
↓ Below: a design concept illustrating basic features and interactions
The design concept allowed us to have a realistic illustration of the basic features and interactions, which in turn allowed us to have meaningful product discussions as well as to assess the scope of work more accurately. The design concept was primarily accepted, and from here, I moved into high-fidelity design.
High-fidelity design & user testing
Taking some pre-existing brand guidelines and components, I started to design the rescheduling platform visually. Over the next three weeks, I presented and iterated on high-fidelity designs with the team, which included executives and software development. We performed user testing to the best of our ability but were unable to secure a high number of participants, given that it was around the holidays.
↓ Below: A high-fidelity visual design of the primary screen plus secondary screens
Designing for mobile
Around the time I started designing the visual design for desktop, I began the mobile design as well. In addition to taking a mobile-first approach, we had statistics that told us that something like 30% of users would likely reschedule on mobile. While I did want to remain as consistent as possible and reuse design patterns as not to have two code sources for one design component across desktop and mobile, I did make some minor customizations for navigating on mobile.
↓ Below: two screens from a larger deck highlighting design solutions based on the specific problem to be solved.
Designing for the exception cases
The last part of the design process was dedicated to designing for all the exception cases (or “use cases”) that a customer might encounter. This process helped development visualize all the different things that might happen as a user interacts with the platform and to cover it in the front and backend code.
↓ Below: Examples of exception cases screens
Implementation & metrics
I worked with our small development team to implement the user interface and build the platform. We had regular check-ins and frequently paired together to work on the designed screens in code. I suggested that we implement tracking to see and understand how customers were using the platform and a poll to capture any real feedback from users. In addition to Google Analytics, we used Hotjar.
Outcomes included an increase in the number of customers that rescheduled online versus calling Customer Care, as well as rescheduled a session, instead of canceling. Both of these business goals were part of the project from the beginning, and the metrics we setup helped us to have a better idea of the challenges that customers encountered.