The not-yet-complete interaction design syllabus
How humans work
- Cognitive load (how much does the software make the user think?)
- Short term memory
- Recognition vs. recall
- How people look at things
- People don’t read
- Locus of attention
- Directing attention (e.g. use of alignment, white space to encourage the user to look somewhere)
- Peripheral vision (people can’t see anything clearly except the specific thing they're looking at)
- Inattentional blindness (people might not see something that they’re not actively looking for)
- Movement grabs our attention
- Colour grabs our attention
- Reading patterns
- Scanning
- Satisficing (we find something that seems good enough and try it)
- Information scent/smell
- Gestalt principles
- Mental models (how the user thinks something works, even if they’re not aware of it)
- Hick’s Law
- Accessibility (read the WCAG)
- Pre-attentive processing (people unconsciously take information in about their environment before they pay conscious attention)
- Persuasive design (certain psychology principles can be used to encourage users to act in a certain way, e.g. scarcity, loss aversion)
- Miller’s law (Miller suggested that people can keep 3 to 7 items in short term memory at once)
- Aesthetic-usability effect (people believe that more beautiful interfaces are easier to use)
- Flow state (people can enter a state of intense concentration and your design might help them do that)
- 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)
- The direction of time and progress (this can change across cultures. e.g. in the West right = forward)
- Make important things enjoyable (if you want the user to do something in your software, make it enjoyable)
Context of interaction
- Platform guidelines/principles/rules
- 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)
- Interaction context (e.g. kiosks, mobile, ten-foot, web browser, native app)
- Interactions available in the next context up (e.g. OS menu, browser controls)
- Prior knowledge (how much does the user already know that can help them interact with your software?)
Keyboard and pointer design
- Hover
- Reveal on hover (show actions for an area once the user hovers over that area)
- Tooltips
- Available methods of interaction (e.g. what buttons are there on the mouse)
- Accelerators (including keyboard shortcuts)
- Keyboard-only interaction
- Generous mouse paths (e.g. don't immediately hide a menu if the user accidentally mouses outside of it)
Mobile touch design
- Available gestures/touch actions
- Controls near thumbs
- Orientation
- Thumb reach
- Touch target size
- Direct manipulation
- One-handed use
- Input-appropriate keyboards (e.g. you can show a numerical keyboard for a numerical input)
Navigation
- Screen flow / app architecture
- Browsing vs. searching
- Information architecture (how information is organised and presented to the user. This is a huge topic)
- People can drop in from search engine
- Trap doors
- Landmarks (know where you are from cues)
- Nested navigation
- Navigation models (e.g. hub and spoke)
- Tell the user where they’re going
Layout
- Time flows left to right in the West
- Proximity
- Information density (how much information is shown in a given space)
- Next steps when finished
- Spatial awareness (e.g. a button on the right if clicking it takes you to the right)
- Spatially associated areas (e.g. a properties panel should not be taller or shorter than the content it affects)
- Wireframes
- Visual weight (contrast and size)
- Teasing continuation
- Effect hierarchy (controls that affect larger areas of the application should be placed further out towards the edges)
- Field-value pairs (not every field needs to be a field-value pair. Some values are self-explanatory)
- Responsive design (how does the layout react to different viewport sizes?)
- Layout patterns (there are common solutions to layout challenges for various elements)
Task flows
- Excise (steps the user shouldn’t have to take)
- Progressive disclosure
- 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)
- Escape hatches (always provide a way for the user to abandon what they’re doing)
- Next steps (it’s good to provide an action for the user to take next, even if they’ve finished a task)
Interface elements
- Representation of state versus action on controls
- Best practices for each interface element
- Fitt’s Law
- Operational simplicity vs. perceived simplicity (works simply vs. looks simple. Often at odds)
- Ways to differentiate things (shape, colour, size, and brightness)
- Skeuomorphism
- Signifiers of interaction (e.g. Color)
- Icons vs. labels (icons are neater, help recognition, but may be harder to recognise than text)
- Signifiers
- Put controls near what they affect
- Control states (controls like buttons can have different states that inform the user, e.g. inactive, error, hover)
- Don’t put too much in (too many elements will make it hard for the user to understand the design)
Forms
- Field style to suggest field contents
- Mark either optional or required fields
- Placeholders (text inside a field’s default state to help the user to fill it out)
- Labels not placeholders (form fields are more usable if they have labels and don’t rely on placeholders)
- Alignment of form fields
- 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)
- Best practices for auto-suggest fields, password fields
- When to use similar elements like radio buttons and checkboxes
- Validation (logic which is used to check that a field or form has been filled out correctly)
Communication
- Feedback (when the software lets the user know something about their action)
- Feedback redundancy (ideally software should show that something has changed in more than one way)
- Denotive colour (colours that are assigned a specific meaning, either culturally or by the designer)
- Connotative colour (colours that have existing associations in the user’s mind)
- Conversational design (design the interface as if it’s a person having a conversation with the user)
- Tone of voice/personality (in what way should the interface communicate to the user?)
- Notifications (how you communicate with your user outside of the software)
- 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)
- Language selector not country selector (languages aren’t necessarily tied to countries so let the user select a specific language)
Writing
- Well-written error messages (the user should know what has happened and what they can do about it)
- Microcopy (small amounts of copy throughout the interface)
- Helper text (short text that explains something, like a form field)
- Readability (good typography means the user can read the words in your interface)
- Short action labels for scanning (short labels on a list of actions helps the user to scan through the options available)
- Types of interface text (titles, buttons and other interactive text, descriptions, empty states, labels, controls, text input fields, transitional text, confirmation messages, notifications, errors)
- Control group titles (you can add a title above a group of controls to add more context and allow for shorter control names)
- Truncation (cutting off text helps layout but makes the text less easy to understand)
Initial experience
- Designing for sale vs. designing for use (is your interface designed to impress someone initially, or to impress them over time?)
- Empty states (empty screens should still communicate well with the user)
- Sensible defaults (the default settings should work well. You can’t rely on the user customising anything)
- Product tours (the interface can highlight parts of itself to teach the user, or even guide them through it)
- Onboarding (how does the app help the user to get started for the first time?)
Concepts
- Responsiveness (software should ideally respond as quickly as possible)
- Discoverability (how easy is it to discover something in the interface?)
- Microinteractions (small moments of interaction in an interface)
- Multitasking (how well does the software support someone who does more than one thing at once?)
- Where, what, how (where they are, what they’re looking at, how they can interact)
- Heuristics (Nielsen Norman Group’s for example)
- Interaction patterns (there are common acceptable solutions to specific interface problems)
- Emphasise where attention should be first, de-emphasise where it shouldn’t be
- Promote common actions, not uncommon actions
- Temporary accessibility needs
- Consistency within the view
- Simplicity
- Law of conservation of complexity/Tesler’s law (who does the work?)
- Graceful failure
- Other laws of UX
- Modality
- Intuition (how easy is it for a person to understand the software to start with?)
- Affordances
- Application posture (you can design software differently depending on whether it’s sovereign, transient, daemonic, or parasitic)
- Don’t rely on user memory (e.g. don’t ask the user to remember information from one screen to the next)
- Metaphor (your interface can rely on metaphors the user will be familiar with)
- Customisation (users can change the interface/information to suit their preferences)
- Personalisation (the application can change automatically to suit the user’s preferences)
- Beginner, intermediate, and expert users (how is your interface designed to support people at each of these three levels?)
- 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)
- Deceptive patterns (some design patterns use unethical methods to encourage the user to act)
- Gamification (apps can feature game-like mechanics to encourage engagement)
- Postel’s law (be liberal in what input you accept from the user)
- Prevention vs. undo (you can ask the user if they’re sure about an action, or you can do it and let them undo)
- Semiotics (the science of signs, e.g. icons)
- Clarity (the copy, the typography, the layout, the colours, and more can make the design easier to understand)
- Useful animation (animation can help people understand how the interface works)
- Animation curves (animation speed can follow curves to give it a more natural feel, e.g. easing)
- Flexibility vs. usability (the more flexible an interface is, the harder it is to make it usable)
- Accelerators (e.g. keyboard shortcuts, or other methods that people can use to speed up their task)
- Visual hierarchy (how the design visually lets you know which elements are more and less important)
- Juiciness (how much character/colour/animation/effects interface elements use to react to user input)
- Visual weight (brightness, size, and other factors make some elements grab the attention more)
- Interaction iteration (some interactions need a lot of tweaks before they “feel good”)
- Four ways to simplify (remove, organise, hide, displace)
- Obvious always wins (making an interaction obvious is usually the safest approach)
- Nouns and verbs (you can usually think of an interface as a collection of things and actions)
- Interruptible animations (animations should react gracefully if a user wants to interrupt them with an action)
- Intuition vs. power (some software is more effective but is hard to learn to use, and this can be a good thing)
- Necessary friction (some actions are usually unwanted, e.g. delete, and adding friction to those actions is a good thing)
- Paper cuts (lots of small usability issues that add up to something truly painful)
- Perception of speed (even if software is not fast you can use design to make it feel faster)
Interaction design methods
- 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)
- Prototypes (it’s hard to judge interaction design until you can try it)