Microsoft · Windows Autopatch

Update journey

Stage by stage, device by device.

I identified a gap in update reporting: a 94% success rate did not show where the other 6% stalled. I designed a flow visualization to address the issue, making multi-dimensional update data easy to understand at a glance, with 4-level drill-down from the entire fleet to a single device timeline and actions at each level. It started as a hackathon concept, was promoted to a roadmap priority, and was announced at Microsoft Ignite 2025 and shipped in 2026.

The state point in time section of the update journey report. A date picker labeled select a date sits beside a Generate button, above a strip of stage counts - not started 1000, server stage 1500, client stage 3500, installed 1000, no telemetry 2000, not installed 500 and canceled 1000 - each marked with a colored rule. Below, a radio group headed view devices by stage they have reached offers server stage, client stage and process completed, with process completed selected. A flow diagram then carries devices left to right through four columns: not started, holding policy approved at 4000; server stage, splitting into scheduled at 3500 and on hold at 500; client stage, splitting into downloading or installing at 3500 and on hold at 500; and completed, ending in four color-coded bars - installed at 2000 in green, no signal at 500 in orange, not installed at 500 in red, and canceled at 1000 in gray, reached by a ribbon that leaves the first column directly.
Attrition becomes visible, and every branch opens the devices behind it.
Role
Lead / solo designer - concept through shipped experience
Platform
Microsoft Intune admin center
Focus
Data visualization · Update reporting
Milestones
Ignite 2025 · GA 2026
Public reference
Microsoft announcement

Problem

Existing reports reduced updates to status counts: up to date, not up to date, or error. They didn't answer important questions such as:

  • At which deployment stage did issues occur?
  • When and why did a device stall?
  • What actions can be taken to resolve the issues?

An update is a pipeline: offer, download, install, restart, confirm.
Each stage fails for a different reason and requires a different fix.

Telemetry was split across service status, client status, and the final result, with no joined device journey. With Engineering, we defined constraints that I could construct a design around.

A redrawn state model in two panels. A row of three phase labels runs across the top: request received by service, upgrade in progress, and upgrade result. Below, a panel headed service side, UCServiceUpdateStatus, groups ten states - pending, holding validated and scheduled; offering, holding offer ready and offer received; on hold, holding admin paused, service paused and safeguard hold; and canceled, holding admin canceled, removed from deployment and service canceled. A gray arrow crosses a gap to a second panel headed client side, UCClientUpdateStatus, which groups eighteen more - installing, running download start, download complete, install start, install complete, restart required and restart complete; on hold, holding paused and safeguard hold; canceled, holding user canceled; uninstalling, holding uninstall, restart required, restart initiated, restart complete and rollback; and the terminal groups installed, uninstalled and unknown. A timeline showing when each state becomes knowable. A date axis is marked with three deployment milestones - groups A, B and C targeted, the expected start date, and the target completion date - and divided into four phases: policy created, request received by service, upgrade in progress, and upgrade result. Beneath each phase sit the states the telemetry can report there. Policy created gives total devices. Request received gives scheduled and offer ready, plus invalid devices. Upgrade in progress gives download start, downloaded and installing, plus no client telemetry, no Windows Update connection and no scan after deferral days. Upgrade result gives installed and not installed. The four states drawn with a dashed amber outline are keyed in a legend as arriving on a 24 to 36 hour lag, or not at all.

The two models I had to reconcile, redrawn from the published Windows Update for Business reports schema.

  • State model: 28 unjoined service and client states, including duplicate on-hold and canceled branches.
  • Availability map: states plotted by when they become knowable. Amber states arrive on a 24-36 hour lag, or not at all.

Approach

Defined jobs to be done

  • "Show me how update status is distributed across pipeline stages."
  • "Tell me where devices are falling out, and why."
  • "Take me to the updated rings/policies so I can act."
  • "Take me to the devices so I can act."
  • "Compare this deployment to previous ones."

Found three gaps in the existing experience

1. Deeper analysis required more granular data

The existing report stopped at the fleet level, making it difficult to understand what was driving an issue. I introduced a three-level information model that let admins move from fleet → update ring → device, with progressively more detailed data at each level:

