Use draft state when an object or content item has a recoverable unpublished version that must be resumed, compared, discarded, or published separately from the active version.
Use draft state when an object or content item has a recoverable unpublished version that must be resumed, compared, discarded, or published separately from the active version.
Practice the judgment: Imagine this situation: A draft is labeled Saved, so users assume viewers can see it even though it remains unpublished. 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 | Draft state | Autosave form | Inline edit | Complete complex form |
|---|---|---|---|---|
| UI or UX | UI + UX - Unpublished object version lifecycle | UI + UX - Background-saving form progress | UI + UX - In-place value or row editing | UI + UX - Sectioned enterprise configuration form |
| UI guidance | 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 clear autosave message before users start, then keep a persistent status surface for Pending, Saving, Saved with timestamp, Failed, Retry, and unsafe-to-leave states. | Render a read-state value with a visible edit affordance, then replace only that value, cell, or row with the appropriate input and adjacent Save and Cancel controls when edit mode starts. | Render one coherent form surface with a clear title, section navigation or section headings, current section state, grouped controls, persistent labels, helper text, required indicators, error summary, field-level errors, review or summary state, and one save contract. |
| UX guidance | 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. | Use autosave when losing progress would hurt and background persistence is safer than making users hunt for a distant Save button. | Use inline edit when users need to make frequent, low-impact changes to one visible property while preserving surrounding list, table, or record context. | Use a complete complex form when users must edit many related product settings together and need to inspect dependencies across sections before saving. |
| Good UI | 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 long application step says the application is saved on every change, shows Saving after an edited title blurs, then shows Draft saved just now with a timestamp. | A resource table shows an edit icon beside the owner cell; activating it turns that cell into a text field with Save and Cancel buttons while other cells remain read-only. | A policy configuration form has Basics, Rules, Approvals, Notifications, and Review sections; Approvals shows an error because the threshold in Rules requires at least two approvers. |
| Bad UI | A draft label is missing from the editor, so users publish or discard the wrong version. | A green Saved toast appears after one field saves, while another changed field is still pending or failed. | The edit affordance appears only on pointer hover and is unreachable by keyboard or touch. | A long settings page saves invalid combinations because validation checks each field in isolation and ignores dependencies between threshold, approvers, and escalation owner. |
| Good UX | 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. | A user writes a long answer, pauses, sees Saving, then sees Draft saved just now and can leave knowing the draft is recoverable. | A user clicks Edit owner, changes the value, sees Save become enabled, enters an invalid short value, fixes it beside the field, saves, and stays on the same row. | A user jumps from Review back to Rules, changes a dependency, and sees Review marked stale until the affected sections pass validation again. |
| Bad UX | A user discards a shared draft and unknowingly removes another editor's unpublished changes. | A password or permission field autosaves immediately and takes effect before the user reviewed the consequence. | A user edits a sorted table cell and the row immediately jumps to a different page before the saved value can be confirmed. | A user clicks Save, sees three generic errors somewhere in the page, and must scan many controls to discover which section owns each problem. |
| Best fit | Users need to pause and resume unfinished work across sessions, devices, or routes. | Users spend meaningful time entering form content or application progress. | Users frequently update one visible value or one row property. | A product configuration has many related fields across named sections. |
| Avoid when | The change is a small one-field edit that should be saved or canceled immediately. | The form is short enough that a visible manual Save or Submit is clearer. | The edit affects multiple dependent fields or needs a review step. | The form is a short related set of fields that fits a simple single-page form. |
| Required state | Published or active state with an available draft. | Initial state that explains progress will be saved automatically. | Read state with displayed value and discoverable edit affordance. | Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation. |
| Accessibility burden | Use headings and status regions so screen reader users know whether they are editing a draft or viewing the active version. | Expose autosave status changes in a polite status region so assistive technology users hear Saving, Saved, and Failed states. | Give edit, save, cancel, confirm, and dismiss controls accessible names, especially when icons are used. | Use semantic headings, fieldsets, legends, and persistent labels so each section and field group has a programmatic name. |
| Common misuse | Using Saved to mean both saved draft and published content. | Showing Saved when only an older change was saved. | Using inline edit for high-impact changes that need a review or confirmation step. | Splitting tightly related settings across pages so dependencies are invisible during editing. |