← All work

Verizon Media · 2016 – 2021

Keeping the big games on the air

Designing and building the real-time tools broadcasters use to run live streams — where “we’ll fix it next sprint” isn’t an option, because the Super Bowl is happening right now.

Company
Verizon Media
Verizon Digital Media Services · Uplynk · Edgecast
My role
Senior Front-End Engineer / Product Designer
Worked with
Product managers, backend and platform engineers (manifest, slicer, CMS), NOC and support teams
Platforms
Web ops consoles, internal admin tools, design system
Scale
Live events for partners like Disney, ESPN and Discovery — including the Super Bowl and NBA Finals
Recognition
Award of Excellence – Collaboration (2019) · “Best to Work With” nominee (2019)
Service Assurance channel view in the Uplynk platform, with slicer and audience previews, active and backup slicers, a live viewer chart, and a 60-minute “penalty box” health timeline.

The two-minute version

  1. Live-streaming operators needed to know right now whether a stream was healthy — and fix it fast when it wasn’t. The tools had grown one feature at a time.
  2. I designed and built monitoring, live-event, failover and admin interfaces on top of a deeply technical pipeline, working directly with the engineers who owned each piece.
  3. The result was a more coherent set of ops tools — configurable health rules, clearer alarms, safer destructive actions, and a shared design system — used during some of the biggest live events on the internet.
01 · The problem

When a live stream breaks, everyone finds out at once.

Verizon Media ran the video infrastructure behind a lot of live TV on the internet — the part that takes a broadcaster’s feed from a stadium, slices it into streamable chunks, stitches in ads, enforces blackout rules, and pushes it through a CDN to millions of devices.

The people running those streams (broadcast operators, NOC engineers, customers’ own teams) lived in our tools. And those tools had grown the way platform tools usually do: one urgent feature at a time, across several products and acquisitions, with a legacy version of almost everything still running next to the new one.

During a big game, that’s not a cosmetic problem. If an operator can’t tell in a glance which slicer is failing, whether viewers are actually seeing a slate, or what will happen when they click “activate backup,” the cost is measured in minutes of dead air.

Real operations rooms using the tools. This is the environment we were designing for — lots of screens, lots of pressure, very little patience for ambiguity.
02 · Why it was hard

A deeply technical domain, in real time, for people who can’t afford to guess.

  1. It’s live

    Health changes second to second. The UI has to show state and change without becoming a slot machine of blinking lights.

  2. The domain is dense

    Slicers, manifests, SCTE markers, ad pods, slates, DMAs, zip-code blackouts, encoding ladders. Users are experts; the UI can’t dumb it down, but it can stop getting in the way.

  3. Many kinds of users

    NOC admins see every organization; customer admins see only theirs; operators need speed; engineers need raw JSON. Same screens, different permissions.

  4. Volume

    Hundreds of slicers and channels per account, a dozen-plus health metrics per slicer, events stacked across a calendar day.

  5. Migrating while live

    We were replacing legacy tools that people depended on during live events. Nothing could break, and nobody could be surprised.

03 · My role

Designer and front-end engineer, in the room with platform teams.

I worked across multiple streaming product teams at once, inside a large design organization (roughly 140 designers across Verizon Media), and routinely traveled across the US to work in person with teams in different offices. My role flexed with the job: on some projects I was the designer, on others the developer, often both — how much I coded and how big the team was depended on the task and the deadline. That meant I was in the same conversations as the engineers who owned the slicer, manifest and CMS services, not handing files over a wall.

What I owned

  • UX and UI for live-ops tools: slicer monitoring, service assurance / Streamwatch dashboards, failover groups, encoding profiles, live events and org administration
  • Front-end implementation in Aurelia/TypeScript, including contributions to the Bindable component library
  • Interaction patterns for alarms, destructive actions, empty/unavailable states and deprecation messaging
  • Prototypes and specs (InVision, Jira) that engineering built from — and reviewed with me

What the wider team owned

  • Backend services: slicers, manifests, ad insertion, CDN, analytics
  • Product management and roadmap across the streaming platform
  • Visual brand and the wider Verizon Media design language
  • NOC and support operations, who were also our toughest users
04 · Understanding the system

First, draw the pipeline. Then design the windows onto it.

Every screen in this story is a view onto some part of the pipeline below. Getting this model straight — with the engineers, not just for them — is what made the UI decisions easier. When someone asked for “a red dot when something’s wrong,” we could ask: wrong where? At the slicer, in the manifest, at the CDN, or for the viewer?

