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