A cloud-save conflict screen should identify the affected player, compare the available saves with meaningful metadata, explain what each choice will replace, and offer only actions the current state can safely support. Retry should repeat a defined sync attempt without erasing context. Offline play should appear only when a usable local save exists and the game can track pending reconciliation. Cancellation should leave sync through an explicit, tested route rather than silently choosing a version or looping back into the same prompt.
Separate support disclosure from runtime conflict handling
Cloud-support disclosure answers whether the title offers the feature; runtime UI answers what should happen to this player’s data now. Nintendo says cloud-backup compatibility is title-specific, despite support across the vast majority of Switch and Switch 2 titles for eligible Nintendo Switch Online members. Compatibility is identified in Nintendo eShop and Nintendo.com product information. Treat that as a model for clear title-level disclosure: state support before purchase or installation, without expecting a launch-time conflict prompt to explain the product’s general feature policy. Keep exceptions, account requirements and platform scope in the product information where players can inspect them in advance.
At runtime, assume the player needs a decision, not marketing copy. Name the current problem, show relevant evidence, describe the consequence of each action and provide a safe way to leave.
Route every runtime state to one clear decision
Microsoft documents that Xbox and Windows can provide built-in Game Saves UI, while a platform such as Steam Deck requires title-implemented callback UI; registering callbacks on Xbox or Windows replaces the platform UI. A divergent conflict supplies local and remote descriptors, and resolution chooses one complete save rather than individual files or folders. Active-device contention may include device names, timestamps and save sizes. Retry can invoke the same callback again, while cancellation may finish without a usable save folder. UX ownership and terminal outcomes therefore need to be planned alongside integration work, with equivalent intent across platform-owned and title-owned presentations.
- Sync succeeds: continue automatically and avoid displaying a confirmation that asks the player to approve an already completed operation.
- Sync fails without a conflict: offer Retry, eligible Offline Play and Cancel; retain the error category for diagnostics.
- Another device appears active: identify it, explain that progress may still be changing, then offer Retry or Cancel.
- Local and remote saves diverge: present two equal version cards and require an explicit whole-save selection before replacement.
- Storage is insufficient: identify the affected location if known, offer an available storage-management route, then Retry or Cancel.
Prepare prompt data before polishing the copy
Create a prompt-data contract for every branch. If a value is missing, the layout and wording should degrade honestly rather than inventing certainty.
- Record the signed-in profile and platform account context without exposing unnecessary identifiers.
- Provide local and remote labels, device names, timestamps with time zones, and save sizes when available.
- Add a progress summary only when it comes from authoritative title metadata.
- Write the overwrite consequence beside each selection, not only inside a later confirmation.
- Define the destination of Retry, Offline Play, Cancel and any storage-management action.
Give Retry, Offline Play and Cancel different jobs
Retry means attempt the blocked operation again while preserving the prompt context. Offline Play means proceed from an identified local state while marking cloud reconciliation as pending. Cancel means stop this sync attempt and move to a documented terminal destination, such as the title screen. Do not use three differently named buttons that all reopen the same callback.
- Prevent endless retry loops by returning the refreshed result, changed state or same actionable error to the player.
- Hide Offline Play when no usable local save exists or when the title cannot safely preserve later reconciliation.
- After Cancel, clear transient UI and verify that downstream code does not assume a save is available.
Worked example: contention becomes divergence
Consider a suggested flow for a player moving from a handheld PC to a console. The first prompt reports that the handheld may still be active and offers Retry or Cancel. After the player closes the game there and retries, the service now reports two versions. The next screen shows a local console save and a remote handheld save with available device, time, size and title-authored progress details. Selecting one opens a final consequence statement naming the version that will be replaced. Choosing Cancel returns to the title screen; it does not silently select the newer-looking timestamp.
Use a cross-platform QA matrix built around outcomes
Run each case on every shipped UI-ownership path and record both the visible decision and the state delivered back to the game.
- Online success: begin with matching saves; expect automatic continuation, the intended save state and no unnecessary conflict prompt.
- Offline continuation: remove connectivity with a usable local save; expect clear offline status, preserved play and pending reconciliation.
- Retry loop: keep the failure unchanged, then alter it to success or divergence; expect refreshed UI and no stacked prompts.
- Terminal cancellation: cancel from failure, contention, divergence and storage branches; verify the destination, callback result and absence of save assumptions.
- Presentation parity: compare platform-owned and title-owned flows for action meaning, missing metadata, input focus, localization expansion and readable consequences.