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.

The two-minute version
- 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.
- 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.
- 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.
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.
A deeply technical domain, in real time, for people who can’t afford to guess.
It’s live
Health changes second to second. The UI has to show state and change without becoming a slot machine of blinking lights.
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.
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.
Volume
Hundreds of slicers and channels per account, a dozen-plus health metrics per slicer, events stacked across a calendar day.
Migrating while live
We were replacing legacy tools that people depended on during live events. Nothing could break, and nobody could be surprised.
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
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?
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.
Six decisions that shaped the tools.
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.

- 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.
- Broadcaster metrics first. Sessions, slate % and ad errors — the numbers that turn into phone calls.
- Active slicer + auto-failover visible together, so you know what the system will do before you touch anything.
- Manual failover asks once. Activating a backup slicer is one click and one confirmation — fast, but never accidental.
- The penalty box. Sixty minutes of health as a timeline, with failovers marked, so operators can see patterns instead of scrolling logs.
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.

- Severity per metric — critical, warning, or disabled.
- Trip and clear are separate. Threshold + duration to raise an alert, and a different pair to clear it. No flapping.
- Scoped to an organization, then mapped to the slicers it governs.
- Disabled is a real choice, not a zero — some channels simply don’t carry captions or ads.
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.
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.
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.
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.
The tools, up close.
A cross-section of the shipped product and comps. Click any image to enlarge — these are dense on purpose.
Monitoring

- Critical floats to the top, tinted, with how long it’s been in that state.
- Ruleset in the row, so “why is this red?” has an answer without clicking.
- Per-account tallies (critical / warning / healthy) for people watching several customers at once.
- 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.
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.
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.
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.
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.