June Hong

Chat Tutoring


Chat Tutoring

JUN 2018 - Oct 2018



Project Overview

Chat tutoring is a new product initiative driven by the Chegg Tutors business group. After six years of running online desktop only tutoring service, the team decided to provide simple, mobile-focused tutoring service to meet the changing users’ needs. 

As a lead designer, I had an opportunity for leading the tutor’s dashboard as well as envisioning the mobile experience for student’s side.

I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of Chegg.


Understanding what users want

Chegg tutors is a market place where students can access to the full-fledged lesson space to maximize their learning experiences. We offer audio, video and chat tools alongside whiteboard and other collaborative tools on the desktop. 

However, the metrics showed the low usage rate of audio and video. After the team redesigned its interfaces to improve the discoverability and usability, the numbers went down further. 


Deeper insights

The team decided to get deeper into users’ minds. We knew “what” but we needed to understand “why.” We recruited 16 college students who have used Chegg Tutors at least once. We implemented two research types: online one-on-one interviews and ethnographic study visiting their schools where most of them spend their time to get their homework and study done. 

There are three insights we discovered through the research: 

  1. Students don't want to use audio and video because they think it's too intimidating showing themselves to strangers.

  2. Students usually study in quiet environments or public places such as libraries or cafes. 

  3. Students want to get answers as quickly as possible, and they are concerned about the cost/time to be wasted for communication. 


These findings help the team understand deeply what our users want and how their tastes have transformed. We took a step further to understand how we can address users' needs and what product we are going to build. 

New kids on the block

The team started studying around the new products in the market. The traditional tutoring platforms address two types of users - online and offline tutors. Students who want to have online sessions using AV supporting lesson space on their desktop. The other service focusing on offline tutors is a simple coordinator that connects students to tutors for offline sessions.

However, our study found that there is a third type, more specifically derived from the online model. It's a quick human help when they need only focusing on very specific, narrow areas, which is chat-based, mobile tutoring services.

They have different pricing model and capacity in tutoring subjects and level of expertise, but the steps users take look very similar: take a snapshot of the problem and submit, match with an expert, and get tutored with text, hand-drawing, and solution bot on mobile.

The product/market fit was found and on-demand online tutoring got into more granular level. Users expect short and quick answers for their small questions which usually takes less than 10 mins per session.


Strategy in current ecosystem

To find out the strategy to embrace this new product idea our business leaders and product team s

User survey has been implemented to check out users’ sentiment how we can continue

What Chegg can and should do differently is how to create the synergy in Chegg ecosystem and not cannibalizing Chegg Tutors but reinforcing our business by providing clear use cases. The framework below shows our product strategy. 


Chat tutoring as an embedded model

The most successful product for Chegg is Chegg Study, a database product to help students find solutions in a sec. There are users' needs for a step-by-step human explanation when they get lost in the written answers. The chat-based, quick tutoring is a perfect fit, and it will be a new user acquisition channel and also help enhance current Study user retention.


Chat tutoring as standalone model

The most successful product for Chegg is Chegg Study, a database product to help students find solutions in a sec. There are users' needs for a step-by-step human explanation when they get lost in the written answers. The chat-based, quick tutoring is a perfect fit, and it will be a new user acquisition channel and also help enhance current Study user retention.


Tutor side experience

After exploratory design for student-side, our focus shifted to the tutor’s experience. To find the viability of the product we need to have a very good answer to the key question, how many lessons can tutors handle at once?

More accurately, how many lessons can tutors manage not compromising their lesson qualities?

The first two steps here are all about experiments and learnings. The design is the tool to validate the viability of our product concept as well as to identify the new income source for the business.

Design-research plan

  1. Closed Alpha

    • Scope: simplest lesson space with lesson queue, chat, and workspace

    • One algebra tutor + emulated requests using past lesson requests

    • To learn # of lessons a tutor can handle at once

    • Design challenges:

      • How to create the smooth workflow: requests to multi-lessons

      • What type of tools to provide to help tutors improve efficiency

  2. Controlled Beta

    • Scope: lesson request flow for controlled test + student lesson space interface on desktop + iteration on lesson space

    • 10 math tutors + 1,000 student requests offered as a free trial

    • To learn how students satisfied with the lesson quality

    • Design challenges:

      • How to create simple and credible workflow for students

      • How to create a good feedback system, metrics, and survey

  3. Open Beta

    • Scope: public facing marketing page (mkt) + payment component + tutor’s dashboard + iteration on tutors/students lesson space

MTP: Minimum Testable Product

Chegg is not a startup where we have a great idea, and we design and build the next day. We don’t work this way, but the team usually takes very careful step by step approach implementing all types of researches along the way.

As for the first version, our goal is building the minimum testable product. Yes, it’s not going to be viable, it’s going to be incomplete experience, but it’s good enough to give us answers we need.

User goal is clear here. Tutors will be hired as a full-time, but they will be paid and evaluated by the quality and quantity of their lessons. In this case, their biggest challenge is how many lessons they can handle while not compromising their lesson quality. What’s the optimal process from request to lesson, how they can easily decide what lessons they would take or not, and what tools or features they need to meet their goal.

Group 10@2x.png

Some of the early explorations as below focused on problems: 1) how to transition from request to lesson easy, 2) how to make quick to understand what lesson needs more attention, and 3) more importantly how to outline the workspace to optimize the tutor’s teaching experience.

First, we thought maximizing spaces for chat and whiteboard is always better like Type B or C, but having the lesson lists on the left side makes users feel more comfortable as it looks very familiar, too wide chat space deteriorate readability, and as far as the whiteboard has unlimited length the width is not very critical.

Multi requests feels more overwhelming compare to one request. We put 30 secs timeline to the


The revised version has shown much more improvement on easy management of multi-lessons as well as workspace layout:

  1. Spacing: maximized the whiteboard space while keeping the left bar for lesson list.

  2. One request at a time: the rule was set to make it simple for tutors to handle better. A request will be sent to a tutor based on our magic formula and 30 secs time will be given to accept or reject. Rejected requests comes to the second tier tutors but only 10 secs time (# of tutors and exact time limit pending)

  3. Lesson priority: for the starter, we will show # of unread messages and the time when the first unread message was sent in mins, so that tutors can see which lesson need more attentions.


Final Design

The final design has a lot more areas and details to be designed. Some of the main areas are as below:

  1. Chat UI

    • Chat layout & format

    • Input components (pre-saved sentences)

  2. Whiteboard

    • Type of tools and placement

    • Share images on chat UI

  3. MathSolver integration (TBD)

  4. Tutor’s inventory (TBD)

The amount of details seemed a lot to do but if you have a clear understanding on what’s the most critical area for users. And there are lots of good design we can leverage - as a product designer I don’t think we have to create all ideas an interactions, so that we can get the best outcome within limited timeline. In this case, our design focus was on not creating new type of whiteboard but how to make it easy for tutors to share the images on the whiteboard to the students as well as input components we need to dramatically improve tutors’ speed. The question is how we do what to prioritize, or how to decide. The answer is simple. You use your common sense, ask users, look at the metrics if available, and discuss with all smart people in your team. What if we don’t agree? We don’t need to .. we learn along the process.



The project has gone live for the closed alpha testing. The final version for the testing looks a little bit primitive than the visuals I posted. After all, the goal is getting a quick and dirty user feedback on our most burning questions.

And I moved on…

Working on a new product concept has been my specialties for 4 years time with the company. Good news is at least this product will open to the public sometime. Being comfortable with ambiguity and learning how to find clarity is the most important asset for designers to succeed, and the project helped me one step move forward. Still long way to go!