How did you know a change was saved?
The cue showing a saved change identifies how people distinguish confirmed persistence from an edit still in progress. Compare it with verified save behavior.
Product and software research / Survey guide
Product and software research · Practical survey guide
Saving status clarity survey
Understand whether users know their work is saved.
Opens product registration. Example questions are not imported automatically.
BEFORE YOU INVITE PEOPLE
Local planning aid. No answers are submitted or saved.
A useful starting point
Questions to understand the actual experience.
Understand whether users know their work is saved. Use the prompts relevant to your audience and allow people to skip situations they did not encounter. Keep response handling consistent with what you explain in the invitation.
If nothing was unclear or difficult, say so. Skip questions about steps you did not experience; use not applicable where appropriate.
When did you feel uncertain about saving?
The uncertainty moment identifies where editing, navigation or delayed feedback obscures the saved state. Explain the actual status and available checks, without promising data preservation beyond verified product behavior.
What status information would help?
Requested status information identifies what would reduce uncertainty during editing or navigation. Distinguish pending, saving and saved states without promising preservation beyond observed behavior.
If nothing was unclear or difficult, say so. Skip questions about steps you did not experience; use not applicable where appropriate. How did you know a change was saved? When did you feel uncertain about saving? What status information would help?
Download the questions as text ↓
Examples to adapt, rather than a validated research instrument.
Before you send it
Check what your wording assumes.
Would you agree that everything about saving status clarity was clear and easy?
How did you know a change was saved?
The first wording combines an assumed positive outcome with two different judgments. The revised prompt asks about a specific experience and permits an inconvenient or uncertain answer.
Choose the response format
Make room for the explanation.
| Question | Suggested format | What to preserve |
|---|---|---|
| How did you know a change was saved? | Optional short text | Retain the specific point or condition described; avoid replacing it with an unexplained rating. |
| When did you feel uncertain about saving? | Optional written explanation | Keep context that distinguishes different experiences. Do not promise autosave behavior from interface feedback. |
| What status information would help? | Optional improvement suggestion | Keep the suggested change separate from whether it has been tested. Show clear saving and saved states. |
Make questions optional where appropriate. If you add a rating scale, label its endpoints, keep one idea per question, and retain a follow-up for reasons. These examples are not a validated measurement instrument.
From question to next step
Make the feedback useful.
Set the decision
Start with the decision: Understand whether users know their work is saved.
Invite relevant voices
Invite people with relevant experience. Ask after someone has encountered the situation described in “How did you know a change was saved?”, while they can still recall the details. For material testing, show the actual draft first; for planning, ask before the next relevant activity.
Choose an action
Show clear saving and saved states.
A worked interpretation example
From a comment to a practical next step.
Illustrative scenario. These are not customer results.
Keep the finding specific
Users cannot distinguish pending edits from saved changes.
Choose an action to test
Show clear saving and saved states.
Check the experience again
After trying the change, repeat “How did you know a change was saved?” with people who experienced it. Check whether they still describe the original issue: users cannot distinguish pending edits from saved changes. Compare explanations and sample context, rather than claiming the change caused an improvement.
Read the answers carefully
Keep the conclusion within the evidence.
Do not promise autosave behavior from interface feedback.
Users cannot distinguish pending edits from saved changes. This is a synthetic example, not a customer result. Do not promise autosave behavior from interface feedback.
Before you send it
Questions, answered.
Who should receive this questionnaire?
Product users who attempted the described task. Ask only about steps each person encountered; do not treat a voluntary response sample as representative.
When should I ask these questions?
Ask after someone has encountered the situation described in “How did you know a change was saved?”, while they can still recall the details. For material testing, show the actual draft first; for planning, ask before the next relevant activity.
What should I investigate in the answers?
Users cannot distinguish pending edits from saved changes. This is an illustrative pattern to look for, not a claim about your respondents. Do not promise autosave behavior from interface feedback.
What would a practical follow-up look like?
Show clear saving and saved states. After trying the change, repeat “How did you know a change was saved?” with people who experienced it. Check whether they still describe the original issue: users cannot distinguish pending edits from saved changes. Compare explanations and sample context, rather than claiming the change caused an improvement.
How should I ask “When did you feel uncertain about saving?”?
The uncertainty moment identifies where editing, navigation or delayed feedback obscures the saved state. Explain the actual status and available checks, without promising data preservation beyond verified product behavior. Use an optional written explanation when predefined choices would hide relevant context.
Can I use the questions in SurveyTeams?
Copy the prompts or download TXT, CSV, JSON, or a Markdown worksheet, then adapt them in your own survey. The CTA opens registration; it does not import this example automatically. Verify available features in your account.
Build with SurveyTeams
Draft your own saving status clarity questionnaire.
Use these examples to draft your questionnaire. Create a survey draft, add questions, and check the respondent preview in SurveyTeams. Additional features depend on your account and plan.
Create your survey in SurveyTeams
Opens product registration. Example questions are not imported automatically.
Learn about the product ↗Continue exploring