Amazon

Livestream & real-time engagement platform

Role

Product designer

Team

PM, eng, event ops

Scope

Operator workspace, automation, viewer experience, organizer branding

Scale

10,000+ events a year · up to 160K concurrent viewers

Problem

Operators ran up to 10,000 events a year across disconnected tools and found setup errors live, in front of as many as 160,000 employees.

Strategy

Treat live failures as a system problem, not a screen problem. Fix them where the process creates them: let the system handle the common case, route exceptions to people, and let each event and role set what it needs instead of following one platform rule.

What I did

Replaced five setup tools with one workspace organized around event stages, made recurring events run without operator setup, separated organizer and operator access by role, made reactions and branding configurable per event, and designed a viewer layer where participation never competes with the video.

Result

Setup effort down 60%. 60% of 10,000+ annual events eligible for automation. Viewer participation up 30% at events of up to 160K concurrent viewers, with zero reaction-flooding incidents.

Before

Five disconnected setup activities

Planning, scheduling, setup, and production lived in separate tools. Operators held the dependencies in their heads, and problems surfaced during the live event.

After

Dashboard → event workspace → task completion

One workspace organized around the operator's stages, with status and next steps visible in context.

Research · Diagnosis before design

The failure point was setup, not playback

Six months of support tickets, user interviews, and operator shadowing showed that problems started weeks before an event, in a setup process spread across several tools.

Swimlane map of the end-to-end setup process across organizers, operations, presenters, and viewers, from weeks before the event through event time — The end-to-end process across all four roles, from weeks before the event through event time.

Show the reasoning · users, failure point, proposed model

"If this Livestream does not play right within 2 minutes, I'm out of here!"
— Livestream viewer

The four user groups: organizers, presenters, viewers, and operations — **Four groups, four needs.** Organizers wanted consistent branding, presenters wanted real-time feedback, viewers wanted to participate, and operations needed reliable tools to run events smoothly.

Process map with the operations setup step highlighted as the failure point — Where it broke: the setup step operations owned. The more complex the event, the higher the risk.

Detailed map marking every manual step operations performed to get one event live — Every manual step operators carried out to get a single event live.

Insight

We were making operators responsible for monitoring fragmented tools and processes just to run one event.

Reframe

From "How might we simplify setup?" to "How might we give operators a coherent mental model of the whole livestream process?"

Proposed model collapsing manual operations steps into one consolidated livestream service — The proposed model: planning, scheduling, setup, and production collapsed into one service, with AI-assisted troubleshooting and summaries scoped as future work.

Design decision 1 · Information architecture

A dashboard built around one question: "What needs my attention?"

Status, timing, and trends lead. Everything else moves into the event, so operators triage first and dig in second.

Livestream operator dashboard with today's totals, a filtered event list, status and time columns, and a three-dot actions menu on each row

1
Trends, not just totals. Change against the previous period helps operators anticipate busy periods.
2
Scoped to my events. A filter and search narrow the list to what this operator owns.
3
Status and timing are primary. Status is always a text label, so meaning never depends on color alone.
4
Secondary actions stay out of the way. Extra actions sit one click away in the row menu.
5
One primary action. "Create new event" is the only filled button on the screen.

Show the reasoning

Operators didn't need another place to see every piece of event data. They needed to quickly identify which events required action and understand what to do next. I prioritized event status, configuration state, upcoming tasks, date and time, and trend information. Presenter names, organizer notes, and technical details live in the event workspace, not on the dashboard.

See what needs attentionDashboard

Understand whyStatus + tasks

Open the eventEvent workspace

Complete the taskBack to dashboard

Problem

Setup was split across five disconnected activities in separate tools, and operators found configuration problems during the live event.

Evidence

Six months of support tickets, user interviews, and operator shadowing pointed to setup, not playback, as the failure point.

Decision

A dashboard that answers "what needs my attention?", linking into a workspace focused on one event at a time.

Why

Showing every field would have recreated the old tools on one screen. Prioritizing status and next steps let operators triage first and dig in second.

Result

Setup effort down 60%.

Design decision 2 · Interaction model

Revealing complexity only when it becomes relevant

Each event starts from sensible defaults. Advanced production options appear only when earlier choices require them.

Default event configurationWhat most events need

Advanced production optionsRevealed by prior choices

Show the reasoning

The event workspace focuses on a single event. A task list and a status model work together, so operators always know what is done, what is blocked, and what comes next.

Defaults firstCommon configurations start from sensible defaults. Advanced production options appear only when earlier selections require them.
Tasks + statusEach event's task list is paired with a status, so operators can focus on their assigned events and see what requires action.
Warn, don't blockIncomplete setup shows a warning rather than stopping progress when the missing information can legitimately arrive later. Unresolved issues are surfaced clearly before event day.

Design decision 3 · Workflow automation

Letting most events run without an operator touching them

60% of 10,000+ annual events became eligible for automation. Operators shifted from setting up every event to monitoring the exceptions.

Organizer schedulesEligibility shown up front

System configuresRecurring setups automated

Operator monitorsExceptions only

Show the reasoning

Support-ticket analysis showed that most recurring events used the same configuration every time. Operators were still setting each one up by hand. I interviewed organizers and operators to define which events could be automated, what counted as an exception, and how the system should behave when something fell outside the rules.

Clear eligibilityOrganizers learn at scheduling time whether their event qualifies for automation, and what would change that, instead of finding out from an operator later.
Exceptions route to peopleEvents with special requirements (multiple cameras, off-campus venues, VIP presenters, sign-language interpretation) automatically go to an operator with the reason attached.
Monitor, don't configureFor automated events, the operator's job shifts from setup to oversight: the dashboard shows status and flags only the events that need a person.

