Choose draft state when the main issue is an unpublished or inactive version lifecycle, such as resume, discard, compare, publish, or active-version visibility.
Choose draft state when the main issue is an unpublished or inactive version lifecycle, such as resume, discard, compare, publish, or active-version visibility.
Practice the judgment: Imagine this situation: A file sync app creates a conflict copy but hides it from the affected folder and owner. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Conflict state | Sync state | Draft state | Error state |
|---|---|---|---|---|
| UI or UX | UI + UX - Competing-version resolution state | UI + UX - Local-and-remote reconciliation status | UI + UX - Unpublished object version lifecycle | UI + UX - Recoverable failure surface |
| UI guidance | Show both competing versions near the affected object, field, paragraph, file, row, or branch with source labels such as Your edit, Server version, Mina's edit, Target branch, and Current published value. | Show sync state close to the object or queue it describes, using labels such as Local saved, Queued, Syncing, Synced, Partially synced, Failed, Paused, and Conflict needs review. | Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish actions. | Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions. |
| UX guidance | Preserve each version, explain why automatic merge was unsafe, guide users through the smallest conflicting unit, and make the post-resolution result reviewable before committing. | Use sync state to keep users confident while local changes, remote copies, attachments, messages, or records reconcile across devices, services, or background workers. | Use draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version. | Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI. |
| Good UI | A field report says Conflict on supervisor comment, shows Your offline edit from 11:06 beside Server edit by Mina at 11:07, and offers Keep mine, Keep server, and Merge comment. | A field report queue shows 5 local changes: notes synced, two photos uploading, meter reading queued, signature failed with Retry, and supervisor comment needs review. | A knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish. | A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. |
| Bad UI | A save banner says Something went wrong and only offers Retry after another user changed the same field. | A single green Saved badge appears while several attachments are still queued. | A draft label is missing from the editor, so users publish or discard the wrong version. | Tiny transient toast for a blocking failure. |
| Good UX | A user tries to sync an offline field report, reviews only the two changed fields, merges one comment, keeps the server contact number, and commits a resolved version. | A user reconnects after editing offline and sees the queue move from local saved to syncing, then to one failed photo with retry while the accepted notes remain synced. | A user opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers. | User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state. |
| Bad UX | The app silently keeps the newest server value and deletes the user's local note. | The offline banner disappears after reconnect, but hidden queued changes keep failing in the background. | A user discards a shared draft and unknowingly removes another editor's unpublished changes. | Clearing work after save failure. |
| Best fit | Concurrent users, devices, branches, or background jobs changed the same object or location. | Local changes, files, messages, uploads, or records need to reconcile with a remote service or another device. | Users need to pause and resume unfinished work across sessions, devices, or routes. | A system or task failure blocks expected content or action. |
| Avoid when | The user is managing an unpublished draft lifecycle rather than resolving competing edits. | A confirmed failure blocks the whole view and needs a full error recovery surface. | The change is a small one-field edit that should be saved or canceled immediately. | Nothing exists yet and the state is expected. |
| Required state | Conflict detected state naming affected object and source versions. | Queued state for work waiting for a sync attempt. | Published or active state with an available draft. | Normal expected state before failure. |
| Accessibility burden | Associate each conflict message with the affected field, row, line, paragraph, or file. | Expose sync summaries through polite status updates when state changes matter to the current task. | Use headings and status regions so screen reader users know whether they are editing a draft or viewing the active version. | Use appropriate alert or status semantics for newly appearing critical errors. |
| Common misuse | Treating a conflict as a simple retryable save error. | Calling local persistence Synced before remote acceptance. | Using Saved to mean both saved draft and published content. | Using a transient toast for critical errors. |