(Below is the most complete collection of product thinking and design heuristics I’ve compiled for System is as System does. I think it stands on its own as a useful resource, so publishing here, hoping you find it helpful.)
Have one I should add? Let me know in the comments!
Attention
Banner blindness - People ignore elements similar to a common pattern if they’re not interested in that type of content, even if they aren’t sure what that content is.
Color - Stand-out colors grab people’s attention.
Doherty Threshold - People’s attention and productivity increase when interaction response is within 400 milliseconds.
Focus - Interfaces should contain the information needed and nothing more.
F-Pattern - Users scan web content in an F-shaped pattern, reading the first lines fully, then scanning down the left side.
Inattentional blindness - People might not see something they’re not looking for.
Jakob’s Law - People spend most of their time using digital products other than yours.
Novelty bias - People pay attention to new things.
Scanning - People look for information quickly. Information and interfaces can be designed to make scanning easier.
Visual weight - Attention is drawn to items with the most visual weight.
Z-Pattern - On pages with less text, eye movement follows a Z-pattern from top-left to top-right, then diagonally down and across.
Communication
Anticipation - Products should communicate with knowledge of what comes next.
Context-specific communication - Communication style should suit the context people are using the software in (for example, Mailchimp stops being jovial when there are problems or error messages).
Denotative color - Colors are assigned a specific meaning, either culturally or by the design.
Empty states - Empty states should communicate well with the user.
Preview changes - Show users previews of changes in real time and how the action will affect something as they consider options.
Status visibility - The product should keep users informed about what is going on.
Useful animation - Animation can help the user understand how the interface works.
Complexity
Bloat - Bloat is a function of too many features for too little cognitive space.
Combinatorics - If two or more sets of elements can be combined, then you have to account for X * Y total potential outcomes.
Discoverability - There should be ways for users to explore and discover how the software application works on their own.
Four methods of simplification - Remove, organize, hide, displace.
Halstead complexity measures. The higher the number of inputs, the amount and depth of nested elements, the types of actions available, the higher the complexity, the potential branching logic paths, the higher the complexity. The previous sentence would score quite high.
Law of Prägnanz - People interpret groups of complex and ambiguous shapes in the simplest form possible.
Operational simplicity vs perceived simplicity - Working simple vs. looking simple. These can be at odds.
Simple & powerful - Products should be simple enough for novices and powerful for experts.
Tesler’s Law - A system’s complexity cannot be simplified beyond its condition to function. Simple interfaces require complex code.
Context
Affordances - The design of a thing should tell you how to use it. For example, a form field for postal code should only be long enough for 5-9 characters.
External consistency - Things should behave similar to examples outside of your design.
Familiarity - The design should speak the users’ language and follow real-world conventions.
Internal Consistency - Words, actions, and other affordances should have consistent meaning.
Pre-attentive processing - People unconsciously take in information about their environment before they take it in consciously.
Copywriting
Document - Build a product that doesn’t require documentation, then document it anyway.
Grouping - Group similar items or action under group titles.
Inverted Pyramid - Present the most important information first, followed by supporting details.
People don’t read - Assume people don’t read the text in software.
Readability - Use typography that ensures your text is readable in your interface.
Specific actions - Actions should be specific so the user knows what will happen.
Decisions
Choice overload - Too many options hurt users’ decision-making ability. How they feel about the experience as a whole can be impacted as a result.
Deferred choices - If actions aren’t required now, they should be possible to leave until later.
Hick’s law - The time it takes to make a decision increases as the number of choices increases.
Smart defaults - Make the right thing easy and the wrong thing hard.
Errors
Emergency exits - Users can quickly correct mistakes or backtrack on choices.
Error prevention - Prevent errors where you can and provide clear feedback when you can’t.
Error recovery - Error messages should provide a solution.
Graceful degradation - When errors or failures occur, the system should continue to function in a reduced capacity rather than failing completely.
Worst-case design - Interfaces should be designed to cover the worst-case scenario.
Forms
In-line errors over global errors - Better to show errors in proximity to where they happened.
Labels over placeholders - Placeholders disappear, are not accessible.
Mark optional or required fields - You don’t have to mark them all but mark one or the other.
Radio buttons vs. Checkboxes - Radio buttons are single select, checkboxes are multi-select
Validation - Include logic to check that a field has been filled out correctly.
Interaction
Buttons vs Links - Buttons take actions, links go places
Confidence - The user should have confidence that performing an action will have the outcome they expect.
Control redundancy - It can be good to have multiple ways to perform an action - i.e. a keyboard shortcut, a button, a menu item.
Fitt’s Law - The time it takes to click a target based on the target’s size, distance, and position.
Keyboard-only interaction - Some people interact with software with their keyboard only, either for accessibility or power-user reasons.
Object permanence - Objects should not appear and disappear as if by magic, it should be made clear why they did through animation, layout, or some other tool.
Postel’s Law - Be liberal in what input you accept from the user, and limited in what you ask of them.
Principle of Least Astonishment - Systems should behave in the way users expect; surprising behavior should be avoided.
Simulated physical interaction - Items moving with momentum can help communicate how the application works.
Layout
Cause-and-effect - It should be clear what changes an action caused to happen.
Conditional elements - Hide elements if they are not relevant to the user.
Control proximity - Controls should be near what they affect.
Law of common region - When elements are positioned together within a region or boundary, the user perceives those elements as belonging together.
Law of connectedness - We assume elements connected by color, lines, frames, or arrows are part of a related group.
Law of Continuity - The eye follows lines, curves, and sequences of elements.
Law of Proximity - Similar items should be closer, unrelated items should be further apart.
Law of similarity - Elements that look similar will be perceived as being a related group.
Memory
Miller’s Law - People hold an average of seven things in their working memory they can identify.
Negativity bias - People remember bad experiences more than the good. The bad feelings of losing $20 is stronger than the good feelings of winning $20.
Recognition over recall - The machine is the user’s memory, not the other way around. A GUI lets you recognize commands, a CLI requires you to remember them.
Serial position effect - Users are most likely to remember the first and last items in a sequence.
Spatial memory - People remember elements by their position.
The Von Restorff Effect - One visually unique object will be remembered among a group of visually similar objects.
Zeigarnik Effect - Uncompleted or interrupted tasks stick in people’s memories more than completed tasks. Give users ways to track incomplete tasks in-app so they don’t have to do it in memory.
Speed
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.
Immediate Feedback - Systems should respond immediately to user actions to maintain flow and confidence.
Latency - People assume a system is lower quality if interactions take more than 100ms.
Parkinson’s Law - A task expands to fill the time allotted for its completion. Design tasks to take as little time as possible. Give users estimates on how long things will take.
Task Flows
Communicate progress - Provide users with clear progress or task status visibility to keep them motivated.
Escape hatches - Provide the user with a way to abandon what they are doing.
Goal-Gradient Effect - The closer a user gets to a goal the more motivated they are, and the faster they move to complete it.
Incremental construction - A person might need to start on something now, add to it later, work on it over time, etc.
Midstream task change - Sometimes people change what they want to do in the middle of doing it.
Minimize clicks - Reduce the number of clicks & actions a user needs to complete a task.
Progressive disclosure - Display things in stages instead of all at once.
Remove steps - Steps the user shouldn’t have to take should be removed.
Save progress - Provide the user a way to save and come back to a task in case they get detoured.
Streamlined repetition - If something needs to be repeated it should be possible to repeat it endlessly.
Quality
Aesthetic-Usability Effect - People are more tolerant of minor usability problems when an interface has an aesthetically pleasing design.
Paper cuts - Lots of small usability issues add up to a negative experience.
Peak-End Rule - People judge experiences mainly on how they end.
Sturgeon’s Law - 90% of everything is crap.
Sign up to be notified when my book on product thinking for engineers, is available for purchase.