Pulse brings Telestream’s IP video, timing, and alarm monitoring into a single web application. I led the design of an experience that lets engineers see and configure their hardware from any computer, while everything stays on the customer’s own secure network.
Telestream’s IP monitoring lived in two places: Inspect 2110, a browser-based probe interface, and PRISM, a waveform monitor whose interface ran on the hardware itself. To check a signal or change a configuration, engineers often had to be standing at the device. Pulse set out to bring these capabilities into one web application that connects to the customer’s hardware and runs entirely on their own servers and network, with no internet connection, so sensitive media and data never leave the facility.
Design Problem
Business Problem
Before talking to customers, I reviewed the Inspect 2110 and PRISM interfaces that Pulse would replace. Both were powerful, but they were built around the device rather than the person using it. I treated what I found as hypotheses to test in customer interviews.
Key LearningsPRISM’s touchscreen interface meant that diagnosing an issue often started with walking to the rack.
Uniform tables of packet counts and stream parameters made the one value that mattered look like every other.
A red Critical banner flagged a problem, but not which stream, when it started, or what to check next.
customer
interviews
I asked customers how they monitor live IP signals today, where they lose time during an incident, and what they would need to trust a browser-based tool with on-air monitoring. The same needs kept surfacing across very different roles, and each one became a design opportunity that shaped a part of Pulse.
Engineers pieced together a signal’s health from the rack, Inspect, and separate tools that didn’t integrate.
A configurable dashboard of live video, audio, waveform, and vector tiles, sourced from any connected device.
Too many alerts looked urgent, so engineers lost time during an incident working out which ones really were.
A severity-first alarm summary with counts, filters, acknowledgment, and grouped occurrences, shown beside the data it relates to.
Network specialists lacked media context in their IT tools, while broadcast engineers lacked network context.
An input view that pairs video, audio, and ANC vitals with IP sessions, SFP details, and timing on the same page.
Multicast and PTP problems came and went, and were hard to understand from a single snapshot of values.
Per-port timelines, a live and historical time range, and a clear record of when each value last changed.
Findings lived in people’s heads, and incomplete documentation meant the next person started the investigation over.
Comments pinned to a moment on a graph, plus CSV and image export for reports and handoffs.
Protecting sensitive media and data was non-negotiable, so remote access couldn’t mean sending anything to the cloud.
A browser-based experience deployed on the customer’s own servers, with no internet dependency.
Engineers didn’t want less data. They wanted to see every signal in one place, know which problems mattered, and understand them quickly, on both the broadcast and network side.
I synthesized the interviews into three personas that anchored design decisions across the product: two primary personas who share responsibility for the signal and the network that carries it, and a secondary persona focused on how the picture looks on air.
Primary Persona
Broadcast and media workflow engineers
Responsible for error-free live output and measured on downtime. They needed to resolve problems quickly, without being tied to a single piece of equipment.
Drake keeps live broadcasts running. His goals center on minimizing downtime and glitches during live events. His pain points were frequent equipment issues during broadcasts, time-consuming manual workflows, and difficulty integrating the many tools he already relied on.
Primary Persona
IT and IP network specialists
Responsible for the network that carries the media. They needed packet loss, latency, multicast, and PTP data in one place, alongside the broadcast context their IT tools could not show.
Edna keeps the facility network healthy under pressure. Her pain points were fragmented tools that did not integrate, alerts that were not actually critical, limited visibility into media-specific traffic, and hard-to-diagnose multicast and timing issues.
Secondary Persona
Video shaders and colorists
Responsible for how every frame looks on air. They relied on waveform and vector scopes and needed advanced HDR analysis without a complicated interface.
Daniel paints and balances cameras during live events and grades content afterward. His needs centered on real-time waveform and vector tools, and his pain points were unintuitive HDR tooling and balancing creative decisions against technical standards.
I translated the research into four connected areas of the product, all built on a shared navigation and design language. Together, they let engineers build the view they need, dig into any input or timing source, and move from an alarm to its cause without leaving the browser.
PRISM showed one scope at a time on the hardware’s own screen. The Pulse dashboard turns that into a grid of live tiles that engineers arrange, configure, and group for the way their facility works.
Engineers needed to watch many sources and scopes at once, from anywhere.
A grid-based dashboard of video and scope tiles, configured in a side panel and saved per team.
Grid layouts · Scope tiles · Tile presets · Color-coded groups · Saved dashboards
01
Start from an empty state or insert a grid, then add tiles by right-clicking or using Add Tile.
02
Picture, waveform, lightning, and stop display tiles bring PRISM’s scopes into the browser, side by side.
03
A side panel organizes input, settings, display, and statistics into tabs, with presets that can be saved and reused.
04
Select several tiles to assign a group color and a shared source, so related views change together.
05
Save, favorite, share, and import dashboards so each team keeps the views that match its role.
Inspect 2110 presented each stream as long tables of equally weighted metrics. The Input Monitor starts with a status-first overview of every input, then opens into tabs that pair signal vitals with the network details behind them.
Broadcast and IP specialists each saw only half of the picture.
Input cards that show health at a glance, and a detail view that connects signal, network, and alarms.
Status cards · Guided setup · Vitals · IP sessions · In-context alarms
01
Each input shows a preview, its format, color-coded status, and alarm icons, plus clear states such as Disabled or Waiting for NMOS.
02
One form covers the resource, standard, alarm profiles, and 2110 streams, with live previews of both paths as you configure.
03
Signal type, redundancy, and video, audio, and ANC details are summarized first, and mismatches link straight to the stream that caused them.
04
IP sessions show SFP vendor details, link speed, and optical power for each network, as data, graphs, or both.
05
An alarm panel sits beside the input, so engineers can acknowledge issues without losing their place in the data.
Timing problems are often intermittent, so a single snapshot rarely explains them. The PTP Monitor shows lock status and alarm distribution up front, then lets engineers trace each port’s behavior over time.
Multicast and timing issues were among the hardest to diagnose.
Status cards for each PTP resource and time-based graphs that show exactly when and where things changed.
Monitor cards · Alarm setup · Port timelines · Live and history · Collapsible graphs
01
Each resource shows its domain, lock status (Locked, Unlocked, or Drifting), and a bar of active alarms by severity.
02
Engineers choose which PTP alarms to track, and set their duration and severity, while creating the monitor.
03
State bars show when a port moved from Follower to Listening or Faulty, with hover details for each change.
04
A date picker and interval control let engineers look back at an incident, then return to live data with Go Live.
05
Every metric shows its current value and last change, and its graph expands only when it is needed.
In the legacy tools, an alarm was a red banner. In Pulse, every alarm is a record that can be filtered, investigated, acknowledged, and discussed, with the event log and graph comments preserving what the team learned.
Alarm noise and lost context slowed resolution and handoffs.
A severity-first alarm summary, a searchable event log, and comments attached directly to graphs.
Severity tabs · Alarm details · Drill-down · Event log · Graph comments
01
Tabs with counts for Critical, Warning, and Informational alarms help engineers focus on what matters first.
02
Selecting an alarm shows its source, device, duration, occurrences, and a video thumbnail without leaving the table.
03
Engineers can view every occurrence of an issue, then acknowledge one alarm or many in bulk.
04
Every event is timestamped, filterable by date range, and exportable, with timecode and device details for each entry.
05
Engineers pin comments to a moment on a graph, so the next person sees what happened and what was already checked.
Each feature area went through its own round of unmoderated usability testing in UserZoom, built on the same template: a small group of participants, a set of realistic tasks, and three measures. I linked a clickable prototype into each UserZoom study, and participants worked through the tasks on their own while UserZoom recorded their screen, voice, and click paths. After each task, UserZoom asked participants whether they had completed it, which gave me perceived completion. I then reviewed the recordings and click paths to score actual completion. Each study ended with a System Usability Scale survey, also delivered in UserZoom. The gap between perceived and actual completion was the most useful signal, because it showed where engineers felt confident but were quietly going wrong.
The average System Usability Scale score across the usability tests of each feature area.
The share of tasks participants actually completed, averaged across the usability tests of each feature area.
How long participants took to complete each task, averaged across the usability tests of each feature area.
How difficult participants rated each task, averaged across the usability tests of each feature area.
Status colors, severity counts, and “last changed” timestamps did more to speed up scanning than adding new views ever would have.
Broadcast and IP specialists look at the same incident from different sides. Putting signal and network data on one page gave them a shared picture.
Participants felt successful more often than they were. Measuring actual completion alongside SUS caught problems a satisfaction score alone would have hidden.
