Role: Lead Designer
Team: PM, engineers. UX research, Data
Platform: Native desktop app, Mac and Windows
Scope: Concept through shipped MVP
Company: Prezi
Team: PM, engineers. UX research, Data
Platform: Native desktop app, Mac and Windows
Scope: Concept through shipped MVP
Company: Prezi
Context
Camera overlay lets someone appear on screen, live, next to their own content while presenting or recording. It's a live camera feed layered on top of the presentation, positionable anywhere on screen, that stays visible through screen sharing or recording, instead of the presenter hiding behind a static slide deck or a plain screen share.
The Opportunity
Three signals pointed the same direction, which is worth laying out as three columns rather than one paragraph:
The problem
Presenting live is already high stakes. If turning the camera on takes even one extra step, people skip it and default back to hiding behind a plain screen share.
"Ninety seconds before a client call, there's no time to open a settings dialog, choose a camera shape, and decide where an overlay should sit. There's only time to hit one button and be on screen, put together, before anyone joins."
What we tried first, and discarded
The first version was a full setup dialog: pick your camera, choose a camera shape, choose where it sits on screen, confirm with OK. It was thorough, and it also added a modal and an extra click between "I want to show my face" and actually being on screen.
The UI approach before user testing and stakeholder alignment
User testing surfaced the friction directly. People wanted a fast way to turn the camera on, and the setup dialog was in the way of that. So we cut it. The final MVP replaced the dialog with a single button in the bottom bar, camera off by default, one click to turn it on, with positioning handled afterward by simply dragging the overlay to wherever it needed to sit on the canvas.
Final UI approach
Designing the edge cases
Removing the dialog meant the permission and configuration logic that used to live inside it had to be handled elsewhere, quietly, without turning a one click action into a maze.
Permission denied
If someone declined camera access, the button itself shifted into a visible error state, with a native callout explaining how to fix it manually rather than leaving them stuck with no explanation.
If someone declined camera access, the button itself shifted into a visible error state, with a native callout explaining how to fix it manually rather than leaving them stuck with no explanation.
First-time users only
A feature callout introduces the new button once, then disappears, so returning users aren't repeatedly interrupted by an explanation they no longer need.
A feature callout introduces the new button once, then disappears, so returning users aren't repeatedly interrupted by an explanation they no longer need.
Platform divergence, hidden behind identical UI
Mac and Windows show nearly the same interface, but the permission model underneath is different. Windows grants all apps camera access by default, so most Windows users never see a permission prompt at all in the happy path, while Mac requires an explicit native permission dialog before the camera can turn on. Same button, different underlying logic depending on the OS.
Mac and Windows show nearly the same interface, but the permission model underneath is different. Windows grants all apps camera access by default, so most Windows users never see a permission prompt at all in the happy path, while Mac requires an explicit native permission dialog before the camera can turn on. Same button, different underlying logic depending on the OS.
Goal
This work was aimed at the Prezi desktop app specifically, which meant it was aimed at our most loyal, highest paying users, the segment already invested enough to be on native rather than web. For that audience, feature parity with competitors wasn't optional; it was table stakes for keeping them from drifting to a tool that already had this built in. The objective was to improve activation of the feature and support retention on desktop. Going from "camera access requires a multi field setup dialog" to "camera access is one click, everything else handled after" was the bet on how to get more of that high value segment actually using it.
What came next
This feature's direction fed into a larger initiative, a dedicated recording studio experience built on the same underlying logic, using native platform technologies. That work doesn't have supporting visuals ready yet, so it's left here as context for where this direction led rather than as part of this case study.
Reflection