End-to-end design

Designing a classroom monitoring tool for teachers at an online school.

This is 1 of 2 projects I led during my internship at is a non-profit learning platform founded by Sal Khan that provides free, quality online education to anyone who wants to learn.


Product Design Lead


4 weeks


Product manager, engineer (x2), design manager




Online education on is self-paced, so each student enrolled in an online classroom will progress through the course independently. To ensure students are on track, teachers must monitor the learning progress of their students.

How might we help teachers at monitor the learning progress of students in their online classes?


This solution was shipped in August 2022. It is being piloted with a full-time online school of 200 students from around the world.

Group students by class

Most teachers teach more than one class or subject. To manage students between multiple classes, teachers can create classrooms for their respective students to join.

Monitor student progress

Teachers would like a high-level understanding of overall class progress. The table displays certification progress for every student in the class.

Zero-in on individual students

Sometimes, there are students that struggle more than others. To obtain more insight into the individual needs of their students, teachers can view individual details for each student.


The project team talked to teachers using about their current experience, and I defined the key insights.

The current experience

Turns out, the current experience was unsatisfactory – Why?

Information overload

Most of the time, teachers only required a high-level understanding of overall class progress. Currently, teachers received individual progress reports from every student they taught, which meant the information they reviewed contained too much detail.

No visibility

Self-paced learning meant students must be continuously monitored. With the current experience, teachers had to request updated progress reports from every student every time they wanted an update.

Introducing: Classrooms

Why design "classrooms"?

Because most teachers taught more than one class, they currently monitored a mixed pool of individual progress reports from students in different classes. Classrooms would group students by class. We knew teachers typically relied on class rosters (lists of students in each of their classes) to keep track of their students and there was no need to change existing systems.

Designing classrooms

In designing Classrooms, we encountered a problem – Our user database didn’t keep track of whether a user identified as a student or as a teacher.

Classrooms had to be designed for both roles with the goal of a teacher to create classrooms and the goal of a student to join classrooms – How?

Option 1
  • Visually, a hierarchy is created between the two roles

  • Teacher-based actions appear to be the primary role

  • It is unlikely for teachers to join classrooms and students to create classrooms, resulting in an indefinite empty state

Option 2

In this option, the hierarchy between the two actions is less obvious. There was no reason to prioritize one action over the other. A teacher's primary action is creating a classroom but a student's primary action is joining a classroom.

  • Actions are more equally prioritized

  • Students who need to join a class must first navigate themselves to the correct tab

What did we decide?

Option 2 was shipped. Eventually, we would want to scale this feature so it can be used by peer tutors and their students, not only professional teachers. Peer tutors are teachers, but are also students of other peer tutors. The tabs help these users keep their two roles distinct.

Before shipping, the tabs were redesigned into a toggle control and relabelled. The toggle helps define two distinct, binary states and the labels are now more action-oriented.



The tradeoff of option 2 was that students needed to first navigate themselves to the correct tab. To mitigate this tradeoff, I proposed an onboarding page for first-time users of classrooms. The user selects if they are a student or teacher and they will be automatically directed to the appropriate tab. Because the onboarding page required more of a technical effort (it required a database), this was first tested with users to determine if it helped direct users to their desired actions.

Would an onboarding page help direct users towards their desired roles?


Turns out, it wouldn't be that helpful. But at least we knew our worries weren't that big of a deal.

Designing progress monitoring

Teachers needed to know at any point, and for any student, which unit tests were not attempted, in review, completed, or rejected.

This was a lot of information. A classroom could have up to 30 students and a course could have up to 20 units, resulting in some form of a 30x20 matrix. Regardless, teachers required high-level understanding, so all this information needed to be scannable – How?

Option 1
  • Familiar with our users because many also used Khan Academy

  • For each unit in the course, it is easy to see the proportion of students that have completed it

  • Per unit progress is easy to scan

  • Accordions make accessibility to individual students difficult

  • Per student progress was not easy to scan

Option 2
  • For each unit in the course, teachers see the proportion of students that have completed it

  • Similarly, for each student in the course, teachers see the proportion of units they have completed

  • Per unit AND per student progress is easy to scan

  • Although per unit AND per student progress is easy to scan, content was sure to overflow

  • Teachers have to scroll horizontally, which reduces scannability

What did we decide?

Option 3 was shipped. It was important for teachers to see per student progress so they can focus on individual students who are struggling.

Before shipping, we made sure the first column of student names in our table component could remain sticky upon horizontal scroll to help with scannability.

Iconography Considerations

Each unit could have a status of not started, complete, in review, or rejected – How can we represent each status?

The Schoolhouse design system used font-awesome icons, but several options were curated for consideration.

Option 5 was chosen because it was the most visually balanced. The other options contained filled icons with varied stroke width. These options were visually unbalanced because filled icons have higher visual salience.

How can we display icons in the status table?

Option 3 was chosen because it provided the most visual contrast. User research insights revealed teachers prioritized high-level understanding of general class progress. They would like to know, at-a-glance, approximately what percentage of their class has progressed. Therefore, visual contrast and colouring the cell background between statuses was important because it would increase scan-ability within the table.



Share work early, even if it’s sketchy

At one point in this project, I didn’t feel comfortable sharing my work with team members because I felt like I hadn’t made any decisions and was still exploring options. Upon sharing however, I received very valuable and directional feedback.

Collaborating in parallel with engineers

Development work for this project began before designs were finalized, which was overwhelming to begin. I learned to give engineers a heads up if I uncovered a potential design problem that would require additional time. Constant design updates in Slack and the project tracker were also important so there was visibility into my progress and updates.

thank you