Update journey

Context

IT admins update many devices at once. Each update follows a path: the server makes it available, the device downloads and installs it, it takes effect after a restart, and the device reports its status. Problems can occur at any step, and each may need a different fix.

Problem

Update failures were hard to diagnose.

Existing reports reduced update progress to a few status counts. They didn't help IT admins understand where devices stalled, what caused the stall, or what action to take.

Approach

• Understand the users: Learn their mental models and jobs to be done.
• Understand the data: Map its complexity and constraints.
• Identify the gap: Find what's missing or not working in the current experience.
• Design the information model: Choose a visualization that turns data into actionable insights.

Understand the users

Conversations with IT admins revealed a shared mental model: start with overall update progress, then narrow down to where devices stall or fail, and investigate why.

Their jobs to be done were to:

• track progress across stages,
• identify what needs attention,
• act on affected devices,
• and compare deployments.

Understand the data

Telemetry was split across service status, client status, and final outcome, and availability varied by stage. I worked with Engineering to understand the data.

• The complexity: The underlying update state model with all the states and transitions.
• The constraints: Which telemetry was available and when.

Identify the gap

The existing report showed fleet-wide and individual-device data, but not how issues developed between them. Without that context, IT admins struggled to identify root causes and take action.

To address this, we needed to answer three questions: Where did the issue occur? When did it happen? What should IT admins do next?

• Where: Deeper analysis required more granular data. IT admins needed progressively more detailed views to pinpoint where issues occurred.
• When: Time was missing from the flow. We needed a way to show how updates progressed over time, not just the final status.
• What's next: The report should provide actionable insights. Actions needed to be taken at the right level and in the right scope.

Design the information model

Chose the right visualization: the Sankey diagram

I compared visualizations to find one that showed sequence and attrition while remaining readable as device counts changed.

I fixed the chart's total height so attrition was visible and every device remained accounted for.

Addressed concerns

Feedback surfaced several concerns about the Sankey diagram. I addressed them with the following design choices.

Concern	Solution
Unfamiliar to many IT admins	Put a plain-language summary above the chart
Screen readers cannot read it	Provide an equivalent, navigable data-table view
Thin branches become unclickable	Enforce minimum targets and group smaller branches under "Other"
Too many stages can make the chart hard to read	Show actionable stages by default and move substates down one level
Color alone cannot carry meaning	Pair every color with an icon and label

Designed a new information model

I designed a four-level information model around IT admins' shared mental model: fleet → update ring or policy → device group → device.

Each level adds detail, and selecting a flow segment opens a filtered, exportable device list. It supports their jobs to track progress, find where updates stall, compare deployments, and take action.

Tested different explorations

I turned the reporting gap I had identified into a hackathon project. For the hackathon, I tested three ways to represent the available telemetry.

Windows Update Journey

The key shift: from “what?” to “where?”, “why?”, and “what's next?”

From hackathon to shipped

Turned a POC into a roadmap priority

The proof of concept from the hackathon gained traction and was promoted onto the product roadmap with priority.

The core model carried through to the shipped design: one visualization that narrows from fleet to ring to device while retaining consistent stages, colors, and icons.

Designed around data constraints

The MVP could not join service status, client status, and final result. I split the continuous concept into three stage views, each based on available telemetry. This trade-off made it possible to ship within the available telemetry. Joining the data remained a follow-up opportunity.

The stage selector redraws the chart with fewer columns while keeping the same starting point and stage labels:

Created a fleet-to-device path

The shipped flow narrows across four increasingly granular levels, taking IT admins from a view of the entire fleet to the timeline of a single device:

Outcome

What began as my hackathon initiative gained traction across the organization, became a prioritized feature that was presented at Microsoft Ignite 2025. Its reception validated both the problem I identified and the unfamiliar visualization I proposed to solve it.

In March 2026, Quality Update Journey reached general availability as one of the four pillars of Windows Autopatch update readiness, providing end-to-end, per-device visibility into where an update is and what is blocking it.

• End-to-end visibility into each device's update journey
• Clear, granular phases showing what completed, where a device is paused, and where issues occur
• Trustworthy timelines with timestamps, state transitions, and mapped alerts.
• Faster troubleshooting by spotting patterns and problem areas across devices.

📢 Read Microsoft's announcement: Windows Autopatch update readiness brings insights to IT