Designing a classroom, not another video meeting
Designing the instructor and learner experience for an in-house live-learning platform where participation, moderation, device readiness, permissions and recovery all have to work in real time.
Eight learners are in the room. Priya holds the floor; nobody else has a microphone.
Some product visuals have been simplified or reconstructed to protect confidential platform and customer information. Learner names and session data are synthetic.
A live class has different rules from a meeting.
Conferencing tools optimize for meetings, where everyone is fundamentally a participant. Teaching needs asymmetry: one instructor holding attention, structured participation, moderated questions, recording, and a way back in when something breaks.
Everyone is fundamentally a participant.
Roles are asymmetric by design.
More control can make teaching harder.
Every extra control offered to the instructor competes with the attention they need to teach. That is the tension the whole product had to resolve.
Needs control without leaving the teaching context.
Needs clear, low-friction participation.
Needs to coordinate real-time permissions, state and recovery.
The question was never “what controls does Zoom have?” It was “what interrupts teaching?”
Participation is not one thing.
Participation is not one thing.
Chat, Q&A, Raise Hand and Polls all look like “engagement,” but they solve different social behaviours. Different intentions needed different interaction models.
“Say something.”
Low-friction conversation. Ephemeral by nature.
“Ask something that deserves an answer.”
Structured questions that persist until resolved.
“I want to speak.”
A request for permission, not a message.
“Respond to what the instructor asks.”
Instructor-led structured response with a result.
If all four collapse into one chat stream
Chat is conversation. Q&A is a queue with an answer. A raised hand is a request for permission.
The classroom experience starts before Join.
A device problem discovered inside a live class is already an interruption. Permission errors are cheaper before the class starts.
Eight learners are in the room. Priya holds the floor; nobody else has a microphone.
Every device state has an answer before the room opens.
The interface had to stay predictable while the class kept changing.
One lifecycle, two roles, and a set of states that move underneath the same layout.
The same room, read as state.
Twenty-eight learners, one instructor, and the signal doing the work at each beat — the abstract read of the classroom above.
Twenty-eight learners arrive over a minute. The instructor holds the stage throughout.
Speaking needed to be a controlled state transition.
A raised hand is a request. What follows is a permission the instructor grants, a capability the learner holds temporarily, and a return to the default state — not a toggle.
A raised hand is not a toggle. It is a temporary permission state.
Default learner state. Mic and camera unavailable, screen share restricted.
Learner permissions are temporary, not permanent.
A meeting can start with everyone as a peer. A classroom cannot: the hierarchy has to survive participation.
Teaching material stayed inside the classroom.
Leaving the room to fetch content costs instructor attention.
Responsive meant changing priority — not shrinking the room.
Teaching content first, then the critical audio and video actions, then participation state, then secondary tools. What changes across platforms is how much can be true at once.
The build had to cover web, mobile browser and mobile WebView integration.
Real-time products fail in public.
A learner cannot wait for a hidden retry job. Some failures belong to the person in the room, and some should be absorbed before they ever see them.
The classroom had to survive the server disappearing.
A class can run on a self-hosted session or on cloud. If the self-hosted server dies, participants reconnect and land on cloud. Recovery should feel like an interruption, not a new class.
- 01Self-hosted session
- 02Server fails
- 03Participants reconnect
- 04Cloud session
Reconnect shouldn’t reset who you are in the room.
Participant and host state persists across a rejoin, so a dropped learner returns as themselves rather than as a new arrival.
Kabir dropped out. His seat is held and the class keeps running.
Kabir drops out. The class continues and his seat is held.
The new classroom still had to fit the existing learning product.
A real-time experience could not behave like a standalone app: it enters from a lesson and returns to one.
A live class becomes learning material after it ends.
The live experience is temporary. The learning asset is persistent — and so is the behavioural signal the instructor can review.
- 01Session
- 02Recording
- 03Processing
- 04Uploaded recording
- 05Learner playback
- 06Admin download
What the instructor can review afterwards
A live-learning system built around classroom behaviour.
The platform now supports an in-house live classroom across joining, participation, moderation, engagement, recording and recovery, rather than relying on a generic meeting interaction model.
What this changed in how I design real-time products.
The instructor’s attention is part of the interface budget.
Participation needs explicit states and permissions.
Failure recovery is part of the main experience, not an edge case.
And responsive real-time design preserves priority, not layout.
What I’d measure and improve next
- A deeper accessibility audit for live-state announcements and keyboard control
- Measure join and device-readiness failure rates
- Study engagement-feature usage without overloading instructor attention
- Post-session learning continuity and recap
This project taught me that in a real-time product the instructor’s attention is part of the interface budget.