Behavior should match what naming and appearance imply

What it is

The principle of least surprise asks a system to behave as people reasonably expect from naming, icon, form, location, current state, and prior experience. An action called “Preview” should not publish immediately; a field that appears editable should not silently change other objects after entry. The point is not an unoriginal product. It is not needlessly violating a reasonable inference from visible cues.

Why it happens

People continually use cues to predict action results. When prediction is met, operation can become automatic; when broken, people must stop, reinterpret, inspect consequences, and update a rule. One surprise may be a learning cost; repeated surprise makes people distrust names and appearance, probe cautiously, reconfirm, or avoid capability. Clear signifiers, mapping, feedforward, and consistent feedback jointly reduce surprise, rather than one warning dialog alone.

Studying it

Before action, ask people what they expect to happen and compare it with actual result. Record confident but wrong predictions, surprising consequences, repeated confirmation, and recovery. Cover first use, skilled transfer, exceptional state, and permission changes, because surprise often arises at edges. Rapid undo, backtracking, repeated clicking, and support issues in logs can indicate expectation violation.

Where it stops holding

A system sometimes must do something unexpected, such as block a dangerous action, resolve a conflict, or respond to external change. The goal is not to pretend no change occurred, but to explain reason, scope, and next step before or at occurrence. Accommodating old expectation should not block safer or more usable design. The key is enough information and recovery choice to rebuild a model after deviation.

Applying it

• Audit the behavior promised separately by a key element's name, form, location, and state, eliminating combinations that imply an opposite result.
• Supply timely feedforward, local explanation, and checkable feedback for necessary exceptions and automatic behavior so people understand why it differs.
• Evaluate experience through expected-versus-actual result, not completion alone; prioritize frequent surprise points for design and implementation repair.

Related

• Same group: B2.14.2 The cost of surprise rises with consequence severity · B2.14.3 Clever but unexpected behavior is a net liability
• Nearby: B2.10.4 Superficial consistency with behavioral inconsistency is the worst case · B2.07.3 Feedforward and feedback should use the same expression system
• Search terms: least surprise · predictable behavior · expectation mismatch