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
• How people look at things
• 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
• 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 those 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 is less likely to pay attention to it)
• Acceptable latency (100ms is the delay at which a person notices a delay)

Context

• 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)
• 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?)

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
• Generous mouse paths (e.g. don't immediately hide a menu if the user accidentally mouses outside of it)
• Context menu (a menu where the items change depending on where the menu is opened)
• 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
• 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)
• Common touch patterns (e.g. pinch to zoom)

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)
• 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 if they interact witih them)
• Scroll and pan (if more content is available than can be shown, you can add scroll and pan)

Layout

• Time flows left to right in the West
• Proximity
• Information density (how much information is shown in a given space)
• 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 (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)

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)
• 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)

Interface elements

• Representation of state versus action on controls
• Best practices for each interface element
• 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
• 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. color, 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
• 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)

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

• 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)

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)
• 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
• 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)
• Temporary accessibility needs (e.g. someone with a broken arm only has use of one hand)
• Consistency within the view
• Simplicity
• Law of conservation of complexity/Tesler’s law (who does the work?)
• Graceful failure (if software fails it should fail in the best possible way)
• Modality (something is modal if it changes the mode of the software when it’s active, e.g. an edit mode)
• Intuition (how easy is it for a person to understand the software to start with?)
• 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)
• Don’t rely on user memory (e.g. don’t ask the user to remember information from one screen to the next)
• 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)
• 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 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, 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)
• 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)
• 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)
• Sources of input (e.g. mouse, keyboard, touch screen, motion, light sensors)
• 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?)
• Incidental learning (when a person sees something in the interface that teaches them about the interface)
• 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)

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”)