Azure
Streaming
Designing live video for the operator, not the API
I set an operator-first direction for the Azure Media Services portal and carried it into Azure Video Analyzer, turning Live Events into a supported portal workflow; support satisfaction passed its 4.7 goal in August 2020.
My part
Lead designer: portal strategy, Live Events, measurement
Duration
2019 – 2022
Crew
PM, engineering, research, content, data
Ships on
Azure portal
Context & role
Azure Media Services was Azure's cloud platform for encoding, live streaming, content protection and video analytics. Its users ranged from video engineers who script against the API to operators and producers who run live events and don't code. I was the lead designer, working with PM leadership, an engineering manager, a researcher, a content designer and a data partner. My role: I owned the experience strategy for the portal and Live Events, the measurement approach for design work, and the design side of the research agenda; engineering built it, PM owned priorities, and the researcher and I ran research together. On Azure Video Analyzer, a hybrid edge and cloud service for analyzing camera video, I was the product designer.
Stakes
Azure Media Services was a large platform, but most of its use came from Microsoft's own products, and external growth was flat. For external customers the first step was the hardest: the Azure portal didn't support Live Events, so people pieced together documentation, a desktop tool, forums and support calls. Competitors were winning on approachability as much as capability, and leadership's growth goal couldn't be reached on internal customers alone.
Reframe
Asked: put Live Events in the portal. Reframed: get a non-programmer to a monitored stream.
Built as asked, the portal would have mirrored the API's objects (inputs, outputs, locators, endpoints) for people who already understood them. I redefined the job as reducing the time and media knowledge it takes someone who doesn't code to set up, monitor and deliver a live event. Customers had already asked three plain questions: how do I set up my event quickly, how do I monitor it, and how do I deliver it to my audience. Two years later I reframed it again: research showed the barrier was comprehension, which moved the work toward positioning and scenarios.
Illustration: a portal that mirrors the API's objects, versus one that walks an operator through the event.
Evidence
Three roles, and the product had been built for only one
Desk research showed symptoms but not causes, so we ran primary research: customer interviews, company user studies, rapid studies and Live Events studies. The output was a three-role model (video engineer, operator and producer), each with a different learning curve, and it showed the product had been designed for the most technical role only. One operator called the new flow "the closest of all the experiences" to what they needed. Later, a 7-person study comparing our prototype with competitors found people evaluate products scenario-first, not feature-first.
01
Three roles, one served. Video engineers, operators and producers each had a different learning curve, and the product had been built for engineers.
02
Operators had to know everything already. The portal assumed people knew what everything was and where it lived.
03
People evaluate scenario-first. Next to competitors, people judged products by whether they fit their scenario, not by feature lists.
In their words
"The closest of all the experiences."
Live event operator, on the new portal flow compared with what they'd tried
Key decision
Design for the operator, not the API
There were two ways to build the portal: mirror the API so engineers would see familiar objects, or resolve API terms into the operator's task, even where labels and structure departed from the API. I chose an operator-first portal because the people stuck at setup weren't programmers, accepting that portal language would no longer match the API and docs engineers knew. Engineers kept the API; the portal's job became bridging the gap for everyone else. The same call came back on Video Analyzer, where we recommended plainer language and ready-made templates rather than narrowing the audience to AI experts.
Second call
Plain status instead of thumbnails
Operators asked for larger output previews. Thumbnails weren't technically feasible, so the choice was to wait for them or invest in what we could ship. We invested in clear status and plain language instead, and designed several portal screens directly from the top support issues, such as a streaming endpoint that won't start or Video Indexer failing to connect, so error and recovery paths were designed rather than left to support. Operators got a dashboard that leads them through the event instead of assuming they know the system.
Illustration: mirror the API, or resolve it into the operator's task, for three roles.
Craft
Zone Drawer: where the model met AI
Spatial analysis only works if a person tells the model where to look, such as a danger zone near a crane or a line people shouldn't cross. I designed Zone Drawer so an operator can pause a frame, draw a line or polygon and tag it without touching the API, then view its coordinates or isolate one zone among many. I sized it for mobile web and worked through how it sits in the video player. When another Azure team adopting the widget asked for presets, drawing limits, a compact layout and edit-without-redraw, I answered each request, said plainly that editing had no engineering allocation, and split the work into a P0 design for development and a P1 proposal that took in the feedback.
Illustration: recovery screens designed from the top support issues.
System
Name things by the task, and design for the least expert person who must succeed
I applied that model across the Live Events workflow, a navigation and IA update for the whole portal, and Video Analyzer's widgets, including a zone-drawing tool that lets an operator mark areas for AI to watch without touching the API. I paired it with a way to check it: success measures per feature area, including Live Events created in the portal, support ticket volume and fewer "nomenclature" questions on the forum. I pushed for portal telemetry to be built into development cycles, and it was. Another Azure team began bringing the zone-drawing widget into its own portal.
Illustration: one model across three surfaces, and how we'd know it worked.
What shipped
What shipped
Live Events became a supported, operator-first workflow in the Azure portal: set up an event, connect an encoder, monitor ingest and deliver the stream without the API, a desktop tool or a support call. The portal's navigation and information architecture were rebuilt around customer tasks, and several screens were designed directly from the top support issues, so recovery paths existed before customers needed them. Portal telemetry was built into development cycles, giving the team a way to measure design instead of arguing about it. On Video Analyzer, Zone Drawer went to development handoff with a P0 design and a P1 proposal, and another Azure team began bringing the widget into its own portal.
Outcome
What changed
Live Events became an operator-first workflow in the Azure portal, replacing reliance on the API, a desktop tool and support calls for basic setup and monitoring, and the portal's navigation was rebuilt around customer tasks. Support satisfaction passed its 4.7 goal in August 2020, and we tracked it as a trend rather than a win. The research changed how planning talked about the product, from features to scenarios. It didn't change the market position: Microsoft retired Azure Media Services in June 2024. Design lowered the bar to entry; the business question it surfaced was bigger than the portal.
Reflection
Tie design to the business constraint from day one
My early measures were about engagement with portal surfaces, while the real constraint was external acquisition, and I got there later than I should have. I would also challenge solution-led goals like "build a marketing site" earlier, because the problem was comprehension, which no single artifact could fix. The principle I took away: design for the person who isn't yet an expert, and name the limits of design out loud.
Next up