A content editor can look simple while leaving its users unsure whether a change was saved or made public. Define the states before choosing a frontend pattern or library.
## Separate the user's draft from the stored value
Treat the text being typed as an unsaved draft until the save operation succeeds. Keep the last confirmed value available for comparison and recovery. Do not show “Saved” merely because the user clicked a button.
When a save fails, preserve the draft so the user can retry or copy it. Explain what happened in ordinary language without exposing server details.
## Make publication a distinct concept
Some systems publish on save; others have separate draft and publication steps. Either model can work if the interface explains it accurately.
Label the action by its actual effect. If saving changes the public page, say so before the user acts. If saving only updates a draft, show how to publish and who is allowed to do it. Never display a publication success state based only on a local change.
## Plan for delayed and repeated requests
A person may click twice, navigate away or lose connectivity. Decide how the interface behaves during an in-flight operation and how the server prevents duplicate actions.
Disabling a button can reduce accidental clicks, but it is not a substitute for server-side authorization or safe handling of repeated requests. On a slow connection, keep enough context visible for the user to understand that work is still pending.
## Handle changes from another editor
If someone else updates the same content, avoid silently presenting an old draft as the latest version. Define whether the system warns, rejects a stale write or asks the user to compare versions.
The interface needs a meaningful recovery path: reload the latest value, copy the unsaved wording, or review a conflict. The exact mechanism depends on the system; do not claim automatic merging unless it exists and has been tested.
## Test from the editor's perspective
Check a successful save, rejected permission, lost connection, expired session and public reload. Include two browser sessions if the product supports concurrent editing. Verify that failures preserve authored content and that status messages match server outcomes.
These checks are useful whether the site uses a CMS, custom editor or an installed product. The [handoff checklist](/blog/website-handoff-checklist-client-updates) translates the resulting behavior into instructions for the person maintaining the website.
## Separate the user's draft from the stored value
Treat the text being typed as an unsaved draft until the save operation succeeds. Keep the last confirmed value available for comparison and recovery. Do not show “Saved” merely because the user clicked a button.
When a save fails, preserve the draft so the user can retry or copy it. Explain what happened in ordinary language without exposing server details.
## Make publication a distinct concept
Some systems publish on save; others have separate draft and publication steps. Either model can work if the interface explains it accurately.
Label the action by its actual effect. If saving changes the public page, say so before the user acts. If saving only updates a draft, show how to publish and who is allowed to do it. Never display a publication success state based only on a local change.
## Plan for delayed and repeated requests
A person may click twice, navigate away or lose connectivity. Decide how the interface behaves during an in-flight operation and how the server prevents duplicate actions.
Disabling a button can reduce accidental clicks, but it is not a substitute for server-side authorization or safe handling of repeated requests. On a slow connection, keep enough context visible for the user to understand that work is still pending.
## Handle changes from another editor
If someone else updates the same content, avoid silently presenting an old draft as the latest version. Define whether the system warns, rejects a stale write or asks the user to compare versions.
The interface needs a meaningful recovery path: reload the latest value, copy the unsaved wording, or review a conflict. The exact mechanism depends on the system; do not claim automatic merging unless it exists and has been tested.
## Test from the editor's perspective
Check a successful save, rejected permission, lost connection, expired session and public reload. Include two browser sessions if the product supports concurrent editing. Verify that failures preserve authored content and that status messages match server outcomes.
These checks are useful whether the site uses a CMS, custom editor or an installed product. The [handoff checklist](/blog/website-handoff-checklist-client-updates) translates the resulting behavior into instructions for the person maintaining the website.