Do what people expect it to do.
A component should behave the way most of its users expect. Every surprise costs attention and trust, so follow the conventions people already know, choose sensible defaults, and make each control do what it looks like it does.
An early reference to a ’Law of Least Astonishment’ appeared in the PL/I Bulletin in 1967. IBM’s PL/I had become notorious for breaking it: because of its precision rules, 25 + 1/3 could stop with a fatal error or return 5.33 instead of 25.33. The law first appeared in print in 1972, in a paper on systems programming languages by Bergeron, Gannon, Shecter, Tompa, and van Dam, which asked that every construct behave exactly as its syntax suggests.
Eric S. Raymond made it the Rule of Least Surprise in The Art of Unix Programming (2003): borrow from functionally similar programs your users already know. Joshua Bloch applied it to API design in 2006. In interface design it is often summed up in one textbook line: people are part of the system, and the design should match their experience, expectations, and mental models.
A component should behave the way most of its users expect. When behavior and expectation differ, change the behavior rather than the users: follow established conventions, choose sensible defaults, and make every control do what its appearance suggests.
PL/I’s precision rules meant 25 + 1/3 could stop with a fatal error or, with errors suppressed, return 5.33 instead of 25.33. The language did exactly what its rules said and astonished everyone who used it.
People bring expectations from every other app. F1 opens help on Windows, and pressing ? lists the keyboard shortcuts in Gmail, YouTube, and Jira. Reusing a convention costs users nothing to learn.
A button or link should tell people exactly what to expect. A Download button that opens a sign-up form, or a Continue button that charges a card, breaks the promise and the trust that goes with it.
JavaScript’s parseInt once read ’08’ as octal because of the leading zero, a default that caused years of bugs until ECMAScript 5 dropped it. A default should match what most people mean.
Things that look alike should act alike. Two identical buttons that do different things, or a swipe that archives on one screen and deletes on another, surprise people every time.
What is least surprising depends on who is using it. Command-line users expect Unix flag conventions, Windows users expect its shortcuts, and beginners expect neither. Design for the audience you actually have.
Functions and methods should do what their names promise, with no side effects the name doesn’t suggest. The same goes for interfaces: a toggle labeled Notifications shouldn’t also unsubscribe someone from email.
The corollary: if a necessary feature has a high astonishment factor, it may be necessary to redesign it. Usability tests show surprise directly in hesitation, repeated clicks, and the words ’wait, what happened?’
AI can give a different answer to the same question and take actions nobody asked for. Predictability has to be designed in.
An assistant that books, sends, or deletes on its own can astonish people in ways that are hard to undo. Say what will happen, show a preview, and ask before acting.
People treat an assistant like a person, a search box, or a command line, depending on what it resembles. State its capabilities and limits up front, so its behavior matches the model people bring.