February 1, 2023 Training

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