Work · Case study
Multi-livestream experiences on connected TV
Product work that runs across Nexstar's connected TV portfolio: the 108 local station CTV apps and the NewsNation CTV app. How multiple live channels surface, how the experience handles availability and fallback, and what support teams need to live with it after launch.
Overview
Live video looks simple to viewers. Open the app, pick a channel, watch. The reality on the inside is messier. When an app surfaces multiple live channels, you need to decide what happens when a stream is up, when a stream is down, when one channel is the main event and the others are background, how the user moves between them, what program metadata to show on each, and what support needs to know when something looks off. Multi-livestream isn't a feature you bolt on top of a single-livestream app. It's a different model.
The multi-livestream pattern at Nexstar runs across the entire CTV portfolio: every local station CTV app I helped launch in 2025 (108 of them, across Apple TV, Fire TV, Roku, and Samsung), plus the NewsNation CTV app. The patterns defined here are the ones every station's app inherits.
The problem
The default mental model on a streaming app is "one channel at a time." A live news product that wants to surface several channels at once has to make a series of choices that look small individually and add up to the experience the viewer actually feels. Without explicit decisions, the app picks defaults that are hostile: blank players, "stream unavailable" errors with no context, navigation that re-buffers on every move.
The product work was to make the explicit decisions. Then to write them down in a way that engineering could build, QA could test, and support could explain.
Context
Several audiences depended on this working:
- Viewers opening the app expected live news to feel like live TV. Reliable, predictable, and easy to navigate.
- The editorial side needed to know what would show up on screen at any given moment so the schedule and the app stayed in sync.
- Engineering needed acceptance criteria precise enough to build against, including the edge cases.
- QA needed test cases that covered the matrix of stream-up, stream-down, program-changeover, and navigation-while-playing.
- Support needed to know how to read what they were looking at when a viewer reported something broken.
My role
I owned the product definition end to end:
- Defined how multiple live channels surface in the app, including which is primary and how secondary channels are presented
- Specified the behavior when streams are up, when they're down, and during the transition between programs
- Defined fallback behavior: what plays, what's shown, what gets logged when a stream isn't available
- Worked with design on the navigation pattern between live channels and how program metadata appears
- Wrote acceptance criteria covering normal cases and the matrix of edge cases
- Coordinated with engineering during build, reviewed QA test plans, and pushed back on cases that needed sharper definition
- Built the support documentation that explains the expected behaviors so the team has a reference when investigating a report
What the behavior set covers
Channel presentation
How multiple live channels are surfaced in the app. Which one auto-plays, which ones are visible as choices, what the navigation feels like.
Program metadata
What program is on each channel, what shows next, when the changeover happens. Program metadata as a first-class part of the live experience, not an afterthought.
Stream availability
What happens when a channel is up and what happens when it isn't. The "isn't" case has to be designed, not left to the player to express through generic errors.
Fallback
When a stream is unavailable, what does the viewer see? When does the app fall back to a different stream, a placeholder, or a non-live experience?
Navigation
How viewers move between channels, how the player handles those moves, what happens to playback state during the transition.
Support readiness
When something looks wrong, how the support team reads the situation. What logs they look at, what the expected behaviors are, how to confirm whether the app behaved correctly or not.
Product decisions and trade-offs
- Fallback as a first-class behavior. The temptation is to define the happy path and let the unhappy path inherit from the player. We did the opposite. The fallback behavior got explicit specification so the viewer sees something coherent when a stream goes down.
- Metadata over markup. The "what's on now" and "what's next" experience runs off program metadata in the feed, not hardcoded labels in the app. That keeps the app honest as the schedule changes.
- Support docs in the spec. The internal support playbook for the multi-livestream experience was part of the product deliverable, not a follow-up. Built alongside the feature, not after.
- Test cases by matrix. Stream up vs down, program transition vs middle-of-program, navigation vs idle. Each combination gets a test case so QA isn't guessing what "live behaved correctly" means.
Outcomes
A multi-livestream experience on the NewsNation CTV app that handles the cases live video actually presents, not just the happy path. The feature shipped with documentation good enough that support knew how to read it on day one, not week six. The product specs and the support playbook were the deliverables that made the launch supportable.
The bigger win is the pattern. The decisions we made on this feature carry over to anywhere a Nexstar app surfaces multiple live streams. The defaults are now defined.
What I learned
Live is not just a player. The player is the easy part. The decisions around the player (what shows when, what fallbacks happen, what the viewer feels during a transition) are where the product lives.
The edge cases are where the design happens. Anyone can spec what happens when everything works. The product judgment is in what happens when a stream is down, when metadata is late, when the viewer navigated somewhere unexpected.
Write the support doc before the launch, not after. If you can't explain to support what should happen, you haven't designed it precisely enough yet.
The apps this work touches
Browse the local CTV apps
Every local Nexstar CTV app supports the multi-livestream behaviors defined here. Tap any card to open the station livestream.