I validated the complete workflow with both roles before launch. Automation reduced operator workload, organizer lead time, and support tickets while increasing platform capacity.

Design decision 4 · Roles and permissions

Same event, different jobs: occasional organizers and expert operators

Navigation, hierarchy, and permissions follow each role's responsibilities, not the underlying system.

Occasional organizer

Needs confidence, not controls

Simple event information
Only the configuration relevant to them
Limited technical complexity
View and edit access appropriate to the role

Experienced operator

Needs depth and control

Technical configuration
Livestream endpoint information
Full event-management actions
Deeper troubleshooting and control

Signature interaction story

When two user groups need opposite things, don't force a global rule

Viewers wanted thumbs-down. Organizers refused it. I made reaction sets configurable per event, then designed throttling for hundreds of reactions a second. Result: participation up 30%, zero distraction complaints, zero flooding incidents.

Designing for hundreds of reactions in one second

Rejected

25% larger emoji

Size didn't map to any natural metaphor. Users didn't understand what it meant.

Rejected

"+47" counter badge

The badge competed with the emoji and still felt disruptive at large numbers.

Shipped

Single instance per type

One emoji per type per second. Chosen by viewers in testing; least distracting.

Show the reasoning · stakeholder conflict, tradeoffs, edge cases

How the conflict surfaced and resolved

Interviewed viewers firstAsked which emojis they would actually use during a business presentation. They chose eight types, including negative ones; thumbs-down was explicitly requested.
Validated with organizers: an unexpected vetoOrganizers rejected all negative emojis: "Business leaders will not be happy seeing thumbs down from audiences during their presentation."
First instinct: pick a sideA platform-wide rule, either all emojis or positive only, would have failed one legitimate group.
Reframe: platform policy → per-event settingOrganizers know their event's norms better than the platform does. A large all-hands has different norms than a small team call.
Shipped: emoji set chosen during event intakeOrganizers pick the available reactions for their event. Viewers stay expressive; organizers keep control.

Consideration	Global rule	Per-event setting (shipped)
Viewers get the reactions they asked for	Partly	Yes
Organizers control audience signals	No	Yes
Platform stays neutral about context	No	Yes
Extra intake complexity	None	One extra step, accepted

After launch, large events (200+ viewers) consistently chose positive-only sets, and smaller teams opted into the full set. Context determined the norms, and organizers were the right people to decide.

Designing for edge cases before they happened

Layer, not featureThe reaction stream is capped at 15% of the player's width and 25% of its height. The video is the product; every throttling decision served that.
Viral momentWhen everyone laughs at once, show one emoji per type per second. Volume is implied by the single emoji, so the stream never becomes a wall over the video.
Bad actorA per-viewer limit of one reaction per 10 seconds stops intentional flooding. Normal viewers never notice the limit.

Decision

Changed the product architecture from a platform-wide rule to organizer-configurable reaction sets, plus display throttling and a per-viewer rate limit.

Result

Participation up 30% versus chat alone. Zero distraction complaints and zero flooding incidents after launch.

Visual and responsive design

Designing trust at the viewer layer

A calm, professional visual language where the video is always the hero, from the moment viewers arrive.

The waiting room sets the tone. Viewers often join minutes before an event starts. I designed and animated this welcome loop to fill that wait with a reminder of why they're attending (engaging with their team, discovering new technology, celebrating the company's diversity) so they arrive ready to take part.

Livestream viewer experience: video player as the hero, event chat alongside, and a reaction bar below the player

1
Visual hierarchy. The video stays the hero. Chat and reactions are visible without competing for attention.
2
Responsive behavior. On smaller screens, chat moves below the player rather than shrinking the video.
3
Interaction density. Reactions are capped at about 25% of the player's height, and viewers can hide them.

–
Organizer branding without one-off builds. One submitted player-skin asset generates coordinated header and footer treatments, previewed and approved by the organizer before going live.

Show the reasoning · chat placement, dark mode, branding constraints

Rejected

Pop-up chat

Would have freed the whole viewport for video. User testing showed viewers needed to watch the video and the conversation at the same time.

Shipped

Chat integrated beside the video

Visible by default, with hide, theater, and fullscreen controls so viewers choose how they watch.

ColorA dark blue palette chosen to communicate stability for high-visibility company events.
Dark modeReduced visual intensity for long viewing sessions while preserving hierarchy and interaction states.
Branding constraintsConfigurable header, footer, and custom regions work within defined image and responsive constraints, so high-profile events get a distinct identity without breaking the layout. Organizers preview in a test environment before production.

Engineering partnership. I designed within the existing component system and worked with engineering on responsive behavior, system states, configuration logic, throttling, and implementation tradeoffs, using existing components where they fit and designing new variants where no pattern existed.

Also explored with AI

Where AI could meaningfully help viewers find, catch up on, or fix things. Prototyped and scoped as future-state work.

Livestream ShortsConcept

AI-surfaced moments from a 10,000+ event library, with a direct path into the full recording.

AI-assisted playback troubleshooting concept

Playback troubleshootingFuture state

Detects common failure patterns and suggests fixes without leaving the stream.

Event summariesFuture state

Lets late joiners catch up without rewatching the full stream.

What I'd do differently

I'd shadow operators during live events earlier. Real-time stress behavior differed from what tickets described, and that shadowing is what showed operators needed a unified workspace, not a simpler version of one step.

I'd test viewers and organizers together. Interviewing them one after the other meant the reaction conflict surfaced late.

All work Next: TIBCO