The Power of The Principle of Least Astonishment

When it comes to successful app or software development, understanding and following The Principle of Least Astonishment is key.

If you’ve ever purchased something online, you’ll probably identify with the following experience. A customer wants to buy a pair of shoes from their phone. They locate the pair they want from Amazon or Zappos, select their size from a drop down menu, and click “add to cart” to right of the product photo. When they’re ready to purchase, the input boxes for their shipping and credit card information autofocus as they select each field. Before they continue, a review page loads, allowing them to edit the order as needed. Pretty straight forward.

Now imagine that same customer buys a pair of shoes on a different mobile site. On the second site, they spend a few extra seconds hunting for the “add to cart” button, which is located on the bottom left side of the page instead of on the right near the product photo. They also spend extra time checking their information because the input fields don’t autofocus, making it harder to see what they’re typing. Obviously, this second experience sounds more time consuming and frustrating than the first — but why, exactly?

Defining the Principle of Least Astonishment.

The creators of the second e-commerce page neglected to follow The Principle of Least Astonishment (PoLA). In other words, don’t surprise the user. According to PoLA, developers and designers create intuitive experiences by following common patterns and leveraging what they know about user expectations. For instance, most users expect an “add to cart” button to appear on the right side of the page somewhere near the product photo. Placing it elsewhere creates an unnecessary learning curve and a potentially frustrating experience.

As software and product developers, we rely on PoLA not only to create seamless user experiences but also to streamline our internal processes. Following conventions that make our code more predictable empowers our team members to be flexible. They can jump into projects they’ve never worked on before, or return to code they’ve written weeks or months prior with a clear understanding of what’s going on. Even something as simple as naming a function to reflect its purpose makes a big difference in writing clear, maintainable code.

Following PoLA can make a world of difference to a product’s success.

The poorly designed e-commerce site we mentioned earlier most likely has a higher bounce rate than its competitors because visitors need to work harder to get what they need. Like a high rise without a steal-beam foundation, a product that doesn’t ground its users with familiar patterns will eventually fall apart. On the other hand, the more developers and designers consider their users’ preferences and habits, the greater their ability to create intuitive, pleasing experiences.