The Principle of least Astonishment

When designing digital products, it’s critical that the interaction between the user and the system is well designed. To facilitate designing user interfaces, apps or websites, numerous guidelines, rules and principles can be applied. One principle that should be considered—from the beginning of the design to the release of the final product—is the principle of least astonishment.

Don’t surprise your user

The main statement of the principle of least astonishment or principle of least surprise is that you should avoid surprising your user (in an unpleasant way) at any cost. Interfaces should always be designed in a way that confronts the user with the least amount of unexpected incidents possible.


While trying to develop systems that behave in a way that most users would expect them to should be the goal of every developer, it’s not as easy as it may sound or seem. Everybody who has some sort of knowledge in the area of UX/Usability-Design or user research knows that “you are not your user”. This fact is the reason for a number of problems that can arise when designers and developers try to determine, what users expect:

• Developers are usually a lot further removed from their users than they think they are. They also are a lot closer to the system (obviously: they developed it).


• Surprising behavior should be determined from the point of view of someone using the product, not someone who develops it.


• Developers as well as designers have an especially hard time imagining what users would expect or find surprising since they are experts in the area of interfaces and therefore know considerably more about shortcuts or interaction patterns than the average user.


• Different users of the product will have different expectations of how it should work. Since you can’t design a different interface for every user, you’ll have to prioritize or decide which behavior is the most expected/least surprising.

Why you should avoid being astonishing

Surprises aren’t always positive but almost always a potential source of frustration in the context of human-computer-interaction. Users want to be in control so the system should behave as it’s expected to. Users should never have to figure out how to get the system to do what it should do, especially when they already have their own mental model of how the system could or should work.

The aim of the law of least astonishment is to enable users to use pre-existing knowledge they acquired in their past interactions with digital products. If you design interfaces to be similar to analogous products which you target group is familiar with, you minimize their learning curve when they first start using your product. This results in a smooth and pleasant onboarding process.
Consistency in the way digital products work and behave increases the predictability during the interaction and reduces the distraction. Things that look the same and serve the same purpose should also behave in the same way. Things that are similar to each other should also behave in a similar way. When everything works as expected, the user will make fewer mistakes. It’s okay to build upon similar systems and incorporate the best elements of an existing system—at least to a certain degree. The interaction will be more efficient and therefore also more rewarding.

How to apply the Principle of least Astonishment

Since you’re trying to guess what your users expect your system to do, the most obvious first step is to gather information about your user group and their characteristics. What surprises your users depends on the kind of user you’re targeting (end users, programmers, maintainers) as well as the kind of interface you’re designing. So consider both of those things!
Doing a careful analysis of the user journey and the flow of the interaction can highlight breaks in the logic flow that need to be fixed. Once you decided on interaction patterns you want to use and a preliminary design for your interface, you should begin user testing as quickly as possible using wireframes, mockups or rough prototypes. That way you can avoid expensive development fixes and redos later in the process. When analyzing the user journey, try to consider all the different ways to reach the defined goal. The sooner you gather feedback from real users, the sooner you can implement them.

Ideally the system you designed should not only reflect users’ needs but anticipate the way they interact and maybe even suggest appropriate next steps to take. E.g. if you use shortcuts that are commonly used for a certain action (Ctrl + Z) you should never assign them a different function. When the user clicks on the button leading to the contact form, it’s sensible to directly place the cursor in the form’s first input field. Before making any changes to the way users interact with an existing product, carefully consider whether those changes improve the experience
To sum it up the law of least astonishment states that the result of performing some operation should be obvious, consistent and predictable to the user. The human user is an integral part of the larger system. Therefore the systems design and structure should match the users’ past experiences, expectations and mental models. If a necessary feature has a high astonishment factor it may be necessary to redesign this feature to better meet your users’ needs.

You need a tool that helps you analyze your research results? We’re working on the solution for you: Consider.ly makes it possible for you and your team to create searchable recharche findings and helps you spot patterns assisted by AI. For any questions, please send us an E-Mail.