Windows
Recovery
Point-in-time restore
I designed the end-to-end restore experience for Windows 11 point-in-time restore, from the recovery screen to Settings. It became generally available in June 2026.
My part
Designer: recovery entry point, restore flow, Settings page
Duration
Apr – Jun 2025
Crew
PM, engineering, design research, content
Ships on
Windows 11
Context & role
Point-in-time restore rolls a Windows PC back to a snapshot from the last 72 hours, with apps, settings and files intact, in minutes instead of a re-image. It was part of the Windows Resiliency Initiative and serves Home, Pro and Enterprise devices, with IT admins as the main customer. From April to June 2025 I was the designer, working with a PM, the engineer who built the recovery-environment UI, feature-team partners, a design researcher and a content designer. I owned the recovery-environment entry point, the restore flow and the Settings page; PM owned requirements and research, engineering owned the snapshot technology, and the team carried my designs to launch after I handed off.
Stakes
Re-imaging was the default fix for a PC in a critical state, taking one to two and a half hours, and admins chose it because they knew it worked. Windows already had System Restore, but it was off by default and widely seen as unreliable; as one admin put it, "when we need them, we do not have them." A rollback that fails after an hour is worse than re-imaging from the start, so trust was the product.
Reframe
Asked: design the rollback UI. Reframed: make a risky action honest.
I treated the brief as a trust problem. The experience had to make a destructive action predictable, help people pick the right restore point, say plainly what would be lost and what wasn't available, and do all of it inside the recovery environment, a legacy framework with few components and no scrolling. The question stopped being "what should the screens look like" and became "what does a person need to know before they bet their PC on this?"
Illustration: a dropdown and a Restore button, versus a paged choice that says what you'll lose.
Evidence
Every step answers a concern from the research
Before I joined, the PM ran interviews with IT admins and a survey. I didn't run this research; I designed against it. Restore success was the top priority, and the top concerns were snapshot storage, unreliable restore points, losing local data and accidental rollbacks. I tied each step of the flow to one of them: choosing a restore point answers rolling back too far, the warning answers data loss, and the final confirmation answers accidental rollbacks. The designs then went through review with PM and engineering partners.
01
Reliability beats features. A high restore success rate was admins' top priority, ahead of anything the interface could add.
02
Storage was the top worry. Admins feared snapshots eating disk space most, followed by unreliable restore points and losing local data.
03
Accidents are a real risk. Rolling back a whole PC needs one deliberate, final confirmation, not a single click.
In their words
"We know it works so it is usually faster."
IT admin, on why they re-image a broken PC instead of restoring it
Key decision
Show the safety net's gaps instead of hiding them
When a PC has no room for a snapshot, the options were to switch the feature off silently, send system notifications, or warn in place. We chose an in-place warning on the Settings page, because a safety net that silently switches itself off leaves people unsure whether they're covered, accepting that most people will never open that page. One call was clearly mine: for the storage limit I argued that a slider confuses people, and proposed plain levels (low, medium, high, custom), accepting coarser control. After I handed off, the team shipped a slider, and that's the lesson in the reflection below.
Second call
Keep unusable snapshots visible, marked with the reason
Some snapshots exist but can't be used, for example one taken before a security policy was applied. Partners asked whether they should simply be deleted: if it isn't usable, why show it? The PM argued to keep them in the list, marked unusable with a reason, so people could see the capture had worked and wouldn't wonder where an expected restore point had gone. I designed that state into the final designs. It applies the same principle as the storage warning: a safety net earns trust by showing its gaps, not hiding them.
Illustration: what to do when there's no room for a snapshot.
Craft
Each way a restore can go wrong gets its own screen
Beyond the happy path, the final designs covered a progress screen (a spinner, since an accurate progress bar wasn't guaranteed), a success confirmation before returning to Windows, the feature on with no space for a single snapshot, a restore that fails, a restore interrupted by power loss or a reboot, and a snapshot marked unusable. Reviewers flagged that "consent" read as Microsoft doing something to your PC, so the step became a warning the person acknowledges. Every failure the team could name got a plain-language screen instead of an error code.
Illustration: each way a restore can go wrong gets its own plain-language screen.
System
One decision order and one vocabulary across two environments
The model behind the screens is three decisions in a fixed order: choose a restore point, understand the cost, confirm. Because the recovery environment can't scroll, I replaced the restore-point dropdown with a paged table, so every restore point shows its exact date and time. The recovery screens and Settings share labels, descriptions and verbs, each with its own native controls, so a person sees the same words whether their PC boots or not.
Illustration: one decision order and one vocabulary, whether the PC boots or not.
What shipped
What shipped
Point-in-time restore reached Windows Insiders in November 2025 and became generally available in June 2026 in consumer and commercial editions of Windows 11. The shipped flow follows the design's structure: pick a restore point in the recovery environment, acknowledge the risk, review the choice and the data-loss warning, then restore. Settings shows current restore points by timestamp and the disk space they use, which speaks directly to storage, the top concern in the research. The team carried my designs to launch after I handed off in June 2025, and I was credited for design and research in the preview and GA announcements. One call didn't hold: the shipped storage control is a precise slider rather than the plain levels I proposed.
Outcome
What changed
Point-in-time restore reached Windows Insiders in November 2025 and became generally available in Windows 11 in June 2026, following the design's structure: pick a restore point, acknowledge the risk, review the data-loss warning, then restore. Settings shows restore points by timestamp and the space they use, answering storage, the top concern in the research. Each failure the team could name has its own screen in plain language: no space, a failed restore, a restore interrupted by power loss, and an unusable snapshot. There isn't yet a number that shows what the design itself changed.
Reflection
Bring evidence to the calls you care about
I joined after the research and left before the preview, so I saw neither the interviews nor the first real restores. Next time I'd push design into discovery, prototype inside the recovery environment's real limits in week one, and stay through the first release. The storage slider is the clearest lesson: I argued from conviction, not data, and once I handed off, the team defaulted to the precise control. The principle I took away: a safety net earns trust by being honest about its gaps, and a design call earns its place with evidence.