The existing update report stopped at the fleet level, making it difficult to understand what was driving an issue.

I introduced a four-level information model that let admins move from fleet → policy (deployment ring) → device group by status → individual device, with progressively more detailed data at each level:

Four connected panels show the same update flow re-scoped from the full fleet, to one deployment ring, to a group of devices, and to one single device. Each level keeps the same stage names, colors and visual structure while answering a narrower question.

2. Status messages needed to drive action

Existing experience showed unclear error codes, which users must look up in external sources to figure out.

With Engineering and Content Design, I replaced the error codes with three-part status messages that tell admins what happened, why it happened, and what to do next:

Before and after panels. Before: a card reading

3. Time was missing from the flow

We still needed a way to show how updates progressed over time as the existing reports only showed status.

To trace the flow of an update and pinpoint where it stalled, I iterated through visualizations to find one to visualize sequence, show attrition, and remain readable as the number of devices changes.

I compared candidates and chose a sankey diagram as the best option:

A comparison grid titled Why sankey, scoring four chart types - stacked bar, funnel chart, flow or Sankey, and state table - against five criteria, with each cell marked pass, partial or fail. Preserves the denominator: fail, partial, pass, pass. Shows attrition as a shape: fail, partial, fail, pass. Matches the admin's mental model: fail, partial, fail, pass. Scales across fleet sizes: partial, partial, pass, pass. Familiar to most admins: pass, pass, pass, fail. The flow or Sankey column is outlined in blue, passing every criterion except familiarity.

Designed the visualization for clarity and actionability

Addressed known risks

I considered many risks and through feedback identified some of the common ones. Below is a table of these concerns and their solutions.

Concern Solution
Unfamiliar to many 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 becomes spaghetti Show actionable stages by default and move substates down one level
Color alone cannot carry meaning Pair every color with an icon and label

Made the visualization complete, comparable, and actionable

To show the missing attrition, I fixed the total width, leaving no device unaccounted for.

To allow IT admins to compare [the thing to be compared, product], comparison can be done to a user-selected baseline.

Three properties of the chart became non-negotiable:

  • Constant total width: no device unaccounted for, including an explicit node for machines without a policy.
  • Comparison by default: how whether a 6% failure rate is improving or worsening.
  • Every node is a doorway: clicking any part of the flow produces a filtered, exportable device list.

Made the table a peer view, not a fallback

The sortable, exportable table remained a peer view, not a fallback. It presents the same data in stage order for screen-reader users and admins who prefer tables.

Two panels side by side. On the left, headed data visualized, a small flow diagram with the note that it reads as a shape and is fastest for pattern recognition. On the right, outlined in blue and headed equivalent data table, a five-row table with columns for stage, devices, percent and change: offered 88,412 at 100%; downloaded 77,802 at 88%, change minus 12%; installed 68,961 at 78%, change minus 10%; restarted 61,888 at 70%, change minus 8%; up to date 61,888 at 70%. Beneath it, the table is described as fully navigable, sortable, exportable and announced in order.
In tests with 30+ IT admins, almost all preferred the visualization as the primary view.

Tested different explorations

I turned the reporting gap I had identified into a hackathon project. I tested three explorations to make the idea tangible before scope and telemetry constraints narrowed thedesign.

A single continuous flow diagram covering every stage at once, drawn on a large working canvas. Total devices at ten thousand splits into scheduled at eight thousand, service on hold at one thousand and canceled at one thousand; the scheduled band then splits into download or install at five thousand, client on hold, no telemetry and device invalid at one thousand each; those resolve into installed at four thousand, no telemetry at one thousand and not installed at four thousand, the last carrying a red list of reasons. A flat fan-out. A single node, all devices at ten thousand, spreads in one hop to eight end states, banded on the right by the system that reports each one: deployment service holding scheduled and service on hold; client device holding download or install, client on hold and device invalid; and update result holding no telemetry, installed and not installed. Canceled at two thousand branches away low and separate. A four-column pipeline with saturated color at every stage - teal, pale blue, periwinkle, then green, orange and red. Policy created at ten thousand feeds scheduled, service on hold and canceled; those feed download or install, client on hold and device invalid; those end in installed marked with a green tick, no telemetry with an orange warning triangle and not installed with a red cross.

