A save indicator that tried to show two different states at once, and the rule it broke.
We spent one of our crit sessions this week on a save indicator for a long-form editor, the kind where people write detailed records they can’t afford to lose. The team had wanted something like Google Docs autosave. That didn’t work out, because this editor has required fields, so it isn’t really like Google Docs at all.
The sharpest moment in the room was the realization that the indicator was being asked to do two unrelated jobs. One job is real-time save status: did this content persist? The other is note completeness: are the required fields filled in, so this can be saved at all? Those are different jobs to be done, and we’d quietly conflated them while arguing about the language and the icon. Once you see the two jobs, you stop debating copy and start seeing two design problems wearing one icon’s clothes.
A green check is a promise
The proposed indicator used a green check. A green check reads as good to go, and that’s a promise. When the same state can flip to a warning a moment later, the promise breaks, and the flip itself feels alarming. A neutral last-saved timestamp does something more honest: it confirms the system is doing its work without claiming the note is complete. You keep the reassurance and drop the false guarantee.
There was also a parallelism problem. Showing “changes saved” one moment and “required fields missing” the next puts two non-parallel statements in the same slot, as if they answer the same question. They don’t. One is about persistence, the other is about validation.
If you can’t show it consistently, consider not showing it
One of the designers made the all-or-nothing case, and it stuck with me. If the indicator can’t be shown reliably everywhere, we may be teaching people to look for something that isn’t always there. His point, roughly: in this era I assume everything autosaves. You don’t need to tell me. Intermittent feedback trains the eye to expect it, and then its absence reads as a problem when nothing is actually wrong.
The counterweight came from the risk angle. For a high-stakes task, reassurance earns its place. If I’m spending real time writing something I can’t lose, I need to trust that a crash won’t erase it, or I’ll keep my own copy somewhere else and never make this my system of record. So the level of feedback should track the stakes of the task, not a house style.
Last thread: we debated whether to say “saved” when the data is in fast storage but not yet committed to the database. My read is that it’s fine if we’re confident it doesn’t affect the user. The ins and outs of database versus not-database aren’t the user’s concern. Being overly transparent about where the bytes physically sit isn’t more honest, it’s just noisier. Abstract to the level of the user’s mental model, as long as the technical reality genuinely doesn’t change their outcome.
The teachable part
Before you design the feedback, list the distinct states the element is being asked to express. If it’s more than one, you don’t have a copy problem or an icon problem. You have more than one design problem, and the first move is to separate them.