Auto-save and manual save need distinct UI identity

What it is

Auto-save (system-triggered at events) and manual save (player-chosen timing and location) mean different things to players: a manual save is a controllable safety point ("I can return here any time"), an auto-save is a system-controlled snapshot ("it happens when the system decides"). Distinct save UI identity—icons, animations, slots, loadability—lets players know which save is a trustworthy fallback and which is merely the system's record. Confusing the two collapses trust in the whole save system: believing you manually saved only to find the auto-save overwrote it destroys the foundation of security.

Why it happens

Distinct identity works because it maps onto players' different mental models of the two save types. Manual saves carry the expectation "this snapshot is my chosen moment, and I control when it gets overwritten" (dedicated slot, naming ability, overwrite protection); auto-saves carry "this is the system's progress record—it fires at key moments but I don't control it." Separate UI treatment (spinning icon and dedicated slot for auto-save, fixed icon and nameable slot for manual) gives each model its home. The failure mode of confusion is concrete: a player manually saves before a boss, an auto-save later overwrites the same slot, and loading after defeat returns them hours back—betrayed safety expectations hurt more than having no save function at all. The load screen's clarity (which slots are manual, which auto, clear timestamps) is part of the identity system too.

Where it stops holding

Not every game needs two save types. Roguelike and roguelite designs deliberately delete manual saves' controllability (death ends the run, no return to the past)—only auto progress records exist there, and the distinction question disappears. Identity complexity must match the save system's real functions: one save type with two identity treatments confuses; two save types with identical behaviour (manual saves get overwritten too) means the identity distinction is a lie—the promised behaviour must exist in the system. Cloud and local saves add another dimension (which slot is cloud, which local, sync status) that the identity system must extend without confusing. Display timing also matters: auto-save completion indicators should appear after the write confirms, not when it starts—an interrupted auto-save that showed a completion indicator manufactures false security.

Applying it

• Give the two save types distinct visual identity and slot zones: manual saves nameable, overwrite-protected, pinned in the load list; auto-saves in their own slots labelled with the trigger event ("before boss," "chapter complete").
• Show auto-save completion only after the write confirms, stating save time and trigger scene, and group the two types clearly in the load screen.
• Verification: have testers manually save before a boss, play until an auto-save triggers, then check the load screen—players should accurately identify "which is my manual save." Misidentification means the identity distinction is insufficient.

Related

• Same group: W5.06.1 Pause must truly freeze game state, not just hide the screen · W5.06.2 Save-point predictability shapes risk-taking · W5.06.4 Deep menu hierarchies make common settings expensive
• Nearby: I1.03 Pausing and interruption recovery · R1.02 Storage and data management · W5.06 Menus, pausing, and saving
• Search terms: auto save · save slot · save system design · checkpoint indicator