03
Lessonix Play
An interactive system for finding and playing educational games in the classroom.
Role
Sole product designer
Team
Product manager, development team
Platform
Projection system, operated by remote
Scope
Redesign and a new design system
Redesigned for this portfolio. The problems, decisions and flows are from the real product.
Context
Lessonix makes interactive projection systems for schools. An educational game is projected onto a floor, wall or table, and students play it by touch and by moving their bodies.
Lessonix Play is the interface that runs on the system itself. Teachers use it to browse the game library, gather chosen games into playlists, and set the system to turn on and run them on its own.
Play is one half of a connected system. Teachers create their own games in
Lessonix Studio and run them here. Studio has its own case study.
The product was already in schools, but it felt dated and many of its flows were long and unclear. I redesigned it from end to end and built a new design system for it. Along the way we simplified the initial setup, added onboarding for first-time tasks such as creating a playlist, and introduced new features. This case study follows one of those flows: building a playlist and putting it to work.
The challenge
No mouse, no touch. A remote, read from across the room.
Students play the games by touch and movement, but the teacher runs the system itself with a D-pad remote. Things a designer usually takes for granted work differently here. There is no cursor to point with and nothing to hover over. One element is in focus at a time, and the only way to reach another is to step there with the arrows. So the order of those steps becomes part of the design: every screen needs a focus state that is easy to spot, and a planned answer to where each arrow leads from each element.
All of this happens in front of a class. While the teacher is working the remote, the students are waiting, so every extra step costs lesson time. Playlists were where this mattered most. A playlist is a chosen list of games that play one after another, so a break or a lesson can run without anyone browsing in front of the class. But filling one with games, deciding how long each one runs and choosing when it plays had become a long, unclear chain of steps.
The approach
01
Fill a playlist without a press per game.
Adding games happens on one screen. The playlist sits at the top, the library below it is grouped by subject, and OK selects or deselects any game in place. Each subject row has Add all, and a running count shows how many games are selected before anything is confirmed.
Subject chips at the top jump straight to a row, so reaching a subject far down the list doesn't mean scrolling through every one above it.
02
Connect it to a schedule.
A schedule turns the system on and off at set hours. On its own it opens the system for free play, and a playlist can be connected to it at any point. When a teacher schedules a playlist from its own page, the playlist is connected automatically. During those hours its games run one after another, with no one at the remote.
The end time follows the start and keeps the duration, so moving a 30-minute break is one change, not two. Playlists that a schedule runs carry a Scheduled badge, so nobody deletes one by accident.
03
Set one time limit for every game.
Without a limit, one long game can hold up the whole break. The time limit lives in the playlist's toolbar, and since the toolbar is icon-only, each action names itself when it gets focus.
The dialog offers four choices and does the math for the teacher: 14 games at 10 minutes is about 2 hours 20 minutes for a full round. Once set, the limit shows under the playlist's name.
Product logic
When two schedules overlap.
Two schedules can cover the same hours with different playlists, so the system needs a rule. The later one takes over: a morning free-play window from 9:00 still gives way to an active break at 11:00.
The harder question was when to tell the teacher. The answer was before saving, not after. A yellow notice appears the moment an overlap actually exists and spells out what will happen in plain words. After saving, the same note stays on the schedule that gives way.
Looking back
Designing for a remote changed what I count as friction. A screen can look clean and still cost ten presses. The playlist flow got simpler by counting those presses, and by having the system explain what will happen before the teacher has to ask.