AoPS Browser-Based Whiteboard Classroom
Closing the gap between students and AoPS's world-class curriculum
THE GAP
Traditional meeting and annotation tools severely limit student interactivity and their active learning
ROLE
0-to-1 Product Design Lead
TEAM
PM, Senior Eng Lead, 3 Engineers, 5 cross-functional stakeholders
GOAL
End-to-End Product Design, Design Systems, AI-Prototyping, UX Strategy & Research
CONTEXT
AoPS has built some of the best math and science curriculum in the US over 20+ years. Their classroom software didn't come close to matching it. Teachers were stitching together Drawboard for PDF annotation, Zoom for virtual delivery, and a series of workarounds just to run a lesson.
I led design on Torchboard — AoPS's own interactive, multiplayer classroom whiteboard — from 0 to 1 over a 1.5-year roadmap.
CHALLENGE
It's not just that the tools were bad - every band-aid fix teachers made during class, was attention stolen from being a great facilitator. Students weren't engaging with the material the way it deserved.
Big picture: Classroom software was the only missing piece in AoPS's end-to-end content delivery system.
DIGGING INTO THE PROBLEM
Early on, I sat in on classes and interviewed teachers across campuses. Three questions became the design north star:
How do we reduce cognitive load so teachers can focus on facilitation?
How do we increase student engagement without adding tech-induced distractions?
How does AoPS's product quality match its curriculum?
WHY
Every teacher has their own way of teaching. The best indicator of what they do in a class and how they do it is to sit and observe classes.
SOLUTIONING
I made an early call to build our own design system on top of shadcn/ui and Tailwind CSS rather than wait for a company-wide system that had no clear owner or timeline.
WHY
To directly accelerate our front-end process and make LLM-assisted prototyping practical for our team.
Additionally, to ship code and AI-based prototyping for designing features quickly.
SETTING SCRAPPY BUT SOLID FOUNDATIONS
My shipping philosophy was deliberate: broad strokes first. Get things into classrooms fast — even rough — to observe how they behave live. Polish in slower sprints after real-world signal.
WHY
To keep us from over-engineering features, scaling our efforts well, and making sure I continuously shipped without blocking engineering on nitpicks.
BUILD, DOGFOODING, OBSERVE, REPEAT
The best way to look for feedback was to put our product in teachers' hands and let them play with it. Here's a quick video of co-creating success metrics with them using the product itself.
Visited several campuses, like Redmond, WA, and Frisco, TX - implemented features based on requests within days to show how much we care.
WHY
To increase nationwide adoption without a giant rollout, we needed successful product evangelists to work out the initial kinks and show senior leadership that we're customer-obsessed.
KEY IMPACT
$500k+
saved in classroom hardware costs every year
20k
students learning daily, across 150+ classes
4.3/5
average lesson rating, as reported by teachers
LEARNING
Shipping rough on purpose is the right call for a product with no long flows — only papercuts you can't anticipate in a design file. See them live first.