Three explorations:

  • Continuous flow (clear, but implied joins the telemetry could not support)
  • Fan-out by reporter (accurate to the data source, but lost sequence)
  • Staged pipeline (closest to the shipped structure; reserving color for the final column clarified outcomes)

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.

Its core model survived: one visualization that narrows from fleet to ring to device while keeping the same 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. I would make that trade-off again to ship, then prioritize joining the data.

The stage selector redraws the chart with fewer columns while keeping its anchor and stage names fixed. Each view answers a distinct question without looking like a different chart:

The stage selector set to server stage. A two-column flow: not started, holding policy approved at 1500, feeds server stage, which splits into scheduled at 1000 and on hold at 500. The server-stage bars are blue; the not-started bar is gray. The stage selector set to client stage. A three-column flow: not started, holding policy approved at 3500, feeds server stage, holding scheduled at 3500, which splits into three client-stage bars - downloading or installing at 2500, on hold at 500, and device invalid at 500. The client-stage bars are indigo; the earlier columns are gray. The stage selector set to process completed. A four-column flow: not started, holding policy approved at 4000, feeds server stage as scheduled at 3500 and on hold at 500, then client stage as downloading or installing at 3500 and on hold at 500, ending in completed - installed at 2000 in green, no signal at 500 in orange, not installed at 500 in red, and canceled at 1000 in gray, reached by a ribbon that leaves the first column directly.

One chart, three depths:

  • Server stage (whether the service handed out the update)
  • Client (where a device first fails rather than waits)
  • Process completed (the full pipeline, with color reserved for outcomes)

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:

The Summary tab for Windows quality updates. A multi-line trend chart plots number of devices over a thirty-day range, toggleable between percentage and device count. Beneath it, headline counts for up to date, in progress, not up to date, not ready and total device count. Below those, a table of policies - Marketing, VIP Devices, Finance, IT department, Windows Autopatch expanded to show its Test, First, Fast and Broad rings, and Test devices - each row carrying device count, up to date, in progress, not up to date, not ready, approved releases, and an update journey column whose cells are View links.
Level 1 - Fleet: the summary tab shows the overall trend and per-policy counts, with a View link to the journey for each policy.
The Quality update journey report, filtered to one target release and one policy, with OS version left at all. A status breakdown strip runs across the top with counts for request received by service, device upgrade in progress, update failed, update successful, no telemetry, canceled, and total devices. Below it, a state trending stacked area chart plots those states across six months, with a hover tooltip listing each state's device count and percentage. Below that, a state point in time section with per-stage counts, and a flow diagram carrying devices left to right through not started, server stage and client stage to completed, branching into installed, no telemetry, not installed and canceled, with intermediate service on hold and client on hold branches.
Level 2 - Policy (deployment ring): trends show whether the rollout is moving; the flow shows where it stopped.
The Device status report for quality updates, filtered by two chips reading client state failed and policy Marketing. A strip of headline counts runs above the table - up to date, in progress, not up to date, paused, not ready and total device count. Beneath it a long device list carries columns for device name, update status, installed release, target release, target release available, Autopatch group, deployment ring policy, quality update policy, OS version, readiness, alerts, and an update timeline column of View links. Every row reads not up to date, the ring policy column names individual Autopatch and Finance rings, and readiness is a mix of ready and not ready.
Level 3 - Device group by status: selecting a branch opens its filtered device list by status.
The update timeline for a single device. A device details panel lists device name, primary user, management name, ownership, compliance, serial number, operating system, device model, manufacturer and last check-in time. Beneath it, a horizontal timeline runs along a date axis from the tenth to the sixteenth of February, from a release marker to an installed marker, with event dots along it. Three open cards describe events: a warning that available storage dropped below 500 MB, a cleared temporary files event that freed 1.2 GB, and a download complete event. Below, a table lists each event with start time, end time and a status of completed, scheduled, in progress or warning.
Level 4 - Individual device timeline: every event and state transition with timestamps.

Outcome

What began as my hackathon initiative gained traction across the organization, became a priortized 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 in 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.

"The award for the best screen in Intune goes to this page."

Lewis Barry · Microsoft MVP, Principal Security Architect

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