This type of logic, from a user perspective at least, is invisible logic - the system has a set of rules that the user can only infer.
- Why the save button is disabled?
Invisible logic is counter usability since users are left to infer why things are the way they are.
Even when the logic can be easily inferred - as in the case of a disabled login button when either the username or password fields are blank - designers will sometimes prefer to allow users make errors then tell them explicitly what they've done wrong than let users work out invisible logic.
Situational & contextual design
Designers often ignore the situation and context in which users operate.
Consider the following scenario:
A user types a new value in the field, and gets a Tinder notification on their mobile. Eagerly, the user unlocks his phone. After 10 minutes of flirting, the user is back to the system, with the save button disabled. "Have I pressed save? I don't remember I did!". Obviously the user did, but he can't remember.
Back to the user
An IO analysis of users in this case goes:
- Output: In terms of actions, users want to save what they have entered.
- Input: In terms of information, users want to know all their changes have been saved.
To satisfy the output requirement, simply have a
To satisfy the input requirement, simply add a message next to it
All changes are saved - that's much more reassuring than a disabled save button.
You may still choose to disable the save button, or in some cases replace it with the
All saved message.
In the case you've described, since the message reads
Changes saved, any change should enable the button (even if the change ends up as the saved version). If your message reads
Saved than disabling or hiding the button makes more sense.