Principle of least astonishment

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The principle of least astonishment (POLA) applies to user interface and software design, from the ergonomics standpoint.[1] It is alternatively referred to as the law, principle or rule of least astonishment, or least surprise.[2][3] "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature."[4]


A textbook formulation is "People are part of the system. The design should match the user's experience, expectations, and mental models."[5] What is least surprising may however depend on the expected audience, e.g. end users, programmers or system administrators.[2] In more practical terms, the principle aims to exploit users' pre-existing knowledge as a way to minimize the learning curve for instance by designing interfaces borrowing heavily from "functionally similar or analogous programs with which your users are likely to be familiar."[2] User expectations in this respect may be closely related to a particular computing platform or tradition. For example, Unix command line programs are expected to follow certain conventions with respect to switches,[2] and widgets of Microsoft Windows programs are also expected to follow certain conventions with respect to key bindings.[6] In more abstract settings like an API, the expectation that function or method names intuitively match their behavior is another example.[7] This practice also involves the application of sensible defaults.[4]



A website may declare an input that should autofocus when the page is loaded,[8] such as a search field (e.g., or the username field of a log in form. Sites offering keyboard shortcuts often allow pressing ? to see the available shortcuts. Examples include Gmail[9] and JIRA.[10]

The F1 Function key in Windows operating systems is almost always for opening a help program associated with a software, and similarly for some of the Linux desktop environments. The corresponding key in Mac OS X is Command+ Shift+?. Users expect a help screen or similar help services popup when they press the F1 key. Software binding this key to some other feature is likely to cause astonishment at the lack of help. Malicious programs are known to exploit users' familiarity with regular shortcut keys.[11]

See also[edit]


  1. ^ Peter Seebach (2001-08-01). "The Principle of Least Astonishment". The cranky user. IBM DeveloperWorks. Retrieved 2014-01-23. 
  2. ^ a b c d Eric Steven Raymond (2003). "Applying the Rule of Least Surprise". The Art of Unix Programming. p. 20. ISBN 978-0-13-142901-7. Retrieved 2014-01-23. 
  3. ^ Geoffrey James (1987). "Law of Least Astonishment". The Tao of Programming. 4.1. ISBN 0-931137-07-1. Retrieved 2014-02-05. 
  4. ^ a b c M. F. Cowlishaw (1984). "The design of the REXX language". IBM Systems Journal, VOL 23. NO 4, 1984 (PDF). IBM Research. p. 333. doi:10.1147/sj.234.0326. Retrieved 2014-01-23. "Could there be a high astonishment factor associated with the new feature? If a feature is accidentally misapplied by the user and causes what appears to him to be an unpredictable result, that feature has a high astonishment factor and is therefore undesirable. If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature." 
  5. ^ Saltzer, J. H.; Kaashoek, Frans (2009). Principles of computer system design: an introduction. Morgan Kaufmann. p. 85. ISBN 978-0-12-374957-4. 
  6. ^ Petroutsos, Evangelos (2010). Mastering Microsoft Visual Basic 2010. John Wiley and Sons. p. 133. ISBN 978-0-470-53287-4. 
  7. ^ Bloch, Joshua (2006), How to design a good API and why it matters, Association for Computing Machinery, pp. 506–507 
  8. ^ "Forms in HTML". Mozilla Developers Network. Mozilla. Retrieved 27 July 2013. 
  9. ^ "Keyboard shortcuts". Google. 21 Jun 2013. Retrieved 27 July 2013. 
  10. ^ "Using Keyboard Shortcuts". Atlassian. Retrieved 27 July 2013. 
  11. ^ Microsoft: Don't press F1 key in Windows XP - Computerworld

External links[edit]