The interaction design syllabus

How humans work

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)
Spatial memory (people might remember elements by their position)
Chunking (information in chunks is easier to process and remember)
Recognition vs recall (e.g. a graphical user interface lets you recognise commands. A command line interface expects you to recall them)
People don’t read (it’s best to assume that people don’t read all of the text in software)
Locus of attention (the specific area that a person is paying attention to in a given moment)
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 (especially in our peripheral vision)
Colour grabs our attention
Complexity/detail grabs our attention
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)
Satisficing (we find something that seems good enough and try it)
Information scent (people tend to choose options/actions that seem most related to their task)
Information foraging (people will continue looking for something only when the benefit seems to outweigh the cost)
Gestalt principles
Mental models (how the user thinks something works, even if they’re not aware of it)
Hick’s Law (decision time goes up with the number of choices)
Choice overload (more choices increases the mental effort required to choose)
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 (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)
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)
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 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)
Familiarity vs novelty for attention (if something is novel, a viewer might be less likely to pay attention to it)
Acceptable latency (100ms is the delay at which a person notices a delay)
Don’t rely on user memory (e.g. don’t ask the user to remember information from one screen to the next)
Incidental learning (when a person sees something in the interface that teaches them about the interface)
Midstream task change (sometimes people change what they want to do in the middle of doing it)
Microbreaks (people often have a few minutes to spare and want to do something in that time)
Prospective memory (people often leave themselves a reminder in some form that they know they’ll see when it’s relevant)
Curiosity gap (you can design things so that they make people curious but don’t give them all of the information)

Context

Platform guidelines/principles/rules (e.g. the company that makes an operating system will provide rules for how best to design for it)
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)
Device context (e.g. kiosks, mobile, ten-foot, web browser, native app, virtual reality, augmented reality)
Device variation vs creativity (the less devices you need to design for, the more tailored/creative you can be with the design)
Types of interfaces (e.g. text-based, graphical, tangible)
Interaction situation (e.g. waiting for a bus, holding a baby, skiing down a mountain)
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)
Interactions available in the next context up (e.g. operating system menu, browser controls)
Integration (how does the software integrate with and enable interaction through other software, including the system software?)
Prior knowledge (how much does the user already know that can help them interact with your software?)
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)
Contextual features (make specific interface elements available when in certain contexts, e.g. show picture tools when interacting with a picture)
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)
Knowledge of the “real world” (can you make use of users’ experience with the world outside of software?)
Multitasking (how well does the software support someone who does more than one thing at once?)
Temporary accessibility needs (e.g. someone with a broken arm only has use of one hand)
Beginner, intermediate, and expert users (how is your interface designed to support people at each of these three levels?)
Moment to moment interaction preferences (someone might prefer to use the mouse in one moment and the keyboard in the next)
Sources of input (e.g. mouse, keyboard, touch screen, motion, light sensors)

Keyboard and pointer design

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)
Available methods of interaction (e.g. what buttons are there on the mouse)
Accelerators (including keyboard shortcuts)
Keyboard-only interaction (some people interact only with their keyboard, so you should design for this)
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)
Cursors (you can change the image used for the cursor to give more information about possible interactions)

Mobile/touch design

Available gestures/touch actions (the platform will offer specific actions by default)
Controls near thumbs (the most important controls should be near the thumbs)
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)
Touch target size (elements should be large enough that they’re easy to touch. Platforms provide a minimum size suggestion)
Direct manipulation (it’s often better if you can interact with an element directly by touching it, e.g. pinch to zoom)
One-handed use (often people will use their phone with one hand. You should design for this)
Input-appropriate keyboards (e.g. you can show a numerical keyboard for a numerical input)
Common touch patterns (e.g. pinch to zoom)

Navigation

Screen flow / app architecture (how does each screen or view connect to every other screen or view?)
Browsing vs searching (two broad approaches to finding something in an interface)
Information architecture (how information is organised and presented to the user)
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)
Landmarks (know where you are from cues)
Hierarchical navigation (a lot of software navigation structure is hierarchical, and the navigation interaction should reflect this)
Nested navigation (menu structure that represents hierarchy)
Breadth vs depth (a menu can present lots of options in a flatter hierarhcy, or few options with a deep hierarchy)
Navigation models (e.g. hub and spoke)
Tell the user where they’re going (navigation elements should give the user enough information about where they’ll end up)
Scroll and pan (if more content is available than can be shown, you can add scroll and pan)
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)

