tutor orial

TYPE

UX Project

Individual Project

RESEARCH METHODS

Affinity Diagram 

User Interviews

4W frameworks

Frequency/urgency graph 

SUMMARY

I improved the user flow of helping users find a tutor on a website.

PROJECT BACKGROUND

Tutor Orial is an online tutoring website, where students of all ages can find a suitable tutor to schedule a class with. They had the quality tutors and resources for an amazing business, but the design says to potential customers otherwise.

 

My job was to discover the current issues of the main user flow (searching and booking a tutor) and re-design that flow. I was also allowed to redesign the UI.

Original Home Page

HEURISTIC EVALUATION

I first did some basic heuristic analysis to determine areas that do not adhere with pre-defined principles. 

STICKY NOTE COMMENTS

I went through the original flow to see what stuck out and felt like it was missing. I was able to get some other designers to help out for this portion of the project. More perspective the better! 

The main issues discovered in the current flow:

1. Lacking in tutor information 

2. Doesn't have reliability for users to want to pay.

3. Confusing final screen/next steps

ADJACENT INDUSTRY AUDIT

I also researched  what other websites do that I may want to look at as a reference to tutor orial. 

Takeaway 1: Websites with good processes always tell users why an information is needed and necessary to be filled out, so users understand why certain information is being asked. 

Takeaway 2: Good forms are concise and EASY to fill out. A lot of times they have options to “sign up with google,” to make signing up even faster.

I put all my research into a Figma file. This way I can easily look back on it when needed:

USER FLOW RECREATION

I changed the user flow of the current main task to align with my research findings and the company's goals - I had to ensure that Tutor Orial provided information and transparency to increase customers. Therefore, rather than having users sign up and take questionnaires right from the beginning, these tasks can be secondary while completing the users' original goal (to find a tutor). 

SKETCHING

Finding A tutor

  • Filters to make it easier to find tutors (including currency preference)

  • Sketch 4 is a portrayal of after users click on the tutor’s name for more information. You can message the tutor first or read reviews, etc

  • Teacher bio and different specific courses they can teach e.g. AP Biology, or just “conversational Spanish”

Showcasing tutors

  • Original screen with many tutors

  • Clicking into the name will go to either a pop up of the tutor’s bio, or…

  • A separate page. This might take longer loading issues because it’s a completely new page. 

Book & pay

  • Book before paying. Show transparency of the amount users are going to pay

  • An informative header that shows what happens during this whole process: you schedule/pay here, then receive confirmation of meeting location or meeting link, then potential refund option.

success confirmation

  • Tells users what has happened and what will/can happen next

  • Transaction summary and tutor information show

  • Information regarding rescheduling/cancelling, or to go back and search for more tutors. 

USER INTERVIEWS

I created a low-fi design for my flow and conducted userbility testings with 3-4 people (participants were chosen at random via screening and surveying)

Research Questions

  • Was the flow to schedule a tutor easy and self explainable for users?

  • What was missing that users noticed?

  • What did users fail to understand the most (what part were users confused at)?

I created a general script to follow with questions to ask for certain screens, and recorded the session in case I missed out on useful information while I moderated and took my notes. Below are some screen shots of the recorded tests.

RESEARCH QUESTIONS

  • Was the flow to schedule a tutor easy and self explainable for users?

  • What was missing that users noticed?

  • Reoccurring sessions, one time lessons, free trials - more information about what users are scheduling for.

  • What did users fail to understand the most (what part were users confused at)?

 

  • How to work with messaging as you schedule for a session. Adding a message during payment page also seems ambiguous.

SYNTHESIS PROCESS

With my notes from testing my low fidelity prototype, I used affinity mapping, 4 W's framework and urgency/frequency graphs to come up with results. 

TAKEAWAYS

  • ​Clear up misunderstandings for scheduling: reoccurring, one time, free trial, etc. Make sure users know before they pay if they can schedule recurring classes later, what to expect AFTER a tutoring session. 

  • Include more transparency with the tutor’s teaching style. Users want to know if tutors can be trusted from this website, and if the tutor is real.

 

  • Include functions to message the tutor during payment/scheduling stage more obviously. This is so that students can have a more transparent communication with the tutor, see if their personalities match before committing, and ask specific questions about lessons/studies that may not be in the tutor’s bio. 

  • Display materials required by the tutor on the tutor bio and confirmation screen. Will textbook be required? Or will the tutor prepare PDF’s? 

  • Create chat box in the flow for final version to show how the flow is if users wanted to message before scheduling.

FINAL UI VIDEO GUIDE

YOU ARE ON ROSEANNE CHAO'S PORTFOLIO!

Master's in Digital Product Design

Bachelor's in Visual Design

Proud user of Figma, Adobe Creative Suites, and Procreate.

CONTACT ME