top of page

2018 - 2019

@ Preply

​

Preply is an online educational technology platform that pairs students with private tutors, either locally in-person or remotely online. It features a ranking algorithm that uses machine learning for the classification and recommendation of tutors. I joined the Retention Squad as a senior product designer for end-to-end design. We were focused on the customer experience after the "first payment".

preply25.png

TLDR 

​

During my 1 year of leading Retention Design at Preply, I contributed to the following 

 

  • Product Design: Designed 15+ features like tutor's cabinet and statistics, cancellation flow, lessons rescheduling, Preply calendar and integrations, report issues flow, student goals, etc;

  • Design System and UI Refactoring: Refactored old UI to new components and redesigned UI to be responsive. Improved UX specifically for mobile devices.

  • Customer Service: Decreased customer issues resolution time x2; Increased NPS by 18%.

  • A/B testing: Conducted various A/B tests and a few UI fake door tests.

  • User research: Facilitated dozens of user interviews.

Table of contents​​

​

  1. Design for Mobile

  2. Product Design Challenges

  3. Design Experimentation

  4. Design Case Studies

1. Design for Mobile

​

When I joined, one of our big design objectives was to make Preply UI responsive and convenient on mobile devices. While refactoring our front-end to React, we also refactored the older design to be responsive by using new UI components to improve overall platform usability and scalability.  

mobile.png

2. Product Design Challenges

​

Below, you can explore different design challenges I was engaged with, and see some examples of UI designed at that time. If you are interested in the design process and more context about user problem areas, you can find case studies at the bottom of this page.  

Booking UX

​

One KPI of our Retention Team KPI was to increase the number of hours a student spends on our platform. That is why we had many design projects related to the "scheduling" and "taking lessons" experience.  

 

For example, we used our UI to directly involve our users in shaping new feature proposition, and improve UX. 

2.3.1b LMS - GCalendar OFF Copy_2x.png

Or helping students don't forget about upcoming lessons, using whether push-notifications, email, UI, or Google Calendar.

2.6.5.2 Settings_ Calendar ON_2x.png

But "retention" starts from the first-time user experience. So we worked closely with the Conversion Team on many interrelated projects, such as Instant Booking. It allowed students to book a lesson with a tutor immediately and provided Preply Calendar for tutors.

3.4.1 Calendar - Week view_2x.png
01_1_Search Copy.png

Onboarding less digital users

​

Most of our tutors didn't use a digital calendar before, it was challenging to "onboard" them properly. We had to explain all the benefits and teach tutors how to use new digital features.

3.4.0.1 Calendar - Onboarding - Start_2x
3.4.0.3 Calendar - Onboarding - Step 2_2

Tutors Cabinet

​

The performance of tutors affected students' experience directly, and it was crucial for the business. We were doing our best to provide tutors all the relevant statistics and motivate them to conduct more and better lessons, as well as improve their profile attractiveness. 

3.6.1 Statisctics - Version B_2x.png

In addition to UI challenges, we had plenty UX issues like "Cancellation Policy", "Different Time Zones" or "Lesson Confirmation". This required much more time for a Product Designer to study the problem rather than create a new UI.

3. Design Experimentation

​

We used to release almost any new design solution as an A/B experiment. I was designing not only UI but creating many experiments myself. Meaning I often worked on defining metrics to measure, setting up Google Analytics, and creating dev specifications.

 

For example, below are 2 versions of the lessons package we offered to buy for a student. It appeared in UI after the first lesson was confirmed by a student. We wanted to increase conversion into 2d payment, as well as an average cheque. We hypothesized that we could do it by having a focus (reducing the number of options) and adding social proof.

mobile2.png

A vs B

mobile2.png

Sometimes, to validate new solutions, we conducted "fake door" tests and collected direct users' feedback about upcoming features. Below is an example of a "recurring lessons" feature.

2.7.4.2 Fake door - selected_2x.png

4. Design Case Studies

​

We used to release almost any new design solution as an A/B experiment. I was designing not only UI but creating many experiments myself. Meaning I often worked on defining metrics to measure, setting up Google Analytics, and creating dev specifications.

 

For example, below are 2 versions of the lessons package we offered to buy for a student. It appeared in UI after the first lesson was confirmed by a student. We wanted to increase conversion into 2d payment, as well as an average cheque. We hypothesized that we could do it by having a focus (reducing the number of options) and adding social proof.

Other Cases Overview

bottom of page