Live streaming stackSignal path: venue feed, slicer, streaming cloud, CDN, viewers. Control tools below: live channels and events, slicer monitoring, failover and encoding, ad server debug, service assurance — each connected to the part of the pipeline it controls or observes. Operators, NOC engineers, customer admins and support use them.Signal pathVenue feedBroadcaster’s livesignal from the eventSlicerEncodes & slices;reads ad markersStreaming cloudManifests, ads, DRM,blackouts, slatesCDNDelivery acrossregions & POPsViewersWeb, mobile,TV & OTT appsControl plane — where my work livedLive channels & eventsSchedules, slates, rules,blackout audiencesSlicer monitoringHealth, rulesets, alerts,allowed watchersFailover & encodingSlicer groups, priorities,encoding profilesAd server debugQuery → job →request/responseService assuranceSessions, rebuffering,ad insertion, slate %Who used themBroadcast operatorsNOC engineersCustomer org adminsSupport & solutionsPartner engineering
A simplified model of the live-streaming stack. The signal flows along the top; the tools I designed and built lived in the bottom row, each one a window onto part of the pipeline.

For slicer monitoring, I worked with engineering to map every state a slicer and its management tasks could be in, and how those states rolled up to what a human needed to see. That map became the contract between the backend events and the UI.

Working state model for slicer monitoring. Task states on the left, the slicer’s lifecycle in the middle, what monitoring should show on the right. Unglamorous, and the most important artefact in the project.
05 · Key decisions

Six decisions that shaped the tools.

Decision 1

Show what the viewer sees, not just what the machine reports.

Operators kept asking the same question: “Is the problem real, or is it just the dashboard?” So the channel view puts the slicer’s output next to the audience’s actual playback, says plainly that the audience view runs a minute behind, and keeps the numbers that matter to a broadcaster — concurrent sessions, missing-content slate, ad insertion errors — in one column.

Service Assurance channel detail: slicer view and audience view previews, active slicer with auto-failover toggle, backup slicers with a confirmation popover, a live viewers chart, and a color-coded 60-minute health timeline.
  1. Two truths, side by side. Slicer view vs. audience view, with the one-minute lag stated in the UI so nobody panics about a mismatch.
  2. Broadcaster metrics first. Sessions, slate % and ad errors — the numbers that turn into phone calls.
  3. Active slicer + auto-failover visible together, so you know what the system will do before you touch anything.
  4. Manual failover asks once. Activating a backup slicer is one click and one confirmation — fast, but never accidental.
  5. The penalty box. Sixty minutes of health as a timeline, with failovers marked, so operators can see patterns instead of scrolling logs.
Decision 2

Make “healthy” configurable, not hard-coded.

A sports network and a 24/7 news channel don’t agree on what “bad” means. Rather than hard-coding thresholds, we made health a ruleset: for each metric (dropped frames, loss of audio, black video, upload queue, closed captions…), set a severity, a threshold and a duration to trip it, and a separate threshold and duration to clear it. Rulesets are scoped to an organization and mapped to groups of slicers.

The separate “clear” values mattered more than they look. Without them, a flaky signal flaps between healthy and critical every few seconds — which is exactly how you train operators to ignore alarms.

Create Ruleset drawer with sections for dropped frames, loss of audio, signal status, upload queue, closed captions, processing backlog, black video and extended ad break — each with severity, set threshold, set duration, clear threshold and clear duration.
  1. Severity per metric — critical, warning, or disabled.
  2. Trip and clear are separate. Threshold + duration to raise an alert, and a different pair to clear it. No flapping.
  3. Scoped to an organization, then mapped to the slicers it governs.
  4. Disabled is a real choice, not a zero — some channels simply don’t carry captions or ads.
Decision 3

Alarms you can read without relying on color.

One customer’s existing tool encoded severity with subtly different ellipse shapes and colors. In a dark room at 2 a.m., on a wall of monitors — and for anyone with color vision deficiency — that’s a guessing game. I explored an alternative where severity is carried by the count of a single, familiar icon, with color reserved for the levels that need attention first.

Design-approach study: shape-and-color vs. count-based alarm indicators.
Decision 4

Destructive actions that don’t surprise anyone.

We had two delete patterns in the product, and they behaved differently. In one, rows disappeared immediately but weren’t actually deleted until you hit Save. In another, deletion was instant after a confirmation. I wrote up the confusion — with annotated flows — and proposed a “slated for deletion” state so what you see always matches what will happen.

My working notes on delete mechanics. This is the kind of small interaction inconsistency that becomes a big trust problem in an ops tool.
Decision 5

Retire the legacy tool without a revolt.

Moving operators from Monitoring v1 to v2 meant changing muscle memory during live-event season. We explored where a deprecation message should live and how loud it should be — persistent but dismissible, specific about the date, and always with a way back to the legacy view during the transition.

Option A
Option B
Option C
Deprecation banner explorations for the legacy monitoring view. v2 kept a “Return to legacy monitoring” escape hatch in the header during the cut-over.
Decision 6

Ship the MVP operators need, then grow it.

Streamwatch — a customizable monitoring dashboard across channels and events — could have become a year-long “single pane of glass” project. We scoped an MVP around two charts operators actually asked for (concurrent sessions and missing-content slate by channel), then grew toward the widget dashboard.

MVP
Where it was heading
06 · The work

The tools, up close.

