Cognitive load: how much does the software make the user think?
Short term memory: people can remember some short-term information if they need to
Miller’s law: people can keep 3 to 7 items in short term memory at once
Spatial memory: people might remember elements by their position
Prospective memory: people often leave themselves a reminder in some form that they know they’ll see when it’s relevant
Recognition vs recall: e.g. a graphical user interface lets you recognise commands. A command line interface expects you to recall them
Don’t rely on user memory: e.g. don’t ask the user to remember information from one screen to the next
Chunking: information in chunks is easier to process and remember
Attention and perception
Pre-attentive processing: people unconsciously take information in about their environment before they pay conscious attention
Locus of attention: the specific area that a person is paying attention to in a given moment
Peripheral vision: people can’t see anything clearly except the specific thing they're looking at
Gestalt principles
Inattentional blindness: people might not see something that they’re not actively looking for
Banner blindness: interface elements which look similar to a common pattern may be ignored if the user is not interested in that type of content, even if that’s not what the content really is
Familiarity vs novelty for attention: if something is novel, a viewer might be less likely to pay attention to it
Movement grabs our attention: especially in our peripheral vision
Colour grabs our attention
Complexity/detail grabs our attention
Reading and finding information
People don’t read: it’s best to assume that people don’t read all of the text in software
Reading patterns: e.g. people in the west tend to read from top left to bottom right
Scanning: looking through information quickly. Information can be designed to help scanning
Information foraging: people will continue looking for something only when the benefit seems to outweigh the cost
Information scent: people tend to choose options/actions that seem most related to their task
Satisficing: we find something that seems good enough and try it
Choices and decisions
Choice overload: more choices increases the mental effort required to choose
Hick’s Law: decision time goes up with the number of choices
Number of clicks vs confidence: the number of clicks it takes to do something is not as important as the user feeling confident in what they’re doing
Habits and motivation
Habit: interfaces should encourage and allow habits to form, and should not interfere with existing habits
Flow state: people can enter a state of intense concentration and your design might help them do that
Persuasive design: certain psychology principles can be used to encourage users to act in a certain way, e.g. scarcity, loss aversion
Make the right thing easy and the wrong thing hard: to encourage users to interact in the right way
Make important things enjoyable: if you want the user to do something in your software, make it enjoyable
Curiosity gap: you can design things so that they make people curious but don’t give them all of the information
Deceptive patterns: some design patterns use unethical methods to encourage the user to act
Users and context
User knowledge and expectations
Mental models: how the user thinks something works, even if they’re not aware of it
Prior knowledge: how much does the user already know that can help them interact with your software?
Knowledge of the “real world”: can you make use of users’ experience with the world outside of software?
Intuition: how easy is it for a person to understand the software without guidance?
Metaphor: your interface can rely on metaphors the user will be familiar with
Idiomatic design: the interface establishes or uses existing idioms from the world of interaction and visual design
Skeuomorphism: ornamentation based on the inherent/structural designs of the past, often to make people feel more comfortable or teach them something
Beginner, intermediate, and expert users: how is your interface designed to support people at each of these three levels?
Accessibility and situations of use
Accessibility: read the WCAG
Temporary accessibility needs: e.g. someone with a broken arm only has use of one hand
Interaction situation: e.g. waiting for a bus, holding a baby, skiing down a mountain
Multitasking: how well does the software support someone who does more than one thing at once?
Microbreaks: people often have a few minutes to spare and want to do something in that time
Moment to moment interaction preferences: someone might prefer to use the mouse in one moment and the keyboard in the next
Platforms and devices
Types of interfaces: e.g. text-based, graphical, tangible
Device context: e.g. kiosks, mobile, ten-foot, web browser, native app, virtual reality, augmented reality
Device variation vs creativity: the fewer devices you need to design for, the more tailored/creative you can be with the design
Platform guidelines/principles/rules: e.g. the company that makes an operating system will provide rules for how best to design for it
Integration: how does the software integrate with and enable interaction through other software, including the system software?
Interactions available in the next context up: e.g. operating system menu, browser controls
Connection quality: the speed and reliability of the user’s internet connection affects their experience. There are things the designer can do to take this into account
Consistency and conventions
Jakob’s law: “users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know”
External consistency: things should behave the same way as examples of that thing outside your design
Internal consistency: things that look the same should act the same
Consistency within the view: you might have consistency across views, but is everything within each view consistent?
The direction of time and progress: this can change across cultures. e.g. in the West right = forward
Time flows left-to-right in the West: design time-based interactions/displays based on this
Product scope and simplicity
Purpose and capabilities
Types of software: your design approach/method/patterns will change depending on the type of software you design
Single purpose vs general use: software exists on a spectrum from “does one thing” to “is a tool to do lots of things”
Application posture: you can design software differently based on whether it’s sovereign, transient, daemonic, or parasitic
Efficacy: how much the completed task helps
Expressiveness: how much some software allows you to do
Opinionated software: software that models one way to do the work, based on the creator’s belief that that’s the best way
Designing for sale vs designing for use: is your interface designed to impress someone initially, or to impress them over time?
Complexity and trade-offs
Simplicity: simplicity is not minimalism, and is always a good thing, but is hard
Law of conservation of complexity/Tesler’s law: if the organisation doesn’t work hard to make it simple, the person who uses the software might need to
Operational simplicity vs perceived simplicity: works simply vs looks simple. Often at odds
Flexibility vs usability: the more flexible an interface is, the harder it is to make it usable
Intuition vs power: some software is more effective but is hard to learn to use
More use cases means harder interaction design: the more general-purpose a feature is, the harder it is to choose rules for how it should behave, because people will use it in many different ways
Bloat: software is described as bloated usually if it has too many features in too little cognitive space
Expand vs new: do you expand an existing feature or create a new feature?
Implementation-centric design: interface design that reflects how the software is coded. Usually a bad idea
Four ways to simplify: remove, organise, hide, displace
Customisation and personalisation
Customisation: users can change the interface/information to suit their preferences
Personalisation: the application can change automatically to suit the user’s preferences
Personal, informational, contextual content: in situations where content can change, you can choose it based on these categories
Sensible defaults: the default settings should work well. You can’t rely on the user customising anything
Engagement and promotion
Involvement: how much does the interface involve the user?
Emotional design: software can be designed to encourage specific emotions in the person who uses it
Aesthetic-usability effect: people believe that more beautiful interfaces are easier to use
Gamification: apps can feature game-like mechanics to encourage engagement
Promotion: sometimes it’s good to promote something that the user didn’t know they wanted, but this can be annoying
Fiddle factor: is your interface so fun to use that users want to fiddle with it?
Navigation and information structure
Information architecture
Information architecture: how information is organised and presented to the user
Screen flow / app architecture: how does each screen or view connect to every other screen or view?
Navigation models: e.g. hub and spoke
Hierarchical navigation: a lot of software navigation structure is hierarchical, and the navigation interaction should reflect this
Breadth vs depth: a menu can present lots of options in a flatter hierarhcy, or few options with a deep hierarchy
Nested navigation: menu structure that represents hierarchy
Finding and identifying destinations
Browsing vs searching: two broad approaches to finding something in an interface
Where, what, how: where they are, what they’re looking at, how they can interact
Landmarks: know where you are from cues
Tell the user where they’re going: navigation elements should give the user enough information about where they’ll end up
People can drop in from search engine: so you should design the interface to help them understand where they are, from anywhere
Trap doors: confusing or misleading actions that lead people away from what they wanted
Teasing more content: show that more content exists e.g. if you scroll down
Scrolling and windows
Scroll and pan: if more content is available than can be shown, you can add scroll and pan
Scrolling metaphors: does the viewer move the page through the viewport, or do they move the viewport along the page? This affects scroll direction expectations
Window management/tiling: different self-contained areas of interactivity like windows can be arranged in different ways
Window states: main, key, and inactive
Light dismiss: a dialogue or overlay can be light dismissed if you do not need to take an explicit action, e.g. clicking anywhere outside the overlay
Tasks and workflows
Task efficiency
Efficiency: how quickly someone is able to complete a task
Tool time vs goal time: time spent using the interface vs time spend achieving the goal
Excise: steps the user shouldn’t have to take should be removed
Convenience tipping point: even a small amount of extra convenience can make software useful
Feature affinity: what features do people often use as a group?
Promote common actions, not uncommon actions
Command loops: the steps between repeatedly-used controls should be as simple as possible
Streamlined repetition: if something needs to be repeated it should be possible to repeat it easily
Task guidance and disclosure
Get in the way vs get out of the way: if you want a person to do something, you can get in their way. If they already want to do it, you should get out of their way
Intention vs hand-holding: the more intention you safely assume the user has, the less you need to hold their hand through potential problems
Progressive disclosure: display things in stages instead of all at once
Conditional elements: some elements should only be shown to the user when they’re relevant
Contextual features: make specific interface elements available when in certain contexts, e.g. show picture tools when interacting with a picture
Encourage focus when appropriate: use concepts like modality to encourage the user to focus on a particular task until it’s finished
Match main action to stated purpose: the language used in the main/preferred action in a view should match the stated purpose of that view, e.g. in its title
Next steps: it’s good to provide an action for the user to take next, even if they’ve finished a task
Interruptions and unfinished work
Midstream task change: sometimes people change what they want to do in the middle of doing it
Escape hatches: always provide a way for the user to abandon what they’re doing
Save progress: if a user needs to detour from their task, they should be able to return to exactly the same point as they left
Deferred choices: if actions aren’t required now it should be possible to leave them until later
Incremental construction: a person might need to start on something now, add to it later, add to it again, etc.
Learning and onboarding
Learnability: is the interface designed so that someone learns more about it as they use it? e.g. showing an empty state where some data would be, instead of hiding that area altogether
Discoverability: how easy is it to discover something in the interface?
Obvious always wins: making an interaction obvious is usually the safest approach
Hidden but useful: many interactions are useful but hidden, and this is valid
Incidental learning: when a person sees something in the interface that teaches them about the interface
Onboarding: how does the app help the user to get started for the first time?
Product tours: the interface can highlight parts of itself to teach the user, or even guide them through it
Controls and input
Actions and control behaviour
Affordances: what the user can do with the software, even if they’re not aware of it
Direct vs indirect control: e.g. a button controls something somewhere else, which means you can be clearer with the button itself. Resizing an image by pinching is direct, but less clear
Mapping: the relationship and connections between one set of elements and another, e.g. light switches to lights in the room
Best practices for each interface element: there are generally best practices for each element. These might depend on context
Representation of state versus action: e.g. a button can represent the state, “On”, or the action, “Turn off”.
Control states: controls like buttons can have different states that inform the user, e.g. inactive, error, hover
Modality: a mode is an interface state where the same actions might have different effects
Application or element focus: an application or element has focus if it is ready to accept input
Continuous and discontinuous selection: when you select more than one thing, continuous means they’re all next to each other, and discontinuous means they’re not
Idempotence: an action has idempotence if you can take it multiple times but it only has an effect the first time, e.g. if you press a button labelled “sort” and it doesn’t do anything the second time
Interaction cues
Signifier: interface clues that tell the user that something can be done
False signifier: visual clues about something that turn out to be wrong
Common signifiers of interaction: e.g. colour, shape
Interactivity motif: use visual motifs to signify interactivity
Icons vs labels: icons are neater, help recognition, but may be harder to recognise than text
What symbols can represent: Feeling, object, action, concept
Cursors: you can change the image used for the cursor to give more information about possible interactions
Contextual elements: some elements appear near whatever triggers them, e.g. context menus, tooltips
Input methods and shortcuts
Sources of input: e.g. mouse, keyboard, touch screen, motion, light sensors
Available methods of interaction: e.g. what buttons are there on the mouse
Input-aware interface changes: e.g. if a user connects a mouse to a touch-screen device, the interface can change to suit the mouse instead
Keyboard-only interaction: some people interact only with their keyboard, so you should design for this
Control redundancy: actions can have more than one way to use them. e.g. a keyboard shortcut, a toolbar icon, and a menu item
Accelerators: e.g. keyboard shortcuts, or other methods that people can use to speed up their interaction
Chording: input method where more than one button or key is pressed at the same time
Pointer interaction
Fitt’s Law: something is easier to press if it’s closer and/or bigger
Hover: moving the cursor over an area of the interface without clicking
Reveal on hover: show actions for an area once the user hovers over that area
Tooltips: revealable text that explains more about an element
Generous mouse paths: e.g. don't immediately hide a menu if the user accidentally mouses outside of it
Infinite corners/edges: if you put controls at the true edge of the screen, they’re easier to use with a mouse because the pointer cannot move past them
Touch interaction
Direct manipulation: it’s often better if you can interact with an element directly by touching it, e.g. pinch to zoom
Available gestures/touch actions: the platform will offer specific actions by default
Common touch patterns: e.g. pinch to zoom
One-handed use: often people will use their phone with one hand. You should design for this
Orientation: a device can be held in portrait or landscape, and that should be designed for
Thumb reach: there’s an area of the screen that is easier to reach with the thumbs
Controls near thumbs: the most important controls should be near the thumbs
Touch target size: elements should be large enough that they’re easy to touch. Platforms provide a minimum size suggestion
Input-appropriate keyboards: e.g. you can show a numerical keyboard for a numerical input
Forms and data entry
Field types and layout
When to use similar elements like radio buttons and checkboxes: e.g. radio buttons are single-select, checkboxes are multi-select
Alignment of form fields and labels: there’s more than one approach you can take with alignment of form fields and labels. Each is a trade-off
Field style to suggest field contents: e.g. set the length of a “post code” field to be shorter than a “Name” field
Best practices for auto-suggest fields, password fields: look these up so you don’t need to re-invent the wheel
Labels and instructions
Labels not placeholders: form fields are more usable if they have labels and don’t rely on placeholders
Placeholders: text inside a field’s default state to help the user to fill it out
Mark either optional or required fields: you don’t need to mark every field. Mark the less common state
Helper text: short text that explains something, like a form field
Validation and field errors
Postel’s law: be liberal in what input you accept from the user
Validation: logic which is used to check that a field or form has been filled out correctly
Field error states: fields can have associated error messages if the form was filled incorrectly
In-line errors vs global errors: it’s better to show field errors next to the field
Interface communication
Clarity and meaning
Purpose: it’s important to communicate the purpose of the app or screen to the user
Clarity: the copy, the typography, the layout, the colours, and more can make the design easier to understand
Simple communication: simpler communication will be understood by more people
Semiotics: the science of signs, e.g. icons
Disambiguation: you can provide information that helps a person tell between similar items e.g. in a list
Connotative colour: colours that have existing associations in the user’s mind
Denotive colour: colours that are assigned a specific meaning, either culturally or by the designer
Voice, tone, and language
Context-specific communication: communication style should suit the context people are likely using the software in
Conversational design: design the interface as if it’s a person having a conversation with the user
Voice and tone: the voice the software speaks in should be consistent, but the tone can change depending on the situation
“My” vs “your” interface: does the interface communicate from the user’s perspective, or the interface’s?
Localisation: translating the interface to works in other languages/cultures
Language selector not country selector: languages aren’t necessarily tied to countries so let the user select a specific language
Interface text
Types of interface text: titles, buttons and other interactive text, descriptions, empty states, labels, controls, text input fields, transitional text, confirmation messages, notifications, errors
Microcopy: small amounts of copy throughout the interface
Readability: good typography means the user can read the words in your interface
Specific actions: names of actions should be specific so the user knows what will happen
Short action labels for scanning: short labels on a list of actions helps the user to scan through the options available
Action group titles: you can add a title above a group of actions to add more context and allow for shorter action names
Truncation: cutting off text helps layout but makes the text less easy to understand
Feedback and status
Feedback: when the software lets the user know something about their action
Types of feedback: functional: when the artefact acts as it should. Augmented: feedback added by the designer to communicate something. Inherent: feedback that naturally belongs to the action taken, e.g. the movement of keyboard keys.
Tell vs show feedback styles: you can either tell the user what is happening, or show them directly
Feedback redundancy: ideally software should show that something has changed in more than one way
Anticipation: software should communicate with knowledge of what is coming next, to help the user understand
Preview changes: ideally the user can see, in real time, how an action will affect something, as they consider each option
Empty states: empty screens should still communicate well with the user
Notifications: how you communicate with your user outside of the software
Edit and read “wear”: elements can show how much they’ve been used over time
Layout and visual hierarchy
Content organisation
Content forward: you can make the content the focus by giving it more space in the interface, and also making the interface less cognitively demanding
Information density: how much information is shown in a given space
Don’t put too much in: too many elements will make it hard for the user to understand the design
Layout patterns: there are common solutions to layout challenges for various elements
Proximity: related things should be closer, unrelated things should be farther away
Field-value pairs: data very commonly comes in a field name/field value pair
Hierarchy and emphasis
Visual hierarchy: how the design visually lets you know which elements are more and less important
Visual weight: brightness, size, complexity, and other factors make some elements grab attention more
Emphasise where attention should be first, de-emphasise where it shouldn’t be
Directing attention: e.g. use of alignment, white space to encourage the user to look somewhere
Ways to differentiate things: shape, colour, size, and brightness
Control placement and spatial relationships
Spatial awareness: e.g. a button on the right, when clicked, opens a panel on the right
Put controls near what they affect: we assume things that are close are related, which is true for cause-and-effect as well
Effect hierarchy: controls that affect larger areas of the application should be placed further out towards the edges
Spatially associated areas: e.g. a properties panel should not be taller or shorter than the content it affects
Contextual list order: e.g. a context menu order might change if the the trigger element is above or below the list
Layout adaptation and stability
Scaleability: is the interface designed in a way that if the content/elements suddenly doubled, it would still work?
Responsive design: how does the layout react to different viewport sizes?
Shifting content: it’s bad if the content shifts around, e.g. because of loading, while the user tries to interact with it
Relative movement: as you scroll or pan, some elements might move at different speeds, or not at all, e.g. canvas controls stay still while the canvas is panned
Motion and physical feedback
Interaction over time
Change over time: interaction design is about the design of changes over time in an interface
Microinteractions: small moments of interaction in an interface
Aspects of action-reaction coupling: coupled in time, location, direction, dynamics (position, speed, acceleration, force), modality (sensory), expression (matching the person’s use). These can be decoupled in software
Object constancy/permanence: when elements do not disappear and appear as if by magic, but which act as if they’re always there through animation, layout, etc.
Animation and transitions
Useful animation: animation can help people understand how the interface works
Spatial interaction hints: e.g. a screen animating in from the bottom gives a hint that it can be dismissed by dragging it back down
Animation curves and other properties: animation speed and movement can follow rules to give it a more natural feel, e.g. easing, damping
Interruptible animations: animations should react gracefully if a user wants to interrupt them with an action
Juiciness: how much character/colour/animation/effects interface elements use to react to user input
Physical behaviour and feedback
Physicality: interface elements react/behave like physical materials
Simulated interaction physics: e.g. rubber banding, momentum
Tactile feedback: e.g. vibration in a phone
Detents: positions that interactions will snap to/stop at, e.g. size presets for an expandable sidebar
Speed and input timing
Performance and perceived speed
Fast software: people always prefer software to be as fast as possible
Responsiveness: software should ideally respond as quickly as possible
Perception of speed: even if software is not fast you can use design to make it feel faster
Acceptable latency: 100ms is the delay at which a person notices a delay
Skeleton loading screens: show abstract shapes which represent the layout of the screen, until the screen is loaded
Input timing and tolerance
Input buffering: accept an input (e.g. single mouse click) but wait a little bit to see if there’s another coming (e.g. double mouse click)
Debouncing: don’t trigger an outcome based on an event until input has stopped (e.g. if a person is typing you don’t need to show auto-complete suggestions until they stop)
Coyote time: e.g. if the user lets go of a keyboard key a little too early while performing a modified action, don’t punish them
Delay removal: if an event usually has a delay, e.g. a tooltip appearance, you might want to remove that delay in some situations, e.g. someone is hovering over a row of buttons one after another
Errors and recovery
Preventing mistakes
Slips vs mistakes: a slip is the right intent, but the wrong action. A mistake is the wrong intent
Necessary friction: some actions are dangerous, e.g. delete, and adding friction to those actions is a good thing
Prevention vs undo: you can ask the user if they’re sure about an action, or you can do it and let them undo
Handling failure
Graceful failure: if software fails it should fail in the best possible way
Inline, detour, and blocking error types: inline: let them know next to the problem. Detour: let them know they need to go somewhere else to fix it. Blocking: the software can’t help them to fix the error
Well-written error messages: the user should know what has happened and what they can do about it
Design methods and evaluation
Principles and patterns
Heuristics: Nielsen Norman Group’s for example
Interaction patterns: there are common acceptable solutions to specific interface problems
Antipattern: a pattern that looks like a solution but causes problems
Paper cuts: lots of small usability issues that add up to something truly painful
Modelling interfaces and flows
Nouns and verbs: you can usually think of an interface as a collection of things and actions
Object Oriented UX: an approach to interaction design that maps out the objects in some software and what you can do with them
User flow diagrams: a way to draw the steps a user takes through some software to help design good flows
Wireframes: you can use simpler drawings of interfaces to decide where things should go and how they connect
Prototyping and testing scenarios
Prototypes: it’s hard to judge interaction design until you can try it
Interaction iteration: some interactions need a lot of tweaks before they “feel good”
Worst-case design: interfaces can be designed to cover the worst case scenario e.g. longest name, biggest security risk
Best-case design: interfaces are often designed for only the best case scenario e.g. perfect internet, powerful computer