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)