UX Principles Flashcards
Doherty Threshold
Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.
Takeaways:
- Provide system feedback within 400 ms in order to keep users’ attention and increase productivity.
- Use perceived performance to improve response time and reduce the perception of waiting.
- Animation is one way to visually engage people while loading or processing is happening in the background.
- Progress bars help make wait times tolerable, regardless of their accuracy.
- Purposefully adding a delay to a process can actually increase its perceived value and instill a sense of trust, even when the process itself actually takes much less time.
Origins
In 1982 Walter J. Doherty and Ahrvind J. Thadani published, in the IBM Systems Journal, a research paper that set the requirement for computer response time to be 400 milliseconds, not 2,000 (2 seconds) which had been the previous standard. When a human being’s command was executed and returned an answer in under 400 milliseconds, it was deemed to exceed the Doherty threshold, and use of such applications were deemed to be “addicting” to users.
Occam’s Razor
Among competing hypotheses that predict equally well, the one with the fewest assumptions should be selected.
Takeaways:
- The best method for reducing complexity is to avoid it in the first place.
- Analyze each element and remove as many as possible, without compromising the overall function.
- Consider completion only when no additional items can be removed.
Origins
Occam’s razor (also Ockham’s razor; Latin: lex parsimoniae “law of parsimony”) is a problem-solving principle that, when presented with competing hypothetical answers to a problem, one should select the one that makes the fewest assumptions. The idea is attributed to William of Ockham (c. 1287–1347), who was an English Franciscan friar, scholastic philosopher, and theologian.
Pareto Principle
The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes.
Takeaways:
1. Inputs and outputs are often not evenly distributed.
2. A large group may contain only a few meaningful contributors to the desired outcome.
3. Focus the majority of effort on the areas that will bring the largest benefits to the most users.
Origins
Its origins stem back to Vilfredo Pareto, an economist who noticed 80% of Italy’s land was owned by 20% of the population. Though it might seem vague, the 80/20 way of thinking can provide insightful and endlessly applicable analysis of lopsided systems, including user experience strategy.
Postel’s Law
Be liberal in what you accept, and conservative in what you send.
Takeaways:
1. Be empathetic to, flexible about, and tolerant of any of the various actions the user could take or any input they might provide.
2. Anticipate virtually anything in terms of input, access, and capability while providing a reliable and accessible interface.
3. The more we can anticipate and plan for in the design, the more resilient the design will be.
4. Accept variable input from users, translate that input to meet your requirements, define boundaries for input, and provide clear feedback to the user.
Origins
Postel’s Law (also known as the Robustness Principle) was formulated by Jon Postel, an early pioneer of the Internet. The Law is a design guideline for software, specifically in regards to TCP and networks, and states “TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others”. In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
Tesler’s Law
Tesler’s Law, also known as The Law of Conservation of Complexity, states that for any system there is a certain amount of complexity that cannot be reduced.
Takeaways:
1. All processes have a core of complexity that cannot be designed away and therefore must be assumed by either the system or the user.
2. Ensure as much as possible of the burden is lifted from users by dealing with inherent complexity during design and development.
3. Take care not to simplify interfaces to the point of abstraction.
Origins
While working for Xerox PARC in the mid-1980s, Larry Tesler realized that the way users interact with applications was just as important as the application itself. The book Designing for Interaction by Dan Saffer includes an interview with Larry Tesler that describes the law of conservation of complexity. The interview is popular among user experience and interaction designers. Larry Tesler argues that, in most cases, an engineer should spend an extra week reducing the complexity of an application versus making millions of users spend an extra minute using the program because of the extra complexity. However, Bruce Tognazzini proposes that people resist reductions to the amount of complexity in their lives. Thus, when an application is simplified, users begin attempting more complex tasks.