Design Concepts on LawsOfUX.com
Peak-End Rule
Our feelings about something are largely based on how we felt at its peak (good or bad) and at the ending, not based on the sum of the whole
Identify where your program is most helpful/interesting/valuable
Focus your efforts on the most intense/important parts and the ending
We recall negative experiences better than positive experiences
Use a technique called “journey mapping” in order to identify and plot these peak points
– Be sure to specifically identify who the user is and in what scenario the user is interacting with your product
This is because of memory bias and recency bias
Postel’s Law
– I understand this one, but I am finding a lot of the language used here weirdly tricky. It feels obtuse. Really: Be open and flexible, but know what the minimum boundaries are
– Part of my issue seems to be that this “law” is vague in theory but applied very specifically in different contexts
Be liberal in what you accept and conservative in what you need
Be empathetic to and flexible about any actions the user could take or any input they provide
Anticipate everything while maintaining something reliable and accessible
The more you plan, the more resilient you will be
Accept input, translate that input to meet your requirements, and provide feedback
What is sent should conform rigidly to standards, but what is accepted should not
– This law was designed specifically for packet-switching and applied elsewhere
Apply with Occam’s Razor – minimal requirements for feedback
It’s your job to verify and standardize the content/info you receive, not the sender
Use the simplest method to complete something, it’s often harder to simplify more complex systems later than it is to scale and optimize later
Serial Position Effect
People are better at remembering the first and last items in a series
Place the least important items in the middle of a list
Place the most important items at the top/bottom or most right/left positions
This is because of the primacy and recency effects
Reference Miller’s Law and Hick’s Law
Allowing people to continually reference the info they need prevents them from having to remember it and reduces the cognitive load
– Use UI elements to impart this info, like maps, rulers, applicable filters, etc.
This is generally less important when users decide the pace of the information
Tesler’s Law
AKA The Law of Conservation of Complexity
For any given system, there is a certain amount of complexity that which cannot be reduced
These complexities must be assumed by either the system or the user
It’s your job to assume those complexities for the system
The complexity rarely can be erased entirely
Be careful of simplifying to the point of abstraction
When we want simplicity, we really want understanding
Removing functionality does not necessarily make something simpler
Often, we perceive the simplest things to be the ones we don’t need to interact with at all
– e.g. having auto-pay set up for water and being able to turn on your tap anytime
– some people (like professionals) desire the complexity
– not everything needs to be as simple as possible!
Something is only as good as when it is broken
Try to have one control for one function
Valuable to keep in mind with other principles, like law of common region and Postel’s law
People are generally only interested in the end product, not the process