| UI or UX | UI + UX - Guided workflow for reviewing and committing conflict decisions | UI + UX - Competing-version resolution state | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Recovery surface for failed or uncertain background saves |
| UI guidance | Show a durable resolution workspace that lists every unresolved conflict, exposes the current conflict, names each version source, and separates choose-local, choose-remote, merge, save-copy, skip, and commit actions. | 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. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. | Show a persistent recovery surface when autosave did not protect the latest work, naming the affected field or section, last server-saved time, local copy status, and available recovery actions. |
| UX guidance | Use conflict resolution after conflict detection when users must make one or more explicit decisions before a record, document, branch, import, or synced object can continue. | Use conflict state when multiple valid changes overlap and the system needs a human, rule, or review workflow to decide what survives without losing work silently. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. | Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy. |
| Good UI | A field report resolver shows 2 of 3 conflicts remaining, displays Your offline value and Mina's server value for the current field, offers Keep local, Keep server, Merge both, Save copy, and shows a reviewed result before Commit resolutions. | 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 claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. | A claim form says Household income answer failed to autosave at 10:42, keeps the typed answer visible, and offers Retry save, Copy answer, Restore last saved, and Continue after saved. |
| Bad UI | A conflict page has one Accept recommended button for all fields and no way to inspect discarded values. | A save banner says Something went wrong and only offers Retry after another user changed the same field. | A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links. | A small toast says Could not save and disappears while the form still shows a green Saved label. |
| Good UX | A user resolves the supervisor comment by merging both versions, keeps the server contact number, saves the local safety note as a copy, reviews the final report, then commits with an audit summary. | 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 changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. | A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates. |
| Bad UX | The system silently resolves all conflicts by newest timestamp and only shows a success toast. | The app silently keeps the newest server value and deletes the user's local note. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | A user submits after seeing Saved, but the newest section was failed and never reached the server. |
| Best fit | A conflict has been detected and a user must choose, merge, save-copy, skip, or commit a result. | Concurrent users, devices, branches, or background jobs changed the same object or location. | A user has provided multiple answers and should verify them before a consequential submit action. | Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work. |
| Avoid when | The system can safely merge non-overlapping changes without user judgment. | Only one operation failed and there is no competing valid version. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The product does not use autosave or local draft persistence. |
| Required state | Conflict list state with unresolved count and current conflict position. | No conflict state after automatic safe merge. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Clean saved state with current server timestamp. |
| Accessibility burden | Expose conflict number, total count, source labels, field names, and resolution status as text, not only color or diff markers. | Use headings and text labels to name each side of the conflict; do not rely only on red/green diff colors. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Announce failed, local-only, retrying, recovered, and conflict states through status text without repeating every save attempt. |
| Common misuse | Marking conflicts resolved before the user reviews the surviving value. | Treating a conflict as a simple retryable save error. | Using a review page that contains no captured answers. | Leaving a green Saved label visible after a failed or stale autosave. |