03 · How I approached it
The interaction model
Four principles anchored every decision: modular, unite the living room, instinctive by design, inclusive for all. From those, three interaction calls shaped the whole dual-screen model. All three are mobile-first decisions: once the quiz starts, every player action happens on the phone, the TV stays as the host display.
TV as host, phone as controller
Once the host hits start, the TV runs the show. No remote fumbling, phones handle input.
Confirm before submit
A two-tap pattern (select, then confirm) prevents accidental answers when the countdown piles on pressure.
Attention ping-pong
Shared on TV, private on phone. Attention bounces between the two, with built-in pauses for reactions and banter. The TV anchors the room.
One frame, three zones
Three containers create the app experience, and the same structure carries across the whole app, so new quizzes and IPs plug into it without rebuilding the frame.
App structure
Top bar
Information about the game: timers, settings in the lobby, QR code, question number.
Bottom bar
Information about the players: number of players, names, and points.
Middle area
Where the action happens: quiz selection, the quiz itself (question and answers), and scores.
That same three-zone structure carries through lobby, gameplay, and final scores, so the frame never needs to be rebuilt as the screen changes.
Applied across the experience
One TV, one phone: the shared and private split
The TV guides the room through the experience. It never requires input from a phone to progress, keeping the pace for the group.
Key decisions and trade-offs
Confirm before submit, not auto-submit
Most mobile games auto-submit: tap and it locks in. After competitor research, we chose select-then-confirm. With a countdown running and people shouting across the room, misclicks are constant, so the extra tap protects the player from an irreversible mistake at second 3.
QR code, not a typed room code
The MVP shipped QR only: faster to build and no typing on a TV remote D-pad. A typed code sits in the roadmap as a v2 fallback for contexts where a scan isn't practical.
Persistent top and bottom bars
Following established TV UI patterns: orientation at the top, social presence at the bottom, a flexible main area between. Defined in the IA as modular zones, so new quizzes and IPs plug in without rebuilding the frame.
Shaping constraints and failure states with Product and Engineering
- 8-player cap
- Set deliberately to match what fits comfortably on a TV and the typical living-room group size.
- No-app-install requirement
- Defined by the Head of Product for launch. I partnered with the Senior UI Designer on the visual system and the Senior Game Designer on gameplay rhythm and pacing.
- Cross-functional alignment
- Most collaboration ran through the CPS-Blue engineering team. The confirm-before-submit pattern required their buy-in because it introduced a new state to the answer flow. Framing it as player protection, not added friction, turned it into a shared decision rather than a design preference.
- Failure-handling for a live, networked quiz
- Unlike static screens, a real-time quiz can fail in multiple ways. Together with engineering, we mapped ~12 error scenarios and designed a graceful fallback for each, prioritising the connectivity cluster first (5xx errors, WebSocket timeouts, failed asset loads) as the highest-stakes failures to get right.
One error template, ~12 scenarios
Working with the CPS-Blue engineering team, I defined a unified failure-handling model by mapping twelve potential error states and creating a single full-screen template for any issue that halted the experience, ensuring consistent messaging and predictable recovery paths.
Non-blocking scenarios like a full room or a rejected player name were intentionally handled through lightweight notifications instead, preserving room flow while still giving the affected player immediate, actionable feedback.
