Draft state

Problem Context

• The product supports creating or editing content, records, rules, pages, policies, listings, workflows, or business objects before they become active.
• Users may pause work, close the editor, follow deep links, return from a dashboard, or collaborate on unpublished changes.
• The draft can differ from a live version that remains visible to viewers, customers, systems, or downstream workflows.
• Discard, delete, publish, or activate can affect collaborators, public visibility, search visibility, locks, or business state.

Selection Rules

• Choose draft state when a recoverable unpublished version exists separately from a published, active, or previously saved version.
• Use autosave form when the main need is reliable background persistence while a user is filling fields, not a separate draft lifecycle.
• Use inline edit when one local value enters edit mode and is saved or canceled immediately without durable unpublished-version management.
• Use complete complex form when many related fields need section ownership, validation, and review; add draft state only if the whole configuration has a separate inactive version.
• Use multi-step form when the work is primarily a sequence of pages with Back, Continue, saved step state, and final review.
• Show whether the current view is draft, published, active, locked, or unavailable before users edit or publish.
• When opening an active object that has a draft, ask users to resume the draft or discard it before silently showing either version.
• Keep Publish, Activate, Submit, or Send visually and semantically distinct from Save draft.
• Before discard, identify whether the draft is personal, shared, includes other contributors, or differs from the active version.
• For draft lists, expose filters or labels for own drafts, shared unpublished changes, locked records, active records, and deleted or unavailable draft links when relevant.

Required States

• Published or active state with no draft.
• Published or active state with an available draft.
• Draft editor state with draft label and last-saved time.
• Unpublished changes state for an already-published object.
• Resume draft confirmation state when an active object has a draft.
• Compare draft with published state before publish or discard.
• Discard draft confirmation with scope of loss.
• Published or activated state after draft promotion.
• Locked or another-user draft state.
• Unavailable draft state for deleted, published, inaccessible, or stale deep-linked drafts.

Interaction Contract

• Opening a draft from a list lands in draft edit mode and preserves the unpublished values.
• Opening a published object with an existing draft prompts Resume or Discard with object name and last-saved time.
• Resume shows the latest draft, not the active version, and labels it as draft throughout editing.
• View published or Compare shows what viewers currently see versus what the draft will change.
• Save draft keeps the item unpublished and recoverable without implying viewer visibility.
• Publish or Activate promotes the draft to the active version and updates visibility or downstream effects.
• Discard removes only the stated draft scope and returns users to the active version or draft list.
• Stale draft links explain why the draft is unavailable and offer a path to the active object or list.

Implementation Checklist

• Model active, draft, unpublished-changes, locked, unavailable, and published states separately instead of deriving them from a generic dirty flag.
• Store draft owner, collaborators, last-saved timestamp, source active version, and publish readiness.
• Add labels and filters wherever drafts appear: dashboards, object lists, editor headers, breadcrumbs, recent-work surfaces, and deep-link recovery pages.
• Separate Save draft from Publish, Activate, Submit, or Send in copy, placement, disabled logic, analytics, and permissions.
• Provide Resume, View published, Compare, Discard, and Publish actions only when each action is valid for the current state.
• Warn before discard or delete when the draft is shared, has collaborators, or contains unpublished changes by others.
• Handle missing drafts, stale bookmarks, deleted drafts, published drafts, permission loss, session expiry, locks, and another user's draft.
• Test draft discovery, resume, publish, discard, reload, deep links, permissions, collaboration, mobile return, screen reader labels, and keyboard access.

Common Generated-UI Mistakes

• Using Saved to mean both saved draft and published content.
• Opening the draft silently when users expected to view the active version.
• Hiding draft labels in lists so users cannot find unpublished work later.
• Making Publish and Save draft adjacent buttons with identical visual weight and vague labels.
• Discarding shared unpublished changes without collaborator scope warnings.
• Treating a draft as merely a form dirty state even though it survives navigation and appears in object lists.
• Failing to explain why a bookmarked draft is gone after publish, discard, deletion, or permission change.

Critique Questions

• Can users tell whether they are viewing draft, published, active, locked, or unavailable content?
• Where can users find drafts after closing the editor?
• Does Save draft clearly differ from Publish or Activate?
• What exactly is lost when the user discards this draft?
• Can users compare the draft with the active version before publishing or discarding?
• What happens to collaborators' unpublished changes, locks, and stale draft links?