Principle of Least Astonishment

When there are two possible behaviours for the same interaction, pick the one that will surprise the fewest users.

If the back button on a checkout page clears the cart, that surprises people. And 'the spec is unambiguous' is a terrible defence when you're looking at a support backlog full of the same complaint. The surprising behaviour might be technically correct, internally consistent, or even 'the way it's always worked' — but if it's not what most users expect, you're generating support tickets and churn every time someone hits it.

This rule matters most for destructive actions, navigation defaults, form submissions, and undo behaviour. Your job is to be the person who asks 'what will a user actually expect here?' when everyone else is arguing about what the spec says.

A 'Save' button on a settings page also navigates the user back to the previous screen after saving. The designer's logic: the user is done, so we should take them back to where they came from. The spec reflected this and was signed off.

Three weeks after launch, support gets a steady flow of tickets: 'I saved my settings and got logged out / lost my place / went to the wrong page'. Users expected a Save button to save and stay — the way every other settings screen they've ever used behaves.

The fix is six lines of code and a one-line copy change, but the lesson is cheaper to learn up front: Save saves. Navigation is a separate intent. If you want the combined behaviour, label it 'Save and return' — and now it's no longer astonishing.