Layout

Time flows left-to-right in the West (design time-based interactions/displays based on this)
Proximity (related things should be closer, unrelated things should be farther away)
Information density (how much information is shown in a given space)
Spatial awareness (e.g. a button on the right, when clicked, opens a panel on the right)
Spatially associated areas (e.g. a properties panel should not be taller or shorter than the content it affects)
Wireframes (you can use simpler drawings of interfaces to decide where things should go and how they connect)
Visual weight (some elements feel more important/draw the eye more, often due to contrast and size)
Teasing more content (show that more content exists e.g. if you scroll down)
Effect hierarchy (controls that affect larger areas of the application should be placed further out towards the edges)
Field-value pairs (data very commonly comes in a field name/field value pair)
Responsive design (how does the layout react to different viewport sizes?)
Layout patterns (there are common solutions to layout challenges for various elements)
Shifting content (it’s bad if the content shifts around, e.g. because of loading, while the user tries to interact with it)
Window management/tiling (different self-contained areas of interactivity like windows can be arranged in different ways)
Skeleton loading screens (show abstract shapes which represent the layout of the screen, until the screen is loaded)
Contextual list order (e.g. a context menu order might change if the the trigger element is above or below the list)
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)

Task flows

Excise (steps the user shouldn’t have to take should be removed)
Progressive disclosure (display things in stages instead of all at once)
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)
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)
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)
Encourage focus when appropriate (use concepts like modality to encourage the user to focus on a particular task until it’s finished)
Conditional elements (some elements should only be shown to the user when they’re relevant)
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.)

Interface elements

Representation of state versus action (e.g. a button can represent the state, “On”, or the action, “Turn off”).
Best practices for each interface element (there are generally best practices for each element. These might depend on context)
Fitt’s Law (something is easier to press if it’s closer and/or bigger)
Operational simplicity vs perceived simplicity (works simply vs looks simple. Often at odds)
Ways to differentiate things (shape, colour, size, and brightness)
Skeuomorphism (ornamentation based on the inherent/structural designs of the past, often to make people feel more comfortable or teach them something)
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)
Icons vs labels (icons are neater, help recognition, but may be harder to recognise than text)
What symbols can represent (Feeling, object, action, concept)
Put controls near what they affect (we assume things that are close are related, which is true for cause-and-effect as well)
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)
Interactivity motif (use visual motifs to signify interactivity)
Contextual elements (some elements appear near whatever triggers them, e.g. context menus, tooltips)

Forms

Field style to suggest field contents (e.g. set the length of a “post code” field to be shorter than a “Name” field)
Mark either optional or required fields (you don’t need to mark every field. Mark the less common state)
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 and labels (there’s more than one approach you can take with alignment of form fields and labels. Each is a trade-off)
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 (look these up so you don’t need to re-invent the wheel)
When to use similar elements like radio buttons and checkboxes (e.g. radio buttons are single-select, checkboxes are multi-select)
Validation (logic which is used to check that a field or form has been filled out correctly)

Communication

Purpose (it’s important to communicate the purpose of the app or screen to the user)
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.)
Feedback redundancy (ideally software should show that something has changed in more than one way)
Tell vs show feedback styles (you can either tell the user what is happening, or show them directly)
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)
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)
Emotional design (software can be designed to encourage specific emotions in the person who uses it)
Context-specific communication (communication style should suit the context people are likely using the software in)
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)
“My” vs “your” interface (does the interface communicate from the user’s perspective, or the interface’s?)
Empty states (empty screens should still communicate well with the user)
Localisation (translating the interface to works in other languages/cultures)
Simple communication (simpler communication will be understood by more people)
Useful animation (animation can help people understand how the interface works)
Disambiguation (you can provide information that helps a person tell between similar items e.g. in a list)
Edit and read “wear” (elements can show how much they’ve been used over time)

Writing

