The 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 (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
• 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 (decision time goes up with the number of choices)
• 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)
• 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)

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

Task flows

• Excise (steps the user shouldn’t have to take should be removed)
• 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)
• 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 (you can use concepts like modality to encourage the user to focus on a particular task until it’s finished)

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

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

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 (e.g. someone with a broken arm, or holding a baby, 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
• Other laws of UX
• 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 depending 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)
• Useful animation (animation can help people understand how the interface works)
• 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)
• 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)
• 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 (aside from standards like mouse, keyboard, touch screen, etc., what other inputs can you use? e.g. motion and 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)

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