Loading

Robin
ProductReflection

Project Summary

1/13/2017 · 5 min read

「Course Design」 is the core of an education project and matters greatly for the experience;

Below is my summary from this design phase:

Problems in course design:

Briefly: teachers and students book online, then meet offline to choose in-person or remote learning.

So we face these questions:

  1. How do we get both parties to trust each other enough to show up for class?

  2. How do we ensure the lesson completes successfully?

  3. What factors do students and teachers care about most?

  4. If protection is needed, how do we set reasonable rules to protect teachers?

Finding answers:

I. Look to competitors

Turns out their product is quite different from ours:

  1. On 在行, most teachers are big names (KOLs) with relatively high credibility;

    On our platform, most teachers are long-tail, grassroots—relatively needing reasonable rules to manage them.

  2. 在行's courses are standalone—you only learn introductory knowledge;

    Our platform wants students to systematically learn professional knowledge—courses must be continuous.

  3. 在行 currently works like: student pays, teacher calls, then teaches. Clearly 在行 wants a social vibe, like meeting a friend, so they don't set strict rules—and don't guarantee lesson quality;

    Our platform is responsible for both student and teacher rights—we can't be that free.

The result: competitors didn't give us answers, but made me more confident in our product direction.

Our courses need continuity and reasonable rules.

II. Think about what users want and worry about

Since participants are teachers and students, let's analyze them first

  1. Teachers first—most are internet industry workers. Besides salary, they may take side gigs. So for them,

    what needs do they have on our education platform?

    Answer: "Make money—that's the core"

    They also have a problem: overtime can be irregular, so scheduling is hard to control.

  2. Then students. We divided student personas into two types:

    Type 1: soon-to-graduate or recent graduates hoping to enter the internet industry—they're eager to learn and have plenty of time.

    Type 2: relatively new industry workers who want to level up.

    Both have strong learning motivation and often hit bottlenecks in growth—they need someone to guide them through.

    But for a new education platform, they may hesitate to try. Fortunately, our platform lets teachers and students decide via chat whether to proceed with learning.

    They're also savvy—they want every yuan spent to yield equivalent knowledge.

Based on what both sides need on the platform, we knew what to prioritize in rule design.

Rules for teachers:

Considering teachers' unstable schedules and preserving pricing control, only teachers can publish courses;

Teachers can protect their interests by not teaching. Rules for students:

The lesson 「Start」 should be confirmed by the student, because students worry more about being scammed;

After the student confirms 「Start」, based on "lesson duration," the course auto-ends at the specified time—keeping it simple while protecting student interests.

Envision scenarios, analyze possible behaviors

With goals and user pain points set, let's walk through how users use our product

  1. After student and teacher agree, teacher publishes a course

  2. Student pays tuition

  3. Student and teacher meet at the specified time and place

  4. Student taps Start Lesson

  5. Lesson complete; after student confirms, tuition transfers to teacher's account

  6. Student can choose whether to continue learning

  7. Teacher publishes a course

  8. Student pays tuition

The above is the main flow—we need to confirm it's the simplest and correct, or we can't proceed.

Now for edge cases:

What if the course the teacher published is unreasonable—can the teacher edit it?

Add teacher course editing requirement

What if teacher or student doesn't show up on time and can't be reached—can the course be cancelled?

If either party doesn't arrive on time, the other can cancel. If it's the teacher, 5% of tuition goes to the teacher; cancellation requires location and photo proof for authenticity;

What if someone can't arrive on time for special reasons?

Free cancellation more than 2 hours before class; within 2 hours, if student cancels, 5% of tuition goes to teacher; if teacher cancels, credit score drops;

What if the student forgets to tap Start Lesson?

Push reminder 10 minutes before class; teacher's screen shows "Please start after student confirms";

If student doesn't tap within 1 day, auto-cancel with 5% refund to teacher.

What if the student accidentally taps Start Lesson?

Double confirmation if tapped more than 30 minutes before class; no prompt within 30 minutes

What if the lesson doesn't reach the agreed duration?

Student can request a refund with photos and time proof based on actual situation

What if the student doesn't confirm payment after class?

Auto-confirm after 3 days if no refund request.

If student chooses to continue learning, must the teacher accept?

If busy, they can decline

Can students cancel a course the teacher published?

If unsatisfied, they can cancel or ask the teacher to revise

Organize user needs into a feature list

With user flow and requirements set, it's time to organize what actions users take at each step in a table

Start designing pages

With actions and display info defined, now consider page design

  • For course continuity, use a timeline design

  • To quickly find courses in different states, use tabs to switch course status

  • For real-time teacher-student communication, highlight phone and chat at the top of the course page

  • To keep latest and important courses on top, display timeline in descending order

  • To guide students to keep learning, show a 「Continue Learning」 button after each lesson

Specific screens below:

Related posts