Well-written error messages (the user should know what has happened and what they can do about it)
Specific actions (names of actions should be specific so the user knows what will happen)
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)
Action group titles (you can add a title above a group of actions to add more context and allow for shorter action names)
Types of interface text (titles, buttons and other interactive text, descriptions, empty states, labels, controls, text input fields, transitional text, confirmation messages, notifications, errors)
Truncation (cutting off text helps layout but makes the text less easy to understand)
Voice and tone (the voice the software speaks in should be consistent, but the tone can change depending on the situation)

Initial experience

Designing for sale vs designing for use (is your interface designed to impress someone initially, or to impress them over time?)
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?)

Physical/spatial

Simulated interaction physics (e.g. rubber banding, momentum)
Physicality (interface elements react/behave like physical materials)
Tactile feedback (e.g. vibration in a phone)
Animation curves and other properties (animation speed and movement can follow rules to give it a more natural feel, e.g. easing, damping)
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)
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)
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.)

Concepts

Responsiveness (software should ideally respond as quickly as possible)
Discoverability (how easy is it to discover something in the interface?)
Hidden but useful (many interactions are useful but hidden, and this is valid)
Microinteractions (small moments of interaction in an interface)
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
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)
Consistency within the view (you might have consistency across views, but is everything within each view consistent?)
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)
Graceful failure (if software fails it should fail in the best possible way)
Modality (a mode is an interface state where the same actions might have different effects)
Intuition (how easy is it for a person to understand the software without guidance?)
Affordances (what the user can do with the software, even if they’re not aware of it)
Application posture (you can design software differently based on whether it’s sovereign, transient, daemonic, or parasitic)
Types of software (your design approach/method/patterns will change depending on the type of software you design)
Customisation (users can change the interface/information to suit their preferences)
Personalisation (the application can change automatically to suit the user’s preferences)
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)
Flexibility vs usability (the more flexible an interface is, the harder it is to make it usable)
Expand vs new (do you expand an existing feature or create a new feature?)
Accelerators (e.g. keyboard shortcuts, or other methods that people can use to speed up their interaction)
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, complexity, and other factors make some elements grab attention more)
Four ways to simplify (remove, organise, hide, displace)
Obvious always wins (making an interaction obvious is usually the safest approach)
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)
Necessary friction (some actions are dangerous, 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)
Fast software (people always prefer software to be as fast as possible)
Perception of speed (even if software is not fast you can use design to make it feel faster)
Promotion (sometimes it’s good to promote something that the user didn’t know they wanted, but this can be annoying)
Control redundancy (actions can have more than one way to use them. e.g. a keyboard shortcut, a toolbar icon, and a menu item)
Bloat (software is described as bloated usually if it has too many features in too little cognitive space)
Efficiency (how quickly someone is able to complete a task)
Efficacy (how much the completed task helps)
Feature affinity (what features do people often use as a group?)
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)
Fiddle factor (is your interface so fun to use that users want to fiddle with 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)
Personal, informational, contextual content (in situations where content can change, you can choose it based on these categories)
Implementation-centric design (interface design that reflects how the software is coded. Usually a bad idea)
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)
Single purpose vs general use (software exists on a spectrum from “does one thing” to “is a tool to do lots of things”)
Change over time (interaction design is about the design of changes over time in an interface)
Application or element focus (an application or element has focus if it is ready to accept input)
Scaleability (is the interface designed in a way that if the content/elements suddenly doubled, it would still work?)
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)
Mapping (the relationship and connections between one set of elements and another, e.g. light switches to lights in the room)
Opinionated software (software that models one way to do the work, based on the creator’s belief that that’s the best way)
Involvement (how much does the interface involve the user?)
Slips vs mistakes (a slip is the right intent, but the wrong action. A mistake is the wrong intent)
Intention vs hand-holding (the more intention you safely assume the user has, the less you need to hold their hand through potential problems)
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)
Convenience tipping point (even a small amount of extra convenience can make software useful)
Chording (input method where more than one button or key is pressed at the same time)
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)
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)
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)
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))

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)
Interaction iteration (some interactions need a lot of tweaks before they “feel good”)
Nouns and verbs (you can usually think of an interface as a collection of things and actions)