A cross-section of the shipped product and comps. Click any image to enlarge — these are dense on purpose.

Monitoring

Monitoring list of slicers for Fox accounts: critical slicers tinted red at the top, healthy slicers below, muted slicers at the bottom; sidebar with saved views and per-account red/orange/green counts.
  1. Critical floats to the top, tinted, with how long it’s been in that state.
  2. Ruleset in the row, so “why is this red?” has an answer without clicking.
  3. Per-account tallies (critical / warning / healthy) for people watching several customers at once.
  4. Muted slicers sink instead of disappearing — out of the way, not out of mind.

Slicer detail: preview, health, status and history in one view.

Alert log: every transition, filterable, with the metric that caused it.

Channel monitoring wall — built for literal walls of monitors.

Org admin: NOC admins manage organizations; org admins see only their own.

Live channels & events

Channel detail — every setting that decides what a viewer gets, in tabs, with a live preview pinned.

Blackout audiences by IP network, zip, DMA, device and country — this is how regional sports rights get enforced.

A week of live events. Density is the design problem.

Live event dashboard: source, switcher, and what the audience is seeing.

Plumbing that has to be right

Failover groups with slicer priority.

Encoding profiles mapped to slicers.

Ad Server Debug: end-to-end visibility into ad insertion.

07 · Working with engineering

Closer to a pairing than a handoff.

Because I was also writing front-end code, “handoff” was more of a conversation than an event. A few things that made it work:

  • Shared components, not redlines. I contributed to Bindable, our Aurelia design system — table styles, pill variants, loading states — so designs and code used the same building blocks. (More on Bindable.)
  • Specs where the work lives. Tickets carried the reasoning and a clickable prototype, so engineers could see the intent, not just the pixels.
  • Designing the unhappy paths. Unavailable thumbnails, failed connections, “you’re not authorized to operate this event,” read-only states for rulesets you don’t own. In ops tools, the edge cases are the product.
  • Meeting operators where they already were. Alerts went to Slack as well as the UI, with allowed-watcher permissions so customers could let partners watch their slicers.

My pull requests to Bindable.

A failover ticket with the reasoning and prototype attached.

Failover alerts piped into Slack.

Unavailable states, designed for light and dark.

Watch Together, in two weeks

In 2020 Yahoo was launching Watch Together for the NFL season. COVID lockdowns meant commentators and hosts might be stuck at home at a moment’s notice, so the platform needed an operator tool to create watch-party groups, connect them to scheduled or live events, and add or remove hosts and commentators on the fly. I designed the Watch Together Operations Manager in a two-week design window with engineers and PMs from our manifest, slicer and CMS teams, Yahoo Sports, technical account managers for the NFL and Fox Sports, and Phenix, the real-time streaming partner.

Watch Together launched in the Yahoo Sports app in September 2020: one person could invite up to three friends into a split-screen video call while everyone streamed the same live NFL feed. The Operations Manager was the tool behind it that let operators run those groups, hosts and events live.

The consumer experience: Yahoo Sports Watch Together, which the Operations Manager ran behind the scenes.

Why it was a two-week job. The NFL season doesn’t move. With lockdowns, hosts and commentators could end up stuck at home at a moment’s notice, so operators needed to create watch-party groups, attach them to scheduled or live events, and add or remove hosts and commentators on the fly.

Getting there meant aligning a lot of people fast: our manifest, slicer and CMS teams, Yahoo Sports, the NFL and Fox Sports account teams, and Phenix, the real-time streaming partner.

08 · Outcome

What changed.

These tools ran underneath live events for partners like Disney, ESPN and Discovery — including the Super Bowl and the NBA Finals — for audiences in the millions. The platform itself was built for that scale: Verizon Media publicly reported serving a single client more than a million simultaneous viewers at streaming peaks, and a test milestone of 10 million concurrent viewers in 4K HDR. The work replaced a patchwork of legacy screens with a more consistent set of tools: health defined by configurable rules instead of guesswork, alarms that read at a glance, safer failover and deletion, and one component library shared by design and engineering.

The way we worked got noticed, too — working across teams quickly and well, shifting between design and development as each deadline needed.

Collaboration · January 2019
Award of Excellence
Nominated · November 2019
“Best to Work With”
MX Studio, NAB · April 2017 (see MX Studio)
Best in Show

Platform scale figures are from Verizon Media’s public announcements (press release) and describe the platform, not metrics I owned.

09 · What this shows

What this project says about how I work.

  • Complex systems

    Modeling a real-time pipeline with engineers before designing the windows onto it.

  • Design × engineering

    Designing and building in the same codebase and component library.

  • Operational UX

    Density, alarms, permissions and edge cases for expert users under pressure.

  • Collaboration

    Award of Excellence for collaboration and a “Best to Work With” nomination, for working across many teams and locations, fast.

  • Judgment

    Scoping MVPs, retiring legacy tools carefully, and saying no to “red dot” requests without context.