Video Lectures

Human Cognition and Perception

1

Human Cognition and Perception

▶

Every interface is, in effect, a proposal made to a human nervous system. A button, a menu, an error message, or a loading spinner is only "good" to the extent that it fits the way people actually see, attend, remember, and decide. Human-computer interaction therefore rests on a working understanding of cognitive psychology: not as abstract theory, but as a set of design constraints that are as real and as unforgiving as screen resolution or network bandwidth. A system can be functionally flawless and still fail completely because it asks users to hold seven items in mind at once, to notice a change in a region they were never looking at, or to wait without evidence that anything is happening. This topic examines the mental machinery users bring to an interface — cognition, perception, attention, memory, information processing, and the subjective experience of time — and translates each into concrete design implications.

Foundations of Human Cognition

Cognition is the umbrella term for the mental activities by which people acquire, transform, store, and apply information. It includes perceiving (interpreting sensory input), attending (allocating limited processing resources), remembering (encoding and retrieving information), reasoning (drawing inferences), problem-solving (finding a path from a current state to a goal state), decision-making (choosing between alternatives under uncertainty), learning (changing behaviour based on experience), and language processing. In an interactive system, these are not separate episodes; they interleave continuously. A user filling out an online insurance quote is simultaneously reading field labels (perception and language), deciding which coverage band applies (decision-making), recalling the registration number of a car parked outside (long-term memory retrieval), and keeping track of how many steps remain in the form (working memory).

The critical design fact about cognition is that it is bounded. Herbert Simon's notion of "bounded rationality" captures this: people do not optimise, they satisfice — they accept the first option that is good enough, because exhaustive evaluation is too expensive. This is why users famously do not read pages but scan them, and why they will click a plausible-looking link rather than study a navigation taxonomy. Designs that assume careful, complete, rational reading of all available information are designing for a user who does not exist.

Two bounds matter most for interface structure:

Processing speed. Mental operations take measurable time. A simple perceptual cycle takes on the order of 100 milliseconds; a cognitive comparison or decision step takes roughly 70 ms; a motor action takes roughly 70 ms. These sound trivially small, but they accumulate. An interface that forces a user to make eleven separate decisions to complete a routine task imposes a measurable and felt burden, even if each decision is easy. Furthermore, decision time grows with the number of alternatives: Hick's Law states that choice reaction time increases approximately logarithmically with the number of equally probable options. A navigation bar with 24 undifferentiated links is slower to use than one with six grouped categories, even though the second structure technically requires two clicks instead of one.
Working memory capacity. The amount of information a person can actively hold and manipulate is extremely small. George Miller's classic estimate was "seven plus or minus two" chunks; later research by Nelson Cowan suggests a more realistic figure of about four chunks for material that cannot be rehearsed. The practical implication is severe: any design that requires the user to carry information across screens — a reference number shown on step 2 and required on step 5, or a measurement unit declared in a header and needed twenty rows later — is gambling against a stingy memory system.

A frequent misreading is that "7 ± 2" dictates menu length. It does not. The limit applies to information that must be held in mind, not to items that remain visible on screen. A visible list of twenty options imposes a search and scanning cost, not a memory cost. A dialog that flashes five values for three seconds and then asks a question about them imposes a memory cost. Distinguishing these two situations is one of the most practically useful skills a designer can develop.

Cognitive activity also differs in mode. Psychologists distinguish controlled (conscious, deliberate) processing from automatic (unconscious, practised) processing — a distinction popularised as "System 2" and "System 1" thinking by Daniel Kahneman. Controlled processing is slow, serial, effortful, and capacity-limited, but flexible: it is what you use when configuring an unfamiliar VPN client. Automatic processing is fast, parallel, effortless, and hard to suppress, but inflexible: it is what lets a touch-typist produce text without attending to individual keys, or an experienced driver change gear while holding a conversation.

Property	Controlled processing	Automatic processing
Speed	Slow	Fast
Effort / attentional demand	High; occupies working memory	Low; largely bypasses working memory
Parallelism	Essentially serial — one task at a time	Can run in parallel with other tasks
Flexibility	Can handle novelty and exceptions	Rigid; triggered by familiar cues
Typical interface situation	First-time setup, error recovery, unfamiliar terminology	Expert use of a daily tool, keyboard shortcuts, habitual click paths
Characteristic failure	Overload, abandonment, slips in reasoning	Capture errors — running a familiar sequence when a different one was intended

Good design serves both modes. Novices need controlled processing to be cheap: clear labels, visible structure, explicit guidance, forgiving defaults. Experts need automaticity to be supported: stable layouts (so muscle memory remains valid), keyboard accelerators, and consistent placement. The two goals can conflict. A redesign that relocates the "Send" button improves nothing for a novice but destroys thousands of hours of accumulated automatism in daily users — which is precisely why email clients that move core controls generate disproportionate outrage. Automaticity also produces a distinctive error class: capture errors, where a well-learned sequence hijacks an intended variation. A user who intends to "Save As" but types the habitual Ctrl+S is committing a capture error, and the system — not the user — should be designed to tolerate it through undo and non-destructive defaults.

Human Perception

It is tempting to think of perception as a camera: light enters the eye, and an image appears in the mind. This model is wrong in every important respect. Perception is an active, constructive, inferential process. The retina delivers a noisy, low-resolution, upside-down, interrupted stream of data with a literal blind spot in it, and the visual system builds from this a stable, meaningful scene using prior knowledge, expectation, and context. What you "see" is the brain's best hypothesis about what is out there.

Several consequences follow directly for interface design:

Expectation shapes interpretation. Users see what they expect to see. A user looking for a "Submit" button may read a button labelled "Send" as "Submit" and later misremember it; a user who expects a dialog's right-hand button to be the confirming action will click it without reading. This is why conventions matter so much: they align the system with the hypothesis the user is already generating.
Context changes appearance. The same grey swatch looks lighter on a dark background and darker on a light one (simultaneous contrast). A 14 px label looks cramped beside a 48 px heading and comfortable beside 12 px body text. There is no such thing as an element's appearance in isolation — only its appearance in a layout.
Grouping is automatic. The Gestalt principles describe how the visual system imposes organisation before conscious thought intervenes. These are not stylistic preferences; they are perceptual facts that your layout will obey whether you intend it or not.

Gestalt principle	Perceptual effect	Interface application
Proximity	Items close together are seen as a group	Place a form label nearer to its own field than to the field above; tighten spacing within a card and loosen it between cards
Similarity	Items sharing colour, shape, or size are seen as related	Style all primary actions identically so "clickable" is learnable from appearance alone
Common region	Items inside a shared boundary are seen as a unit	Panels, cards, and bordered fieldsets that bind related settings together
Continuity	The eye follows smooth lines and alignment	Aligning field edges creates a clean vertical scan path; ragged alignment forces re-fixation
Closure	Incomplete shapes are perceived as whole	Icons can be minimal; a partially visible row at the fold signals "more content below"
Figure–ground	One region is seen as the object, the rest as background	Modal dialogs with dimmed overlays pull the dialog forward as figure

A notorious real-world failure of proximity: a form in which each label sits directly above the preceding field's input box rather than its own. Users dutifully type their surname into the box labelled, to their eyes, "Surname" — which the system reads as "First name." Nothing is wrong with the code; the grouping is wrong, and perception does the rest.

Visual hierarchy is the deliberate exploitation of these principles to control the order in which elements are noticed. The eye is drawn preferentially to high contrast, large size, strong colour, isolation (whitespace around an element), unusual shape, faces, and motion. By manipulating these variables, a designer can effectively dictate a reading sequence. A well-constructed landing page might establish three tiers: a dominant headline, a visually distinct primary call-to-action, and a quieter body of supporting text and secondary links. The test is simple and worth applying routinely: squint at the screen, or blur it heavily, and note what still stands out. If the most prominent element is a decorative image or a "Cancel" button, the hierarchy is working against the task.

Hierarchy fails in two directions. Too little differentiation produces a flat screen where everything competes and nothing leads — the user must read linearly, which is slow and effortful. Too much emphasis produces the same result by a different route: if six elements all shout, none is prominent. Emphasis is a zero-sum resource. Every element promoted demotes everything else.

Perceptual limitations impose hard boundaries on what hierarchy can achieve. Key ones include:

Contrast sensitivity. Legibility depends on luminance contrast between text and background far more than on colour difference. WCAG specifies a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (AA level), rising to 7:1 and 4.5:1 at AAA. Light grey text on a white background — a recurring fashion in minimalist design — may measure 2.5:1 and become genuinely unreadable for older users, whose lens yellowing and reduced pupil size can require several times more light contrast than a twenty-year-old needs.
Colour vision deficiency. Roughly 8% of men and 0.5% of women of northern European descent have some form of colour vision deficiency, most commonly red–green. An interface that signals validity solely through red and green borders conveys nothing to these users. The remedy is redundant coding: pair colour with an icon, a text label, a shape, or a position. A map legend that distinguishes regions only by hue should also distinguish them by pattern or direct labelling.
Foveal versus peripheral vision. Sharp, detailed, colour-rich vision is confined to the fovea — roughly two degrees of visual angle, about the width of a thumbnail at arm's length, or a few characters of text at normal reading distance. Everything else is peripheral: low acuity, poor colour, but highly sensitive to motion and gross luminance change. This explains both why users miss static text placed away from their focus and why an animated banner in the periphery is so distracting that users have learned to suppress it entirely ("banner blindness").
Pre-attentive processing. A small set of visual features — hue, orientation, size, motion, curvature, enclosure — is processed in parallel across the whole visual field in under about 200 ms, before focused attention engages. A single red item among grey items "pops out" regardless of how many grey items there are. But this only works for a single distinguishing feature against a uniform background. Conjunctions of features (find the item that is both red and square) require slow serial search. Hence: use one strong, unique visual treatment for the one thing that must be found instantly.

Putting this together, the design rule is that criticality should map onto perceptual salience. If a destructive action, a safety warning, or a state change matters most, it must be the thing that wins the pre-attentive competition — through isolation, contrast, size, and placement in the expected scan path — and it must not be competing with eight animated promotional elements. Conversely, routine or rarely-needed controls should be perceptually quiet. In a radiology viewer, a critical "unverified result" flag should not be rendered in the same soft grey as the file-naming metadata; in a cockpit or process-control display, a master caution indicator earns a unique colour, a unique location, and an auditory channel of its own.

Attention and Its Limits

Attention is the mechanism that allocates limited processing capacity to a subset of available information. It is best thought of not as a spotlight the user chooses to point, but as a contested resource: partly directed by goals (top-down, endogenous control) and partly captured by the environment (bottom-up, exogenous capture by motion, loud contrast, sudden onsets).

Selective attention means that attending to one thing necessarily means not processing others. The classic demonstration is the "cocktail party effect": in a crowded room you can follow one conversation and remain almost entirely ignorant of the content of adjacent ones — yet your own name spoken nearby will break through. For interfaces, two implications follow. First, anything outside the user's current focus is, for practical purposes, invisible, no matter how legible it is. A help text placed in a right-hand sidebar while the user is typing in a centre-column field may as well not exist. Second, salience is the designer's lever: to be attended, an element must either lie on the user's goal-driven scan path or be strong enough to capture attention bottom-up. Research on web reading shows strong F-shaped and layer-cake scanning patterns on text-dense pages — heavy fixation on the top lines, on the left edge, and on headings — which tells you where goal-driven attention is likely to land by default.

Information overload occurs when the number of competing elements exceeds the user's capacity to triage them. Symptoms include longer task times, increased error rates, decision avoidance or abandonment, random clicking, and subjective frustration. Overload is not simply a matter of quantity — a dense spreadsheet can be perfectly usable because it is highly structured — but of unstructured quantity, where nothing indicates what to look at first. Remedies are well established:

Chunking and grouping: break long forms into labelled sections; group related settings in common regions; format long digit strings (a 16-digit card number as four groups of four) so each group becomes a single chunk.
Progressive disclosure: show the common 80% of controls, and hide advanced options behind "Advanced settings" or an expandable panel. This reduces the visible decision space without removing capability.
Defaults: every sensible default is a decision the user does not have to make. Defaults are the cheapest usability intervention available and among the most powerful.
Ruthless prioritisation: remove or demote content that does not serve the primary task. A dashboard with forty metrics communicates less than one with six well-chosen ones.
Deferred and batched notifications: interruptions consume attention and evict working memory. Batching non-urgent alerts protects the user's current task.

Change blindness is the failure to notice a substantial change to a visual scene when the change coincides with a disruption — a flicker, a saccade (eye movement), a page transition, a brief occlusion. In laboratory demonstrations, observers routinely fail to notice that a large object has vanished from a photograph across a brief blank frame. In interfaces, change blindness explains why users miss a validation error that appears at the top of a page after a submit, why a quietly updated total in a shopping basket goes unnoticed, and why a status message that replaces another status message in the same slot can seem never to have changed at all. Mitigations include: place feedback near the locus of attention (next to the offending field, not only at the page top); use a brief, purposeful transition or highlight to draw the eye to the changed region; avoid full-page reloads where a targeted update would preserve context; and never rely solely on a silent change of state to communicate something important.

Inattentional blindness is the related failure to notice a fully visible, often conspicuous object because attention is engaged elsewhere. The canonical demonstration is Simons and Chabris's "invisible gorilla" study: observers counting basketball passes frequently fail to see a person in a gorilla suit walk through the scene. The design lesson is sobering, because it is not solved by making the element bigger or more colourful — the gorilla was neither small nor subtle. When a user is deeply engaged in a goal, elements irrelevant to that goal are filtered out pre-consciously. Users genuinely do not see the cookie banner, the "did you mean?" suggestion, or the upsell panel. If something must be noticed, it generally has to be placed in the path of the task itself — in the flow the user must traverse to proceed — rather than merely displayed somewhere on the same screen. This is why genuinely critical confirmations are modal: they interrupt the task because nothing less reliably penetrates.

Banner blindness is inattentional blindness that has become learned and habitual: users have internalised the visual signature of advertising (rectangular, animated, right-rail or top-of-page, high-saturation) and filter it automatically. The perverse consequence is that legitimate content styled like an ad becomes invisible — an important warning for designers tempted to make an important notice "stand out" by making it look promotional.

Memory: Types and Implications for Design

The standard multi-store account distinguishes three systems, each with radically different capacity and duration characteristics.

Memory store	Capacity	Duration	Role in interaction
Sensory memory (iconic/echoic)	Large but raw and unprocessed	~200–500 ms visual; ~2–4 s auditory	Buffers the display long enough for attention to select from it; underlies the perception of continuity in animation
Working (short-term) memory	~4 chunks (classically 7 ± 2)	~15–30 s without rehearsal	Holds the current sub-goal, a value being transcribed, the position in a multi-step process
Long-term memory	Effectively unlimited	Minutes to a lifetime	Stores conventions, learned procedures, domain knowledge, expectations about how systems behave

Working memory is the bottleneck of interaction. Baddeley's influential model subdivides it into a phonological loop (verbal/acoustic material), a visuospatial sketchpad (images and spatial layout), an episodic buffer, and a central executive that coordinates them. Two practical facts emerge. First, the verbal and visual sub-systems are partially independent, so a task that combines a diagram with spoken narration loads memory less than one that combines a diagram with competing on-screen text. Second, working memory decays fast and is catastrophically vulnerable to interruption. A user who memorises a six-digit two-factor code and is interrupted by an incoming call for twelve seconds will frequently have lost it. This is why modern platforms auto-fill SMS codes, why "copy to clipboard" buttons are provided next to reference numbers, and why a well-designed checkout keeps the order summary permanently visible rather than making the user remember the total from the previous page.

Typical interface patterns that overload working memory, with remedies:

Cross-screen transcription. Showing a booking reference on one screen and requiring it on another. Remedy: carry it forward automatically, or keep it persistently visible.
Modal dialogs that obscure the data they ask about. "Are you sure you want to delete these items?" with the list hidden behind the dialog. Remedy: restate the specifics inside the dialog — "Delete 14 files from /project/archive?"
Instructions that disappear before they are needed. A tooltip or placeholder that vanishes the moment the user clicks into the field, taking the format requirement with it. Remedy: persistent hint text beneath the field, or inline format masking.
Deep, unlabelled wizards. Multi-step flows that give no indication of where the user is or what remains. Remedy: a step indicator ("Step 3 of 5: Delivery") externalises the position so it need not be held in mind.
Mode changes without visible mode indicators. The user must remember that the tool is currently in "erase" rather than "draw" mode. Remedy: visible, persistent mode feedback — a highlighted toolbar state and a changed cursor.

Long-term memory is effectively unbounded in capacity but imperfect in retrieval. It is commonly divided into declarative memory — semantic (facts and concepts: "a floppy-disk icon means save") and episodic (personally experienced events: "last week I found the export option under the File menu") — and procedural memory (skills: how to drag, how to pinch-zoom, how to touch-type). Procedural memory is slow to build but extremely durable, which is exactly what underlies expert automaticity.

For design, the significance of long-term memory is that it is where conventions live. A user arriving at a new site already possesses a rich body of learned expectations: a logo in the top-left returns to the home page; an underlined coloured word is a link; a magnifying glass means search; a trash can means delete; a gear means settings; a horizontal three-line icon opens navigation; swiping down at the top of a list refreshes it. Each of these is an item of knowledge already stored at no cost to you. Jakob's Law — "users spend most of their time on other sites, so they prefer your site to work the same way as all the other sites they already know" — is really a statement about reusing long-term memory. Novel interaction metaphors are not inherently wrong, but they impose a learning cost that must be repaid by genuine benefit; most redesigns that discard conventions are spending a resource they did not earn.

Long-term memory also degrades in predictable ways that interfaces must tolerate. Retrieval failure is far more common than genuine loss — people recognise what they cannot recall. Memory is reconstructive, so users confidently misremember details (which menu an item was under, what the password rules were). Interference is severe: a user with forty accounts cannot keep forty passwords distinct, which is precisely why password policies demanding frequent change of complex strings produce written-down passwords and systematic variants (Summer2024! becoming Autumn2024!) rather than security.

These facts converge on one of the most durable heuristics in the field: favour recognition over recall. Recall requires generating information from memory with few cues; recognition requires only judging whether presented information is familiar, and is dramatically faster and more reliable. The difference is the difference between an essay question and a multiple-choice question.

Task	Recall-based design (harder)	Recognition-based design (easier)
Issuing a command	Blank command line requiring exact syntax	Menus, toolbars, or a command palette with searchable, listed commands
Entering a country	Free-text field expecting the official name	Type-ahead select list showing matching options
Returning to earlier work	Remembering the file path and typing it	"Recent files" list with names, thumbnails, and dates
Re-entering a delivery address	Retyping from memory	Saved addresses presented as selectable cards
Knowing where you are	Remembering the navigation path taken	Breadcrumb trail and highlighted current section
Applying a password rule	Reading the rules once, then recalling them while typing	Live checklist that ticks each requirement as it is satisfied

Recognition is not a universal cure. Experts often prefer recall-based shortcuts because they are faster once learned — a seasoned developer types git rebase -i HEAD~3 far more quickly than they could navigate a GUI. The mature answer is to layer both: a discoverable, recognition-friendly path for learning, with recall-based accelerators exposed alongside it. This is exactly what a menu does when it prints "Ctrl+Shift+P" beside the command: it teaches the shortcut through recognition until it migrates into procedural memory.

The broader principle is knowledge in the world versus knowledge in the head (Donald Norman). Information placed in the environment — visible, legible, persistent — does not need to be stored by the user at all. Practical applications include: persistent order summaries during checkout; showing the previously entered value next to an edit field; keeping the question visible while the answer is being typed; displaying units, formats, and constraints inline rather than in a one-time instruction; auto-saving drafts so an interruption is not catastrophic; and preserving entered data when a form fails validation rather than clearing it. Each of these converts a memory task into a perception task, and perception is cheap where memory is expensive.

Information Processing Models

The information-processing tradition models the human as a system that takes in input, transforms it, and produces output — deliberately analogous to a computer, and useful precisely because it lets us quantify and predict performance. The classic three-stage formulation is:

Perception (input): sensory registration and encoding of the stimulus — the eye lands on the screen, the display is encoded as a recognisable pattern ("that is a red warning triangle").
Cognition (central processing): interpretation, comparison against memory, decision about what to do — "red triangle means the upload failed; I should retry."
Response execution (output): selecting and carrying out a motor action — moving the pointer to "Retry" and clicking it.

Card, Moran and Newell's Model Human Processor formalises this as three interacting processors (perceptual, cognitive, motor) with associated memories and nominal cycle times — roughly 100 ms, 70 ms and 70 ms per cycle respectively, each with a substantial range. Chaining these cycles yields surprisingly accurate predictions. A simple reaction to an expected stimulus takes roughly one perceptual plus one cognitive plus one motor cycle — around 240 ms — which matches laboratory simple-reaction data well. More elaborate predictive techniques (GOMS and the Keystroke-Level Model) assign times to elementary operators — a keystroke at roughly 0.2 s for a skilled typist, pointing at roughly 1.1 s, mental preparation at roughly 1.35 s, homing between keyboard and mouse at roughly 0.4 s — and sum them to estimate expert task time before a line of code is written. If a redesign removes two mental-preparation operators and one homing operation from a transaction performed four hundred times a day by a call-centre agent, the saving is substantial and calculable.

Each stage introduces its own characteristic delays and failures:

Stage	Typical delay source	Typical error	Design response
Perception	Low contrast, small targets, cluttered display, element outside the scan path	Misreading a label; failing to detect a state change	Increase contrast and salience; place critical items in the expected path; reduce clutter
Cognition	Ambiguous terminology, many alternatives (Hick's Law), unfamiliar concepts, required mental arithmetic or unit conversion	Choosing the wrong option; mode errors; abandoning the task	Plain language, sensible defaults, grouping, doing the computation for the user
Response execution	Small or distant targets (Fitts's Law), fiddly drag operations, deep menu traversal	Slips — clicking the adjacent item, mistyping	Enlarge and position targets well; separate destructive from benign controls; provide undo

Two quantitative laws are worth stating explicitly because they govern the outer stages. Fitts's Law holds that the time to acquire a target is a function of the distance to it and its size: large, near targets are fast; small, far targets are slow. This is why screen edges and corners are valuable real estate (the pointer cannot overshoot them, making them effectively infinite in depth), why mobile touch targets are specified at around 44–48 px, and why a "Delete" control placed immediately adjacent to a frequently used "Save" invites slips. Hick's Law, as noted, holds that decision time rises logarithmically with the number of options, which argues for structured, hierarchical choice rather than vast flat lists — provided the structure itself is comprehensible, since a badly categorised hierarchy simply moves the cost from decision to search.

Reaction and completion time are not fixed quantities; they vary systematically with:

Task complexity — number of alternatives, number of sub-decisions, whether information must be transformed (converting currencies, computing a date difference) rather than merely read.
Familiarity and practice — performance on a repeated task improves following a power law of practice; the same screen that takes a novice ninety seconds may take a daily user eight, which is why usability measures taken on first use do not predict expert throughput and vice versa.
Stimulus–response compatibility — how naturally the control maps to its effect. A volume slider that increases upward is compatible; four stove knobs in a row controlling burners in a square is not, and the resulting mapping errors persist for decades of use.
Clarity and timeliness of feedback — ambiguous or delayed feedback forces the user to re-perceive and re-decide, effectively repeating the whole processing loop.
Stress, fatigue, divided attention, and age — all of which narrow available capacity, which is why systems used in high-pressure or mobile contexts must be designed with far more generous margins than office software.

Thinking in terms of bottlenecks is the practical payoff. Walk through a task and count the operations the interface imposes: how many fixations, how many decisions, how many mode switches, how many keystrokes, how many items held in memory. Then attack whichever stage dominates. If the bottleneck is perceptual, visual design will help and shortening the workflow will not. If the bottleneck is cognitive — the user cannot tell which of two similarly named options applies — then enlarging buttons is wasted effort; clearer labels, examples, or an automated decision are what is needed. A common and high-value move is to shift work from the human to the machine entirely: deriving the card type from the card number instead of asking; detecting the country from the address; pre-filling the date; validating as the user types rather than on submit. Every eliminated decision point removes a full perceive–decide–act cycle along with its error probability.

Perception of Time and Feedback

Responsiveness is a perceptual and cognitive phenomenon, not purely an engineering metric. Users do not experience milliseconds; they experience whether a system feels alive, under their control, and trustworthy. The widely used thresholds, originating with Robert Miller's 1968 work and popularised by Jakob Nielsen, are:

Duration	Perceptual experience	Required feedback
Under ~100 ms	Feels instantaneous; the result is perceived as caused directly by the action	None beyond the result itself — the response is the feedback
~100 ms – 1 s	Noticeable delay, but the flow of thought is preserved; the user still feels in control	Usually none, though a subtle state change (button pressed state) reassures
~1 s – 10 s	Attention begins to wander; the user is aware of waiting for the computer	A determinate indicator: spinner, progress bar, skeleton screen, status text
Over ~10 s	The user disengages, switches tasks, or abandons	Percent-done progress, time estimate, ability to cancel, and notification on completion

The 100 ms threshold matters particularly because it underpins the sense of direct manipulation. When dragging an object, scrolling a list, or resizing a window, the on-screen element must track the input essentially in lock-step; even modest lag breaks the illusion that one is handling an object rather than instructing a machine. The same threshold governs keystroke echo, hover states, and button press feedback. Latency above it does not merely annoy — it changes the phenomenology of the interaction from manipulation to command-and-wait.

Missing feedback produces compounding errors. If a user clicks "Submit" and nothing visible changes, the only available hypothesis is that the click was not registered — so they click again. On a payment form this can produce duplicate charges; on a record-creation form, duplicate records; on a lift or pedestrian crossing, repeated presses that do nothing. The same logic explains hammering a browser's reload button, double-submitting a comment, or unplugging a device mid-firmware-update because the progress indicator stalled silently. Robust practice is to acknowledge the input immediately and separately from completing the work: disable or change the state of the control on click, show an inline spinner or "Processing…" label, and — because the client cannot guarantee uniqueness — enforce idempotency on the server so that a duplicated request cannot produce a duplicated effect. Feedback must also cover outcomes, not just activity: a silent success is almost as confusing as silent failure, which is why toast confirmations ("Draft saved", "Message sent") exist.

Perceived performance can diverge substantially from measured performance, and designing for perception is legitimate engineering, not deception — provided it does not misrepresent what is actually happening. Established techniques include:

Skeleton screens. Rendering grey placeholder shapes in the layout of the forthcoming content makes a page feel faster than a spinner does, because the user begins parsing the structure immediately and the eventual content appears to "fill in" rather than "arrive."
Optimistic UI. Reflecting the expected result immediately — the "like" turns blue, the message appears in the thread — while the request completes in the background, with graceful reconciliation if it fails. Risky for consequential or irreversible actions; excellent for small, high-frequency, reversible ones.
Progress indicators that behave honestly. Determinate bars for operations of known length; indeterminate indicators only when duration genuinely cannot be estimated. A bar that sticks at 99% erodes trust more than no bar at all. Where several sub-operations occur, naming the current one ("Compressing images… 3 of 12") converts dead waiting time into informative progress.
Animation used to mask and explain. A 200–300 ms transition can cover a brief load while preserving spatial continuity, showing the user where the new content came from. Beyond roughly 400 ms, animation becomes the delay rather than a cover for it.
Active waits and preloading. Letting users continue to do something useful during a wait — reviewing a summary, entering the next field — shortens perceived duration, because occupied time is consistently judged shorter than unoccupied time. Prefetching likely-next content and lazy-loading below-the-fold material shift the wait out of the user's critical path.
Early first paint. Showing the header, navigation, and above-the-fold text before the rest arrives gives the user something to read; perceived start time matters more than total completion time for satisfaction.

Two further perceptual facts about waiting are worth knowing. First, uncertain waits feel longer than known, finite waits — hence the value of estimates and queue positions ("You are number 4 in the queue"). Second, the end of an experience disproportionately colours the memory of it (the peak–end rule), so a flow that ends with a clear, pleasant confirmation is remembered more favourably than one of equal duration that simply stops. None of this licenses artificially slowing a system or faking progress; dishonest feedback, once detected, costs more trust than the delay it concealed.

Taken as a whole, this body of knowledge converts vague advice about "user-friendliness" into a set of defensible, testable constraints: keep the number of simultaneous decisions small, make the important thing the salient thing, never ask users to hold what you could show them, exploit learned conventions rather than fighting them, remove processing stages rather than merely decorating them, and respond fast enough — or visibly enough — that users always know the system heard them.

Alignment with Learning Outcomes

MO1: Directly supported. The topic distinguishes sensory, working, and long-term memory, states their respective capacities and durations, and derives interface constraints from each — chunking, persistent on-screen information, recognition over recall, and tolerance of interruption.
MO2: Partially supported. The discussion of perception as expectation-driven construction, learned conventions stored in long-term memory, mode errors, and capture errors explains the cognitive basis on which mismatches between user expectations and system behaviour generate systematic, predictable errors, which the module develops further into explicit mental-model analysis.
MO3: Only indirectly supported. This topic does not teach Hierarchical Task Analysis, but it supplies the cognitive rationale for task decomposition — counting perceptual, decision, and motor steps and identifying processing bottlenecks within a task sequence.
MO4: Not directly addressed. Usability evaluation techniques are not covered here; however, the cognitive limits described provide the criteria (error, memory load, attention, response time) against which any evaluation method ultimately judges a design.
MO5: Indirectly supported. The principles of visual hierarchy, grouping, progressive disclosure, salience, feedback timing, and target sizing are the interaction design principles a low-to-mid fidelity prototype must embody, though prototyping technique itself is not taught in this topic.

NotesQuantitative figures used (Model Human Processor cycle times, KLM operator times, Miller/Nielsen response-time thresholds, WCAG contrast ratios, Cowan's ~4-chunk working memory estimate, colour-vision-deficiency prevalence) are standard published values and are given as approximations suitable for teaching. Useful follow-on readings: Norman, *The Design of Everyday Things*; Johnson, *Designing with the Mind in Mind*; Card, Moran & Newell, *The Psychology of Human-Computer Interaction*; Simons & Chabris (1999) on inattentional blindness. Possible in-class activities: a squint test on three live websites to assess visual hierarchy; a contrast-ratio audit using a checker tool; a KLM estimate comparing two checkout flows; a change-blindness demonstration using before/after screenshots.

2

Videos on This Topic

▶

Every interface you design is used by a person with a limited and predictable set of cognitive abilities. We perceive only part of what is in front of us, we attend to even less, and we can hold only a handful of items in mind at once before they decay or get overwritten. Theories of human information processing — perception, attention, working memory, long-term memory, and the time course of feedback — give us a vocabulary for explaining why some interfaces feel effortless and others feel exhausting.

In this course, these ideas are the justification behind many design rules you will otherwise have to memorize. Recognition over recall, chunking, consistent placement, visible system status, and short feedback latencies are not style preferences; they are responses to documented limits in human cognition. Understanding the underlying mechanism lets you reason about novel design situations instead of guessing.

The videos below come from the Nielsen Norman Group, a long-established usability research and consulting firm. As you watch, note two things: first, the specific claim about human capability being made (how much, for how long, under what conditions), and second, the concrete interface implication drawn from it. Also notice how the third video shifts from describing cognition to using a cognitive model as an evaluation tool — that bridge from theory to method is exactly what we are after.

3

Video 1: Short-Term Memory Limitations Impact User Interface Design

▶

NNgroup · 3:23 · 11,228 views · 4y ago · captions — Watch on YouTube

About this video

A short explainer on short-term memory: how little information people can hold at one time and how quickly it fades when attention shifts. The video connects these limits to common interface decisions, such as not forcing users to carry information from one screen or step to the next. Expect practical examples of designs that respect — or violate — these constraints.

Why this video

It directly addresses the memory subtopic with concrete capacity and duration claims, and the Nielsen Norman Group is a credible source for research-grounded usability guidance stated in plain language.

4

Video 2: Working Memory and External Memory

▶

NNgroup · 4:39 · 7,656 views · 5y ago · captions — Watch on YouTube

About this video

This video distinguishes working memory — the limited mental workspace used while performing a task — from external memory, meaning information the interface itself displays or stores on the user's behalf. It argues that interfaces should offload remembering onto the screen rather than onto the user. Likely examples include keeping instructions, entered values, or prior selections visible during multi-step tasks.

Why this video

It extends the memory subtopic beyond raw capacity into a design strategy, which is the key move for this course: treating the interface as an extension of the user's cognitive system.

5

Video 3: Cognitive Walkthroughs Help Assess Interface Learnability

▶

NNgroup · 4:45 · 14,522 views · 3y ago · captions — Watch on YouTube

About this video

An introduction to the cognitive walkthrough, a task-based usability inspection method in which evaluators step through a task as a first-time user would and ask whether the user would know what to do and whether they would recognize that their action was correct. The video explains the purpose of the technique, its focus on learnability, and how it differs from other evaluation approaches. Expect a walkthrough of the questions evaluators ask at each step.

Why this video

It shows cognition applied as an analytical lens — the method is built directly on assumptions about perception, attention, and feedback — and it connects this topic to the evaluation methods covered later in the module.

6

How These Videos Support the Learning Outcomes

▶

The first two videos support MO1 by distinguishing short-term and working memory, naming their practical capacity limits, and translating those limits into interface constraints such as minimizing recall and externalizing information on screen. The cognitive walkthrough video supports MO2, since the method's core questions surface exactly where a user's expectation diverges from what the system actually does, and it supports MO4 by illustrating a structured, expert-driven inspection technique you can later compare against empirical user testing. Together they supply the cognitive rationale you will draw on when decomposing tasks (MO3) and when justifying the layout, labeling, and feedback choices in your prototype (MO5).

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Knowledge, Mental Models, and Conceptual Frameworks

1

Knowledge, Mental Models, and Conceptual Frameworks

▶

Every time a person sits down in front of an unfamiliar interface, they are not starting from zero. They arrive carrying a dense, partly organised, partly contradictory store of knowledge: facts about how machines usually work, habits of action learned on other devices, expectations about what a word like "Save" or an icon like a trash can should mean, and a general theory about causality in digital systems. Interaction is therefore never a simple matter of a user "reading" an interface. It is a continuous process of interpretation, in which the visible surface of a system is matched against internal representations the user already possesses. When that match is good, the interface feels obvious, even invisible. When it is poor, the user experiences hesitation, false starts, and errors that appear irrational to the designer but are perfectly logical given the user's internal picture of the system. This topic examines the structure of that internal picture — the knowledge types that feed it, the mental models it forms, the conceptual models designers attempt to communicate, the metaphors that bridge the two, and the feedback loops through which models evolve or stagnate.

Types of knowledge users bring to interactions

Cognitive psychology distinguishes between several kinds of knowledge, and the distinction is directly useful in interface design because each type is acquired differently, decays differently, and fails differently.

Declarative knowledge is "knowing that" — factual, propositional knowledge that can usually be verbalised. A user's declarative knowledge of an email client might include: "there is a folder called Drafts," "attachments have a size limit," "the paperclip icon attaches a file," "BCC hides recipients from one another." This knowledge is relatively easy to acquire from documentation, labels, tooltips, or a colleague's explanation, and it is also relatively easy to forget. Crucially, declarative knowledge can be recognised rather than recalled: a user who cannot remember that a particular menu contains the export command will nonetheless recognise "Export…" when they see it. This is the cognitive basis for the long-standing design maxim that interfaces should favour recognition over recall — visible menus, labelled icons, and browsable option lists let the interface carry the declarative load instead of the user's memory.

Procedural knowledge is "knowing how" — the compiled, often automatic sequences of actions that accomplish a goal. Experienced users of a spreadsheet do not consciously retrieve the fact that Ctrl+C copies; their fingers execute the sequence while attention remains on the data. Procedural knowledge is slow to acquire (it requires repeated practice) but extremely durable, and it is notoriously difficult to articulate. Ask a skilled user to explain exactly how they reorder slides in a presentation tool and they will often have to perform the action to describe it. Two design consequences follow. First, because procedural knowledge is built by repetition, consistency is enormously valuable: a shortcut or gesture that means the same thing everywhere becomes an automatic skill, whereas one that changes meaning between screens never compiles into a routine. Second, because procedural knowledge is automatic, it can misfire when the context changes. This produces capture errors, where a well-learned routine hijacks a less-practised intention — the classic case is the user who intends to "Save As…" but whose fingers execute the more frequent plain "Save," or the driver of a hire car who reaches for a windscreen wiper stalk that is actually the indicator.

A third category worth naming is prior domain and system knowledge — knowledge transferred from related systems, from the professional domain, or from the physical world. A radiographer approaching new imaging software already knows what a study, a series, and a window level are; the software does not have to teach those concepts, only its particular expression of them. Equally, a user who has used three photo applications has a generalised schema: there will be an import step, a library view, non-destructive edits, and an export step. Transfer can be positive (the prior schema accelerates learning) or negative (the prior schema produces confident wrong predictions). Negative transfer is a persistent problem when platforms diverge: a long-time Windows user on macOS repeatedly reaches for the wrong modifier key; a user moving from a system where the leftmost button is "OK" to one where it is "Cancel" will confirm destructive actions by reflex. The deep point is that prior knowledge is not optional for the designer to consider — users will apply it whether or not the designer intends them to.

Finally, gaps and misconceptions in user knowledge are a primary source of interaction errors, and the two are not the same. A gap is an absence: the user does not know that a feature exists, so they do the task the long way or abandon it. Gaps typically produce inefficiency and non-discovery rather than catastrophe. A misconception is an incorrect belief held with confidence, and it is far more dangerous because the user acts decisively on it. A frequently observed misconception is that "closing the window exits the application and discards nothing," or that deleting a file from a synced cloud folder on one device only affects that device, or that a private browsing window hides activity from an employer's network. Each of these produces a confident action with an unintended and sometimes irreversible result. The design responses differ accordingly: gaps are addressed with discoverability (visible affordances, progressive disclosure, contextual hints), while misconceptions are addressed with corrective feedback, explicit state display, and reversibility.

Knowledge type	Nature	How acquired	Typical failure mode	Design response
Declarative	Facts about entities, labels, limits, locations	Reading, instruction, exploration; fast to learn, fast to forget	Forgetting a command name or where an option lives	Visible labels, menus, search, tooltips — support recognition over recall
Procedural	Automated action sequences and motor routines	Repeated practice; slow to learn, highly durable	Capture errors; routines misapplied in a changed context	Consistency of mappings and shortcuts; confirmation for irreversible steps
Prior system/domain	Schemas transferred from similar tools or the work domain	Experience elsewhere; applied automatically	Negative transfer — confident but wrong expectations	Honour platform and domain conventions; signal deliberate departures
Gaps	Missing knowledge the user is aware or unaware of	Never encountered	Feature non-discovery, inefficient workarounds	Discoverability, onboarding, contextual suggestions
Misconceptions	Confidently held but incorrect beliefs	Faulty inference or misleading cues	Decisive wrong actions, data loss, security lapses	Explicit state visibility, corrective feedback, undo

Mental models: internal representations of systems

A mental model is the internal, runnable representation a user holds of how a system is structured and how it behaves. The word "runnable" is important: the defining property of a mental model is that the user can simulate it mentally to answer "what will happen if…?" without actually performing the action. A person who understands a thermostat as a switch that turns the heating on until a target temperature is reached will predict that setting it to 30°C does not heat the room faster. A person whose model is a "valve" — more dial equals more heat — will predict the opposite, and will set the dial too high and then be too hot. Both are running a model; only one is accurate. This single example, drawn from classic work on folk theories of heating, shows how a mental model determines action and produces systematic, repeatable error patterns rather than random mistakes.

Mental models carry out several cognitive functions at once. They support prediction ("if I drag this file onto that icon, it will be copied, not moved"), explanation ("the page is blank because my filter is still applied"), planning ("I'll duplicate the layer first so I can revert"), and diagnosis ("nothing is printing — probably the job is queued on the other printer"). Without a model, a user is reduced to trial and error, which is slow, anxiety-inducing, and unsafe in systems where actions have consequences. With a model, large parts of the interaction become inference rather than exploration.

Mental models are built incrementally and opportunistically. A user forms a provisional hypothesis from the first screen they see, acts on it, observes the response, and revises. Over a few minutes of use, a rough topology emerges — "there's a list on the left and a detail pane on the right; selecting in the list changes the right." Over weeks, the model acquires depth: conditional rules, exceptions, knowledge of where the system is slow, superstitions about what causes crashes. Because the model is assembled from observed behaviour rather than from the system's source code or data schema, it reflects what the interface reveals, not what the system actually is.

This leads to the most important property for designers: mental models are almost never complete or fully accurate. They are typically parsimonious (containing only as much as the user needs), unstable (changing with recent experience), superstitious (containing causally irrelevant steps that happened to co-occur with success), and full of gap-filling assumptions imported from prior experience. A user who cannot see how cloud synchronisation works may infer an analogy to emailing a file to oneself, concluding that each device keeps its own independent copy — a plausible inference, and one that leads directly to surprise and data loss when a deletion propagates. Users also commonly hold a model that is correct in the common case but wrong at the boundaries: "the undo button undoes the last thing I did" is reliable until the last thing was a server-side action that cannot be undone.

The designer's obligation, then, is not to hope for accurate mental models but to anticipate the likely ones. Before building, it is worth asking: what will users assume this control does? What prior system are they most likely to map this onto? Which plausible-but-wrong model would lead to a harmful action here? Techniques such as asking participants to draw or narrate "what you think happens when you press Send" surface these models directly and cheaply. A famous illustration is the pedestrian crossing button or office thermostat that is not actually connected to anything: users continue to press it repeatedly because their model says "more pressing equals faster response," and the absence of feedback never contradicts them.

Conceptual models provided by designers

If a mental model is what the user builds in their head, a conceptual model is what the designer deliberately constructs and communicates: an explicit, coherent description of the entities the user should believe exist, the relationships among them, and the operations that can be performed on them. It is the designer's chosen story about the system — a simplification that is not necessarily how the implementation works, but is true enough to support correct prediction.

Consider three familiar conceptual models:

The file-and-folder model. Entities: files, folders, drives. Relationships: folders contain files and other folders; a file lives in exactly one place. Operations: create, open, move, copy, rename, delete. None of this corresponds to how a storage device physically works — there are no folders on a disk — but the model is coherent, learnable, and predictive.
The photo library model. Entities: a single library of photos, albums, edits. Relationships: an album references photos rather than containing copies; edits are non-destructive layers over an untouched original. Operations: import, organise, edit, export, delete. The key conceptual commitments here — references not copies, edits not overwrites — are exactly the points where users' prior file-and-folder model will mislead them, which is why these applications invest heavily in explaining "removing from an album does not delete the photo."
The version control model. Entities: working directory, staging area, commits, branches, remotes. This conceptual model is notoriously hard for newcomers precisely because the staging area has no everyday analogue; users arriving with a "save the file" model cannot predict the system's behaviour and resort to memorised command recipes — procedural knowledge without a supporting conceptual model, which collapses the moment something unusual happens.

A conceptual model is never conveyed by a written specification that users read. It is conveyed implicitly and continuously through the interface itself:

Visual structure and layout — what is grouped together implies what belongs together; a persistent sidebar of named collections implies that collections are first-class, enduring entities.
Terminology and labelling — calling something a "workspace" rather than a "project" or a "document" sets different expectations about sharing, persistence, and ownership. Inconsistent naming for one underlying entity (sometimes "board," sometimes "list," sometimes "page") fragments the user's model.
System responses and state display — an animation showing an item flying into a folder teaches containment; a sync status indicator teaches that a local file and a remote file are two aspects of one thing.
Onboarding, empty states, and documentation — an empty state that says "Boards hold your lists. Lists hold your cards." is a direct, cheap transmission of the conceptual model at precisely the moment it is needed.
The set of available operations — if there is no "move" command, only "copy" and "delete," the user infers something about the ontology of the system.

A well-designed conceptual model reduces the learning curve chiefly by mapping onto knowledge structures the user already has. When the mapping is strong, learning is largely a matter of attaching new labels to existing schemas rather than building new ones. This is why spreadsheet software succeeded so quickly with accountants: the conceptual model (a grid of cells containing values or formulas, arranged in rows and columns) mapped almost perfectly onto the paper ledger those users already understood, while adding one new idea — automatic recalculation — that could be learned in isolation. Good conceptual models are also economical: they introduce as few new entities as possible and make those entities behave uniformly. Every additional entity type, and every exception to a rule, costs the user memory and introduces a place where prediction can fail.

The central risk is discrepancy. Usability failures are very often not failures of graphic design or performance but of model mismatch: the user's mental model and the designer's conceptual model disagree, and the interface does not reveal the disagreement until something goes wrong. The structure of such failures is consistent — the user acts rationally and confidently on their model, the system behaves correctly according to its own, and the outcome surprises the user. Examples abound: a user believes "Reply All" includes only the people they can see, not the hidden BCC recipients; a user believes closing a laptop lid ends a video call; a user believes that a document shared "with anyone who has the link" is still effectively private; a user believes an autosaved draft is a separate copy and so edits destroy the original. In each case the remedy is not more training but a redesign that makes the real model visible — showing the recipient list before sending, showing an explicit "call continues in background" state, showing a plain-language description of who can access a document.

Interface metaphors as cognitive bridges

A metaphor is a deliberate device for transmitting a conceptual model quickly by borrowing an existing one. Structurally, it maps a source domain that the user already understands onto an unfamiliar target domain. The desktop metaphor maps the physical office — desk surface, documents, folders, filing, wastebasket — onto the file system and windowing environment. The shopping cart maps the supermarket trolley onto a provisional, editable collection of intended purchases that is not yet a transaction. The "card" metaphor in project management tools maps index cards pinned to a board onto task records that can be moved between stages.

When a metaphor works, it does a great deal of explanatory labour at no cost to the user. It conveys not just what things are called but what they afford and what constrains them. A shopping cart implies: you can add things, you can remove things, you can see the running total, nothing is final until you check out, and leaving the shop with the cart is not how it ends. A user who has never seen a particular e-commerce site can predict all of this instantly. Similarly, the trash can implies that deletion is a two-stage process and that retrieval before emptying is possible — a genuine behaviour of the system that would otherwise need explaining.

Metaphors also fail, and they fail in a characteristic way: the analogy is partial, and users do not know where its boundary lies. Because the mapping is so fluent, users over-extend it and predict behaviours the system does not support. Consider the desktop metaphor: a physical desk lets you place a paper partly under another and slide it out; files can be in two piles at once only by photocopying; nothing on a desk silently changes while you are away. A digital file system violates all three in various ways — aliases and shortcuts let one file appear in many places, synced files change without the user touching them, and windowing systems have z-order rules with no physical equivalent. The "folder" metaphor breaks when tagging is introduced, because a physical document cannot be in two folders simultaneously; users who try to reason about tags using containment logic ask "but where does the file actually live?" — a question the system considers meaningless. Likewise, skeuomorphic page-turning in e-readers implies fixed pagination, so users are confused when changing the font size changes the page numbers. The email "folder" that is really a label, the "desktop" that is really a directory, and the "recycle bin" that does not actually erase data from the disk all illustrate the same tension.

The practical discipline, therefore, is not to choose a metaphor and apply it uncritically but to audit it: to enumerate systematically where the mapping holds, where it is silent, and where it actively contradicts system behaviour. A simple analysis table makes the exercise concrete.

Source-domain property	User expectation it creates	Does the system honour it?	Design implication
A trolley holds items provisionally; nothing is bought until the till	I can add freely and decide later; adding is reversible and costless	Yes	Exploit it — make "add to cart" low-commitment and highly visible
Items in a trolley are physically reserved for me	Stock is held; the price will not change	No — stock and price can change	Breakdown point: show explicit stock/price-change warnings at checkout
A paper document lives in exactly one folder	Moving a file removes it from its old location	Yes for move, no for shortcuts/aliases/tags	Visually distinguish references from originals; explain tags separately
Paper in a wastebasket is recoverable until emptied	Deleted files can be restored	Yes, until the bin is emptied	Exploit it; but clarify that emptying is permanent and does not shred data securely
A desk is private; only I see what is on it	My files are visible only to me	No in shared/cloud contexts	Breakdown point: persistent sharing indicators, explicit audience display

Where a metaphor breaks down, designers have three options: extend the system to honour the expectation (sometimes the best answer — add stock reservation); visibly signal the departure (a different icon, a distinct colour, a one-time explanatory message); or abandon the metaphor in that region and teach a native concept directly. What is rarely acceptable is to leave the breakdown silent, because a silent breakdown is precisely a misconception held confidently. It is also worth noting that metaphors age: many contemporary users have never used a floppy disk, a physical file folder, or a rotary telephone handset, so these icons now function as learned conventions rather than live metaphors. A convention still works — it is a shared declarative fact — but it no longer generates correct predictions about unfamiliar behaviour, which is the metaphor's real value.

How mental models evolve through interaction

Mental models are not delivered; they are grown through a cycle of expectation, action, observation, and revision. Understanding this cycle tells the designer where to intervene.

Exploratory interaction and experimentation are the primary engine of model-building. Users probe: they click an unfamiliar control to see what it does, open a menu simply to read it, type a value to see whether it is accepted. This exploration only happens if the environment feels safe. The willingness to experiment is directly proportional to the perceived reversibility of actions. An interface with a reliable, universal undo, clear non-destructive previews, draft or sandbox modes, and prominent "cancel" paths will be explored energetically and therefore learned quickly. An interface where any action might silently commit something irreversible teaches users to freeze: they stick to the one path they know works, never discovering the rest of the system and never correcting their partial model. This is why support for exploration is not a convenience feature but a learning mechanism. Live previews are a particularly efficient form of this: hovering over a font and seeing the text change immediately lets the user run dozens of micro-experiments per minute, each one refining the model at almost no cost.

Feedback and error messages act as corrective signals. Every system response is a lesson about the model, intended or not. Immediate feedback (a button depressing, a row highlighting, a progress indicator) teaches the mapping between action and effect; delayed or absent feedback teaches nothing, or worse, teaches a superstition — the user who presses Submit twice because nothing visibly happened learns that "pressing twice works," and will later create duplicate records. Error messages are the highest-value corrective moments in the whole interaction, because the user is actively confused and therefore maximally receptive to information. A message that says Error 0x8007045D teaches nothing; a message that says "This file could not be saved because the drive was disconnected. Your changes are still open in the editor — reconnect the drive or choose Save As to another location" repairs the model (it names the entity involved, explains the causal relation, and states the current system state) and offers a path forward. The best corrective signals share four properties: they identify what the system believes happened, why in terms of the conceptual model, what state things are now in, and what the user can do next.

Repeated successful completion stabilises the model, particularly its procedural components. The first time a user exports a report they reason consciously about each step; by the twentieth time the sequence has compiled into a single chunk — "export the report" — executed with little attention. This is valuable: it frees working memory for the actual task rather than the tool. But stabilisation has a cost. A consolidated procedure is resistant to revision, which is why interface redesigns that relocate well-learned controls provoke disproportionate frustration from experienced users: their procedural knowledge, built over years, is invalidated in a day, and they are temporarily demoted to novices in a system they thought they knew. It also means that a user who learned a suboptimal route to a goal (say, copying values between two documents by hand because they never discovered the link feature) will keep using it indefinitely, because it works. Success is a poor teacher of better methods. Designers therefore sometimes surface "there is a faster way" hints at the moment the slow route is used — a deliberate intervention into a model that has stabilised prematurely.

Models persist when feedback is insufficient to trigger revision. Revision requires a detectable contradiction between prediction and outcome. If the system hides the consequences of an action, the user's incorrect model is never challenged and can survive for years. Several interface patterns are especially prone to this. Silent failures — a sync that stops working, a backup that has not run since 2019, a form field that drops characters beyond a limit — leave the user believing all is well. Delayed consequences break the link between cause and effect: a privacy setting changed today produces an embarrassing disclosure next month, far too late for the user to connect the two. Hidden state is similarly dangerous: a filter still applied, a keyboard mode still active, a microphone still live. The classic category of mode errors arises exactly here — the user's model says the system is in one mode, the system is in another, and nothing visible disambiguates them, so the same action produces an unexpected result. The design prescription is persistent, unmissable indication of consequential state, and proactive confirmation that background processes are actually working ("Last backed up: 3 minutes ago") rather than silence that is ambiguous between "fine" and "broken."

Implications of mental models for interface design

Everything above converges on a single practical principle: the interface is the only channel through which the designer's conceptual model reaches the user, so that model must be made visible, consistent, guided, and tested.

Make the conceptual model visible and inspectable. If the system has entities, show them and name them consistently. If the system has state, display it rather than requiring the user to remember or infer it. Practical expressions of this include: breadcrumb trails that reveal the hierarchy the system believes it is in; sync and save indicators that externalise an invisible process; a visible selection count before a bulk operation; an explicit "who can see this" summary on a shared document; a recipients list rendered before a message is sent. A useful test is to ask whether a user, pausing mid-task, could answer three questions purely from the screen: Where am I? What is the system's current state? What will happen if I do this next thing? If any answer requires memory or guesswork, the conceptual model is under-exposed.

Use consistency so that learning generalises. Because mental models are built by inference from examples, every regularity in the interface is a rule the user can extract and apply to features they have not yet used. If destructive actions are always red and always confirmed, the user can safely predict the behaviour of a red button they have never pressed. If the right-hand panel always shows properties of the current selection, the user will look there in a new module without being told. Consistency operates at several levels — internal (within the product), external (with platform conventions such as where the back gesture lives or what the system share sheet looks like), and conceptual (the same underlying idea is always expressed the same way). Internal inconsistency is the most damaging because it actively falsifies the rules a user has correctly induced, which teaches them to stop generalising and start memorising case by case.

Design affordances and constraints to steer action. Where the conceptual model implies a correct sequence, the interface should make that sequence the easy one and make the incorrect ones difficult or impossible. Perceived affordances — a control that looks pressable, a handle that looks draggable, a field that looks editable — advertise what is possible. Constraints narrow the space of action: disabling the "Submit" button until required fields are valid, greying out paste when the clipboard holds an incompatible type, restricting a date picker to available dates, forcing a wizard's steps into a dependency order. Mappings should be natural: a control whose spatial arrangement mirrors the thing it controls (burner controls laid out like the burners, volume increasing upwards) lets the user predict correctly without instruction. Where constraint is impossible and the stakes are high, use forcing functions — requiring the user to type the name of the repository they are about to delete, or removing the card before dispensing the cash — so that an automatic procedural routine cannot run to completion unchallenged. And wherever possible, prefer reversibility to confirmation: an undo that genuinely works is both safer and better for learning than a dialogue the user has been trained to dismiss.

Test iteratively with real users to find misalignments. Designers cannot introspect their way to users' mental models, because designers suffer from the curse of knowledge: once you know how the system works, you cannot un-know it, and the interface looks self-explanatory. Only observation reveals the mismatch. Low-cost techniques that specifically target mental models include: asking participants to predict what a control will do before clicking it, and noting where prediction and reality diverge; think-aloud protocols, in which the running commentary exposes the user's theory ("I'll put it in this folder, so it should disappear from here…"); asking users to sketch or describe the system's structure after a session; teach-back, where a participant explains the tool to a notional colleague; and cognitive walkthroughs that ask, at each step, whether the user will know what to do and will recognise that their action moved them toward the goal. Each of these should be run while changes are still cheap — on sketches and clickable prototypes rather than on shipped code — and the findings should be interpreted as a diagnosis of the conceptual model, not merely as a list of cosmetic fixes. If three participants in a row believe that removing a photo from an album deletes it, the problem is not the wording of a button; it is that the system's ontology of references versus originals has not been communicated at all.

Taken together, these ideas reframe what an interface is for. It is not merely a control surface for invoking functions; it is a teaching instrument whose continuous job is to install and maintain an accurate-enough model of the system in the user's head. When it does that job well, users predict correctly, act confidently, recover from errors, and generalise to features they have never seen. When it does it badly, no amount of visual polish will prevent the quiet, systematic errors that follow from a user reasoning faithfully about a system that is not the one in front of them.

Alignment with Learning Outcomes

MO1 — Partially supported. The topic's treatment of declarative versus procedural knowledge, recognition over recall, and the limits of what users can hold in mind while acting provides the cognitive background for memory-related interface constraints, but it does not itself enumerate the types of human memory or their capacities.
MO2 — Directly supported. The discussion of discrepancies between a user's mental model and the designer's conceptual model, including capture errors, mode errors, negative transfer, metaphor breakdown, and silent-failure cases, is precisely an account of how model mismatch produces systematic rather than random errors.
MO3 — Not directly addressed. Hierarchical Task Analysis is not covered here, although the account of procedural knowledge as chunked, hierarchically organised action sequences supplies conceptual grounding for why goals can be decomposed into subtasks.
MO4 — Partially supported. The final part introduces evaluation techniques aimed at exposing model mismatches — prediction tasks, think-aloud user testing, teach-back, and expert-driven cognitive walkthroughs — giving a basis for later comparison of expert-driven and user-based methods, but it does not set out selection criteria in detail.
MO5 — Partially supported. The emphasis on making the conceptual model visible, maintaining consistency, and designing affordances and constraints supplies interaction design principles a prototype should embody, and the call for iterative testing on sketches and clickable prototypes motivates low-to-mid fidelity work, though prototyping technique itself is not taught here.

NotesIllustrative examples (thermostat valve-versus-switch folk theory, the desktop and shopping-cart metaphors, version control's staging area, sync and sharing misconceptions) are drawn from well-established HCI and cognitive psychology literature and may be swapped for domain-specific examples relevant to the cohort. The two tables are intended as reusable classroom artefacts: the knowledge-type table supports a diagnostic discussion of error sources, and the metaphor-audit table can be issued as a blank template for students to complete against an interface of their choice.

2

Videos on This Topic

▶

Every time you sit down in front of an unfamiliar app, you are not starting from zero. You bring prior knowledge: general world knowledge, knowledge of similar software, knowledge of conventions (a trash can deletes, an underlined blue word links), and procedural habits built from years of clicking, tapping, and swiping. From this knowledge you assemble a mental model — an internal, often incomplete and sometimes wrong, account of what the system contains and how it behaves. That model is what you use to predict what a button will do before you press it.

Designers cannot hand users a mental model directly. What they can do is express a conceptual model through the interface: the objects, actions, relationships, and metaphors the design makes visible. Interface metaphors (desktops, folders, carts, feeds) act as cognitive bridges, letting users borrow structure from something familiar. When the conceptual model communicated by the interface matches the system's real behavior, users form accurate mental models quickly; when it does not, they form confident but wrong models and make systematic, repeatable errors.

As you watch these videos, look for three things. First, what cues in the interface are doing the model-building work — spatial arrangement, direct manipulation of visible objects, labels, animation, explanations. Second, how mental models change over time as users accumulate experience with a system. Third, how early impressions can distort a model in ways that persist, which is a direct design concern rather than just a psychological curiosity.

3

Video 1: Direct Manipulation in User Interfaces

▶

NNgroup · 4:40 · 13,656 views · 5y ago · captions — Watch on YouTube

About this video

A short Nielsen Norman Group explainer on direct manipulation, the interaction style in which users act on visible depictions of objects rather than issuing commands about them. Expect a definition, examples from graphical interfaces such as dragging, resizing, and moving on-screen objects, and discussion of why acting directly on a representation feels natural. The video is likely to touch on the trade-offs and limits of the approach as well.

Why this video

Direct manipulation is the clearest practical case of an interface metaphor working as a cognitive bridge: the screen objects stand in for real objects, so users can reuse everyday physical knowledge. NN/g is a long-established usability research and training organization, and the presentation is concise and example-driven, making it a good anchor for the metaphor and conceptual-model subtopics.

4

Video 2: Form Follows Mental Models: Finding Instantiations of Image Schemas using a Design Research Approach

▶

ACM SIGCHI · 10:03 · 172 views · 4y ago · captions — Watch on YouTube

5

Video 3: Anchoring Bias Affects Mental Models and User Reliance in Explainable AI Systems

▶

ACM SIGCHI · 8:57 · 171 views · 5y ago · captions — Watch on YouTube

About this video

A SIGCHI research presentation on how anchoring bias — being overly influenced by information encountered first — shapes the mental models users form of an AI system and how much they then rely on it. The talk reports on a study of explainable AI, examining how the order and nature of early examples affect users' understanding and trust. Expect study design, findings, and implications for designing explanations.

Why this video

This video shows mental models forming and evolving through interaction, and shows how a distorted model leads to miscalibrated reliance and systematic error. It extends the topic into a current, high-stakes design context where the gap between a user's model and a system's actual behavior has clear consequences.

6

How These Videos Support the Learning Outcomes

▶

These videos focus most directly on MO2: the SIGCHI talks show how mental models are formed, how they can be skewed by early information or by interface form, and how a mismatch between a user's model and the system's real behavior leads to predictable errors and misplaced reliance. The direct manipulation video supplies the design-side counterpart, illustrating how a well-chosen metaphor and visible conceptual model reduce the memory and reasoning burden on users, which connects to the memory and capacity constraints discussed in MO1. The design implications raised across all three — making structure visible, sequencing what users see first, matching form to expectation — also feed into the later module outcomes on task decomposition (MO3), evaluation (MO4), and prototyping (MO5), where you will need to justify design choices in terms of the understanding they produce in users.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Human Error and Learning

1

Human Error and Learning

▶

Every interactive system is used by people who are, inevitably, fallible. Human error is not an occasional defect in otherwise reliable operators; it is a normal, statistically predictable by-product of the way human cognition works. People automate frequently repeated actions, they economise on attention, they reason from incomplete models of the world, and they forget. Because these tendencies are stable properties of the human cognitive architecture, they can be anticipated and designed for. The central insight of modern human–computer interaction is therefore a shift in blame: when a user deletes the wrong file, enters a date in the wrong format, or sends a message to the wrong recipient, the most productive question is not "why was the user careless?" but "what in the design made that error easy to commit and hard to detect or reverse?" This topic examines how errors are classified, what conditions provoke them, how interfaces can prevent errors or soften their consequences, and how the principles of human learning shape designs that make users progressively more competent over time.

A vocabulary for error

The most widely used classification in HCI derives from James Reason's work on human error and Donald Norman's application of it to everyday things. The key distinction rests on where in the chain from intention to action the failure occurs. A user forms a goal, develops a plan to achieve it, executes the plan, and then evaluates the outcome. If the plan is sound but the execution goes astray, the error is a slip or a lapse. If the plan itself is wrong, the error is a mistake. This is not academic hair-splitting: slips and mistakes have different causes and require entirely different design remedies. Slips are best addressed by constraints, distinctiveness, and feedback; mistakes are best addressed by better conceptual models, clearer information, and better training or onboarding.

Slips: right intention, wrong action

A slip occurs when the user knows exactly what they want to do, has chosen a correct course of action, and then performs something other than what they intended. Slips are overwhelmingly associated with skilled, routine, automatic behaviour — paradoxically, they are errors of expertise. A novice who must consciously think through every step rarely slips; an expert whose actions have become automated can be hijacked by habit or momentary inattention.

Capture slips occur when a familiar, frequently performed action sequence "captures" control from a similar but less frequent one. A user who intends to use Save As… but has pressed Ctrl+S thousands of times may find themselves saving over the original file. The everyday analogue is driving toward a weekend destination and finding yourself on the route to work.
Description-similarity slips occur when the internal description of the target object is too vague to distinguish it from a neighbour. Two icons that look alike, two adjacent list items, two contacts named "Chris" — the user acts on the right kind of object but the wrong instance. Sending a confidential message to the wrong "Chris" in a chat client is a canonical case.
Mode errors occur when the same action produces different results depending on an invisible or poorly signalled system state. A text editor in command mode versus insert mode, a camera in video mode versus photo mode, a phone keyboard with Caps Lock engaged, or a flight-management system in vertical-speed mode rather than flight-path-angle mode (implicated in the 1992 Mont Sainte-Odile crash) all share the same structure: the user's action is correct for the mode they believe they are in.
Activation and action slips include premature termination (walking away from a photocopier with the original still on the glass once the copies — the real goal — are in hand) and loss of activation (opening a menu and forgetting which command you came for).

Lapses: failures of memory

A lapse is a failure of the memory system rather than of attention during action. The plan was correct, but a step was omitted, a sub-goal was forgotten, or the user lost track of where they were in a sequence. Post-completion errors are a classic and well-documented lapse: once the main goal has been achieved, the memory trace that sustained any remaining clean-up step decays rapidly. Leaving a bank card in an ATM after collecting the cash was so reliable a lapse that banks redesigned machines to return the card before dispensing the money — a design fix for a memory problem. Other examples include forgetting to attach the file one has just written an email about, forgetting to re-engage a safety setting after a temporary override, and losing one's place in a multi-step form after an interruption. Lapses are design-addressable through checklists, persistent progress indicators, system-maintained state, and reminders triggered by context (for instance, an email client that detects the word "attached" and warns before sending).

Mistakes: the plan itself is faulty

A mistake occurs when the user's intention is inappropriate for the situation — the action is executed faithfully, but it should never have been chosen. Mistakes arise from inadequate knowledge, misdiagnosis of the situation, or an inaccurate mental model of how the system works. A user who believes that dragging a file to another drive moves it (when in fact it copies it) and then deletes the original has made a mistake, not a slip: they executed their plan perfectly. Mistakes are typically slower to commit, are accompanied by conscious reasoning, and are harder for the user to detect, because the user's flawed model also generates the expectations against which the outcome is evaluated — they may interpret contradictory feedback as confirming their belief.

Rasmussen's skill–rule–knowledge framework gives mistakes a useful internal structure:

Rule-based mistakes occur when a user applies a stored if-then rule that is either a good rule applied in the wrong situation or a bad rule learned from earlier experience. A user who learned that "the X in the corner closes the window and discards nothing important" will apply that rule to a dialog where X silently cancels an hour's work. Strong but inappropriate rules dominate: the more often a rule has worked in the past, the more readily it is triggered, even when situational cues contradict it.
Knowledge-based mistakes occur in genuinely novel situations where no rule exists and the user must reason from first principles using their mental model. This is effortful, slow, and biased: people fall prey to confirmation bias, to availability (favouring explanations that come to mind easily), and to the "cognitive tunnel vision" of fixating on an initial hypothesis. A system administrator diagnosing an unfamiliar outage, or a user trying to recover a corrupted document for the first time, is operating at the knowledge-based level, and error rates there are far higher than at the skill or rule levels.

The practical design consequence is that different error types demand different countermeasures, as summarised below.

Error type	What failed	Typical trigger	Illustrative example	Primary design remedy
Slip	Execution of a correct plan	Automaticity, inattention, similarity, hidden modes	Pressing "Reply All" instead of "Reply"	Visual/spatial distinctiveness, constraints, mode visibility, confirmation for high-cost actions
Lapse	Memory for plan steps or place in sequence	Interruption, post-completion state, long sequences	Sending an email without the promised attachment	System-held state, progress indicators, checklists, contextual reminders
Rule-based mistake	Selection of an inappropriate rule	Strong habitual rule, misleading surface cues	Treating a destructive "X" as a harmless cancel	Consistency across contexts, distinctive labelling of exceptional cases, clear state information
Knowledge-based mistake	Reasoning in a novel situation	Incomplete or wrong mental model, ambiguous data	Misdiagnosing a sync conflict and deleting the newer copy	Transparent system model, diagnostic feedback, explanations, safe exploration and undo

Violations and the limits of the taxonomy

One further category deserves mention because designers meet it constantly: the violation, a deliberate departure from a prescribed procedure. Users click through security warnings, reuse passwords, or circumvent a mandated workflow — not out of malice, but because the official path is slower or more burdensome than the goal justifies. Violations are a design signal rather than a moral failing: when a safeguard is routinely bypassed, the safeguard is mismatched to the work. Repeated violations also erode genuine protection, as with "warning fatigue," where users who dismiss dozens of inconsequential confirmations each day will dismiss the one consequential one just as fast.

Cognitive overload and working memory

Human working memory is small and volatile. The classic estimate of roughly seven plus or minus two items has been revised downward in contemporary research to about three to five meaningful chunks, held for a matter of seconds without rehearsal. Interfaces that require users to hold information "in their head" are therefore operating on the most fragile resource available. When the demands of the task, the interface, and the environment together exceed that capacity, performance degrades in characteristic ways: users shed sub-goals (lapses), fall back on automatic routines (slips), and narrow their attention so that peripheral cues go unnoticed.

A multi-page checkout that shows the order total only on page one, but asks for a discount decision on page four, forces the user to carry a number across screens.
A command-line tool whose flags must be recalled from memory imposes higher load than a menu, where recognition replaces recall — a direct application of the principle that recognition is far cheaper than recall.
A dense dashboard with forty simultaneously competing indicators produces load through visual search rather than memory, with the same net effect on error rates.

The design corollary is to put knowledge in the world rather than in the head: display the running total, keep entered values visible, carry context forward between steps, and never require the user to transcribe information from one part of the system to another.

Poor feedback and the gulf of evaluation

Users cannot act correctly on a system whose state they cannot perceive. Norman's "gulf of evaluation" describes the distance between what the system actually did and what the user can tell it did. Where feedback is absent, delayed, or ambiguous, users form their own inferences — and those inferences become the faulty mental models that produce later mistakes. A button that produces no visible response within a few hundred milliseconds invites the user to press it again, generating duplicate orders or duplicate transactions. A save operation with no confirmation leaves the user unsure whether to repeat it. A file transfer with a progress bar that sits at 99% for three minutes teaches users that progress bars lie, which in turn makes them abandon operations prematurely. Good feedback is timely, proportionate to the significance of the action (subtle for routine actions, prominent for consequential ones), and expressed in terms of the user's goal rather than the system's internals.

Similarity, capture, and modes

Similarity is a double-edged property. Consistency — a form of deliberate similarity — reduces learning cost, but similarity between items that must be distinguished increases error. The design question is always: similar in what respect, and distinct where it matters? Two adjacent toolbar icons that differ only in hue will be confused under time pressure. Commands such as rm -r and rm -rf, or Archive and Delete placed side by side with similar iconography, invite description-similarity slips. Separation strategies include spatial distance (putting destructive actions away from frequently used ones), differing shape and colour, differing interaction requirements (a destructive action that requires a deliberate hold or a typed confirmation), and differing labels that avoid shared prefixes.

Modes deserve particular attention because they multiply the meaning of every user action. The safest approach is to eliminate modes where possible; where they are necessary, they should be made highly visible (a persistent banner, a changed cursor, a coloured border), ideally spring-loaded so that the mode persists only while a key or control is actively held. Holding the Shift key is a spring-loaded mode that essentially never produces errors; Caps Lock is a locked mode that produces them constantly — the difference lies entirely in whether maintaining the mode requires continuous conscious effort.

Environmental and physiological factors

Error-prone design does not operate in a vacuum. Stress narrows attention and biases users toward strong habitual responses — precisely the conditions that produce capture slips and rule-based mistakes. Fatigue degrades vigilance and working memory. Interruptions are especially corrosive: research on task resumption shows that recovering from an interruption takes measurable time and that the risk of omitting a step is highest immediately after resumption. A nurse configuring an infusion pump while being spoken to, a developer deploying a release at 2 a.m., or a commuter completing a banking transaction on a jolting train are all operating with reduced cognitive resources. Designs intended for such contexts should minimise the amount of state the user must carry, make it trivially easy to see where one left off, preserve partially completed work automatically, and avoid timeouts that punish interruption. It is a defining characteristic of good safety-critical design that it assumes degraded operators rather than ideal ones.

Preventing errors: constraints

The cheapest error to recover from is the one that cannot be made. Constraints limit the action space so that invalid operations are impossible or at least difficult. Norman distinguishes physical constraints (a USB-C connector that fits either way, a three-pin plug that fits only one way), logical constraints (a jigsaw piece whose shape tells you where it belongs), semantic constraints (knowledge of the situation's meaning), and cultural constraints (red means stop). In software, constraints appear as:

Disabled or hidden controls — greying out "Submit" until all required fields are valid, so the invalid submission never occurs. (This must be paired with an explanation of why the control is unavailable, or it creates a different problem: a user who cannot proceed and cannot diagnose why.)
Input masks and structured pickers — a date picker eliminates ambiguity between 03/04/2024 as 3 April and 4 March; a numeric stepper with a bounded range makes out-of-range entry impossible.
Type and format enforcement — a field that accepts only digits for a card number, with real-time validation and inline correction rather than rejection after submission.
Sensible defaults — pre-selecting the safe or most common option so that inattentive users land in a good state. A print dialog defaulting to one copy, or a sharing dialog defaulting to "private," embodies a constraint by making the safe path the path of least effort.

Preventing errors: confirmations, undo, and forcing functions

Confirmation dialogs are the most over-used and least effective safeguard in interface design. They work only when they are rare, when they are specific, and when the information they display is genuinely needed for the decision. A dialog that says "Are you sure?" with a generic OK/Cancel adds a click to the user's motor routine, which is quickly absorbed into automatic behaviour; after a week the user is pressing OK before reading. A better pattern is to state exactly what will happen and to what — "Delete 847 messages in 'Clients' permanently? This cannot be undone" — and better still to replace confirmation with reversibility. Gmail's "Undo Send," which delays delivery by a few seconds and offers a single reversal control, prevents far more real-world harm than a confirmation prompt would, because it demands nothing of the user in the common case and everything the user needs in the rare one.

For truly irreversible, high-consequence operations, deliberate friction is appropriate: requiring the user to type the name of the resource being destroyed (as GitHub does for repository deletion) converts an automatic motor action into a conscious, knowledge-based one, which is precisely the cognitive mode that will catch a slip.

Forcing functions are constraints that interrupt the flow of action to ensure a necessary step is completed. Three classic forms are:

Interlocks — forcing a sequence. A microwave that will not run with the door open; a car that will not shift out of Park unless the brake is depressed.
Lock-ins — keeping an operation active to prevent premature exit. "You have unsaved changes — save, discard, or cancel?" keeps the user inside the editing context rather than silently discarding work.
Lockouts — preventing entry into a dangerous state. A staircase barrier at ground-floor level that stops people fleeing a fire from continuing into the basement; in software, requiring re-authentication before access to a destructive administrative panel.

Forcing functions are powerful but intrusive, and they are exactly the mechanism users learn to defeat if they obstruct legitimate work. They should be reserved for consequences that genuinely warrant the interruption.

Preventing errors: affordances and signifiers

An affordance is a relationship between an object's properties and an agent's capabilities — what actions are possible. A signifier is the perceptible cue that tells the user which affordance exists and where. Most interface "affordance problems" are in fact signifier problems: the action is possible but not discoverable, or something that looks actionable is not. Flat visual design that strips shadows, borders, and colour contrast from buttons produces exactly this failure, where users cannot tell what is clickable and resort to trial-and-error clicking. Consistent, honest signifiers reduce error by making the mapping from appearance to behaviour unambiguous: underlined coloured text is a link, a raised rectangle with a verb label is a button, a drag handle shows where dragging begins, and a cursor change confirms it before the user commits.

Equally important is mapping — the correspondence between controls and their effects. A stove with four burners in a square and four controls in a straight line produces a lifetime of low-grade errors because the mapping is arbitrary; placing the controls in a matching square makes the mapping natural and error rates collapse. The software equivalent is placing a control adjacent to and visually grouped with the thing it affects, and ordering options spatially to match the thing being manipulated.

Forgiving interfaces: undo and redo

No prevention strategy is complete, so recovery must be first-class. Undo is the most important forgiving mechanism in interactive computing because it changes the user's relationship to the system: it converts the question "what will this do?" from a risk to be reasoned about into an experiment to be run. A well-designed undo facility is multi-level rather than single-step, has a granularity that matches the user's conception of an action (undoing a typed word or a contiguous typing burst, not a single character), is paired with redo so that the user can oscillate while comparing alternatives, and is honest about its boundaries — the user must be able to tell which operations are reversible and which are not. Where true undo is impossible, near-equivalents are often available: soft deletion with a trash folder and a retention period, version history with restore points, draft autosave, and a "revert to last saved version" command. Where none of these is possible (a payment has been made, a message has reached another person), the system should say so explicitly at the point of action rather than after it.

Forgiving interfaces: informative error messages

An error message is a teaching moment, and most are wasted. A message such as Error 0x80070057: the parameter is incorrect communicates failure without communicating anything actionable, and additionally implies blame. A well-constructed message does four things: it states in plain language what happened, explains why in terms the user can relate to their own action, proposes a concrete next step, and — where possible — offers a control that performs that step. It should also be located where the problem is, which usually means inline next to the offending field rather than in a modal dialog that disappears, taking the diagnosis with it.

Poor:   Invalid input.

Better: Card number must be 16 digits. You entered 15.

Best:   Card number must be 16 digits — you entered 15.
        [ Check the number on the front of your card ]
        (the field is highlighted, the cursor is placed at the end,
         and the already-entered digits are preserved)

Note the last point: preserving the user's work. Forms that clear all fields on a validation failure convert a small slip into a large punishment and are a reliable source of abandonment. Tone matters as well — messages should be neutral and blame-free, avoiding words like "illegal," "invalid user," or "fatal," which invite defensiveness rather than correction.

Forgiving interfaces: graceful degradation

Graceful degradation means the system continues to deliver as much value as it can when something goes wrong, rather than failing wholesale. A mapping application that loses its network connection should continue to display cached tiles and the last known route rather than showing a blank screen. A document editor that cannot reach the sync server should keep accepting edits locally, mark them as pending, and reconcile later. A form that cannot validate a postcode against a remote service should accept the entry with a soft warning rather than block submission. In accessibility and web engineering, the same principle appears as progressive enhancement: the core function works with basic capabilities, and richer capabilities layer on top. Applied to human error specifically, degradation means that a user's mistake should narrow the system's usefulness proportionately, not catastrophically — a malformed search query should return approximate matches and a suggestion, not an empty page.

Forgiveness and exploratory learning

There is a direct link between forgiving design and learning. People learn interfaces primarily by doing, not by reading, and the willingness to try an unfamiliar command is governed by the perceived cost of being wrong. When users believe that an action may be irreversible, they do not explore; they stay within the narrow subset of functionsthey already know, and the long tail of the product goes unused. Conversely, a system that makes every action reversible invites experimentation, and experimentation is the fastest route to proficiency. This is why "safe exploration" appears in nearly every usability heuristic set, and why professional creative tools (image editors, CAD packages, code editors with version control) invest so heavily in history, branching, and non-destructive editing. The designer's aim is to ensure that the worst realistic consequence of curiosity is a few seconds lost, so that the user's internal cost–benefit calculation always favours trying.

A useful way to express this to stakeholders is in terms of cost asymmetry: the cost of building an undo stack is paid once by the development team, whereas the cost of unrecoverable errors is paid repeatedly by every user, and includes not just the lost work but the permanent reduction in exploratory behaviour that follows a single bad experience.

Learning principles: consistency

Consistency is the mechanism by which prior knowledge is transferred to a new situation, and it is the single most economical way to reduce both learning time and error. It operates at several levels:

Internal consistency — the same concept is expressed the same way throughout one product. If "Remove" means detach-but-keep in one screen and destroy-permanently in another, every encounter with the word becomes a knowledge-based decision rather than a rule-based one.
External consistency — conformance with the conventions of the platform and of the wider software ecosystem. Ctrl/Cmd+Z for undo, a magnifying glass for search, a shopping basket at the top right, a back gesture from the left edge. Jakob's Law captures the practical point: users spend most of their time on other products, so their expectations are formed elsewhere.
Conceptual consistency — a stable underlying model, so that once a user understands how one object behaves, they can predict how analogous objects behave. A file system in which every item can be renamed, moved, tagged, and shared by the same gestures is learnable in a fraction of the time taken by one with special-case rules.

The caveat is that consistency must not be applied where it would make genuinely different things look the same. If a destructive action looks and behaves exactly like a benign one, consistency has created a description-similarity slip. The guiding rule is: be consistent about things that behave the same, and conspicuously inconsistent about things that behave differently.

Learning principles: progressive disclosure

Progressive disclosure separates information and controls into layers, showing only what is needed for the common case and deferring the rest behind an explicit, clearly signposted step. It manages cognitive load directly — fewer visible options means a smaller visual search space and a smaller decision space — while keeping advanced capability available rather than absent. Familiar instances include an "Advanced settings" section collapsed by default, a print dialog whose first page covers printer, copies, and range while duplex and colour management sit behind "More options," and a search interface that offers a single box with filters revealed after the first query.

Done well, progressive disclosure matches the user's trajectory: novices encounter a small, comprehensible surface, and as their goals become more specific they go looking for the next layer and find it where they expect. Done badly, it hides essential functionality so thoroughly that users conclude it does not exist — the "mystery meat" problem. Two safeguards help: the entry point to the hidden layer must itself be visible and honestly labelled (Advanced, Show 14 more filters) rather than implied, and the default layer must contain everything needed to complete the primary task end to end.

Learning principles: scaffolding

Scaffolding, a concept borrowed from educational psychology and Vygotsky's zone of proximal development, refers to temporary support that enables a learner to accomplish something they could not yet do alone, and which is withdrawn as competence grows. Interface scaffolding includes wizards that break a complex configuration into a guided sequence, tooltips and inline hints, placeholder text showing the expected format, sample data or templates that demonstrate a well-formed result, coach marks on first use, and contextual help that appears at the moment of difficulty rather than in a manual.

The defining property of scaffolding is that it is temporary. Support that cannot be dismissed becomes an obstacle: a wizard that is the only route to a task will frustrate the expert who wants to change one field, and a tutorial overlay that replays on every launch is noise. Good scaffolding therefore has an exit — a "skip," a "don't show again," a direct path that bypasses the guided flow — and ideally it fades on evidence of competence, as when a keyboard-shortcut hint appears beside a menu item the user has clicked many times, deliberately teaching the faster method and then becoming unnecessary.

Learning principles: feedback and reinforcement

Learning requires a closed loop: the user acts, observes a consequence, and updates their model. The tighter and clearer that loop, the faster the model converges on the truth. Feedback supports learning when it is immediate (delays of more than about a second break the perceived causal link between action and result), specific (showing what changed, not merely that something did), and interpretable in the user's own terms. Direct manipulation interfaces are powerful learning environments precisely because the feedback loop is continuous: dragging an object shows its new position frame by frame, so the model is confirmed or corrected before the action is even completed.

Confirmatory feedback tells the user that an action succeeded — a toast saying "3 files moved to Archive," with an inline Undo.
Corrective feedback tells the user that something is wrong while there is still time to fix it cheaply — a password strength meter updating as it is typed, or a form field validating on blur rather than on submit.
Predictive feedback shows the consequence before commitment — a live preview of a filter, a highlighted drop target, a ghost outline showing where a dragged block will land. This is arguably the most valuable kind for learning, because it allows model-building with zero risk.
Reinforcing feedback marks progress and builds confidence — completed steps ticked off, a progress bar that advances, a summary of what was accomplished. Used honestly it sustains motivation through long tasks; used manipulatively (streaks, artificial scarcity) it becomes a dark pattern rather than a learning aid.

Novices, experts, and the shape of the learning curve

A "user" is not a fixed category but a position on a trajectory. The same person is a novice on Monday and an intermediate by Friday, and the overwhelming majority of a mature product's users are perpetual intermediates: they know the twenty per cent of functionality they need, they have forgotten what they were told during onboarding, and they will not read documentation. Designing only for first use produces a product that is charming for an hour and tedious for a year; designing only for experts produces a product nobody survives long enough to master.

Dimension	Novice needs	Expert needs
Knowledge retrieval	Recognition — visible menus, labelled icons, descriptive text	Recall — memorised shortcuts, command palettes, typed syntax
Option set	Reduced and curated; safe defaults chosen for them	Complete and configurable; defaults they can override globally
Pacing	Step-by-step, one decision at a time, explicit confirmation of progress	Compressed; batch operations, multi-select, macros, scripting
Feedback	Explicit and verbose; explanations of what happened and why	Minimal and peripheral; status in a corner, silence on success
Error handling	Prevention and heavy guard-rails	Fast recovery; powerful undo and history rather than confirmations
Typical failure mode	Mistakes — wrong plan from an immature mental model	Slips and mode errors — correct plan, automated execution gone astray

The last row is worth emphasising, because it shows that error-reduction strategy must change as users mature. Novices need the system to help them choose correctly; experts need it to help them execute safely and reverse cheaply. A product that only ever adds confirmation dialogs is optimising for a population it will soon no longer have.

Layered and adaptive interfaces

The reconciliation of these two populations is the layered interface: a single coherent system presented at multiple levels of complexity. Strategies include training wheels designs that disable advanced features until a core competence is demonstrated, explicit "basic / advanced" modes, accelerators that sit alongside rather than replace the visible route (a shortcut shown next to every menu item, so the slow path teaches the fast one), and command palettes that let an expert type a command name while the novice continues to browse menus. Customisation — rearrangeable toolbars, user-defined shortcuts, saved views — lets experts build a personal, high-efficiency surface without imposing it on anyone else.

Adaptive systems take this further by changing automatically in response to observed behaviour. These must be used with care: a menu that reorders itself according to frequency of use (as in some historical office suites) destroys the spatial memory on which expert performance depends, and so makes experts slower while confusing novices. The safer pattern is adaptable rather than adaptive — the user chooses the change, the system does not impose it — or adaptation that adds without rearranging, such as surfacing a suggestion alongside a stable menu that never moves.

Learnability as a usability dimension

Learnability is usually defined as the ease with which a first-time user can accomplish basic tasks, and more broadly as the rate at which performance improves with practice. It is measured empirically rather than asserted: time on task, error rate, completion rate, and the number of help requests, each plotted across repeated trials with the same participants. A learnability curve typically shows a steep initial improvement followed by a plateau; the interesting questions are how steep the initial segment is (how quickly users become productive), where the plateau sits (how good asymptotic performance is), and how much the curve decays after a period of non-use, which is memorability — a distinct and often-neglected property. A tax-filing application used once a year must be designed almost entirely for memorability, because every user is effectively a novice at every encounter.

There is a genuine trade-off between learnability and ultimate efficiency. A menu-driven interface is highly learnable and permanently moderate in speed; a modal, keystroke-driven editor is brutal to learn and extremely fast once mastered. Neither is universally correct; the choice depends on usage frequency, session length, the cost of training, and how long users remain with the product. The error connection is direct: errors are highest early in the curve, where mistakes dominate because models are immature, and then fall sharply — but they never reach zero, and the residual errors shift in character toward slips and mode errors as behaviour becomes automatic.

Mental models

A mental model is the user's internal, working theory of how a system is put together and how it will respond — what entities exist, how they relate, what causes what. Mental models are constructed opportunistically from whatever evidence is available: prior experience with similar systems, the vocabulary and imagery of the interface, observed behaviour, advice from colleagues, and metaphor. They are characteristically incomplete, unstable, unscientific, and "superstitious" — containing rituals that the user believes are necessary but are not — yet they are the sole basis on which every plan is formed. This is why mental models are the deep source of mistakes: a plan can be no better than the model that generated it.

Norman's framework distinguishes three things that are often conflated. The design model is the conceptual model held by the designer. The system image is everything the system exposes to the user — its interface, its wording, its behaviour, its documentation, its error messages. The user's model is what the user infers. Crucially, the designer never communicates with the user directly; the entire burden falls on the system image. If the system image is thin, inconsistent, or misleading, the user's model will diverge from the design model, and that divergence will express itself as predictable, systematic errors.

How model mismatches produce error

Consider some everyday mismatches and the errors they generate:

Thermostats. Many people hold a "valve" model, believing that setting a thermostat to 30°C heats the room faster. The real model is a simple on/off threshold. The resulting error — overshooting the target and wasting energy — is entirely a product of the model, and no amount of care in turning the dial would prevent it.
Cloud storage. A user whose model is "my files are in a folder on this computer" does not distinguish local from synced state, and so deletes a file to "free up space on the laptop," removing it from every device. The system image — an ordinary-looking folder icon — actively encourages the wrong model.
Autosave versus explicit save. A user trained on explicit save opens a document, experiments destructively to see what a feature does, and closes without saving, expecting the original to survive. In an autosaving application, the experiment is now permanent. The action was executed perfectly; the model was wrong.
Privacy and audience. Users consistently misjudge who can see a post because the system image (a composition box resembling a private message) does not convey the actual distribution model. The errors here are serious and systematic across millions of people, which is diagnostic of a design failure rather than individual carelessness.
Browser back button in a single-page application. The user's model says "back returns me to the previous screen"; the application's model may discard state or re-submit. The mismatch produces data loss that the user cannot anticipate.

A useful diagnostic habit is to treat any error made by many different users in the same way as evidence of a model mismatch, and to look for the element of the system image that is teaching the wrong lesson.

Designing for accurate models: transparency and consistency

Several design strategies help the user's model converge on the truth:

Make state visible. If a file can be local, syncing, synced, or conflicted, show which — a badge on the icon converts an invisible distinction into a perceptible one and teaches the underlying model simply by being present.
Make causality visible. Animate transitions so the user can see where a closed window went, or where a deleted item travelled. The animation is not decoration; it is an argument about the system's structure.
Keep behaviour predictable. The same command should have the same effect everywhere. Special cases are precisely what the user's model will fail to encode.
Expose the conceptual vocabulary consistently. If the system has the concepts "project," "board," and "card," use exactly those words in the UI, the documentation, the API, and the support articles. Synonyms fragment the model.
Explain, don't just report. An error message or status display that reveals why ("this file can't sync because another device changed it at 14:02") teaches the model; one that says "sync failed" leaves the user to invent one.
Support model repair. Provide affordances for inspection — a history panel, an activity log, a "what changed" view — so a user who has formed a wrong belief has the means to discover it.

Onboarding and metaphor

Because the earliest minutes of use set the model that governs months of subsequent behaviour, onboarding is a high-leverage intervention. Effective onboarding is less about touring the interface than about installing the right conceptual skeleton: what the system is for, what the main objects are, and how they relate. A project tool that opens with a pre-populated sample project — a board with three lists and a few cards — communicates its model in seconds, far more effectively than a sequence of tooltips pointing at buttons on an empty screen. Other effective techniques include guided completion of one real task (so the model is built through action rather than reading), progressive onboarding that introduces a concept at the moment it first becomes relevant rather than all at once, and empty states that describe the missing object and offer the action to create it.

Metaphor is the oldest tool for model transfer: the desktop, folders, the trash can, the shopping basket, the clipboard, the feed, the inbox. A good metaphor imports a large body of correct expectations at no cost. Its danger is that it also imports incorrect ones, and the boundary is rarely signposted. Physical folders cannot contain the same document twice, do not sync, and have no version history; a physical trash can does not quietly empty itself after thirty days. When the metaphor breaks, users make rule-based mistakes by applying the physical-world rule to a situation it does not cover. The practical guidance is to choose metaphors that match the structure of the underlying system rather than just its surface, to be willing to abandon a metaphor once the interface's own conventions are established (modern file managers rely far less on skeuomorphic imagery than early ones did), and to signal explicitly at the points where the analogy stops holding.

Bringing it together

Error and learning are two views of the same process. Errors are most frequent where models are immature and where the interface fails to signal state, consequence, or availability; learning is the process by which models mature, driven by feedback, consistency, and safe opportunities to experiment. A design that prevents what it can, makes consequences visible, allows almost everything to be undone, explains failures in human terms, and reveals complexity at the pace the user can absorb will simultaneously reduce error rates and accelerate the growth of expertise — and it will do so for the same underlying reason, namely that it keeps the user's model and the system's behaviour in alignment.

Alignment with Learning Outcomes

MO1 — Supported indirectly but substantially: the discussion of lapses, cognitive overload, and the limited capacity of working memory (roughly three to five chunks, seconds of duration without rehearsal) connects memory types and capacities to concrete interface constraints such as recognition over recall and keeping state in the world rather than in the head.
MO2 — Directly supported: the sections on mistakes, rule- and knowledge-based error, Norman's design model / system image / user model distinction, and the worked examples of thermostats, cloud storage, autosave, and privacy settings explain precisely how mental-model mismatches generate systematic, predictable errors.
MO3 — Not directly addressed. Hierarchical Task Analysis is not covered here; however, the material on multi-step sequences, post-completion lapses, and progressive disclosure provides the error-related rationale that task decomposition is later used to analyse.
MO4 — Partially supported: the topic supplies the error taxonomy, learnability measures (time on task, error rate, memorability curves) and heuristic principles that expert-driven evaluation methods inspect for, and that user testing is used to observe, but it does not itself compare evaluation techniques.
MO5 — Supported as design input: constraints, forcing functions, affordances and signifiers, undo, informative error messages, progressive disclosure, scaffolding, and novice/expert layering are all interaction design principles that a low-to-mid fidelity prototype can be built to embody and justify.

NotesKey source frameworks referenced: Reason's slips/lapses/mistakes/violations taxonomy; Rasmussen's skill–rule–knowledge framework; Norman's gulf of execution/evaluation, design model vs. system image vs. user model, constraints and forcing functions (interlocks, lock-ins, lockouts); Nielsen's usability dimensions (learnability, efficiency, memorability, errors, satisfaction) and heuristics on error prevention, recovery and user control; Vygotsky's zone of proximal development as the basis for scaffolding; Jakob's Law for external consistency. Possible activities: have students classify a set of real error anecdotes as slip/lapse/rule-based mistake/knowledge-based mistake and propose a matched remedy for each; audit a familiar application's confirmation dialogs and propose undo-based replacements; redraft three real error messages using the state-what/explain-why/offer-next-step pattern.

2

Videos on This Topic

▶

People make mistakes, and interactive systems are where many of those mistakes become visible. This topic looks at human error systematically: the difference between slips (doing the wrong thing while intending the right thing) and mistakes (intending the wrong thing in the first place), the conditions that make errors more likely, and the design choices that either invite or prevent them. A recurring theme is that error is rarely just "user fault" — poorly labelled controls, ambiguous feedback, and interfaces that conflict with a user's mental model all produce predictable, systematic failures.

The second half of the topic turns to learning and recovery. Good interfaces are forgiving: they constrain dangerous actions, make the current state visible, offer undo, and explain problems in language the user can act on. They also support a learning curve, letting novices succeed through guidance and discoverability while giving experts faster paths. These goals sometimes pull against each other, which is why designers need principles rather than one-size-fits-all rules.

As you watch the three videos below, keep a running list of two things: (1) the specific error type or cause each example illustrates, and (2) the concrete design move used to prevent, contain, or recover from it. Pay attention to how error handling differs between a form on a large screen and an alert on a small mobile screen — the same principle often requires a different implementation.

3

Video 1: What Is Error and Types of Errors in Human-Computer Interaction (HCI)

▶

IxDF - Interaction Design Foundation · 8:33 · 4,589 views · 2y ago · captions — Watch on YouTube

About this video

An overview of what counts as "error" in human-computer interaction and how errors are classified, likely covering distinctions such as slips versus mistakes and the conditions under which each tends to occur. Expect definitions, examples from interactive systems, and discussion of why error classification matters for designers rather than being just academic labelling.

Why this video

It directly addresses the foundational subtopics — types of human error and their causes — from the Interaction Design Foundation, a well-established HCI education producer, giving you shared vocabulary for the rest of the topic.

4

Video 2: UX Design Best Practices for Forms: How to Prevent Error Messages

▶

IxDF - Interaction Design Foundation · 5:56 · 1,990 views · 1y ago · captions — Watch on YouTube

About this video

A practice-oriented talk on form design that focuses on preventing error messages before they happen, rather than writing better error text after the fact. It is likely to cover input formatting, labelling, validation timing, and other choices that reduce the chance a user enters something the system rejects.

Why this video

Forms are the classic site of user error, so this video grounds the abstract idea of error prevention in concrete, reusable interface decisions you can apply in your own prototypes.

5

Video 3: Error Handling on Mobile Devices: Showing Alerts

▶

NNgroup · 3:03 · 9,068 views · 5y ago · captions — Watch on YouTube

About this video

A short Nielsen Norman Group piece on how error alerts behave on mobile devices, arguing that modal dialogs for error messages often create usability problems on small screens. It discusses how error handling should respect the device context and the user's current task rather than interrupting it.

Why this video

NNgroup is a leading usability research organisation, and this clip extends the topic into forgiving interfaces and error recovery while highlighting how platform context changes the right answer.

6

How These Videos Support the Learning Outcomes

▶

Together these videos support the module outcomes by making the link between user cognition and interface failure explicit. The first video supplies the error taxonomy needed to explain how a mismatch between a user's mental model and actual system behaviour produces systematic, repeatable errors rather than random ones (MO2), and connects to memory and attention limits that constrain what an interface can reasonably ask of users (MO1). The form-design and mobile-alert videos then translate that understanding into design practice — prevention, clear feedback, and recovery — giving you evaluable criteria to apply when critiquing a design (MO4) and concrete patterns to incorporate when you build your own low- to mid-fidelity prototype for a desktop or mobile context (MO5).

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Understanding Users and Task Analysis

1

Understanding Users and Task Analysis

▶

Every interactive system is built on a set of assumptions about the people who will use it. When those assumptions are explicit, tested, and documented, they become a design asset; when they remain implicit, they become the single largest source of design failure. Designers are, almost by definition, atypical users: they know the system's internal structure, they have unlimited exposure to it, and they are unusually tolerant of complexity. The discipline of understanding users exists to counteract this bias, and task analysis exists to convert that understanding into a structured, inspectable description of work that can drive concrete interface decisions. This topic moves from who the users are, through how we learn about them, to how their goals and knowledge are represented, and finally to the formal decomposition techniques — Hierarchical Task Analysis and Cognitive Task Analysis — that turn observation into design specification.

Who Are the Users?

The phrase "the user" is dangerously singular. Real systems serve populations that vary along many dimensions simultaneously, and each dimension carries design consequences. Three of the most consequential are age, experience, and domain knowledge.

Age affects perception, motor control, and expectation. Visual acuity and contrast sensitivity decline with age, which argues for larger default type sizes, higher contrast ratios, and avoidance of low-contrast grey-on-grey styling. Fine motor precision also declines, so touch targets that are comfortable for a twenty-year-old (perhaps 7 mm) may be frustrating for a seventy-five-year-old (who may need 10–12 mm with generous spacing). Age also correlates with different interaction conventions: a user who learned computing in the desktop era may look for a visible "Save" command, while a user raised on mobile apps may assume autosave and be disoriented by its absence.
Experience operates on at least two axes: experience with computing in general, and experience with this particular system. A novice needs visible affordances, informative labels, and forgiving error recovery. An expert needs speed: keyboard shortcuts, batch operations, command palettes, and the ability to bypass confirmation dialogs. Good design does not choose between them; it layers accelerators on top of a discoverable base, so that the same interface supports a learning path from novice to expert. A classic example is a spreadsheet: a beginner uses the ribbon and the function wizard, while an expert types =XLOOKUP( directly and navigates with Ctrl+Arrow.
Domain knowledge is distinct from computing experience and is frequently confused with it. A consultant radiologist may be a hesitant computer user but possesses deep, highly structured knowledge of anatomy and diagnostic workflow. For such users, the interface should speak the domain's language (correct terminology, conventional abbreviations, familiar units and orderings) and should not patronise them with explanations of domain concepts. Conversely, a member of the public using a health-portal booking system has no domain vocabulary at all and needs plain-language translation of clinical terms.

Beyond these, designers routinely profile users by cultural and linguistic background (reading direction, date and number formats, name structures), accessibility needs (screen-reader use, colour vision deficiency, motor impairment, cognitive load sensitivity), frequency of use (daily versus once a year — an annual tax filing system cannot rely on remembered procedure), and the physical and social context of use (a warehouse scanner used with gloves in cold storage; a point-of-sale terminal used under time pressure with a queue watching).

Because populations are heterogeneous, it is useful to classify users by their relationship to the system rather than only by their attributes. The conventional classification is primary, secondary, and tertiary.

Category	Definition	Hospital e-prescribing example	Typical design implication
Primary	People who operate the system directly and frequently to perform their core work	Doctors and prescribing nurses entering medication orders	Optimise for speed, efficiency, and error prevention on high-frequency tasks; provide expert accelerators
Secondary	People who use the system occasionally, indirectly, or through an intermediary	Pharmacists verifying orders; ward clerks printing summaries; a consultant who reviews but rarely enters data	Optimise for clarity and learnability rather than raw speed; avoid relying on memorised procedure
Tertiary	People affected by the system, or who decide about it, without operating it	Patients receiving the medication; hospital finance and procurement; clinical governance auditors; regulators	Outputs must be intelligible, auditable, and defensible; the system's consequences, not just its screens, are part of the design

The categorisation is not a ranking of importance — it is a reminder of coverage. A design optimised exclusively for primary users can impose severe costs elsewhere: an e-prescribing screen that lets a doctor enter an order in four keystrokes but produces an ambiguous printed label creates risk for the patient (tertiary) and rework for the pharmacist (secondary).

Stakeholder analysis extends this further by systematically enumerating everyone with an interest in the system, including those who never touch it, and recording what they want, what they fear, and what power they hold. A simple stakeholder map lists each party against their interest and influence. The technique is valuable precisely because it surfaces hidden users. Consider a self-service supermarket checkout: the obvious user is the shopper, but the store's loss-prevention staff interact with the exception-handling screens dozens of times an hour, the store manager needs throughput reporting, and the cleaning staff need the hardware to be wipeable. None of these appear in a naive "the user is the shopper" framing, yet the loss-prevention workflow determines whether the whole installation is tolerable to operate. Similarly, in a school attendance system, the hidden stakeholders include parents who receive automated absence texts and safeguarding officers who must be able to reconstruct a record months later. Hidden users are often discovered by asking three questions of any proposed feature: Who else sees the output? Who has to clean up when this goes wrong? Who is accountable if it is misused?

Methods for Researching User Needs

No single research method gives a complete picture, because methods differ along two important dimensions: whether they capture what people say or what people do, and whether they capture a moment or a period. Triangulating across these dimensions is standard practice.

Method	Data type	Main strength	Main weakness	Best used when
Semi-structured interview	Qualitative, self-reported, attitudinal	Depth; reveals reasoning, history, and emotion; can follow unexpected leads	Recall bias, rationalisation, social desirability; small samples	Early exploration, understanding motivations and pain points
Survey / questionnaire	Mostly quantitative, self-reported	Scale; can estimate prevalence across a population	Only answers the questions you thought to ask; sampling and response bias	Validating or sizing issues already identified qualitatively
Contextual inquiry / field observation	Qualitative, behavioural, situated	Captures real work, workarounds, artefacts, interruptions, environment	Time-consuming; observer effect; access and confidentiality constraints	Understanding complex or unfamiliar work domains
Diary study	Qualitative + light quantitative, longitudinal, self-reported in situ	Reveals change, rhythm, and infrequent events over weeks	Participant fatigue; incomplete entries; still self-report	Behaviour spread over time or across contexts the researcher cannot attend
Usage / analytics logs	Quantitative, behavioural, longitudinal	Objective, large-scale, unobtrusive, continuous	Tells you what happened but never why; privacy and ethical constraints	Detecting drop-off points, feature uptake, error frequency at scale

Interviews and surveys are the workhorses of self-report. A well-run interview avoids leading questions ("Don't you find the current system slow?") in favour of concrete, episodic prompts ("Walk me through the last time you had to cancel an order — what happened?"). Episodic questions anchor the participant in a real event and dramatically reduce the tendency to produce idealised accounts. Interviews should probe frustrations and workarounds especially hard, because workarounds are fossil evidence of unmet needs: a sticky note of shortcut codes on a monitor bezel, a parallel spreadsheet maintained "because the system can't do it", or a shared login used to bypass a permissions model. Surveys complement interviews by establishing how widespread a theme is; the typical sequence is interview first to generate the right response options, then survey to measure them. Standardised instruments such as the System Usability Scale (ten Likert items yielding a 0–100 score) are useful for benchmarking, but they diagnose nothing on their own.

The fundamental limitation of all self-report is that people are unreliable narrators of their own behaviour. They forget routine steps precisely because those steps are automatic, they compress a messy twenty-minute process into a tidy four-step story, and they describe the policy rather than the practice.

Contextual inquiry addresses this by moving the research into the user's own environment and adopting a master–apprentice stance: the user works as usual while the researcher watches, asks small clarifying questions in the moment, and periodically reflects an interpretation back for correction. Four principles are usually cited — context (go where the work is), partnership (co-investigate rather than interrogate), interpretation (check your meaning-making with the user), and focus (steer towards relevant work without constraining it). Contextual inquiry reliably reveals things interviews cannot: that the dispatcher keeps three windows tiled and transcribes between them by hand; that the radio interrupts the task on average every ninety seconds; that the "required" field is universally filled with a dot because the real information is unavailable at that point in the process; that a laminated crib sheet encodes the organisation's actual procedure. Physical artefacts collected during a visit — forms, labels, printouts, annotated screenshots — are among the richest design inputs available.

Diary studies and usage logs extend observation across time. In a diary study, participants record entries themselves, triggered either by time (end of each shift) or by event (every time you need to look something up). Modern diary studies often use a phone app with photo and voice capture, lowering the burden of entry. The method is the only practical way to observe phenomena that are rare, private, or distributed — for example, how a family coordinates a care schedule over a month, or how a field engineer's connectivity varies between sites. Usage logs and analytics supply the objective counterpart: funnel analysis showing that 38% of users abandon at the address-verification step, event timing showing that the "advanced search" panel is opened by 2% of sessions, or error telemetry showing that a particular validation message fires 400 times a day. Logs excel at identifying where and how often something goes wrong but are mute about why; the productive pattern is to let analytics localise a problem and then use interviews or observation to explain it. All longitudinal collection raises ethical obligations: informed consent, clear statements of what is captured, data minimisation, anonymisation or pseudonymisation, and the right to withdraw.

User Goals and Mental Models

Research produces raw material; goals and mental models are the structures we use to make sense of it. A widely used framing (from goal-directed design) separates three levels of goal.

Goal type	Question it answers	Example (photo-sharing app)	Design levers
Experiential	How does the user want to feel while using it?	"I want this to feel effortless and private, not like filing paperwork."	Visual tone, microcopy, responsiveness, animation, perceived control, absence of nagging
End	What concrete outcome must be produced?	"Get these 40 holiday photos shared with my family tonight."	Features, task flows, defaults, information architecture, performance
Life	Why does this matter in the user's wider life?	"I want to stay close to relatives I rarely see."	Product strategy and positioning; which end goals are worth supporting at all

The distinction matters because the three levels fail in different ways. A system can satisfy an end goal while violating an experiential goal — the task completes, but the user feels harassed by interruptions, modal dialogs, and upsells — and such systems are abandoned as soon as an alternative exists. Conversely, a delightful interface that does not advance a real end goal is a novelty. Life goals are rarely addressed by individual screens but should discipline the roadmap: a budgeting app whose users' life goal is "stop feeling anxious about money" should think hard before adding a feature that sends daily spending alerts.

A mental model is the user's internal, working theory of how the system behaves — what its parts are, how they relate, what will happen if they do X. Mental models are typically incomplete, partly wrong, and heavily analogised from previous experience, yet they are what people reason with. The conceptual model is the designer's intended story of the system, communicated through the interface; the system image is everything the user can actually perceive (screens, labels, documentation, feedback). Breakdowns occur when the system image fails to convey the conceptual model, or when the conceptual model itself conflicts with the user's prior model.

Two techniques are especially useful for eliciting mental models:

Card sorting probes how people categorise and relate concepts. Participants are given labelled cards (content items, features, document types) and asked to group them. In an open sort they create and name their own groups, revealing their native categories and vocabulary; in a closed sort they place cards into predefined categories, testing whether a proposed structure is guessable. Results are aggregated across participants — commonly as a similarity matrix or dendrogram showing which items were repeatedly grouped together. A university website open sort might reveal that students think in terms of "things I have to do this week" (fees, timetable, assignment submission) while staff think departmentally; this directly suggests task-based rather than org-chart-based navigation. The complementary technique, tree testing, takes a proposed hierarchy and asks users to locate items in it, measuring success and directness.
Think-aloud protocol asks a user to verbalise thoughts continuously while performing a task. Because the verbalisations expose expectations and predictions ("I'll click Settings — that's probably where my saved cards are… no, it isn't, maybe Account…"), the transcript is effectively a trace of the mental model being applied and repaired. Concurrent think-aloud gives in-the-moment data but can slightly distort performance timings; retrospective think-aloud (replaying a screen recording and narrating afterwards) preserves natural performance at the cost of some recall accuracy. Prompts should be neutral — "What are you thinking?" — never "Why didn't you see the button?"

Other elicitation devices include asking users to draw the system ("sketch where your files live"), probing predictions before action ("what do you expect will happen when you press this?"), and analysing spontaneous metaphors in interview transcripts ("my inbox is a to-do list", "the cloud is like a big hard drive somewhere").

Design then has three ways to bridge the gap between the user's model and the system's structure. First and best, change the system so its structure matches the user's: if users think of email as conversations, build conversation threading rather than teaching them about message IDs. Second, change the system image so that the real structure is visible and comprehensible — clear labels in the users' own words, visible state, immediate feedback, constraints that make invalid actions impossible, and metaphors that carry the right implications. Third and last, change the user's model through onboarding, in-context help, and training — which is slow, expensive, and leaks as staff turn over, and should therefore be used only where the underlying complexity is irreducible. Mismatches that are never bridged produce predictable, repeatable errors: thermostats set to 30°C in the mistaken belief that a higher setting heats faster (a valve-versus-thermostat model confusion), files "lost" because a user's model of cloud sync does not include a local/remote distinction, or repeated double-submission of a payment because the system shows no evidence that the first press registered.

Introduction to Task Analysis

Task analysis is the systematic study of what people do to achieve a goal: the sequence of actions, the decisions taken, the information required at each point, the artefacts and tools used, and the conditions under which the work varies. Where user research tells you who people are and what they want, task analysis tells you in detail how the work actually proceeds — and it does so in a representation that can be reviewed, argued about, and handed to a design team.

A thorough task analysis typically captures, for each step: the trigger that initiates it; the actor responsible; the information needed and its source; the action performed; the output or state change produced; the decision rules applied; the typical duration and frequency; and the known failure modes. Consider a seemingly trivial task — a warehouse operative picking an item for an order. A surface description is "scan the item and put it in the tote". A task analysis reveals that the operative must first locate the bin from a code, verify that the bin label matches the pick list, check the item's expiry date against a policy threshold, count a multi-pack quantity, decide what to do if the bin is short (substitute, partial-pick, or raise an exception), and record the result — all while holding a scanner and pushing a cart. Each of those hidden decisions is a design requirement.

Task analysis is also a diagnostic instrument. Laying out the current ("as-is") process almost always exposes inefficiencies and gaps:

Redundant data entry — the same reference number typed into three systems, which indicates an integration opportunity and a likely source of transcription errors.
Context switching — steps that require leaving the application to consult a spreadsheet, a laminated chart, or a colleague, each of which is a candidate for bringing information into the interface.
Memory bridges — information carried in the head from one screen to the next (an account number, a quoted price) which should instead be carried by the system and displayed where it is needed.
Waiting and blocking — steps that stall pending another person's action, suggesting notification, queueing, or parallelisation.
Unsupported exceptions — the "what if" branches that users handle by phone, email, or informal workaround because the system has no path for them. These are frequently 20–30% of real volume while being 0% of the original specification.

The outputs feed directly into three design artefacts. Information architecture follows from what information is needed when and how users group it (reinforced by card-sorting data). Navigation design follows from the sequences and branches: steps performed in strict order suit a wizard; steps performed in varying order by experienced users suit a dashboard with independently addressable sections; frequently alternated pairs of steps should not be separated by deep navigation. Feature prioritisation follows from frequency and criticality: a step performed two hundred times a shift deserves a dedicated single-keystroke affordance, while a step performed twice a year can live three clicks deep in a menu with explanatory text.

Hierarchical Task Analysis (HTA)

HTA is the most widely used task-analysis notation. It represents work as a hierarchy: a single top-level goal is decomposed into sub-goals, which are decomposed further until the analyst reaches operations — units of behaviour concrete enough to be designed for and observed. Crucially, each level of the hierarchy also carries a plan: a statement of the conditions under which its subtasks are performed and in what order. Without plans an HTA is merely a list; with them it is an executable description of work.

Decomposition is conventionally numbered so that any node can be referenced unambiguously. A worked example for withdrawing cash at an ATM:

0. Withdraw cash from ATM
   Plan 0: do 1 - 2 - 3 - 4 - 5 - 6 in order.
           If card is retained at any point, go to 7 and exit.

   1. Initiate session
      Plan 1: do 1.1; then 1.2.
      1.1 Insert card
      1.2 Enter PIN
          Plan 1.2: do 1.2.1 then 1.2.2.
                    If "incorrect PIN", repeat up to 3 times;
                    on 3rd failure, exit (card retained).
          1.2.1 Read keypad / shield keypad
          1.2.2 Key digits and confirm

   2. Select "Withdraw cash"

   3. Specify amount
      Plan 3: if required amount appears on the quick-select
              list, do 3.1; otherwise do 3.2 then 3.3.
      3.1 Press quick-select amount
      3.2 Select "Other amount"
      3.3 Key amount and confirm

   4. Choose receipt option

   5. Retrieve card

   6. Retrieve cash

   7. Record retained card / contact bank

Several things are worth noticing in this small example. The hierarchy separates what is achieved (sub-goal 3, "specify amount") from how it may be achieved (3.1 versus 3.2–3.3), so the analysis remains valid even if the interface changes. Plans capture three distinct kinds of logic: sequence (plan 0), selection under a condition (plan 3), and iteration with a bound (plan 1.2). Finally, the ordering of 5 and 6 is itself a design decision with safety consequences — ATMs were redesigned to dispense the card before the cash precisely because task analysis and field data showed a post-completion error: once the user's main goal (cash) was satisfied, the subsidiary step of retrieving the card was systematically forgotten.

Practical guidance for building an HTA:

Start from a goal, not a screen. "Book a repeat prescription" is a goal; "use the prescriptions page" is not. Goal-framing keeps the analysis independent of any particular implementation, which is what allows it to inform redesign.
Use a consistent stopping rule. A common one is the P × C rule: stop decomposing when the probability of failure multiplied by the cost of failure is acceptably low. A step like "key amount and confirm" need not be broken into individual keystrokes unless mis-keying is both likely and costly — in an infusion-pump dose entry, it certainly is, and decomposition continues to the level of individual digit entry and decimal-point placement.
Keep levels balanced and verb-phrased. Each node should be a verb phrase ("verify patient identity"), and sibling nodes should sit at roughly the same granularity; a level that mixes "authenticate user" with "press Enter" is a sign of uneven analysis.
Validate with real practitioners. An HTA built only from documentation describes the official procedure, which is reliably different from the work as actually done. Walking the diagram through with experienced users surfaces the missing branches.

HTA earns its keep in three ways. It identifies training requirements, because any node whose performance depends on knowledge not available in the interface is, by definition, something a person must be taught or given a job aid for. It identifies error-prone steps, especially when each leaf is examined against a taxonomy of error types — omission, commission, wrong order, wrong object, timing, substitution. Steps that are subsidiary to the main goal (removing the original from a photocopier, retrieving a card), steps that require carrying information in memory, and steps that look similar but have different consequences (two adjacent buttons labelled "Submit" and "Submit and close") are predictably hazardous. And it identifies automation opportunities: nodes that are purely mechanical, deterministic, and information-complete — recalculating a total, looking up a postcode, copying a reference number between fields — are candidates for the system to perform, while nodes requiring judgement under uncertainty generally are not. A disciplined question at each leaf is: must a human do this, should a human do this, or is the human here only because the software is not?

Cognitive Task Analysis

HTA describes observable behaviour very well and the thinking behind it only weakly. In knowledge-intensive domains — air traffic control, emergency medicine, fraud investigation, network operations, military command — the hard part of the task is not the sequence of button presses but the perception, judgement, and anticipation that determine which action is taken at all. Cognitive Task Analysis (CTA) is a family of methods for making that invisible work explicit: the goals that are actually being pursued, the cues that experts attend to, the mental models and strategies they bring, and the trade-offs they make under time pressure, ambiguity, and risk.

The central difficulty is that expertise is largely tacit. Skilled performers have automated much of their behaviour and genuinely cannot report it; asked how they knew a patient was deteriorating, an experienced nurse may say "she just looked wrong". CTA methods are designed to work around this:

Critical Decision Method (CDM). A structured retrospective interview organised around a single memorable, non-routine incident. The interviewer sweeps the story several times: first to establish the timeline, then to identify the decision points, then to probe each decision with specific question types — What cues did you notice? What did you expect to happen next? What alternatives did you consider and reject, and why? What would a less experienced colleague have done here? What information would have made this easier? What if the patient had also been hypotensive? The counterfactual probes are especially productive because they force comparison and thereby expose the decision rule.
Knowledge audit. A targeted interview sweeping known dimensions of expertise: noticing subtle cues, spotting anomalies, improvising, recognising the "big picture", anticipating consequences, and knowing when the standard procedure does not apply. Each probe asks for a concrete example plus the cues and strategies involved.
Concurrent think-aloud on representative problems, often supported by eye tracking to show what was actually looked at and in what order.
Simulation and scenario walkthroughs, in which a realistic case is presented and paused at decision points so the expert can articulate assessments and predictions.
Comparative expert–novice analysis, which isolates what expertise actually consists of by contrasting how the two groups structure the same problem.

The distinction between HTA and CTA is one of focus rather than rivalry; in practice CTA is often used to "deepen" particular nodes of an HTA that are known to be judgement-heavy.

Dimension	Hierarchical Task Analysis	Cognitive Task Analysis
Primary question	What does the user do, in what order?	What does the user know, notice, and decide — and why?
Unit of analysis	Goals, sub-goals, operations, plans	Decision points, cues, strategies, mental models, trade-offs
Typical methods	Observation, documentation review, walkthrough with users	Critical Decision Method, knowledge audit, simulation, think-aloud
Best suited to	Procedural, repeatable, observable work	Judgement under uncertainty, time pressure, high consequence
Typical output	Task hierarchy with plans; error and automation candidates	Decision requirements table; cue inventory; expertise differences
Design implication	Structure of flows, sequencing, shortcuts, confirmations	What information to display, when, and in what representation

The characteristic deliverable of CTA is a decision requirements table, which converts tacit expertise into explicit display requirements. For an intensive-care deterioration-monitoring display, one row might look like this:

Decision	Why it is difficult	Cues and factors used by experts	Common novice error	Interface implication
Should this patient be escalated now or reassessed in 30 minutes?	Individual vital signs may each be within range while the overall trajectory is adverse; escalation has social and resource costs	Rate and direction of change over the last few hours; combination of rising respiratory rate with falling urine output; divergence from the patient's own baseline; nursing "gut feel" about appearance and responsiveness	Reads only the latest values against fixed thresholds and concludes "all normal"	Display trends, not just current values; show deltas against the patient's own baseline; surface the composite early-warning score with its contributing components; make the free-text concern field prominent and visible to the responding clinician

That final column is the point of CTA for designers. Expert knowledge that has been made explicit can be surfaced in the interface so that less experienced users are supported: trend sparklines instead of bare numbers, anomaly highlighting that draws attention to the cue an expert would have noticed, contextual decision aids that show the alternatives an expert would have considered, comparative baselines, and worked rationale ("flagged because respiratory rate has risen 6/min in 2 hours"). The ethical and practical caveat is that such aids should support judgement rather than replace it: over-automated alerts breed alarm fatigue, and displays that hide their reasoning erode the user's ability to detect when the system is wrong.

Applying Task Analysis to User-Centered Design

Task analysis only matters if it changes the artefact. The translation happens through three linked practices: deriving design blueprints, prioritising effort, and validating designs back against the analysis.

First, task flows and use cases turn the hierarchy into an interaction specification. A task flow is a linear or branching diagram of the steps a user takes through a proposed system, including decision diamonds and error paths; a use case is a textual description with actors, preconditions, a main success scenario, and extensions. An HTA plan maps onto these almost mechanically: a strict sequence plan suggests a stepped wizard with a visible progress indicator; a selection plan becomes a branch that the interface should make explicit and reversible; an iteration plan becomes a repeatable block with an obvious "add another" affordance and a clear termination condition. A worked fragment for an insurance claim:

Use case: Submit a motor claim (main success scenario)
  Actor: Policyholder (primary)   Secondary: Claims handler
  Precondition: Policy is active; incident occurred within 30 days

  1. User identifies the policy                [from HTA 1.1-1.2]
  2. System confirms cover and shows excess    [info need: excess amount]
  3. User describes incident (date, location, parties)
  4. User uploads photographs                  [iteration: 1..n images]
  5. System validates required evidence
  6. User reviews summary and submits
  7. System issues claim reference and expected contact time

  Extension 4a: No photographs available
     4a1. User selects "add later"; system issues reference
          and sends a secure upload link valid for 7 days.
  Extension 2a: Cover excludes incident type
     2a1. System explains exclusion in plain language and
          offers to connect to an adviser.

Notice that the extensions come straight from the "unsupported exceptions" found in the as-is analysis — the branches that users previously resolved by telephone. Designing them in is usually where the largest usability gains are found.

Second, prioritisation. Not all tasks deserve equal design investment, and task analysis supplies the three variables needed to allocate it rationally: frequency (how often the task occurs), criticality (the cost of failure), and error-proneness (how likely failure is). Combining them gives a defensible ranking and, importantly, different kinds of treatment rather than simply "more effort".

Task profile	Example	Appropriate design treatment
Frequent, low criticality	Logging a pick in a warehouse app; archiving an email	Ruthless efficiency: minimum keystrokes, no confirmation dialogs, undo instead of prevention, persistent defaults
Infrequent, high criticality	Transferring a large payment; decommissioning a production server	Deliberate friction: explicit review step, re-statement of consequences, typed confirmation, clear reversal path, step-by-step guidance that assumes no memory of last time
Frequent, high criticality	Entering a medication dose; air traffic handoff	Both: fast for experts but heavily constrained — input masks, range checks, forcing functions, distinctive formatting, double-check by a second person where justified
Error-prone regardless of frequency	Post-completion steps; near-identical adjacent options; unit or format ambiguity	Redesign the sequence to eliminate the error class (reorder steps, remove the mode, make the unit explicit and non-defaultable), not merely warn about it
Rare, low criticality	Changing a display preference	Accept depth in the navigation; invest in findability and explanatory text rather than speed

Third, validation. Because the task analysis is written independently of any particular design, it becomes a test oracle for prototypes. Three complementary checks are standard:

Coverage check. Walk every leaf of the HTA against the prototype and ask where each one is performed. Any leaf with no home in the interface is a gap; any screen element that corresponds to no leaf is either an unexamined assumption or scope creep.
Step-count and effort comparison. Compare the as-is and to-be flows for the highest-frequency tasks. If the new design adds steps to a task performed three hundred times a day in order to save steps on a task performed weekly, the trade is almost certainly wrong — and task analysis makes that visible before code is written. This is the standard defence against a redesign that is prettier but slower.
Scenario-based testing. Build usability test tasks and cognitive walkthrough scenarios directly from the analysis, including the exception branches and the decision points identified by CTA. Testing should include realistic conditions revealed by contextual inquiry — interruptions, incomplete data, time pressure — because a design that works only on clean data in a quiet room has not been validated against the real task.

Two cautions complete the picture. Task analysis describes work as it is currently done, so uncritical fidelity to the as-is process can cement obsolete constraints — the analyst must distinguish steps that exist because the domain demands them from steps that exist because the old system demanded them. And work evolves: an analysis is a living document that should be revisited as the system changes the very behaviour it described. Used with that awareness, task analysis is what keeps user-centred design honest — it ensures the system supports the way people actually work rather than quietly imposing new burdens on them in the name of improvement.

Alignment with Learning Outcomes

MO1 — Partially supported. The topic does not enumerate the types of human memory or their capacities, but it touches the same constraint from the task side: "memory bridges" (information users must carry in their heads between steps), post-completion errors, and infrequent tasks that cannot rely on remembered procedure all illustrate why memory limits must shape interface design.
MO2 — Directly supported. The treatment of mental models, conceptual models and the system image, the elicitation techniques (card sorting, think-aloud), and the worked examples of mismatch-driven errors (thermostat settings, cloud sync, double payment submission) explain how a gap between the user's model and system behaviour produces systematic, predictable error.
MO3 — Directly supported. The HTA section provides the goal–sub-goal–operation decomposition, numbered notation, plans expressing sequence, selection and iteration, stopping rules such as P × C, and a worked ATM example, then shows how the resulting hierarchy drives navigation structure, shortcuts, confirmations and automation decisions.
MO4 — Partially supported. The topic does not compare usability inspection methods with user testing as such, but it supplies the research-method comparison (interviews, surveys, contextual inquiry, diary studies, logs) and shows how task analysis generates the scenarios and coverage checks used in both cognitive walkthrough and scenario-based user testing, which is the input that later evaluation choices depend on.
MO5 — Partially supported. Prototyping itself is not taught here, but the topic supplies what a prototype must embody and be tested against: task flows and use cases as interface blueprints, frequency/criticality-based prioritisation of what the prototype should foreground, and validation of prototypes against task-analysis findings.

NotesSuggested in-class activities: (1) run a 20-card open card sort on the module's own VLE content and compare student groupings with the existing menu; (2) build an HTA for "submit an assignment" including plans, then identify one error-prone leaf and one automation candidate; (3) conduct a 15-minute Critical Decision Method interview in pairs about a recent non-routine task and produce a one-row decision requirements table. Examples used (ATM card-before-cash redesign, e-prescribing stakeholder map, ICU deterioration display) are well-established illustrative cases and can be swapped for domain-relevant equivalents. Terminology follows Beyer & Holtzblatt for contextual inquiry, Cooper's goal-directed design for the experiential/end/life goal triad, Annett and Shepherd for HTA, and Klein's Critical Decision Method for CTA.

2

Videos on This Topic

▶

Before you can design an interface, you have to know who will use it, what they are trying to accomplish, and how they think the system works. This topic covers the front end of user-centered design: identifying your actual users (as opposed to the imagined "average person"), researching their needs through interviews, observation, surveys, and contextual methods, and modeling their goals and mental models so that your design matches their expectations rather than the developer's internal logic.

The second half of the topic turns research into structure. Task analysis is the practice of breaking down what users do into describable units: Hierarchical Task Analysis (HTA) decomposes a high-level goal into subtasks and plans that govern their order, while Cognitive Task Analysis focuses on the knowledge, decisions, and attention demands hidden behind observable actions. Both feed directly into design decisions — what to put on a screen, what to automate, what to group together, and where errors are likely.

The videos below focus on the research methods side of this topic. As you watch, pay attention to three things: what kind of data each method produces (what people say versus what people do), what context the data is gathered in, and how a researcher avoids leading or biasing the participant. Try to connect each method back to how you would use its output to build an HTA or a mental-model description for a system you are designing.

3

Video 1: What are Contextual Inquiries?

▶

NNgroup · 3:01 · 19,608 views · 4y ago · captions — Watch on YouTube

About this video

A short overview of contextual inquiry, a research method in which the researcher observes and questions users in their own working environment while they perform real tasks. Based on its title and description, it explains what contextual inquiry is used for — defining requirements, improving processes, and learning what matters to users — and when it is an appropriate choice. Expect a compact introduction rather than a step-by-step field guide.

Why this video

Nielsen Norman Group is a well-established UX research organization, and this video maps directly onto the "Methods for Researching User Needs" subtopic; contextual inquiry is also the classic source of raw material for task analysis, since it captures real tasks in real settings.

4

Video 2: UX Research Methods: The Basics You Need to Get Started

▶

UX in the Head · 11:26 · 35,698 views · 3y ago · captions — Watch on YouTube

About this video

A broader survey of the UX research methods you are most likely to encounter, including common techniques and several lesser-known ones, with discussion of what each is used for. At about eleven minutes it provides enough room to compare methods rather than just name them, which helps you see how interviews, observation, surveys, and testing differ in the kind of evidence they produce. Use it to build a mental catalog of options you can draw on later.

Why this video

It gives you the comparative overview that the "Methods for Researching User Needs" subtopic requires, so you can justify choosing one method over another instead of defaulting to whichever one you learned first.

5

Video 3: Help Users Think Aloud

▶

NNgroup · 3:42 · 18,210 views · 3y ago · captions — Watch on YouTube

About this video

A practical guide to the think-aloud protocol: how to explain the technique to participants, why verbalizing while working is useful, and how to prompt people who fall silent without putting words in their mouths. The focus is on facilitation skill — reinforcing the behavior and keeping the session natural rather than scripted.

Why this video

Think-aloud is the primary way researchers get access to a user's mental model and decision-making, which makes it the best bridge between the research methods subtopics and both "User Goals and Mental Models" and "Cognitive Task Analysis."

6

How These Videos Support the Learning Outcomes

▶

These videos support the module outcomes mainly by supplying the evidence-gathering skills that the analysis and evaluation outcomes depend on. Contextual inquiry and think-aloud sessions are how you surface a user's mental model and detect where it diverges from system behavior (MO2), and the verbalized reasoning and observed task sequences they produce are the raw input you decompose into goals, subtasks, and plans when performing a Hierarchical Task Analysis (MO3). The survey of UX research methods gives you the comparative vocabulary needed to argue why one technique fits a given design context better than another, which carries directly into selecting between expert-driven inspection and user testing later in the module (MO4), while the findings from all three feed the design and prototyping decisions you will make in MO1 and MO5.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Interaction Design and Prototyping

1

Interaction Design and Prototyping

▶

Interaction design is the discipline concerned with shaping the behaviour of an interactive product — what it does in response to what a person does. Where visual design is largely concerned with how an interface looks and information architecture with how content is organised, interaction design asks a sequence of behavioural questions: What can the user do here? What happens when they do it? How do they know it worked? What happens when it does not work? A well-designed interaction is essentially a well-designed conversation, in which the system's responses are timely, intelligible, and predictable enough that the user can form reliable expectations about what will happen next. Prototyping is the practical craft through which interaction designers externalise these conversations, test them cheaply, and communicate them to the people who will build and fund the product. The two subjects are inseparable in practice: interaction design proposes behaviour, and prototyping is how that proposed behaviour becomes inspectable before a single production line of code is committed.

Core principles of interaction design. Interaction design begins with the recognition that a product is not a static artefact but a system of responses. A "Save" button is not merely a rectangle with a label; it is a promise about state change, about where data will go, about what feedback the user will receive, and about what will happen if the network fails mid-operation. Designing that promise — and ensuring the system keeps it — is interaction design. Four principles, drawn largely from Donald Norman's work and refined across decades of practice, structure most of this work.

Visibility means that the controls relevant to a user's current goal are perceivable, and that the current state of the system is apparent. A car dashboard makes fuel level, speed, and warning conditions continuously visible; by contrast, a hidden gesture-only menu in an app makes an entire branch of functionality invisible to anyone who has not been told it exists. Visibility also covers status: a file-sync application that shows a small cloud icon with a checkmark communicates "everything is backed up" without requiring the user to go looking.
Feedback is the system's acknowledgement that an action has been registered and what its consequence was. Feedback operates on several timescales. Sub-100-millisecond feedback (a button depressing, a row highlighting) confirms that input was received; one-second feedback (a spinner, a progress bar) maintains the sense of continuity; and completion feedback (a toast message, "Message sent", an updated list) confirms the outcome. The absence of feedback produces the classic failure mode of repeated clicking: the user, uncertain whether the first press registered, presses again and inadvertently submits the order twice.
Consistency reduces learning cost by ensuring that similar things behave similarly. Internal consistency means that within the product, the same gesture always produces the same class of result — if swiping left deletes an email, it should not archive a contact. External consistency means conforming to the conventions of the wider platform and of competitor products, so that knowledge transfers in. Consistency is not an absolute good: a deliberate inconsistency is justified when two situations genuinely differ and the user must be prevented from conflating them (a destructive action styled differently from a benign one, for instance).
Affordance, in Gibson's original sense, refers to the action possibilities a thing offers to a particular actor; in Norman's revised interface vocabulary, the useful term for designers is signifier — the perceptible cue that advertises the affordance. A raised, shaded rectangle signifies "pressable"; blue underlined text signifies "clickable"; a scrollbar's partial thumb signifies "there is more content below". The flat-design movement of the 2010s stripped many such signifiers and created measurable discoverability problems, which is why contemporary design systems have partially reintroduced shadow, elevation, and border cues around interactive elements.

Two further commitments sit alongside these principles. The first is that good interaction design anticipates user goals and minimises the effort needed to reach them. Effort can be counted literally: number of taps, distance of pointer travel, number of fields to fill, number of decisions to make, and amount of information the user must hold in memory between steps. A booking flow that pre-fills the departure city from the user's last search, defaults the date to tomorrow, and remembers passenger details has not changed what the system can do — it has changed how much work the user must do to get the common case done. Sensible defaults, recognition over recall (offering a list to choose from rather than demanding a remembered string), and progressive commitment (letting a user explore before forcing them to register) are all expressions of this commitment.

The second is the balance between aesthetic appeal and functional clarity. These are not opposed by default: research on the "aesthetic–usability effect" indicates that people perceive attractive interfaces as easier to use and are more tolerant of minor problems in them. But aesthetics become harmful when they consume the perceptual budget that clarity requires — low-contrast grey-on-white text that fails accessibility thresholds, decorative icons without labels whose meaning no one guesses correctly, or an animated transition so long that it becomes a tax on every navigation. The working rule is that visual decisions should be evaluated by whether they help the user perceive structure, state, and available action; ornament that does none of these must earn its place on other grounds, such as brand expression, and must never obstruct the task.

Desktop interaction design. The desktop remains the environment of sustained, precision, multi-document work: writing, coding, spreadsheet modelling, video editing, case management. Its interaction vocabulary matured over forty years, and most of its power comes from the fact that users arrive already fluent in it.

Established GUI conventions. Menu bars give a complete, scannable inventory of application capability, which is why complex professional applications still rely on them: a menu is a self-documenting command set. Toolbars surface the small subset of commands used most frequently; context menus (right-click) deliver object-specific commands at the point of attention; dialogs collect parameters for a single operation; and status bars report ambient state. Window management — resizing, tiling, minimising, tabbing — lets users construct their own workspace, comparing two documents side by side in a way a phone cannot support. Because these conventions are shared, a new application that uses them correctly inherits a large portion of its learnability for free. A reference manager that puts "Export…" under a File menu, supports Ctrl/Cmd+F for find, and offers right-click on a reference entry requires almost no instruction for the basics.
Varied screen sizes and resolutions. Desktop no longer means a single fixed canvas. A design may be rendered on a 13-inch laptop at 1280×800 logical pixels and on a 32-inch 4K display at 200% scaling, and the same window may be dragged between them. Layout integrity therefore depends on resolution-independent thinking: relative units and fluid grids rather than pixel-fixed positions, vector or multi-resolution raster assets so icons stay crisp at high DPI, minimum and maximum content widths so that text columns remain in the comfortable 45–90 character range rather than stretching to an unreadable 200 characters on a wide monitor, and resilient behaviour when a window is deliberately made narrow. Panels that collapse into a drawer below a certain width, tables that allow horizontal scrolling of secondary columns while freezing the identifying column, and toolbars that overflow into a "More" chevron are standard techniques.
Desktop-specific interaction patterns. Three capabilities distinguish the desktop. Keyboard shortcuts and keyboard navigation create an expert pathway that bypasses the pointing device entirely; for a user entering a hundred records a day, the difference between tabbing through a form and reaching for the mouse is measured in hours per week. Shortcuts should be discoverable (shown next to the menu item that performs the same command), conventional (Ctrl/Cmd+S for save, Ctrl/Cmd+Z for undo), and never in conflict with the operating system's reserved combinations. Drag-and-drop exploits the precision of a mouse to express "move this there" directly, and demands careful feedback design: a drag image that follows the cursor, drop targets that highlight on hover, a cursor that changes to indicate copy versus move versus forbidden, and an undo path for the inevitable mis-drop. Multi-window and multi-monitor navigation supports comparison and reference tasks; applications that support detachable panels, multiple document windows, and "open in new window" allow users to externalise working memory onto the screen rather than holding it in their heads.
Platform guidelines. Apple's Human Interface Guidelines and Microsoft's Fluent/Windows design guidance differ in concrete, user-visible ways — the position of the menu bar, the ordering of OK/Cancel in dialogs, the modifier key used for shortcuts, the conventions for preferences versus settings, the behaviour of closing the last window. Honouring the host platform's conventions means a user's existing habits continue to work. Cross-platform frameworks make it tempting to ship one identical interface everywhere; the cost is a product that feels subtly foreign on every platform. A pragmatic compromise is to keep the application's own domain logic and layout consistent across platforms while adapting the "edges" that touch the OS: keyboard modifiers, file dialogs, window chrome, notification behaviour, and system-level typography.

Mobile interaction design. Mobile is not a shrunken desktop. The input device changes from a one-pixel-precise cursor to a soft, occluding fingertip; the display shrinks by an order of magnitude in area; the user is frequently moving, distracted, one-handed, and on an unreliable network. Each of these facts generates design obligations.

Touch input and gestures. A fingertip's contact area is roughly 8–10 mm across, which is why platform guidance specifies minimum targets of about 44×44 points on iOS and 48×48 density-independent pixels on Android, with adequate spacing between adjacent targets so that an imprecise tap does not trigger the wrong one. The finger also occludes what it touches, so confirmation feedback must appear outside the contact area — hence the magnified character bubble above the key on a phone keyboard, and tooltips that appear above rather than below the touch point. Gestures (swipe, pinch, long-press, drag, edge-swipe) are efficient but invisible: they carry no signifier at all. The safe pattern is to treat gestures as accelerators layered on top of a visible control — swipe-to-delete is acceptable because a delete option also exists in an edit mode; pinch-to-zoom is acceptable because it is a near-universal convention. A function available only through an undisclosed gesture is, for most users, a function that does not exist. Gestures must also avoid colliding with system gestures such as the Android back swipe or the iOS home indicator swipe.
Small screens and progressive disclosure. With perhaps one-tenth the visible area of a laptop, mobile design is fundamentally an exercise in prioritisation: deciding what the primary task is and giving it the screen, while moving secondary functions one layer deeper. Progressive disclosure is the formal name for this technique — present the few options most users need first, and provide a clear route to advanced options for those who need them. Practical expressions include accordions and expandable sections, "Show more" links on long descriptions, a summary card that opens a detail view, settings split into "Basic" and "Advanced", and multi-step wizards that ask a few questions per screen rather than presenting a thirty-field form. Navigation patterns follow the same logic: a bottom tab bar is appropriate for three to five top-level destinations, while a hamburger drawer hides everything behind a single icon and consistently reduces engagement with the items inside it — a reasonable trade for rarely used destinations, a poor one for the product's core features.
Mobile context. Orientation changes mean a layout must survive rotation without losing state — a half-completed form that empties on rotation is a well-known defect class. Network variability means designs must have explicit states for offline, slow, retrying, and failed; optimistic UI (showing the message as sent immediately while the request completes in the background, with a clear failure indicator if it does not) preserves responsiveness. Device capabilities open genuinely new interactions — camera-based scanning instead of typed entry, biometric authentication instead of passwords, and location awareness that can pre-fill a pickup address or sort results by proximity. Location, camera, and notification permissions should be requested in context, at the moment the benefit is evident, rather than in a barrage at first launch. Finally, environmental context matters: screens are used in bright sunlight (contrast), while walking (larger targets, forgiving touch), and in short bursts (fast resume to the exact prior state).
Thumb reachability and ergonomics. Studies of one-handed phone use (notably Steven Hoober's observational work) show that a majority of interactions are one-thumbed, and that the thumb sweeps a comfortable arc across the lower and centre portion of the screen, with the top opposite corner the hardest to reach. As devices grew taller, this made the traditional top-anchored navigation bar ergonomically awkward, which is why bottom sheets, bottom tab bars, bottom-anchored primary buttons, floating action buttons in the lower right, and OS-level "reachability" modes have become standard. The design heuristic that follows: place frequent and primary actions in the lower third; place infrequent, destructive, or confirmation-requiring actions further away, where accidental contact is less likely. Reachability must also be reconciled with accessibility — supporting system text scaling, maintaining contrast, labelling controls for screen readers, and never relying on colour alone to convey state.

Prototyping strategies and fidelity levels. A prototype is a deliberately incomplete manifestation of a design, built to answer a specific question. Because it is incomplete, every prototype makes a choice about what to simulate faithfully and what to fake. Fidelity is usually discussed as a single axis, but it is more accurate to think of several independent dimensions: visual fidelity (how finished it looks), functional fidelity (how much of the behaviour actually works), content fidelity (real data versus lorem ipsum), and breadth versus depth (many screens shallowly, or one flow completely).

Fidelity level	Typical form	Build cost	Best suited to answering	Characteristic risks
Low fidelity	Paper sketches, index cards, whiteboard flows, grey-box wireframes	Minutes to a few hours	Is this the right concept? Does the information architecture make sense? What steps does the task take?	Participants critique the drawing rather than the design; fine-grained issues (timing, gesture, legibility) are invisible
Mid fidelity	Digital wireframes with real structure and clickable hotspots; greyscale or minimal styling; realistic sample content	Hours to days	Can users find and complete the task? Is the navigation model sound? Where do people hesitate?	May read as "unfinished product" to stakeholders; interaction nuances still approximated
High fidelity	Pixel-accurate interactive mockups with transitions, states, and real copy; or coded front-end prototypes	Days to weeks	Is the micro-interaction right? Are affordances and labels understood? Is perceived performance acceptable? Will it convert?	Sunk-cost attachment; feedback drifts to colour and polish; stakeholders assume it is nearly built

Low-fidelity prototypes earn their place through speed and disposability. Six paper variants of a checkout screen can be sketched in the time it takes to style one in a design tool, and because nobody is invested in a pencil drawing, the team can discard five without friction. Their roughness is an asset: an unfinished-looking artefact invites structural criticism ("why is payment before shipping?") rather than cosmetic criticism ("can that blue be darker?"). They are the correct instrument in the divergent phase, when the question is still which concept to pursue.

High-fidelity prototypes close the perceptual gap with the real product. Because they look and respond like software, participants in a usability test behave much as they would with the shipped system, which makes measurements of task success, error rate, and time-on-task far more trustworthy. They are indispensable when the design question concerns detail — whether a particular icon is understood, whether an animation communicates a hierarchy relationship, whether a form's inline validation feels helpful or nagging — and when the artefact must double as a specification for developers or as a demonstration to investors or clients.

Mid-fidelity prototypes are the workhorse of most teams. Built in a digital tool with correct layout, real labels, plausible data, and working links between screens, they allow genuine task-based testing while remaining cheap enough to change overnight. Deliberately holding back visual polish — greyscale, a single typeface, placeholder imagery — keeps reviewer attention on flow and structure.

The governing rule is that fidelity should follow the question and the phase, not the team's enthusiasm. Early, when uncertainty is about concept and scope, low fidelity maximises the number of ideas explored per unit of effort. In the middle, when uncertainty is about structure and task flow, mid fidelity gives testable behaviour at reasonable cost. Late, when uncertainty is about detail, polish, and handover, high fidelity pays for itself. A useful corollary concerns audience: engineers and designers read wireframes fluently, but many non-specialist stakeholders and some end users cannot abstract from a grey box to a product and will judge a low-fidelity artefact as evidence of a poor product. For those audiences, raise visual fidelity — or frame expectations explicitly before the session begins.

Prototyping as a communication tool. Beyond testing, prototypes are the lingua franca of a product team. A specification sentence such as "the system shall allow the user to filter results" is read differently by every person who encounters it; a clickable screen showing a filter panel, its default state, its applied-filter chips, and its empty-results message leaves far less room for divergent interpretation. Making the abstract concrete changes the quality of feedback: stakeholders stop offering vague approval and start saying useful things like "our regional managers will need to filter by two branches at once" — a requirement that would likely have surfaced during development, at ten times the cost.

Early sharing creates alignment. When a prototype circulates before engineering begins, the product manager, developers, content writers, support staff, and legal reviewers can all interrogate the same artefact. Developers spot the states nobody designed (what does this screen look like for a user with zero orders?); support staff spot the scenario that generates tickets; content specialists notice that the error message is incomprehensible. Resolving these on a prototype takes hours; resolving them in a release candidate takes a sprint.
Annotation carries what visuals cannot. A static screen cannot express timing, conditionality, or failure. Annotated prototypes attach notes to elements and flows describing: component states (default, hover, focus, pressed, disabled, loading, error, success); validation rules and the exact wording of messages; empty states, first-run states, and maximum-content states; transition and animation specifications; accessibility requirements such as focus order, alternative text, and screen-reader labels; and edge cases — expired sessions, offline submission, permission denial, duplicate records, a name 120 characters long. Annotations are what turn a prototype from an illustration into a buildable description of behaviour.
Iterative review reduces late-stage cost. The economics are well documented: the cost of correcting a defect rises by roughly an order of magnitude at each stage it survives — concept, design, implementation, release. Repeated short reviews with real users and decision-makers catch misconceptions while the only thing to rework is the prototype. A practical cadence is a short review at the end of each design cycle, with a small number of participants, focused on one or two explicit questions rather than open-ended "what do you think?" solicitation.

Iterative design through prototyping. Iteration is not simply "doing it again"; it is a disciplined loop of design → prototype → evaluate → interpret → revise, in which each pass is informed by evidence from the previous one. A first-round prototype might reveal that users never notice the filter control; the second round moves and re-labels it and tests whether discovery improves; the third round finds that discovery is fixed but users do not understand how to clear a filter, and addresses that. Over several cycles the design converges on something that works, and — equally valuable — the team accumulates an evidence-based understanding of its users.

Rapid prototyping lowers the cost of being wrong. When an alternative can be produced in an afternoon, the team is willing to try the risky idea, and willing to abandon it when evidence goes against it. The psychological effect is as important as the economic one: teams that have invested six weeks in a direction defend it; teams that have invested six hours in each of four directions choose dispassionately among them. Parallel prototyping — building several alternatives simultaneously rather than refining one serially — has been shown to produce better outcomes and more critical feedback, partly because critique of one option among many is not experienced as personal criticism.
Structure iterations around explicit hypotheses. Unfocused testing yields unfocused results. A productive cycle begins with a written statement of what is believed and how it will be checked: "We believe that moving the primary action to the bottom of the screen will allow one-handed users to complete checkout without repositioning the phone; we will know this is true if at least eight of ten participants complete the task one-handed and time-on-task falls relative to the previous build." A hypothesis of this form specifies the change, the expected user behaviour, and the observable criterion, which prevents the common failure of declaring a design successful because participants said they liked it.
Document changes and rationale between versions. Teams that cannot remember why a decision was made will re-litigate it. A lightweight version history — a changelog page in the prototype file, or a short entry per version recording what changed, why it changed, what evidence prompted it, and what was explicitly rejected — preserves design rationale. For example: "v4 → v5: replaced the hamburger drawer with a four-item bottom tab bar. Rationale: in round 2 testing, 7/10 participants failed to locate 'Saved items'; drawer discovery was the cause. Rejected alternative: keeping the drawer but adding a badge — judged insufficient because the problem was discovery, not salience." Such records shorten onboarding for new team members, give developers the reasoning behind unusual choices, and protect the team from re-introducing a pattern that evidence has already ruled out.
Knowing when to stop. Iteration has diminishing returns. Reasonable stopping conditions include: the hypotheses for this cycle have been answered; task success and error rates have plateaued across two consecutive rounds; the remaining issues are cosmetic or can be resolved post-launch with analytics; or the cost of another cycle exceeds the expected value of what it would uncover. Stopping should be a deliberate decision recorded alongside the known outstanding risks, not an accident of the calendar.

Tools and techniques for prototyping. The right technique depends on the question being asked, the time available, and how much of the system can realistically be faked. Most teams use several in combination across a project.

Paper prototyping. Hand-drawn screens on paper or index cards, with movable pieces — a sticky note for a dropdown, a cut-out rectangle for a modal, a strip of paper slid up a "screen" to simulate scrolling. In a walkthrough, one team member acts as the "computer", swapping sheets in response to where the participant taps with a finger, while another facilitates and a third takes notes. The method is extraordinarily cheap, requires no tool skills, and is excellent for testing information architecture, task sequence, and terminology. Its limits are equally clear: it cannot test timing, animation, legibility, gesture precision, or anything dependent on real data volume. It is also effective as a collaborative technique — design studio or "six-up" sketching sessions, in which every participant sketches multiple concepts in a fixed number of minutes and the group critiques them, surface far more of the design space than a single designer working alone.
Digital prototyping tools. Tools such as Figma, Adobe XD, Sketch with InVision, Axure RP, ProtoPie, and Framer produce clickable artefacts that can be opened on a real device. Their characteristic capabilities include reusable components and design systems (change the button once, it changes everywhere), variants and interactive states, auto-layout for responsive behaviour, overlays and transitions, and in the more advanced tools, variables, conditional logic, and form input that behaves like the real thing. Axure and ProtoPie, for instance, can hold state — a prototype shopping cart that genuinely accumulates items and recalculates a total — which allows far more realistic testing than a linear click-through where every path leads to the same hard-coded screen. Modern tools are also collaborative: multiple designers edit simultaneously, stakeholders comment directly on the canvas, and developers inspect spacing, colour tokens, and asset exports from the same file, which removes an entire category of handover error. The main cautions are the temptation to over-polish before the concept is validated, the fact that a prototype's "happy path" can conceal unhandled states, and the risk that a highly convincing prototype causes stakeholders to underestimate remaining engineering effort.
Storyboarding. Borrowed from film, a storyboard is a short sequence of panels showing a person, in a context, with a motivation, encountering the product and reaching an outcome. Where a prototype shows the screens, a storyboard shows the situation: a delivery driver double-parked in rain, one-handed, with three minutes to confirm a drop-off. This reframes design questions usefully — glove-compatible targets, loud-environment feedback, offline tolerance — that screen-level work tends to ignore. Storyboards also communicate value to non-designers, support the framing of research scenarios and test tasks, and pair naturally with personas and journey maps. They are quick (stick figures are entirely adequate) and are best produced before or alongside the first prototypes rather than after.
Wizard of Oz prototyping. Named for the man behind the curtain, this technique has a hidden human operator generate the system's responses while the participant believes they are interacting with working software. It is the method of choice when the underlying technology is expensive, unbuilt, or probabilistic: conversational agents and chatbots, speech recognition, recommendation engines, machine-learning classification, and complex automation. A team designing a voice-controlled appliance can, for the price of a microphone and a confederate in the next room, discover what phrasings people actually use, what they expect the system to remember between turns, and how they recover when it misunderstands — findings that directly shape the grammar, prompts, and error-handling of the real system before any model is trained. Running one well requires preparation: a clear protocol so the operator responds consistently (including deliberately simulating realistic error rates, since a flawless "system" produces misleadingly positive results), a plausible cover story, rehearsed response latency, and an ethical debrief in which participants are told how the session worked. Related techniques include the "Pinocchio" or hollow prototype (a non-functional physical mock-up used to study form, handling, and placement) and concierge testing, in which the service is delivered manually to real customers to validate demand before automation.

Technique	Primary question it answers	Typical effort	Strongest in	Main limitation
Paper prototyping	Is the structure and sequence of the task right?	Minutes–hours	Early concept work, group ideation, terminology checks	No timing, motion, gesture or real-data realism
Digital interactive prototype	Can users complete realistic tasks, and where do they fail?	Hours–weeks	Usability testing, developer handover, stakeholder demos	Unmodelled states; polish can distract from structural feedback
Storyboard	Does the design fit the user's real situation and motivation?	Under an hour	Framing context, communicating value, scripting test scenarios	Not interactive; cannot evaluate interface mechanics
Wizard of Oz	How do people behave with intelligent or unbuilt functionality?	Hours of setup plus a facilitation team	Voice, chat, AI-driven and automated systems	Operationally demanding; results depend on operator consistency; needs ethical debrief

Brought together, these ideas describe a single working method. Interaction design supplies the principles — visibility, feedback, consistency, signified affordance, economy of user effort — and the platform-specific knowledge needed to apply them well on a precise, multi-window desktop or on a small, touch-driven, context-sensitive mobile device. Prototyping supplies the means of making proposed behaviour visible at a fidelity matched to the current question, communicating it unambiguously to users, stakeholders and developers, and revising it through hypothesis-driven cycles whose rationale is recorded. The practical discipline lies in choosing deliberately: this fidelity, this technique, this audience, to answer this question, at this point in the project.

Alignment with Learning Outcomes

MO1 — Not directly addressed. The topic does not enumerate memory types or their capacities, although its treatment of recognition over recall, sensible defaults, and progressive disclosure reflects the interface consequences of limited working memory.
MO2 — Partially supported. The discussion of visibility, feedback, consistency, signifiers, and the use of prototypes to expose mismatched expectations shows how a user's expectations about system behaviour can diverge from actual behaviour and produce systematic errors, but the topic does not formally analyse mental models.
MO3 — Indirectly supported. The topic does not teach Hierarchical Task Analysis, but it shows how an understanding of a user's goal and its constituent steps feeds interface decisions such as effort minimisation, progressive disclosure, navigation structure, and the task flows represented in a prototype.
MO4 — Partially supported. Coverage of fidelity selection, hypothesis-driven iteration cycles, task-based prototype testing and Wizard of Oz studies gives the context for choosing an evaluation approach, though the explicit comparison of expert-driven inspection methods with user testing sits outside this topic.
MO5 — Directly addressed. The topic defines low-, mid- and high-fidelity prototyping, explains how to select a fidelity level for a given question, surveys paper, digital, storyboard and Wizard of Oz techniques, and sets out the desktop and mobile interaction design principles a prototype should embody.

NotesDepth notes: the body extends the supplied subtopics with well-established material — Norman's signifier/affordance distinction, the aesthetic–usability effect, platform touch-target minima (44pt iOS, 48dp Android), Hoober's thumb-zone findings, parallel prototyping research, the escalating cost-of-change curve, and state-capable prototyping tools (Axure, ProtoPie) — all consistent with standard HCI literature. Fidelity is framed as several dimensions (visual, functional, content, breadth/depth) rather than a single axis, which is worth emphasising in class. Two comparison tables are provided (fidelity levels; prototyping techniques) and may be reused as revision aids or as the basis for a selection exercise. Alignment note treats MO5 as the primary outcome served by this topic; MO1 is explicitly flagged as not addressed.

2

Videos on This Topic

▶

Interaction design is the practice of shaping how people and interactive systems communicate with each other: what the system shows, what the user can do, what happens next, and how the user knows it happened. It sits between understanding users (goals, tasks, mental models) and building software, and it is deliberately iterative — you sketch a concept, put it in front of someone, learn what breaks, and revise.

In this course the topic matters for two reasons. First, the core principles (visibility, feedback, constraints, consistency, affordances and signifiers) give you a shared vocabulary for critiquing desktop and mobile interfaces instead of calling them simply "good" or "bad." Second, prototyping is how those principles get tested cheaply: paper sketches, wireframes, clickable mockups and higher-fidelity mockups each trade effort for realism, and each is useful at a different stage. A prototype is also a communication artifact — it lets you show a teammate, client or test participant an idea that words alone would not pin down.

As you watch, keep a running list of three things: concrete examples of designs that succeed or fail and the principle that explains why; the stages of the design process and where prototypes and user feedback enter the loop; and the difference between what an interface affords and what it merely appears to afford. You will use all three when you build your own low-to-mid fidelity prototype.

3

Video 1: Chapter 1: What is Interaction Design

▶

Vasiliki - HCI · 16:16 · 14,628 views · 5y ago · captions — Watch on YouTube

About this video

An introductory lecture defining interaction design as a field and distinguishing it from related areas such as HCI, UX and usability. Based on its title and chapter structure, it works through examples of poor design and references classic HCI material, including the Xerox PARC copier ethnography study, to show why designers must understand users in context. Expect coverage of foundational goals and principles that interaction designers work toward.

Why this video

It is the natural starting point for the topic, establishing the vocabulary and motivating examples that the rest of the module builds on, and it is part of a structured HCI lecture series rather than a one-off clip.

4

Video 2: Chapter 2: The Process of Interaction Design

▶

Vasiliki - HCI · 12:04 · 8,018 views · 5y ago · captions — Watch on YouTube

About this video

The follow-up lecture in the same series, focused on the interaction design process itself. Its description points to the Double Diamond framework from the Design Council and the Design Squiggle, both of which illustrate how design moves between divergent exploration and convergent decision-making. Expect discussion of the activities involved — establishing requirements, designing alternatives, prototyping and evaluating — and how they repeat rather than run once.

Why this video

This video directly addresses iterative design and where prototyping sits within the larger process, which is the conceptual backbone of the prototyping subtopics in this module.

5

Video 3: What are Affordances in UX Design. Affordances Explained on Example

▶

IxDF - Interaction Design Foundation · 4:06 · 16,031 views · 3y ago · captions — Watch on YouTube

About this video

A short, focused explainer from the Interaction Design Foundation on affordances: what an object or interface element communicates about how it can be used. The video explains the concept through a worked example and connects it to designing apps that users can operate without instruction. Expect brief treatment of how perceived affordances and visual signifiers guide action.

Why this video

Affordances are one of the core interaction design principles you will be expected to apply in a prototype, and IxDF is a well-established UX education producer, so this gives a concise and reliable treatment of a single high-value concept.

6

How These Videos Support the Learning Outcomes

▶

These videos mainly support MO5: the first two establish the interaction design principles and the iterative, prototype-driven process you will follow when constructing a low-to-mid fidelity prototype for a desktop or mobile context, while the affordances video supplies a specific principle your prototype should demonstrate. They also reinforce MO2, since examples of bad design and the discussion of affordances both illustrate what happens when a system's behavior does not match the model a user forms from its appearance. The process lecture further connects to MO4 by showing where evaluation and user feedback belong in the design cycle, setting up the comparison between expert-driven methods and user testing covered elsewhere in the module.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Usability Evaluation and User Testing

1

Usability Evaluation and User Testing

▶

Usability evaluation is the disciplined practice of judging how well an interactive system supports the people who must use it to achieve real goals. It sits at the heart of human–computer interaction because design intuition, however experienced, is an unreliable predictor of behaviour: designers know their own system too well, hold a complete and accurate mental model of its structure, and have already internalised its vocabulary. Users arrive with none of that. Evaluation is the mechanism that converts assumptions about users into evidence about users. A system may be technically flawless — fast, secure, bug-free — and still fail commercially or operationally because people cannot find the function they need, misinterpret a label, or abandon a checkout flow at the final step. Usability evaluation exists precisely to surface those failures while they are still cheap to fix.

The economics of early evaluation are well established. A usability problem discovered during sketching costs little more than a new sketch. The same problem discovered after a public launch may require re-engineering, retraining of support staff, documentation rewrites, migration of user data, and reputational repair. Barry Boehm's long-standing observation that the cost of fixing a defect rises by roughly an order of magnitude at each successive stage of development applies to interaction defects as much as to code defects. Consider a hospital medication-ordering system in which the dosage units field defaults to milligrams while the clinical convention on that ward is micrograms. Caught in a paper prototype walkthrough, it is a one-line change to a mock-up. Caught after deployment, it is a patient-safety incident with regulatory consequences.

The core dimensions of usability. Usability is not a single property but a cluster of measurable attributes. The classic decomposition identifies five:

Dimension	Question it answers	Typical measure	Illustrative example
Learnability	How quickly can a first-time user accomplish basic tasks?	Time to first successful task completion; success rate on first attempt without help	A new volunteer completes their first shift sign-up on a rota app within two minutes without assistance.
Efficiency	Once learned, how fast can experienced users perform tasks?	Time on task for proficient users; keystrokes or clicks per transaction	A warehouse picker scans and confirms an item in three keystrokes rather than seven.
Memorability	After a period away, how easily is competence re-established?	Performance on return after a defined interval (e.g. four weeks)	An employee who files expenses quarterly still remembers how to attach a receipt.
Errors	How many errors occur, how severe are they, and how easily are they recovered from?	Error count per task; proportion of errors that are unrecoverable	Users select the wrong account in a transfer screen because account names are truncated.
Satisfaction	How pleasant and acceptable is the system to use?	Standardised questionnaires; preference ratings; voluntary adoption rates	Staff rate a redesigned intranet 78 on the System Usability Scale, up from 51.

These dimensions frequently trade off against one another, and recognising the trade-off is part of competent evaluation. An interface optimised for learnability — large labelled buttons, step-by-step wizards, generous confirmation dialogues — is often inefficient for experts, who would prefer keyboard shortcuts and dense command palettes. Professional tools such as photo editors or code editors deliberately sacrifice learnability for efficiency and provide training to bridge the gap; a public-facing tax self-assessment site makes the opposite choice, because most users touch it once a year and learnability and memorability dominate. Evaluation must therefore begin by asking which dimensions matter for which user population, because a test designed around the wrong dimension will produce confident but irrelevant results.

Formative versus summative evaluation. Evaluations differ not only in method but in purpose. A formative evaluation is conducted while the design is still malleable, and its goal is diagnostic: to find out what is wrong and why, so that the next version is better. Formative studies tolerate small samples, unfinished prototypes, messy qualitative data, and evaluator intervention, because their output is a prioritised list of problems rather than a statistic. A summative evaluation is conducted on a stable or completed design, and its goal is to measure: to produce a defensible quantitative statement about how the system performs, often against a benchmark, a competitor, a contractual requirement, or a previous release. Summative studies need larger samples, tightly controlled protocols, and non-interfering observers, because their output is a number that someone will act on.

Formative example: Five participants attempt to book a repeat prescription on a paper prototype. Four of them look for the "repeat" option under My Records rather than Services. The finding triggers an immediate information-architecture change; nobody computes a confidence interval.
Summative example: Thirty participants attempt the same task on the released product. 87% complete it unaided, median time 94 seconds, mean SUS score 74. These figures are reported to a commissioning body as evidence that an accessibility and usability requirement has been met.

A useful rule of thumb: formative evaluation asks "what should we change?"; summative evaluation asks "how good is it?" Most real projects need far more of the former than the latter, yet organisations frequently over-invest in summative measurement because numbers are easier to report upward than narratives about confused users.

Structured evaluation techniques: inspection without users. Inspection methods, also called discount or expert methods, have evaluators analyse an interface against explicit criteria rather than observing real users. They are indispensable when recruiting users is slow, expensive, legally constrained (clinical or military settings), or simply premature because the artefact is a set of wireframes. They are not a substitute for user testing — experts systematically over-predict some problems and miss others, particularly domain-specific misunderstandings — but they clear out the obvious defects so that scarce user sessions are spent on subtle ones.

Heuristic evaluation is the best-known inspection method. Three to five evaluators independently walk through the interface, examining each screen and dialogue against a short list of recognised usability principles, and record every violation they find along with the heuristic it breaches and a severity judgement. Independence matters: individual evaluators typically find only a minority of the problems present, but because different evaluators notice different things, the union of several evaluators' findings is far larger than any one list. Findings are merged in a debriefing session, duplicates collapsed, and severity ratings aggregated.

Nielsen's ten heuristics remain the canonical set:

Heuristic	What it requires	Example violation
Visibility of system status	Keep users informed through timely feedback	A file upload shows no progress indicator, so users click "upload" repeatedly
Match between system and the real world	Use users' language and familiar concepts	An error reads "Exception: null constraint on FK_CUST_ORD"
User control and freedom	Provide clearly marked exits, undo and redo	A multi-step form has no "back" and losing a step discards all data
Consistency and standards	Follow platform conventions and internal consistency	"Save" is top-right on one screen and bottom-left on the next
Error prevention	Design out error-prone conditions	Delete and Archive are adjacent, identically styled, with no confirmation
Recognition rather than recall	Make options visible rather than memorised	Users must remember a 12-digit reference number from a previous screen
Flexibility and efficiency of use	Offer accelerators for experienced users	No keyboard shortcuts in a data-entry tool used eight hours a day
Aesthetic and minimalist design	Avoid irrelevant or rarely needed information	A dashboard displays 40 metrics, burying the three that drive decisions
Help users recognise, diagnose and recover from errors	Plain-language messages with constructive remedies	"Invalid input" with no indication of which field or why
Help and documentation	Searchable, task-focused, concrete help	Help links to a 200-page PDF manual with no index

A well-formed heuristic finding is specific and actionable. Compare a weak finding — "the navigation is confusing" — with a strong one: "On the Order History screen, the back-arrow in the application header returns the user to the dashboard rather than the previous filter state, discarding the applied date range (violates User control and freedom; severity: major; affects every user who filters then inspects an order)."

Cognitive walkthrough takes a narrower and deeper approach, focusing specifically on learnability for users who explore rather than read instructions. Evaluators define a task, enumerate the correct sequence of actions, and then step through each action asking a fixed set of questions:

Will the user be trying to achieve the right effect at this point? (Does the goal structure make this sub-goal obvious?)
Will the user notice that the correct action is available?
Will the user associate the correct action with the effect they are trying to achieve?
After the action is performed, will the user see that progress has been made toward the goal?

Consider a university student attempting to drop a module in a student records portal. Step 3 is "click Amend Enrolment". Question 2: is the control visible? It is, but it sits in a collapsed accordion labelled Administration. Question 3: will the student associate "Amend Enrolment" with dropping a module? Plausibly not — several would look for "Withdraw" or "Remove module". The walkthrough has produced a precise, step-located failure with a clear remedy (rename the control, surface it, or add a synonym-aware search), and it has done so before a single student was recruited. The method's strength is that it localises failure to a specific decision point; its weakness is that it is slow and says nothing about efficiency, satisfaction, or expert use.

Expert reviews and guidelines-based inspections occupy the broader end of the spectrum. An expert review is a holistic critique by an experienced practitioner, drawing on domain knowledge as well as usability principles. A guidelines-based inspection is more mechanical: the evaluator works through a formal checklist derived from a design standard — a platform's human interface guidelines, an organisation's design system, WCAG accessibility success criteria, or ISO 9241 ergonomic requirements — and records compliance item by item. Checklists give coverage and auditability, which matters in regulated or procurement contexts where someone must sign a conformance statement. Their limitation is that compliance is not usability: an interface can satisfy every item on a checklist and still confound users, because checklists test properties of the artefact rather than the fit between artefact and task.

The collective virtue of inspection methods is their cost profile. A heuristic evaluation with four evaluators might consume two days of effort and no participant recruitment, scheduling, incentives, consent administration, or facility booking. This makes them feasible at points in the project — concept sketches, weekly sprint reviews, pre-release regression checks — where a full user study is simply not affordable. The corresponding risk is evaluator effect: findings vary substantially between evaluators, and inexperienced evaluators generate large numbers of false positives (problems that never trouble real users). Mitigations include using several evaluators, pairing a usability specialist with a domain specialist (the "double expert" effect), grounding the inspection in realistic task scenarios rather than free browsing, and treating inspection output as hypotheses to be confirmed in later user testing.

User testing methods: evidence from real behaviour. Inspection predicts problems; user testing observes them. The defining characteristic of user testing is that representative participants attempt representative tasks while the team watches what actually happens, rather than asking people what they think they would do. The distinction matters because self-report is unreliable: users rationalise, forget, and are reluctant to criticise. Observed behaviour is not.

Think-aloud testing asks the participant to verbalise their thoughts continuously while working: what they are looking at, what they expect, what they are trying to do, what surprises them. The resulting commentary exposes the reasoning behind behaviour, which pure observation cannot. A participant who pauses for eleven seconds on a settings screen tells you something is wrong; a participant who says "I'm looking for something about privacy, but these are all called 'Account', 'Profile', and 'Preferences' — I'd guess 'Account'?" tells you exactly what is wrong and suggests the fix.

Concurrent think-aloud captures reasoning in the moment but can slow performance and alter behaviour, making timing data unreliable; verbalising also nudges some participants into more reflective, careful problem-solving than they would normally apply.
Retrospective think-aloud has the participant narrate while reviewing a screen recording afterwards. Timing data stays clean, but recollection is reconstructive and some in-the-moment confusion is lost or rationalised.
Facilitation discipline is essential. The facilitator's prompts should be neutral and content-free: "What are you thinking?", "Keep talking", "What did you expect to happen?" Never "Did you see the button at the top?" — which hands the participant the answer and destroys the finding. When a participant asks "Am I doing this right?", the standard reply is "What do you think?" or "I'd like to see what you would do if I weren't here."

Task-based testing structures the session around a set of realistic tasks with defined success criteria, and records performance measures against each. Task design is where most studies succeed or fail. Good tasks are expressed as goals in the user's own terms, embedded in a plausible scenario, and free of interface vocabulary that would give away the solution.

Weak task:  "Use the Advanced Filter panel to filter the transaction list by date."
            (Names the control; tests button-finding, not task performance.)

Strong task: "You think you were charged twice for a hotel booking last March.
             Find out whether that happened and how much you were charged."
            (States a goal, supplies motivation, leaves the route open.)

Success criterion: participant locates both March hotel transactions and
                   states the amounts, unaided, within 5 minutes.

Typical measures captured per task include completion (binary, or graded as unaided / aided / failed), time on task, error count, number of help requests or hints given, and a post-task ease rating. Collecting a short subjective rating immediately after each task — a single seven-point "how easy or difficult was that?" item — is valuable because it anchors the judgement to a specific experience rather than a vague overall impression.

Remote user testing moves the session out of the lab and into the participant's own environment. In moderated remote testing, the facilitator joins by video conference while the participant shares their screen; the protocol is essentially the lab protocol conducted at a distance. In unmoderated remote testing, participants work through scripted tasks on their own time using a platform that records screen, cursor, audio and sometimes webcam. The advantages are substantial: a far wider geographic and demographic reach, access to participants who cannot travel (shift workers, carers, people with mobility impairments, rural users), lower cost per participant, faster turnaround, and ecological validity — the participant is using their own device, their own browser with its extensions, their own network speed, in their own noisy kitchen. That last point often surfaces problems a lab would never reveal, such as a layout that collapses at a non-standard zoom level the participant has set for comfort. The trade-offs are reduced control over the environment, inability to probe deeply or recover a derailed session (in unmoderated studies), technical failures, difficulty testing hardware-dependent or confidential systems, and weaker observation of body language and physical context.

Controlled laboratory testing sits at the opposite pole. A dedicated facility provides a standardised machine and network, a quiet room, calibrated recording of screen and face, sometimes eye-tracking, and an observation area where stakeholders can watch without intruding. Standardisation reduces variance, which matters enormously for summative comparisons: if you want to claim that version B is faster than version A, environmental noise must be controlled or the difference will drown in it. Labs also permit instrumented measurement (eye fixations, physiological measures) and rich, uninterrupted observation of hesitation, re-reading, and non-verbal frustration. The costs are expense, slow recruitment, geographic restriction of the participant pool, and the artificiality of the setting — participants in a lab are being watched, know it, and typically persevere with tasks far longer than they would at home, which can mask abandonment problems.

Method	Best suited to	Main strength	Main limitation	Typical participants
Heuristic evaluation	Early and mid design; pre-release sweeps	Fast, cheap, broad coverage of known problem types	Evaluator effect; false positives; misses domain misunderstandings	3–5 evaluators
Cognitive walkthrough	Walk-up-and-use systems; learnability of a key task	Pinpoints the exact step where exploration fails	Slow; narrow task focus; ignores efficiency and satisfaction	2–4 evaluators
Guidelines inspection	Standards compliance, accessibility audit, procurement	Auditable, repeatable, comprehensive coverage	Compliance ≠ usability; can be mechanical	1–2 evaluators
Think-aloud (lab)	Formative diagnosis of why problems occur	Exposes reasoning, expectations and mental models	Distorts timing; reactive; small samples	5–8 per user group
Task-based testing	Benchmarking and measuring performance	Comparable quantitative metrics	Task wording heavily influences results	5–8 formative, 20+ summative
Remote unmoderated	Large samples, geographic spread, quick checks	Scale, speed, real environments and devices	No probing; data quality varies; technical failures	20–100+
Controlled lab	Comparative studies; instrumented measurement	Low environmental variance; rich observation	Costly; artificial; restricted pool	8–30

Identifying and documenting usability issues. Observation produces raw material; documentation turns it into something a development team can act on. The discipline here is separating observation from interpretation from recommendation, because conflating them lets arguments about the fix contaminate agreement about the fact. A well-formed issue record contains, at minimum: a short descriptive title; the context (which task, which screen, which participant, what they had just done); the observed behaviour in neutral language; the inferred cause; the impact on the user; the frequency across participants; a severity rating; and, separately, a proposed remedy.

ID:          UI-014
Title:       Users interpret "Clear" as "clear the search box", not "clear all filters"
Task:        T3 — Find a two-bedroom flat under £900 within 2 miles
Context:     Results screen, after applying three filters
Observed:    P2, P4, P5 and P7 clicked "Clear" intending to reset only the
             keyword field; all seven applied filters were removed. P4 said,
             "Oh — no, I only wanted to change the word, not start again."
Frequency:   4 of 6 participants (67%)
Impact:      Loss of 60–90 s of filter-setting work; P5 abandoned the task
Cause:       Ambiguous label; control positioned adjacent to the search input
             rather than to the filter panel; no undo
Severity:    Major
Heuristics:  User control and freedom; Error prevention
Recommend:   Relabel to "Reset all filters", relocate to the filter panel header,
             and offer an "Undo" toast for 10 seconds after reset

Severity rating exists because teams never have the capacity to fix everything before a deadline, and triage by severity prevents the loudest stakeholder's pet complaint from displacing a genuine blocker. Severity is conventionally a composite of three factors: frequency (how many users hit it, and how often), impact (how hard it is to overcome when it occurs), and persistence (whether users learn around it or are defeated repeatedly). A fourth consideration, market or organisational impact, is sometimes added for problems that are mild for individuals but damaging in aggregate.

Rating	Definition	Action	Example
Catastrophic	Prevents task completion, causes data loss, or creates a safety or financial hazard; users cannot recover unaided	Must be fixed before release; blocks sign-off	A booking confirmation is issued but the payment reference is silently dropped, so refunds cannot be traced
Major	Causes significant difficulty, long delays or frequent errors; users eventually succeed but with frustration or workarounds	High priority; fix in the current cycle	The "Clear" control described above, which discards all filter work
Minor	Causes brief hesitation or a recoverable slip; users resolve it quickly without lasting cost	Fix when convenient; batch with related work	A date field accepts `01/06/2025` but rejects `1/6/25` with a clear message
Cosmetic	Does not impede performance; an inconsistency or aesthetic flaw that erodes polish and trust	Fix only if spare capacity exists	Inconsistent capitalisation of button labels ("Save Changes" vs "Submit form")

Two cautions apply. First, severity is a judgement, and judgements made by a single analyst are noisy; having two or three people rate independently and reconcile differences produces markedly more stable priorities. Second, severity must not be confused with fix cost. A catastrophic problem that is expensive to fix is still catastrophic; the cost belongs in a separate column so that the product owner can make an explicit trade-off rather than an implicit one disguised as a severity downgrade.

Frequency of occurrence deserves particular attention because it is the clearest signal distinguishing a systematic design defect from an individual quirk. If one participant out of eight misreads an icon, the team may reasonably wonder whether that person was tired or unrepresentative. If six out of eight misread it, the icon is wrong — the probability that six independent, representative users are all idiosyncratic in the same direction is negligible. This is the statistical intuition behind small-sample formative testing: the well-known estimate that roughly five users reveal around 80% of usability problems derives from the assumption that any given problem affects about 31% of users on average, so the chance that at least one of five participants encounters it is high. The estimate is a rule of thumb, not a law — it degrades badly when the user population is heterogeneous (novices and experts, different clinical specialties, different accessibility needs), in which case five users per distinct group is the appropriate reading. Frequency should always be reported as a raw ratio ("4 of 6") rather than a bare percentage, so that readers can see how thin the evidence actually is.

Affinity diagramming is the standard technique for synthesising findings across participants or evaluators. Each observation is written on a separate card or digital sticky note — one observation per card, phrased concretely and tagged with the participant ID. The team then clusters the cards by similarity without pre-defined categories, letting groupings emerge bottom-up, and only afterwards names each cluster with a statement of the underlying problem. The method's value is that it resists premature theorising: three observations that looked like three unrelated bugs ("P1 couldn't find pricing", "P3 scrolled past the pricing panel twice", "P6 asked whether VAT was included") may cluster into a single structural finding — pricing information is fragmented and visually de-emphasised across the purchase flow — which is a far more useful unit of work than three isolated tickets.

An issue log is the persistent, structured counterpart to the affinity wall: typically a spreadsheet or tracker in which each row is one consolidated issue with the fields listed earlier, plus a status (open, accepted, deferred, fixed, verified) and a link to the round of testing in which it was found and the round in which it was verified as resolved. The log is what makes iteration auditable — without it, teams repeatedly rediscover the same problems and have no record of whether a redesign actually worked.

Metrics and measures. Measurement serves three distinct purposes: diagnosing where a design fails, comparing alternatives, and tracking change over time. Different purposes need different instruments, and a common mistake is to collect precise numbers from five participants and then treat them as if they settled a question.

Quantitative performance metrics are the backbone of task-based testing:

Task completion rate — the proportion of attempts that reach the defined success criterion. Report unaided and aided completion separately; a task completed only after a hint from the facilitator is not a success. Completion rate is the single most informative usability metric because failure to complete is the outcome users and stakeholders both care about most.
Time on task — elapsed time from the start of the task to success or abandonment. Report the median rather than the mean, because time distributions are strongly right-skewed: one lost participant who flounders for nine minutes will drag a mean of six observations into meaninglessness. Time data from concurrent think-aloud sessions is compromised and should be flagged as such.
Error count — deviations from the optimal path that have a cost. Distinguish slips (the intention was right, the execution wrong — clicking the adjacent menu item) from mistakes (the intention itself was wrong, arising from a faulty mental model), because the remedies differ: slips are addressed by target size, spacing, confirmation and undo; mistakes by labelling, information architecture, feedback and conceptual clarity.
Help requests and hints given — each occasion on which the participant consults documentation, searches for help, or receives a facilitator prompt. The point at which a hint was needed localises the breakdown precisely.
Derived measures — lostness (actual page visits against the minimum necessary), efficiency as completion rate divided by mean time, and click or keystroke counts against an optimal path.

Qualitative data supplies the explanation that numbers cannot. Knowing that only 40% of participants completed a task tells you there is a problem; the verbatim comment "I assumed 'Submit' would save a draft, not send it to my manager" tells you what the problem is and roughly how to fix it. The useful qualitative signals include verbalisations and spontaneous exclamations; facial expression and posture (frowning, leaning in, pushing back from the desk); hesitation, repeated scanning and backtracking; workarounds improvised by the participant, which are often direct evidence of a missing feature; and emotional responses such as audible relief or irritation. Qualitative evidence should be recorded with timestamps and quoted verbatim, since a direct quotation from a user carries more persuasive force in a design review than any paraphrase, and it keeps the team honest about what was actually said.

Standardised questionnaires provide validated, comparable measures of subjective experience. Their key advantage over ad-hoc questions is that they have been tested for reliability and have published norms, so a score means something beyond the local study.

System Usability Scale (SUS) — ten alternating positive and negative statements rated 1–5, scored to yield 0–100. It is quick (about a minute), robust with small samples, and heavily normed: the mean across hundreds of published studies is roughly 68, so 68 is approximately the 50th percentile, around 80 sits near the top decile, and below about 50 is poor. The score is not a percentage and should never be reported as one. SUS measures perceived usability globally; it will not tell you which screen is at fault.
NASA-TLX — measures perceived workload across six dimensions (mental demand, physical demand, temporal demand, performance, effort and frustration), optionally weighted by pairwise comparisons. It is the appropriate instrument when the design question concerns cognitive load rather than satisfaction: air-traffic consoles, clinical monitoring, complex configuration tools. Two interfaces may both achieve 100% completion while one imposes far higher mental demand, and TLX exposes that difference.
Others in common use — the Single Ease Question (one post-task item), SEQ-style task ratings, UMUX-Lite (a very short SUS alternative), and QUIS or the Post-Study System Usability Questionnaire for more granular subscale diagnosis.

Questionnaires must be administered consistently to be comparable: same wording, same point at which they are given (immediately after the session, before any debrief discussion that might colour the rating), and no facilitator commentary in between. Mixing an altered SUS with standard SUS data invalidates the comparison against published norms.

Baselines and comparison. A single usability score in isolation is nearly uninterpretable; measurement becomes powerful when something is compared with something else. A baseline is a set of metrics captured on the current system (or a competitor, or the first prototype) under a defined protocol, which subsequent rounds are measured against. To be valid, the comparison must hold the protocol constant: identical tasks, identical wording, equivalent participant profiles, same instrument, same success criteria. Changing a task's wording between rounds and then celebrating a drop in time on task is self-deception.

Metric	Baseline (v1, n=12)	Post-redesign (v2, n=12)	Interpretation
Unaided completion, "add a dependant to policy"	58%	92%	Primary target of the redesign; substantial improvement
Median time on task	4 min 20 s	2 min 05 s	Shorter path and clearer entry point
Mean errors per participant	3.1	0.8	Field validation and clearer labels reduced slips
Help requests	9 across 12 participants	2 across 12 participants	Task now largely self-explanatory
Mean SUS	54	79	Moved from below-average to the upper range of published scores
Mean NASA-TLX (mental demand)	68/100	41/100	Workload reduced, consistent with the behavioural data

Note how the measures corroborate one another: completion, time, errors, help-seeking, satisfaction and workload all move in the same direction, which is far more convincing than any one of them alone. When measures diverge — completion rises but satisfaction falls — that divergence is itself a finding worth investigating, often indicating that the new design is effective but tedious.

Iterative testing and design refinement. Usability evaluation delivers value only when its findings re-enter the design. The iterative cycle — design → prototype → evaluate → analyse → redesign — is the operational heart of user-centred design, and it rests on a simple premise: no one gets an interface right first time, so the question is not whether the design will need revision but how cheaply and how often revision can happen.

A worked example makes the rhythm concrete. A team is designing a mobile application for reporting street faults to a local council.

Round 1 (paper prototype, 5 participants). Four of five cannot decide between the categories "Highways" and "Street Scene" — council vocabulary, not citizen vocabulary. Three expect to start by taking a photograph, but the flow begins with category selection. Two abandon at the address entry because they do not know the street number.
Redesign. Categories are relabelled in plain terms ("Pothole", "Broken streetlight", "Fly-tipping", "Something else"), the camera becomes the first step, and location defaults to GPS with a map pin the user can drag.
Round 2 (clickable prototype, 6 participants, including 2 from round 1 and 4 new). All six complete the report. The category problem is resolved. But a new issue appears: three participants drag the map pin and then tap the back arrow to check the photo, which silently resets the pin to the GPS position — a regression introduced by the new flow.
Redesign. Pin position is persisted; a thumbnail of the photo is shown inline so that going back is unnecessary.
Round 3 (functional beta, 10 participants, remote, on their own phones). Completion 100%, median time 72 seconds, mean SUS 82. One residual minor issue: the confirmation screen does not state when the fault will be inspected, and four participants ask about it aloud. A line of expected-response text is added.

Three principles are visible in that sequence. First, each round has a dual agenda: verify that previously identified issues are genuinely resolved, and scan for problems newly introduced by the fixes. Redesigns routinely create regressions, because changing a flow shifts where attention falls; a team that only re-tests old problems will ship new ones. The issue log supports this by carrying each issue's status forward until it is marked verified in a later round, not merely fixed in a commit. Second, retesting with a mixture of returning and fresh participants balances two needs: returning participants can confirm whether a specific pain point has eased, while fresh participants preserve the ability to judge learnability, since anyone who has seen the previous version is no longer a first-time user. Third, fidelity should rise with confidence — paper early, clickable in the middle, functional late — so that the cheapest artefact is used to answer the most fundamental questions.

Rapid prototyping with quick usability checks is what makes frequent iteration affordable. A paper or wireframe prototype can be produced in hours and tested the same afternoon with three or four people; a Wizard-of-Oz setup, in which a human quietly supplies responses the system cannot yet generate, allows conversational or AI-driven interactions to be evaluated before any model is integrated. Guerrilla or hallway testing — approaching five people in a café or an office corridor with a tablet and a single task — can answer a narrowly scoped question such as "do people understand this icon?" in ninety minutes. These lightweight checks are deliberately imprecise; their purpose is to catch catastrophic misconceptions early, not to produce publishable statistics. The governing trade-off is clear: many small, rough evaluations detect more problems in total than one large, rigorous evaluation conducted too late to act on.

Risk reduction is the ultimate justification for iteration. Usability failures discovered at launch are expensive in ways that extend well beyond engineering: support-call volume, training costs, abandoned transactions, workarounds that corrupt data, regulatory exposure, staff resistance to a mandated internal system, and public criticism. Iterative evaluation converts a small number of large, unpredictable, late risks into a large number of small, manageable, early ones. It also changes the character of design argument inside a team, replacing contests of opinion between senior stakeholders with shared evidence about what users actually did — which is often the most valuable organisational effect of all.

Finally, iteration must know when to stop. Diminishing returns set in when successive rounds surface only cosmetic issues, when completion rates plateau near ceiling, and when the remaining findings concern preference rather than performance. At that point further formative testing adds little, and the appropriate next step is either a summative benchmark to document the achieved level of usability or a shift to monitoring real-world use through analytics, support tickets and field studies — which is, in effect, evaluation continuing after release.

Alignment with Learning Outcomes

MO1 — Not directly addressed. This topic concerns evaluation methodology rather than memory types and capacities, although the use of NASA-TLX to measure cognitive workload and the recognition rather than recall heuristic touch indirectly on memory-related design constraints.
MO2 — Supported indirectly but meaningfully. The distinction between slips and mistakes, think-aloud evidence of user expectations, and cognitive walkthrough questions about whether users associate an action with their intended effect all expose mismatches between a user's mental model and actual system behaviour as a source of systematic error.
MO3 — Partially supported. Task-based testing and cognitive walkthrough both require a user goal to be decomposed into an enumerated sequence of correct actions and sub-goals, which draws on the same task-decomposition logic as Hierarchical Task Analysis, even though the technique itself is not taught here.
MO4 — Directly and primarily supported. The topic compares structured expert-driven inspection methods (heuristic evaluation, cognitive walkthrough, guidelines-based inspection) with user testing approaches (think-aloud, task-based, remote and laboratory testing), setting out the cost, validity and context factors that determine which method suits a given design situation.
MO5 — Supported. The sections on rapid prototyping and iterative testing explain how low- and mid-fidelity prototypes (paper, wireframe, clickable, Wizard-of-Oz) are built and evaluated across rounds in both desktop and mobile contexts, providing the evaluation rationale that shapes prototype construction.

NotesKey figures used: Nielsen's ten heuristics; the four cognitive walkthrough questions; the ~68 mean SUS benchmark; the five-user/31%-problem-probability rule of thumb (presented with its caveats about heterogeneous populations); Boehm's escalating defect-cost observation. The worked examples (hospital dosage units, prescription booking, student records portal, property filters, council fault-reporting app, insurance dependant task) are illustrative constructions, not citations of published studies. The baseline-versus-redesign metric table uses plausible but invented figures for teaching purposes and should be described as such if reused in assessment material.

2

Videos on This Topic

▶

Usability evaluation is the part of the design process where you stop guessing and start checking. Instead of assuming an interface works, you apply structured methods — expert inspections, heuristic reviews, and tests with real users — to find out where people hesitate, make errors, or give up. The goal is not to prove a design is good, but to surface problems early enough and cheaply enough that you can fix them.

In this course, this topic ties together everything that comes before it. You have studied memory limits, mental models, and task structure; evaluation is how you verify that your design actually respects those constraints. You will also see two broad families of methods: expert-driven inspection (such as heuristic evaluation), which is fast and cheap but filtered through a reviewer's judgment, and user testing, which is slower but reveals behavior you could not have predicted. Knowing when to use each is a core professional skill.

As you watch, pay attention to three things: how usability is defined and broken into measurable components, how evaluators move from scattered observations to a consolidated, documented list of issues, and how qualitative findings get paired with quantitative metrics. Also notice that evaluation is described as something you repeat — each round feeds a design revision, which then gets tested again.

3

Video 1: Usability 101

▶

NNgroup · 3:46 · 24,243 views · 3y ago · captions — Watch on YouTube

About this video

A short foundational explainer from Nielsen Norman Group that defines usability and breaks it into five quality components: learnability, efficiency, memorability, errors, and satisfaction. It frames usability as a property of the interface that can be assessed rather than a vague judgment of quality, and likely distinguishes usability from related ideas such as utility and overall user experience.

Why this video

This is the natural starting point for the topic, giving you the vocabulary and the component framework that every later evaluation method measures against; NN/g is the field's most widely cited practitioner source.

4

Video 2: How to Conduct a Heuristic Evaluation

▶

NNgroup · 4:50 · 45,581 views · 2y ago · captions — Watch on YouTube

About this video

A step-by-step walkthrough of how to run a heuristic evaluation, the best-known structured expert inspection method. Based on its chapter markers, it covers having evaluators review the interface independently, works through an example of applying heuristics to a real interface, and then shows how multiple evaluators' findings are consolidated into a single issue list before summarizing the process.

Why this video

It directly addresses the structured evaluation and issue-documentation subtopics, and the consolidation step shows concretely how expert-driven methods differ in workflow and output from user testing.

5

Video 3: The System Usability Scale (SUS)

▶

NNgroup · 6:34 · 24,776 views · 3y ago · captions — Watch on YouTube

About this video

An introduction to the System Usability Scale, a standardized ten-question survey given to participants at the end of a user test. The video explains what the instrument measures — perceived usability — and, based on its framing, how to administer it and interpret the resulting score in context rather than as an absolute verdict.

Why this video

It covers the metrics and measures subtopic with a specific, widely used instrument, and demonstrates how a quantitative score can complement the qualitative issues you observe during user testing.

6

How These Videos Support the Learning Outcomes

▶

These three videos support MO4 most directly: together they let you compare a structured, expert-driven method (heuristic evaluation) with user-testing approaches and their associated measures (SUS), so you can reason about which fits a given design context, budget, and stage of development. The usability components video supplies the criteria — learnability, efficiency, memorability, errors, satisfaction — that connect evaluation back to the cognitive constraints and mental-model mismatches studied earlier in the module (MO1, MO2), since errors and learnability problems are often symptoms of those mismatches. The consolidation and scoring practices shown here also feed forward into prototyping work (MO5), where findings from one round of evaluation become the justification for the next revision of your low- to mid-fidelity prototype.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Human Factors, Ergonomics, and Automation

1

Human Factors, Ergonomics, and Automation

▶

Introduction to Human Factors

Human factors — known in much of Europe as ergonomics and in North America often as human factors engineering — is the scientific discipline concerned with understanding the interactions between people and the other elements of a system, and the profession that applies theory, data, and methods to design systems that optimise both human well-being and overall system performance. Its central premise is deceptively simple: human beings have measurable, fairly stable capabilities and limitations, and systems have demands. Where those two things are mismatched, performance suffers, errors accumulate, and people are harmed. Human factors is the systematic identification and correction of those mismatches.

Crucially, the discipline rejects the idea that the correct response to a mismatch is to "train the human harder" or to "tell people to be more careful." If a drug infusion pump requires a nurse to key in a decimal point correctly at 3 a.m. after a twelve-hour shift, and a misplaced decimal delivers a tenfold overdose, the problem is not nurse carelessness — it is a system that places an unreasonable demand on a known human vulnerability. The human factors response is to change the demand: constrain the input field, require confirmation for out-of-range doses, display the computed dose in words as well as numerals, or remove the free-text entry altogether in favour of a drug library.

The discipline is deliberately broad in application. The same body of knowledge — about reaction times, visual acuity, working memory limits, attention, reach envelopes, and decision-making under uncertainty — is applied across domains that look superficially unrelated:

Aviation: cockpit layout, checklist design, crew resource management, air traffic control displays, and the investigation of accidents in which flight-deck automation behaved in ways the crew did not expect.
Healthcare: medication labelling and packaging, operating theatre layout, electronic health record interfaces, patient monitor alarms, and handover protocols between shifts.
Manufacturing and process industries: assembly line workstation heights, manual handling limits, control room design for refineries and nuclear plants, and lockout/tagout procedures.
Computing and consumer products: keyboard and input device design, screen layout, mobile interaction, accessibility, and the design of software that must be learnable by people who have never been trained on it.
Transport and road design: sign legibility distances, dashboard and infotainment design, and the handover problem in partially automated vehicles.

Three goals recur across all of these domains. The first is efficiency and performance: reducing the time, effort, and resources needed to accomplish work. The second is error reduction and safety: minimising both the frequency of errors and, just as importantly, their consequences when they do occur. The third is human well-being: comfort, satisfaction, job quality, reduced stress, and the avoidance of injury. These goals usually reinforce one another — a workstation that causes less fatigue also produces fewer defects — but they can conflict, and part of the human factors practitioner's job is to make those trade-offs explicit. A warehouse picking system that maximises items-per-hour by pacing workers to the limit of their physical capacity is efficient in the short term and corrosive in the long term.

Human factors findings feed into two distinct channels. The first is product and system design: the physical and digital artefacts people use. The second, often underappreciated, is organisational policy: shift scheduling and fatigue management, staffing levels, training regimes, procedure design, incident reporting culture, and regulatory standards. An airline can buy the best-designed cockpit in the world, but if its rostering policy produces chronically sleep-deprived crews, the human factors problem has merely moved upstream. Similarly, a "blame-free" incident reporting system is a human factors intervention: it changes the information available to designers by making near-misses visible rather than hidden.

Ergonomics: Physical and Cognitive Dimensions

It is conventional to divide ergonomics into three domains: physical, cognitive, and organisational (sometimes called macroergonomics). The first two are the focus here.

Physical ergonomics deals with the body: anatomy, anthropometry, biomechanics, and physiology as they relate to physical activity. Its core concerns include posture, repetitive motion, force exertion, vibration exposure, reach and clearance, and the design of workspaces and tools. The dominant health outcome it seeks to prevent is the work-related musculoskeletal disorder (WMSD) — a family of conditions including carpal tunnel syndrome, tendinitis, rotator cuff injuries, epicondylitis, and chronic low back pain. These rarely arise from a single traumatic event; they accumulate from sustained exposure to risk factors.

The principal physical risk factors are well established and worth knowing by name:

Awkward posture — joints held away from their neutral mid-range, such as a wrist extended 30° to type on a raised keyboard, or a neck flexed forward to read a laptop screen on a desk.
Static loading — holding any posture without movement, which restricts blood flow to muscles and causes fatigue far faster than dynamic work. Standing still is more fatiguing than walking.
High force — gripping, pushing, pulling, or lifting near the limits of capacity, especially with a pinch grip rather than a power grip.
Repetition — high-frequency cycles that do not allow tissue recovery.
Contact stress — hard edges pressing into soft tissue, such as a desk edge against the forearm.
Vibration — hand–arm vibration from power tools, whole-body vibration from vehicles.

Physical ergonomics is quantitative. Anthropometry — the measurement of body dimensions across populations — supplies percentile data that drives design decisions. A general heuristic set is: design clearances (doorway heights, legroom under a desk, aisle widths) for the large user, typically the 95th percentile male; design reaches (control placement, shelf height, emergency stop button) for the small user, typically the 5th percentile female; and design adjustable ranges to accommodate from the 5th to the 95th percentile where adjustment is feasible, as with office chairs and monitor arms. Designing everything for the "average" person is the classic error: almost nobody is average on more than two or three dimensions simultaneously, a lesson the US Air Force learned expensively in the 1950s when it discovered that out of 4,063 pilots, not one fell within the average range on all ten critical cockpit dimensions.

A worked example: a software developer's workstation. Neutral posture requires the top of the monitor roughly at or just below eye height so the head is not tilted; the monitor about an arm's length away to reduce accommodative strain; elbows at roughly 90–100° with forearms approximately parallel to the floor; wrists straight rather than extended, which usually means a negative keyboard tilt rather than the positive tilt that the little flip-out feet on most keyboards create; feet flat on the floor or a footrest; and lumbar support maintaining the natural inward curve of the lower back. Note that even a perfect static posture is insufficient — the strongest single recommendation in modern office ergonomics is postural variation and regular movement, because the "best" posture is always the next one.

Cognitive ergonomics addresses mental processes — perception, attention, memory, reasoning, motor response, and decision making — as they affect interaction with systems. Where physical ergonomics asks "can the body do this without harm?", cognitive ergonomics asks "can the mind do this reliably, and at what cost?" Its subject matter includes mental workload, decision making, skilled performance, human–computer interaction, training, stress, and human reliability.

A few human cognitive constraints recur constantly in design work. Working memory is sharply limited — Miller's classic "seven plus or minus two" is now generally regarded as optimistic, with four chunks a more realistic figure for unrehearsed material — and its contents decay within seconds if attention is diverted. This is why asking a user to read a confirmation code from one screen, navigate away, and retype it elsewhere is poor design, and why wizard-style flows that carry forward previously entered values outperform those that do not. Attention is a limited and largely serial resource for controlled processing: genuine multitasking on two attention-demanding tasks is essentially task-switching with a cost at each switch. Long-term memory is vast but retrieval is unreliable and cue-dependent, which argues for recognition over recall — showing users the available options rather than requiring them to remember command names.

The consequences of poor design on either dimension are cumulative and interact. Physical discomfort consumes attentional resources; cognitive fatigue degrades postural discipline and motor precision. A control room operator sitting in a badly adjusted chair under glare-producing lighting will tire faster, scan displays less thoroughly, and miss more signals. Documented consequences of poor ergonomic design include acute and chronic fatigue, musculoskeletal injury and associated absenteeism, eye strain and headaches, elevated error and defect rates, slowed task completion, reduced job satisfaction, and staff turnover.

An ergonomic assessment is the structured comparison of task demands against human capacities. The general method is to characterise the task (observation, video analysis, interviews, task analysis), quantify the demands (postures held and for how long, forces exerted, repetition rate, information processing requirements, time pressure), compare those demands against published capacity data or exposure limits, and then redesign to close the gap. Standard instruments make this tractable:

Instrument	Dimension	What it measures	Typical use
RULA / REBA	Physical	Posture scores for upper limb (RULA) or whole body (REBA), plus force and repetition modifiers	Rapid screening of a workstation or manual task for injury risk
NIOSH Lifting Equation	Physical	Recommended weight limit for a two-handed lift, adjusted for distance, twist, frequency, and grip	Evaluating manual handling in warehousing and logistics
Strain Index	Physical	Composite risk score for distal upper extremity from intensity, duration, and posture of exertion	Repetitive assembly or packing tasks
NASA-TLX	Cognitive	Subjective workload across mental, physical, temporal demand, performance, effort, frustration	Comparing workload between two interface designs or automation levels
SWAT / Modified Cooper-Harper	Cognitive	Subjective workload ratings, the latter via a decision-tree of handling-quality questions	Aviation and vehicle control evaluations
Secondary-task / dual-task methods	Cognitive	Spare mental capacity, inferred from performance on a concurrent low-priority task	Objective workload measurement in simulation
Eye tracking / pupillometry	Cognitive	Fixation patterns, dwell time, scan path, pupil dilation as an effort index	Display layout evaluation, attention allocation studies

Display Design Principles

A display is any means by which a system presents information to a human — a screen, a dial, a warning lamp, a printed label, an audible tone, a haptic buzz. Display design is where cognitive ergonomics becomes most concretely actionable, because the designer controls exactly what information reaches the operator, in what form, and when.

The first principle concerns level of detail and timing. Information should be presented at the granularity the task actually requires, at the moment it becomes relevant, and no earlier. Presenting everything all the time appears neutral but is not: it imposes a search cost on every single act of reading, and it buries the critical item among the trivial. Two complementary techniques address this. Progressive disclosure hides detail behind an explicit request — a summary row that expands, a "advanced settings" panel, a drill-down from a plant overview to a specific unit. Context-sensitive display changes what is shown according to the current phase of the task: an aircraft primary flight display emphasises different parameters during approach than during cruise; a surgical system shows different information pre-incision than during closing. The counter-consideration is that hiding information can destroy the operator's overall picture, so the rule is to keep status-at-a-glance information permanently visible and hide only detail that is needed episodically.

The second principle concerns visual hierarchy, contrast, and layout. The eye does not read a screen uniformly; it is drawn by salience. The designer's job is to arrange salience so that it matches importance. The available tools are size, weight, colour, contrast, position, whitespace, and motion — and they are a budget, not a free resource: if everything is bold, nothing is. Useful structuring rules include:

Frequency of use, importance, and sequence of use as layout drivers: the most frequently consulted and most critical items occupy the prime visual real estate (centre and upper-left in left-to-right reading cultures), and items used in sequence are placed in that sequence.
Functional grouping: items that belong to the same subsystem or decision are placed together and bounded by whitespace or a subtle border, exploiting the Gestalt principles of proximity, similarity, and common region.
Consistency of location: the same parameter appears in the same place on every screen, so the operator builds a motor and spatial habit rather than searching each time.
Redundancy coding: critical states signalled by at least two channels — colour and shape, or colour and text — so the display survives colour vision deficiency (affecting roughly 8% of men), poor lighting, and monochrome printing.
Adequate luminance contrast: WCAG's 4.5:1 ratio for normal text and 3:1 for large text is the common benchmark in digital interfaces; control room standards typically demand more because of ambient light variation.

The third principle is compatibility with the user's mental model, sometimes called the principle of the moving part or, more broadly, stimulus–response and display–control compatibility. Users build an internal representation of how the system works and how its representation maps to reality; a display that violates that representation forces an effortful mental translation at every reading, and under stress the translation fails. Classic forms of compatibility include:

Spatial compatibility: the display element representing a physical object is positioned analogously to that object. The four burner knobs on a hob should be arranged in the same square pattern as the burners, not in a straight line — a design error that has caused untold numbers of scorched pans.
Movement compatibility: an increasing quantity should move the indicator up or clockwise; a control turned clockwise should increase the value. The aviation "moving part" debate — should the aircraft symbol move against a fixed horizon, or the horizon move against a fixed aircraft? — is a compatibility question, and the resolution (inside-out, horizon moves) matches the pilot's out-the-window view.
Conceptual/semantic compatibility: red means danger or stop in most Western populations, green means safe or go; a rising tone means increasing. Note these are culturally learned, not universal — red signifies prosperity in parts of East Asia, and in some process industries red historically indicated an energised valve rather than a dangerous one, a legacy mapping that has caused confusion.
Proximity compatibility principle: information that must be mentally integrated to make a judgement should be displayed close together or in an integrated form (e.g., a single polygon whose shape deforms when parameters go out of tolerance), while information that must be read independently should be kept separate.

The fourth principle concerns alarms and alerts, which is where display design most often fails catastrophically. An alarm system faces an unavoidable signal-detection trade-off. Setting thresholds sensitively catches more genuine events but produces more false alarms; setting them conservatively reduces false alarms but risks misses. The pathological outcome of over-sensitivity is alert fatigue: operators who are flooded with alarms learn, entirely rationally, that most alarms are irrelevant, and begin to ignore, silence, or disable them. In hospital settings, studies have repeatedly found that 80–99% of physiological monitor alarms are clinically insignificant, and patient deaths have been directly attributed to alarms that were muted or unheard against the background noise. The 1979 Three Mile Island accident presented operators with over a hundred near-simultaneous alarms with no prioritisation, and the 2005 Texas City refinery explosion involved, among many factors, a level alarm that did not function and displays that did not reveal the true state of the splitter tower.

Sound alarm design therefore includes: prioritising alarms into a small number of urgency tiers with distinguishable auditory and visual signatures; suppressing consequential alarms that merely follow from a parent alarm (alarm flood reduction); setting thresholds from operational data rather than vendor defaults; ensuring every alarm is actionable, with a defined operator response — if there is nothing to do about it, it is not an alarm but a log entry; providing clear indication of the alarm's source and the required action rather than a bare code; and monitoring alarm rates as a managed performance metric. The EEMUA 191 guideline, widely used in process industries, suggests a steady-state target of around one alarm per operator per ten minutes, with anything above about ten per ten minutes considered unmanageable.

Automation in Work Systems

Automation is the execution by machine of a function previously carried out by a human. It is not binary; it is better understood as a continuum, and it can be applied selectively to different stages of information processing. Parasuraman, Sheridan, and Wickens proposed an influential framework distinguishing four stages that can each be automated to a different degree: information acquisition (sensing and filtering), information analysis (integration and prediction), decision selection (choosing an action), and action implementation (carrying it out). A medical decision support tool might automate acquisition and analysis heavily while leaving decision and action entirely to the clinician; an anti-lock braking system automates implementation only.

Sheridan and Verplank's ten levels of automation remain a useful reference for thinking about how much authority to transfer:

Level	Description	Example
1	Human does everything; computer offers no assistance	Manual flight with raw instruments
2	Computer offers a complete set of alternatives	Route planner listing all possible paths
3	Computer narrows the selection to a few	Diagnostic tool shortlisting likely conditions
4	Computer suggests one alternative	Satnav recommending a single route
5	Computer executes the suggestion if the human approves	Autopilot engaging a programmed descent on crew confirmation
6	Computer allows the human a restricted veto time before execution	Automatic email send with a 10-second undo window
7	Computer executes automatically, then informs the human	Automatic failover to a backup server with notification
8	Computer informs the human only if asked	Background garbage collection, visible only in logs
9	Computer informs the human only if it decides to	Adaptive fraud-detection system escalating selected cases
10	Computer acts entirely autonomously, ignoring the human	Airbag deployment; reactor SCRAM on hard trip conditions

The benefits of automation are real: consistency (a machine performs the thousandth repetition exactly as it performed the first), throughput and speed, precision, tolerance of conditions hostile or tedious to humans, and the relief of workload during routine phases. But automation does not simply remove human work — it transforms it. Lisanne Bainbridge's 1983 paper "Ironies of Automation" set out the central paradox: the designer who automates because humans are unreliable leaves to the human exactly those tasks that could not be automated, which are typically the hardest ones, and then expects the human to monitor the automation and take over when it fails — precisely the situations in which the automation has already proved inadequate.

Specific consequences follow from the shift to a supervisory role:

Vigilance decrement. Humans are poor at sustained monitoring for rare events. Classic vigilance research (originating in WWII radar watch studies) shows detection performance falling measurably within 20–35 minutes of a monitoring watch, and the effect is worse when the event rate is low and the signal is weak — exactly the conditions created by reliable automation.
Complacency and automation bias. When automation is highly but not perfectly reliable, operators calibrate their trust to its usual behaviour and stop cross-checking. Automation bias has two faces: errors of omission, where the operator fails to notice a problem because the automation did not flag it, and errors of commission, where the operator actively follows an incorrect automated recommendation against contrary evidence. Studies of clinical decision support have shown practitioners reversing correct diagnoses after seeing an erroneous automated suggestion.
Skill degradation. Manual and cognitive skills decay without practice. Airlines have documented erosion of hand-flying and raw-data instrument skills in crews who fly highly automated aircraft, prompting regulators to mandate periodic manual flying. The same effect appears in radiologists who rely on computer-aided detection and in developers who lose fluency in a language their IDE autocompletes for them.
Clumsy automation. Automation often reduces workload during already-low-workload phases (cruise) and increases it during already-high-workload phases (a late runway change requiring reprogramming of the flight management system under time pressure). The workload profile becomes more peaked, not flatter.
Loss of situational awareness. An operator who is out of the control loop is not building the continuous picture that active control generates; when the automation hands back control, the operator must reconstruct that picture from scratch, often in a degraded situation.

The function allocation question — what to automate and what to leave to humans — was once answered with Fitts's 1951 "MABA-MABA" list (Men Are Better At / Machines Are Better At): humans excel at pattern recognition in noise, improvisation, inductive reasoning, and judgement under novelty; machines excel at speed, force, precision, repetitive execution, simultaneous multi-channel monitoring, and computation. The list remains a useful first-order heuristic, but modern practice treats it as insufficient, because it assumes tasks can be cleanly divided and ignores the coordination costs of the resulting human–machine team. Contemporary guidance frames the goal as designing for human–automation teamwork: the automation should be observable (its state and reasoning inspectable), directable (the human can adjust its behaviour without switching it off entirely), and predictable. Related approaches include adaptive automation, in which the level of automation changes dynamically in response to measured operator workload or task phase, and adaptable automation, in which the operator chooses the level — the latter generally preserving a better sense of control and awareness.

A concrete contrast: consider two approaches to automating a radiology workflow. In the first, the algorithm scans images and silently removes those it classifies as normal from the reporting queue. Throughput rises, but a false negative is now invisible, the radiologist's exposure to borderline cases falls, and skill at detecting subtle findings atrophies. In the second, the algorithm annotates regions of interest, states a confidence level, and presents all images in an order prioritised by suspicion, with the radiologist reading every case. Throughput rises less, but the human remains in the loop, the automation's reasoning is visible, and disagreements become a learning signal for both parties. The second design is slower and better.

Human Error and Automation Interaction

Automation does not eliminate human error; it relocates it. Errors of execution on the shop floor are traded for errors of configuration, monitoring, and understanding at the supervisory level. Two error types are so characteristic of automated systems that they have their own names.

A mode error occurs when an operator performs an action that would be correct in one system mode while the system is actually in a different mode. Mode errors require two conditions: the system must have multiple modes in which the same input produces different effects, and the current mode must be insufficiently salient. Everyday examples abound — typing a long password while Caps Lock is on; pressing a key in a text editor's "normal" mode expecting insertion; a camera set to manual exposure when the photographer believes it is on aperture priority. In safety-critical settings the consequences escalate. The most-cited case is the 1992 Air Inter Flight 148 crash near Strasbourg, where the crew appear to have intended a 3.3° descent angle but the flight control unit was in vertical speed mode, interpreting the entered "33" as 3,300 feet per minute. The display differed by only a small visual detail between the two modes. The aircraft descended roughly five times faster than intended into terrain. The design lesson is not "crews should check the mode" — they are always told that — but that two radically different interpretations of the same numeric entry should never be distinguished by a nearly identical display.

Mitigations for mode error are well understood: minimise the number of modes; make the active mode highly salient and encoded redundantly (position, colour, shape, text, and where appropriate a distinct sound or haptic signature); make modes spring-loaded where possible, so the system reverts to a default when the user stops acting (holding a key rather than toggling it); give different modes genuinely different input semantics or different controls rather than overloading one control; and provide immediate, interpretable feedback of what the entered value will actually do ("descend at 3,300 ft/min — arriving at 2,000 ft in 1 min 40 s").

An automation surprise occurs when the system does something the operator did not expect, did not command, and cannot immediately explain. The canonical operator questions — identified by Wiener as the "clumsy automation" trio — are "What is it doing?", "Why is it doing that?", and "What will it do next?" Automation surprises typically arise from indirect mode transitions: the automation changes its own mode in response to an envelope limit, a sensor value, or the expiry of a condition, without a direct operator command and often without conspicuous annunciation. Examples include an autopilot reverting from an altitude capture mode to a basic pitch mode when a constraint is removed; a cruise control that silently disengages on a tight bend; a smart thermostat that enters an "away" schedule because its occupancy sensor saw no movement; and a continuous deployment pipeline that auto-rolls-back a release while an engineer is mid-investigation. The surprise is damaging not merely because of the action itself but because it shatters the operator's model of the system, and rebuilding that model consumes exactly the time and attention that the unfolding situation demands.

Effective automation therefore has an obligation of communication. Good practice includes annunciating every mode transition, especially uncommanded ones, with a signal proportionate to its significance; displaying not only the current state but the automation's intent — the next waypoint, the target value, the time until the next transition, the condition it is waiting on; exposing the inputs on which the automation is acting, so the operator can detect a bad sensor or a stale value; and indicating confidence or data quality rather than presenting all outputs with equal apparent authority. A well-designed flight management display, for example, shows the commanded path, the predicted trajectory, and the point at which the next mode change will occur, so the crew can anticipate rather than react.

Error-tolerant design accepts that errors will occur and works to make them detectable, reversible, and survivable. Its repertoire includes:

Constraints and forcing functions that make the error physically or logically impossible — an interlock preventing a microwave running with the door open, a gas connector that only fits the correct cylinder, a form that will not accept a date in the past.
Confirmation proportionate to consequence, reserved for genuinely irreversible and high-impact actions. Over-used confirmations are themselves a hazard: users click through them automatically, so the dialogue provides the illusion of a safeguard while adding keystrokes. Requiring the user to type a resource name before deleting it works because it cannot be dismissed reflexively.
Undo, reversibility, and generous recovery windows — far preferable to confirmation, because they place the cost on the rare error rather than on every correct action.
Graceful degradation and defined fallback modes, so that when automation fails it hands back control in an orderly and announced way, with adequate lead time, rather than dropping out abruptly.
Monitoring and envelope protection that constrain the consequences of an incorrect input without silently overriding the operator's intent unannounced.
Error messages that diagnose and offer a route forward, naming what was wrong, where, and what to do — not merely that something failed.

Underlying all of this is a model of error that distinguishes slips and lapses (the intention was correct, the execution or memory failed — typing the wrong digit, forgetting a step) from mistakes (the execution was faithful but the intention was wrong, because the situation was misdiagnosed or the rule applied was inappropriate). Mode errors sit awkwardly across this boundary and are often better described as a third category, knowledge-based failures induced by the interface itself. Design responses differ: slips are addressed by constraints, feedback, and reducing memory load; mistakes are addressed by better displays, training, and decision support that surfaces disconfirming evidence.

Situational Awareness and Mental Workload

Situational awareness (SA) is, in Mica Endsley's widely used definition, "the perception of the elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future." The definition decomposes into three hierarchical levels, and the distinction matters because failures at each level have different causes and different remedies.

Level	Name	Question answered	Typical failure	Design remedy
1	Perception	What is happening? What are the raw values and events?	Data not displayed, not salient, obscured by clutter, or missed due to attentional narrowing	Salience matched to importance, decluttering, redundant coding, effective alerting
2	Comprehension	What does it mean for my goals right now?	Elements perceived individually but not integrated; operator cannot assemble the picture under time pressure	Integrated and configural displays, computed summary indices, trend and deviation-from-target presentation
3	Projection	What will happen next, and how much time do I have?	No ability to anticipate; operator is permanently reacting rather than planning	Predictor symbols, time-to-limit countdowns, trajectory previews, "what-if" simulation

A concrete illustration from process control: Level 1 is reading that tank level is 78% and rising. Level 2 is understanding that 78% with the outlet valve closed and the feed pump running means the tank is filling toward an overflow condition rather than simply holding a healthy inventory. Level 3 is knowing that at the current fill rate the high-high trip will be reached in four minutes, which is enough time to open the outlet but not enough to call for instructions. A display that shows only the number supports Level 1; a display that shows the number, a rate-of-change arrow, the valve states, and a predicted time-to-limit supports all three. Endsley's own data from aviation suggest the large majority of SA errors occur at Level 1 — the information was available but not perceived — which is a sobering comment on display design.

Mental workload is the relationship between the cognitive resources a task demands and the resources the operator has available. It is best thought of as a supply-and-demand ratio rather than an absolute quantity, which is why the same task is low-workload for an expert and overwhelming for a novice. The relationship between workload and performance is an inverted U: performance is poor at very low workload (underload produces boredom, mind-wandering, and the vigilance decrement) and poor at very high workload (overload produces shed tasks, attentional tunnelling, and truncated decision making), with a broad plateau of acceptable performance in between. The practical design target is therefore not "minimise workload" but "keep workload within a moderate band and avoid sharp peaks."

Overload degrades SA through several well-documented mechanisms. Attentional narrowing (or tunnelling) causes the operator to fixate on one channel and stop scanning others — the Eastern Air Lines 401 crash in 1972, in which an entire crew became absorbed in a burnt-out landing gear indicator bulb while the autopilot quietly let the aircraft descend into the Everglades, is the archetype. Task shedding drops lower-priority activities, which frequently include the cross-checks and communications that would have caught the problem. Working memory overflow causes steps to be forgotten, especially after interruption — a major source of error in nursing and in software operations. And stress hormones narrow the range of options considered, promoting the first plausible answer over the best one.

Automation's effect on workload is genuinely bidirectional and depends on design quality. It reduces workload when it removes routine, well-bounded, high-repetition tasks whose outputs are easy to verify — an autopilot holding altitude during cruise, a build system running regression tests. It increases workload when it adds a new system that must itself be monitored, configured, and understood; when its interface demands long data-entry sequences at busy moments; when its failure modes are obscure; or when the operator must continually decide whether to trust it. The net effect is also qualitative: automation typically exchanges physical and perceptual-motor workload for cognitive workload of monitoring and interpretation, which is less visible to managers and less amenable to simple measurement.

Interface design practices that support SA follow directly from the three-level model. Present information in the form in which the operator's goals require it rather than in the form the sensors produce it — if the decision depends on the margin to a limit, display the margin, not the raw value and the limit separately. Integrate related parameters into configural displays whose overall shape conveys normality at a glance. Provide trends and history, since a value's direction is often more informative than its magnitude. Expose projections and time-to-event where the decision is time-critical. Make system mode and automation intent explicit, as discussed above. Support goal-directed task switching by preserving and restoring context when the operator returns from an interruption. And design shared displays so that team members hold compatible pictures, since in multi-operator settings SA is a distributed property, not an individual one — this is the rationale for the shared "big board" in control rooms and for callouts and read-backs in crew procedures.

Applying Human Factors in Interface and System Design

Human factors delivers value only if it is embedded in the development process rather than consulted as a late review. The organising framework is user-centred design (UCD), formalised in ISO 9241-210, which rests on four commitments: design is based on an explicit understanding of users, tasks, and environments; users are involved throughout design and development; design is driven and refined by user-centred evaluation; and the process is iterative, with the design team addressing the whole user experience and spanning multiple disciplines. The ISO process describes a cycle — understand and specify the context of use, specify user requirements, produce design solutions, evaluate against requirements — repeated until the requirements are met.

The economic argument for early involvement is strong. Human factors defects discovered after deployment are expensive to fix because they are entangled with architecture, training material, procedures, and regulatory approvals; the same defect found in a paper sketch costs minutes. Retrofitting ergonomics onto a finished control room means moving walls. In regulated domains the argument is stronger still: medical device regulators now require a documented usability engineering process (IEC 62366-1) with use-related hazard analysis and validation testing, and failure to produce it can block market approval regardless of how well the device performs technically.

Task analysis is the backbone activity that converts an understanding of users into design-relevant structure. Its aim is to describe what people actually do — goals, subtasks, sequences, decision points, information needed, tools used, and the physical and cognitive demands at each step. Several complementary forms exist:

Hierarchical Task Analysis (HTA) decomposes a top-level goal into subgoals and operations, and specifies plans stating the conditions under which subtasks are executed and in what order. It produces a structure that maps readily onto screens, menus, and workflow steps, and it exposes where a user must hold information in memory across steps.
Cognitive Task Analysis (CTA), including techniques such as the Critical Decision Method, targets the knowledge, cues, and judgements of experts — the things that are invisible in a behavioural description. It is the method of choice when the interesting part of the work is diagnosis rather than execution.
GOMS and keystroke-level modelling provide quantitative predictions of expert task time from goals, operators, methods, and selection rules — useful for comparing two interaction designs for a high-frequency task before building either.
Link analysis and operational sequence diagrams map movement, gaze, and communication between elements of a workspace, informing physical layout so that frequently linked items are placed close together.
Human Reliability Analysis methods (e.g., HEART, SPAR-H) and Hierarchical Task Analysis-based error prediction (e.g., SHERPA) systematically enumerate credible errors at each task step and their consequences, feeding safety cases and mitigation design.

A short worked fragment shows the flavour of an HTA for an infusion setup:

0. Administer prescribed IV infusion
   Plan 0: do 1 - 2 - 3 - 4 in order; if alarm occurs at any point, do 5 then resume.
   1. Verify prescription and patient identity
      1.1 Read prescription
      1.2 Check patient wristband against prescription
      1.3 Confirm drug, dose, route, time, and allergy status
   2. Prepare pump and line
      2.1 Select drug from pump drug library
      2.2 Load giving set
      2.3 Prime line
   3. Program infusion
      3.1 Enter dose
      3.2 Enter rate or duration
      3.3 Review computed values on confirmation screen
   4. Start infusion and verify flow
   5. Diagnose and respond to alarm

Reading this structure as a designer immediately raises questions: step 3.1 and 3.2 are where decimal-point and unit errors occur, so the interface should constrain entry to a library-defined range and show the computed delivery in a second form; step 3.3 is a verification step that will be skipped under time pressure unless it is made cheap and informative; step 5 interrupts the sequence, so the interface must preserve and restore the state of the interrupted step rather than returning the nurse to a start screen.

Evaluation closes the loop. A layered strategy is normal practice, moving from cheap and early to expensive and realistic:

Method	When used	What it reveals	Limitations
Heuristic evaluation / expert review	Early and continuously; works on sketches	Violations of established principles, consistency problems, missing feedback	Finds issues real users may never hit; depends on evaluator expertise; misses domain-specific errors
Cognitive walkthrough	Early, for learnability of a defined task	Points where a first-time user cannot work out what to do next	Narrow focus on learnability; slow for large interfaces
Usability testing with representative users	Mid to late, on prototypes or builds	Actual errors, misunderstandings, workarounds, task times, satisfaction	Laboratory conditions; participant recruitment cost; may not surface rare events
Simulation and scenario exercises	Late, for safety-critical systems	Performance under realistic workload, degraded modes, team coordination, automation handover	Expensive; requires fidelity in both the simulator and the scenario
Field study / in-situ observation	Before design and after deployment	Real context, interruptions, environmental constraints, informal workarounds	Hard to control; Hawthorne effects; time-consuming
Physical ergonomic assessment (RULA/REBA, anthropometric fit)	Whenever a physical workstation exists	Posture and loading risks, reach and clearance failures	Does not address cognitive demands

Simulation deserves particular emphasis in automated systems, because the failures that matter most — mode confusion, automation surprise, degraded handover — only appear when the automation is pushed into unusual states. A full-mission flight simulator session in which the autothrottle fails silently, or a hospital simulation suite in which a monitor alarms during a difficult intubation, surfaces issues that no amount of screen-by-screen review would find. These sessions also validate procedures and training, which are part of the system design whether or not anyone designed them deliberately.

Finally, standards provide codified benchmarks that shortcut argument and establish defensible baselines. They encode decades of accumulated data about what human beings can tolerate and perceive, and they are frequently contractual or regulatory requirements rather than advice. A selection of the most relevant:

Standard	Scope	Representative content
ISO 9241 series	Ergonomics of human–system interaction	Part 11 defines usability as effectiveness, efficiency and satisfaction in a specified context of use; Part 110 gives dialogue principles (suitability for the task, self-descriptiveness, conformity with user expectations, error tolerance, controllability, suitability for learning and individualisation); Part 210 defines the human-centred design process; Part 5 covers workstation layout and postural requirements; Part 303 and related parts cover electronic visual display requirements such as luminance, contrast and character size.
ISO 11228 series and ISO/TR 12295	Manual handling	Limits and assessment procedures for lifting and carrying, pushing and pulling, and handling of low loads at high frequency.
ISO 11064	Ergonomic design of control centres	Control room layout, workstation dimensions, display and control arrangement, lighting, acoustics, and environmental conditions.
ISO 10075 series	Mental workload	Terminology, design principles for avoiding overload and underload, and guidance on workload measurement methods.
IEC 62366-1	Usability engineering for medical devices	Mandatory use-specification, identification of hazard-related use scenarios, formative and summative validation testing with representative users.
EEMUA 191 / IEC 62682	Alarm systems in process industries	Alarm philosophy documents, prioritisation, rationalisation, performance metrics and target alarm rates, flood management.
WCAG 2.x	Digital accessibility	Perceivable, operable, understandable and robust content; contrast ratios, keyboard operability, timing adjustability, error identification and suggestion.
MIL-STD-1472 / NASA-STD-3001	Defence and aerospace human engineering	Detailed anthropometric, control, display, labelling, and maintainability requirements for equipment design.

Standards should be read as a floor rather than a ceiling. Conformance to ISO 9241 luminance contrast figures does not guarantee that a particular display is readable by a particular operator in a particular lighting environment; it guarantees only that one known class of failure has been avoided. The practitioner's job is to combine the codified baseline with context-specific analysis and empirical evaluation. A useful mental model for the whole discipline is therefore a loop: understand the people and the context, analyse the tasks and their physical and cognitive demands, design against principle and standard, evaluate with real users in realistic conditions, and feed the findings back — into the product, and also into the procedures, training, staffing, and policies that surround it. Human factors fails when any link in that loop is treated as optional.

Alignment with Learning Outcomes

MO1: The cognitive ergonomics discussion identifies working memory (approximately four unrehearsed chunks, decaying within seconds), attention as a limited largely serial resource, and long-term memory as large but cue-dependent, and draws the interface implications of each — recognition over recall, carrying values forward in multi-step flows, and preserving state across interruptions. The treatment of working memory overflow under high workload reinforces the same capacity constraints.
MO2: The topic addresses this directly and at length. Display–mental model compatibility, mode errors such as the Strasbourg vertical speed/flight path angle confusion, and automation surprises are all presented as systematic failures arising when the operator's model of the system diverges from its actual state, together with the design remedies that narrow that gap.
MO3: Hierarchical Task Analysis is introduced as the backbone task-analysis method, with its goal–subgoal–operation decomposition and plans explained and a worked infusion-administration example showing how each level of the hierarchy is read back as a specific interface design decision.
MO4: The evaluation section compares expert-driven methods (heuristic evaluation, cognitive walkthrough, RULA/REBA assessment) with user-involving methods (usability testing, simulation exercises, field observation) in terms of when each is used, what it reveals, and its limitations, providing the basis for selecting a technique appropriate to a given design context.
MO5: This topic does not address prototype construction directly; it contributes only indirectly, by supplying the interaction design principles — visual hierarchy, compatibility, error tolerance, feedback of system state — that a prototype would need to embody, and by noting that early low-fidelity artefacts such as paper sketches are the cheapest place to find human factors defects.

NotesHistorical and empirical claims used as illustrations (the 1950s USAF cockpit-dimension study, Air Inter 148, Eastern 401, Three Mile Island alarm flood, Texas City, hospital alarm false-positive rates, EEMUA 191 alarm-rate targets, vigilance decrement onset times) are well-documented in the human factors literature but are deliberately described at a level of generality appropriate to teaching; instructors wishing to assess on them should direct students to primary sources (Bainbridge 1983; Endsley 1995; Parasuraman, Sheridan & Wickens 2000; Sheridan & Verplank 1978; Fitts 1951; Reason 1990; Wickens & Carswell's proximity compatibility principle). Memory capacity figures are given as a range (Miller's 7±2 versus Cowan's ~4) rather than a single number, since MO1 may be assessed against either convention — check which figure the module's core text uses before setting questions. Standard numbers and scopes are current as of writing but ISO/IEC parts are periodically revised and renumbered; verify part numbers against the latest catalogue before issuing to students.

2

Videos on This Topic

▶

Human factors (also called ergonomics) is the study of how people actually perform within systems — physically, perceptually, and cognitively — and how equipment, displays, software, and work processes should be shaped around those human capabilities and limits. In this topic we look at both halves of the field: the physical dimension (posture, reach, repetitive strain, workstation layout) and the cognitive dimension (attention, memory load, situational awareness, decision making). Both matter to interface design, because an interface is never used in isolation; it sits inside a task, a workstation, and a work system.

The topic also covers automation: what happens when part of a task is handed off to a machine or algorithm. Automation rarely removes work — it changes it, often shifting the human into a monitoring role, which can degrade situational awareness, create new error modes, and leave people out of the loop when something goes wrong. Display design principles (making relevant information visible, grouping it sensibly, matching it to the operator's mental model) are the main lever designers have for keeping people informed and in control.

While watching the two videos below, keep two questions in mind. First, what is the limiting factor in the scenario being described — the body, the senses, attention, or memory? Second, what design or work-system change would relieve that limit, and what new problem might that change introduce? That trade-off thinking is the core habit of human factors work.

3

Video 1: Ergonomics in the Workplace | By Ally Safety

▶

Ally Safety · 4:19 · 256,214 views · 5y ago · captions — Watch on YouTube

About this video

A short workplace-safety style introduction to ergonomics, focused on body mechanics, posture, lifting, and workstation setup as ways to prevent injury. Based on its title and description, it covers practical, everyday ergonomic adjustments rather than theory, and frames ergonomics as fitting the task and equipment to the worker.

Why this video

It gives a concise, concrete entry point to the physical dimension of ergonomics from a safety-training producer, which grounds the abstract idea of 'fitting the system to the human' before we extend that same logic to cognitive and interface concerns.

4

Video 2: How to Stop AI from Killing Your Critical Thinking | Advait Sarkar | TED

▶

TED · 14:55 · 748,525 views · 9mo ago · captions — Watch on YouTube

About this video

A TED talk by researcher Advait Sarkar arguing that offloading reasoning to AI chatbots can speed up work while quietly eroding the user's own critical thinking. Expect discussion of what is gained and lost when a cognitive task is automated, and how people's engagement with a task changes when a tool does part of the thinking.

Why this video

It is a current, well-produced treatment of automation's effect on the human operator — complacency, loss of engagement, and out-of-the-loop effects — which maps directly onto the automation, human error, mental workload, and situational awareness subtopics.

5

How These Videos Support the Learning Outcomes

▶

These videos support the module outcomes by supplying the human-performance context the outcomes assume. The AI talk illustrates how a user's expectations about a system's competence can diverge from what it actually does, which is exactly the mental-model mismatch that produces systematic errors (MO2), and its discussion of cognitive offloading connects to memory and attention limits that constrain interface design (MO1). The ergonomics video reinforces task- and workstation-level thinking that feeds into decomposing goals into subtasks and evaluating designs in realistic use contexts (MO3, MO4). Together they give you criteria — physical fit, workload, error potential, and retained user control — to justify choices when you build and critique a prototype (MO5).

6

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Collaborative and Advanced Interface Technologies

1

Collaborative and Advanced Interface Technologies

▶

Traditional human–computer interaction research grew up around a convenient fiction: one person, one screen, one keyboard, one task. That model was always an approximation, and today it is an increasingly poor one. People write documents that four colleagues are editing at the same moment, dictate reminders to a speaker in the kitchen, follow turn-by-turn navigation projected onto a windscreen, hand off a half-finished message from a phone to a laptop, and supervise automated systems that make thousands of decisions per second on their behalf. This topic examines the interface technologies and design concerns that arise once we abandon the single-user, single-device assumption: cooperative work, groupware architecture, post-WIMP interaction paradigms, automation and oversight, novel display forms, mobile interaction in demanding contexts, and the emerging frontier of brain-computer interfaces, ubiquitous computing, and AI-mediated interaction.

A unifying thread runs through all of these areas. Every advance that removes friction — automating a step, embedding a sensor, predicting an intent, sharing a workspace — simultaneously removes a source of feedback and control. The design work consists largely of putting the right amount of friction, visibility, and authority back in. Keep that tension in mind as each section unfolds.

Computer-Supported Cooperative Work (CSCW)

Computer-Supported Cooperative Work is the study of how people work together using technology, and of how technology should be designed to support that work. The term was coined in 1984 by Irene Greif and Paul Cashman, and the field is deliberately interdisciplinary: it draws on computer science, sociology, organisational psychology, and anthropology, because the hard problems in cooperative systems are rarely purely technical. A shared calendar that works flawlessly at the protocol level can still fail completely if it exposes information that colleagues consider private, or if it assumes everyone's time is equally interruptible.

The classic organising device for CSCW is the time–space matrix proposed by Johansen, which classifies cooperative systems by whether participants are co-located or distributed, and whether their interaction is synchronous or asynchronous.

	Same time (synchronous)	Different time (asynchronous)
Same place (co-located)	Interactive meeting-room displays, shared tabletop surfaces, electronic voting and brainstorming tools, pair-programming at one workstation	Shift-handover boards in hospitals, team information radiators, physical–digital kanban walls, kiosk-based team notes
Different place (remote)	Video conferencing, live collaborative editors, shared whiteboards, screen sharing, multiplayer simulation environments	Email, discussion forums, version control systems, shared document repositories, issue trackers, recorded video messages

The matrix is a starting point rather than a taxonomy of products — most real platforms straddle several cells. A modern collaborative editor supports synchronous co-editing, asynchronous commenting, and a version history that functions as a different-time, different-place record. What the matrix does usefully is force the designer to ask: which cells does my system claim to support, and have I designed for each of them deliberately? A tool that is excellent synchronously but leaves no legible trace for the colleague who logs on tomorrow morning has only solved half the problem.

Three design challenges dominate CSCW practice.

Awareness. In a shared physical office, you absorb an enormous amount of information for free: who is present, who is busy, what someone is working on, whether a conversation is happening that concerns you. Distributed systems must reconstruct this deliberately. Mechanisms include presence indicators (online/away/in a meeting), telepointers and coloured cursors showing where each collaborator is working, activity feeds, read receipts, and "who else is viewing this" badges. Dourish and Bellotti's influential definition — awareness is "an understanding of the activities of others, which provides a context for your own activity" — makes the point that awareness is not an end in itself; it exists so that individuals can make sensible decisions about their own next action.
Coordination. Groups must divide labour, sequence dependent tasks, and avoid duplicated or conflicting effort. Coordination can be explicit (assigning a ticket, @-mentioning someone, setting a deadline) or implicit (seeing that a colleague's cursor is in section 3, so you start on section 5). Good systems support both, because explicit coordination carries overhead and groups naturally minimise it where awareness information makes it unnecessary.
Communication. Cooperative work requires conversation about the work as well as the work itself. Interfaces must provide channels for this meta-conversation — inline comments, suggestion mode, chat panes anchored to artefacts — and must make clear what is in the document versus what is about the document. A frequent failure is forcing all discussion into a separate chat tool, severing it from the artefact it refers to, so that six months later nobody can reconstruct why a decision was made.

Beneath these lies the social layer, which is where many technically sound groupware systems have historically failed. Grudin's well-known critique identified a recurring pattern: the people who do the extra work of maintaining a groupware system are often not the people who benefit from it. A shared corporate calendar benefits managers who want to schedule meetings, but the cost of diligent calendar maintenance falls on everyone else — so the data decays and the system becomes useless. Designers must ask who pays and who gains.

Other social dynamics that interfaces must accommodate include:

Turn-taking and floor control. Face-to-face conversation is regulated by gaze, posture, and subtle vocal cues that video conferencing degrades badly, which is why remote meetings produce more collisions and longer silences. Interfaces can compensate with explicit floor-control mechanisms — raise-hand queues, mute-by-default policies, speaking-order rotation, or a shared whiteboard "token" that must be requested. The trade-off is that explicit protocols are fairer but slower and more formal than natural conversation.
Role hierarchies and permissions. Groups are rarely flat. Owner/editor/commenter/viewer models encode authority in the interface, and the way they are exposed matters: a junior team member may hesitate to edit a document directly but will readily leave a suggestion. Suggestion mode is therefore not merely a technical feature but a social affordance that lowers the cost of contribution for people with less positional power.
Conflict resolution. Conflicts arise at the data level (two simultaneous edits to the same sentence) and at the human level (two people disagreeing about the content). Technical mechanisms such as merge conflict markers in version control solve the first; the second requires interfaces that make disagreement visible, attributable, and resolvable — threaded comments with an explicit "resolve" action, change proposals that require review, or audit trails showing who changed what and when. Attribution is double-edged: it supports accountability but can feel like surveillance, so systems often let users control the granularity at which their activity is recorded.

Common CSCW tools illustrate these ideas concretely. A collaborative document editor combines real-time awareness (named cursors), conflict handling (operational transformation or CRDTs, discussed below), communication (comments and suggestions), and history (version timeline). A shared whiteboard trades structure for expressive freedom, supporting the rough, spatially organised thinking that precedes formal documents; its design problems centre on viewport management — if collaborators can pan independently, they lose shared reference, so whiteboards offer "follow" modes and spatial minimaps. A project management platform such as a kanban board externalises coordination itself: the board is the shared mental model of who is doing what, and its value comes from being a single, visible, continuously updated representation of group state.

Groupware and Collaboration Frameworks

Groupware is the software layer that realises CSCW ideas. Returning to the time–space matrix, each quadrant carries distinct design obligations.

Same-time, same-place systems support people who share a room. Interactive meeting-room displays, digital whiteboards, and multi-touch tabletops must handle problems that remote tools never face: multiple simultaneous touch inputs from different people, orientation (text readable from one side of a table is upside down from the other), reach (a 2-metre wall display has regions some users physically cannot touch), and territoriality — research on tabletop interaction shows that groups spontaneously partition the surface into personal, group, and storage territories, and interfaces that ignore this feel intrusive. Co-located tools also must not duplicate what the room already provides: speech, gesture, and gaze are already available, so the software should support the work rather than mediating the conversation.

Different-time, different-place systems support asynchronous remote collaboration and are, in practice, the workhorses of distributed work. Email, discussion threads, shared repositories, and documentation wikis all share a core requirement: because recipients arrive at unpredictable times and without shared context, the system must preserve context with the content. A good asynchronous tool makes it possible to reconstruct the state of a discussion without having been present. Practical features include threading, quoting, change summaries and diffs, persistent links to specific revisions, and clear markers of what is new since the reader's last visit. Asynchronous tools must also respect the fact that latency is a feature, not a bug — it allows participants in different time zones to contribute thoughtfully rather than reactively.

A persistent design tension in all groupware is the balance between individual needs and group workflow. Individuals want a workspace tuned to their own preferences — their own filters, sort order, zoom level, notification settings, drafts that nobody else sees. The group needs consistency, shared reference, and visibility. Systems resolve this with layered views: a shared canonical artefact plus per-user view state. In a collaborative spreadsheet, for example, filters are commonly made per-user precisely because one person's filter silently changing everyone else's view is disorienting. The same logic produces private drafts that are published explicitly, personal "my tasks" views over a shared backlog, and WYSIWIS ("what you see is what I see") modes that can be relaxed into independent scrolling when tight coupling becomes a burden.

Coordination mechanisms are the technical machinery that prevents shared state from becoming incoherent. The main families are:

Mechanism	How it works	Strengths	Weaknesses
Pessimistic locking (check-out/check-in)	A user acquires an exclusive lock on a file or region; others are blocked until it is released	Conflicts are impossible; simple to reason about; suits binary assets like CAD or image files that cannot be merged	Blocks parallel work; forgotten locks stall the team; poor fit for fast-moving text
Optimistic concurrency with merge	Everyone edits freely; divergence is detected and reconciled on commit (e.g. Git)	Maximum parallelism; full history; branching supports experimentation	Merge conflicts require human judgement and can be intimidating for non-technical users
Operational transformation (OT)	Concurrent operations are transformed against one another so that all replicas converge, typically via a central server	Enables fine-grained, character-level real-time editing with no visible conflicts	Algorithmically intricate; usually requires a central authority to order operations
CRDTs (conflict-free replicated data types)	Data structures mathematically designed so concurrent updates commute and always converge	Works peer-to-peer and offline-first; no central server required	Metadata overhead; convergence is guaranteed but the merged result may still need human review
Versioning and history	Every change is recorded with author and timestamp; prior states are restorable	Supports accountability, undo, and asynchronous catch-up	Storage cost; history itself needs an interface or it is unusable
Notifications and subscriptions	Changes of interest are pushed to relevant users	Closes the awareness gap in asynchronous work	Over-notification causes alert fatigue and desensitisation

The intuition behind operational transformation is worth seeing concretely. Suppose a shared document contains the string "HAT" and two users act at the same instant.

Initial state:  "HAT"

User A (local):  Insert("C", pos 0)   ->  "CHAT"
User B (local):  Delete(pos 2)        ->  "HA"     (removes "T")

Naive application of B's raw operation on A's replica:
  "CHAT" with Delete(pos 2)  ->  "CHT"     WRONG - deletes "A"

Transformation of B's operation against A's insert:
  because A inserted one character at a position <= B's index,
  B's index must shift right by 1:  Delete(pos 2) -> Delete(pos 3)

  "CHAT" with Delete(pos 3)  ->  "CHA"     CORRECT

Symmetrically, A's insert at pos 0 is unaffected by B's delete at pos 2:
  "HA" with Insert("C", pos 0)  ->  "CHA"  CORRECT

Both replicas converge on "CHA".

From an interface perspective, the crucial consequence is that the user should never be asked to think about any of this. The design goal of real-time groupware is that the concurrency control is invisible, while the social information it implies — someone else is typing here, this paragraph just changed, this section is being rewritten — is highly visible. Compare this with version control, where conflicts are deliberately surfaced because the merge decision genuinely requires human judgement about meaning.

Notification design deserves separate emphasis because it is where most groupware is actually judged. A reasonable framework is to classify events by urgency and relevance, and map them to channels accordingly: immediate interruptive alerts reserved for direct mentions and blocking requests; batched digests for ambient activity; and purely passive indicators (badges, change highlights) for everything else. Giving users per-project and per-event-type control, plus a "mute this thread" escape hatch, is not a luxury — without it, people disable notifications wholesale and the awareness channel collapses.

Advanced Interface Paradigms

Beyond the desktop lies a family of interaction paradigms often grouped under the heading "post-WIMP" (beyond windows, icons, menus, and pointers). They share a common ambition: to exploit human perceptual and motor skills that the keyboard and mouse leave idle.

Tangible user interfaces (TUIs) give digital information a physical form that can be grasped and manipulated. Ishii and Ullmer's canonical example, the metaDESK, let users move a small physical model of a building across a map-projected table to pan and rotate the map. Later examples include Siftables and Sifteo cubes, the Reactable music instrument (where placing and rotating pucks on a table configures a synthesiser), and physical tokens used in planning or education. The appeal of TUIs is that they inherit the affordances of the physical world for free: a block can be picked up, weighed, passed to a colleague, and arranged spatially with a precision and speed that no mouse can match, and the constraints of physics prevent many invalid states. They are also inherently multi-user — several hands can act on a tabletop simultaneously — which makes them attractive for co-located CSCW. Their limitations are equally physical: tangibles cannot change shape to reflect state, they can be lost, and they do not scale to large or abstract data sets.

Augmented and virtual reality. These sit on Milgram's reality–virtuality continuum, from unmediated reality, through augmented reality (digital content registered to the physical world), mixed reality (digital and physical content that interact), to fully virtual environments. AR's defining technical requirement is registration: virtual content must be correctly aligned with the physical scene and remain aligned as the user moves. A surgical AR overlay that is three millimetres off is worse than no overlay. Representative uses include a warehouse picker seeing the next bin highlighted through smart glasses, a maintenance technician seeing exploded-view instructions anchored to the actual machine, and a shopper previewing furniture in their own room. VR, by contrast, replaces the environment entirely, which makes it powerful for training (flight simulation, emergency drills, surgical rehearsal), spatial design review, and empathy-building experiences. VR design has its own hard constraints: motion-to-photon latency must stay low (typically under about 20 ms) and visual motion must agree with vestibular sensation, or users experience simulator sickness; text input is awkward; and physical safety in the real room must be managed via guardian boundaries. Both AR and VR raise collaboration questions — shared virtual workspaces need avatars with enough expressiveness to carry gaze and gesture cues, and asymmetric setups (one user in a headset, three on laptops) require careful design so that the non-immersed participants are not second-class.

Natural user interfaces (NUIs) use gesture, voice, touch, gaze, and body movement as primary inputs. The word "natural" is somewhat aspirational: these interfaces aim to feel natural, but almost all gestures beyond the simplest are learned conventions, not innate behaviours. Key design problems are:

Discoverability. Gestures and voice commands are invisible. There is no menu to browse. Systems must teach their vocabulary through onboarding, contextual hints, suggestion chips ("Try saying…"), or redundant visible controls that provide the same function.
The live-mic / Midas-touch problem. If every movement is interpreted as input, users cannot scratch their nose without triggering something. Hence wake words, push-to-talk, explicit engagement gestures, and dwell thresholds for gaze input.
Feedback and error recovery. Recognition-based input is probabilistic. The interface must show what it understood (a live transcript, a highlighted recognised gesture), make the confidence legible when it is low, and make correction cheap — "did you mean…?", easy undo, or a fallback to typing.
Fatigue and ergonomics. Mid-air gesturing produces "gorilla arm"; sustained voice interaction is socially awkward in shared spaces and unusable in noisy ones. Modality choice must fit the physical and social context.

Context-aware interfaces adapt their behaviour based on sensed circumstances: location, time, motion state, ambient light and noise, nearby devices, calendar entries, and interaction history. Examples range from the trivially useful (a phone brightening in sunlight, a watch raising the volume of an alarm when the user has been still) to the sophisticated (a navigation app proposing a departure time based on live traffic and a calendar event, or a car interface simplifying its display at high speed). Dey's standard definition of context — "any information that can be used to characterise the situation of an entity" — is deliberately broad, and the practical difficulty is inference: sensors report that the phone is moving at 25 km/h, but the system must infer cycling versus riding a bus, and the correct adaptation differs. Because such inferences are fallible, context-aware designs should favour suggestion over substitution: proposing a shortcut that the user can accept is far safer than silently reconfiguring the interface. Adaptation also conflicts with learnability — if the interface rearranges itself, users cannot build stable spatial memory of where things are, so adaptive elements are usually confined to a dedicated region (a suggestions row, a smart reply bar) while the core layout stays fixed.

Automation and Human Oversight in Interfaces

Automation is not binary. Sheridan and Verplank's influential scale describes ten levels running from fully manual to fully autonomous; a simplified version is more useful for design discussion.

Level	Description	Example	Primary interface obligation
1 — Manual	The human performs the task; the computer offers no assistance	Typing a document unaided	Efficient direct controls and clear feedback
2–3 — Decision support	The system offers options or narrows alternatives; the human chooses	Spell-check suggestions, route alternatives	Show why each option is suggested; make ranking honest
4–5 — Consent-based automation	The system proposes one action and executes it only on approval	Autocomplete, suggested replies, "install update now?"	Make the proposed action and its consequences inspectable before acceptance
6–7 — Management byexception	The system acts automatically but allows a window for the human to veto, or acts and reports immediately	Automatic braking with an override, scheduled send with a brief "undo" window, autosave	Announce the action clearly and keep the veto path obvious and reachable in time
8–9 — Supervisory control	The system acts and informs the human only if asked, or only on exception	Autopilot holding altitude, cloud backup running nightly, spam filtering	Provide a legible status display and an accessible log of what was done
10 — Full autonomy	The system decides and acts; the human is out of the loop	Airbag deployment, automated circuit protection, high-frequency trading guards	Post-hoc explanation and the ability to audit, tune, or disable the system entirely

Crucially, the level of automation need not be fixed across a system or across time. Parasuraman, Sheridan, and Wickens proposed decomposing automation across four stages of human information processing — information acquisition, information analysis, decision selection, and action implementation — and choosing a level independently for each. A clinical decision support tool might be highly automated at the acquisition and analysis stages (gathering and summarising the patient record, flagging abnormal values) while remaining deliberately low at the decision and action stages, so that the prescribing decision stays with the clinician. This decomposition is one of the most practical design tools in the area: instead of asking "should this be automated?", ask "which stage should be automated, and how far?"

Situational awareness. Endsley's three-level model is the standard reference: Level 1 is perceiving the elements of the current situation, Level 2 is comprehending what they mean, and Level 3 is projecting what will happen next. Automation tends to attack all three. It removes the small manual actions through which operators used to perceive system state, it summarises data so comprehension is pre-chewed, and it makes future behaviour depend on internal logic the operator cannot see. Interfaces therefore need to answer four questions continuously: What is the system doing now? Why is it doing that? What will it do next? And what would make it stop? A cruise-control display that shows only "ON" answers none of these; one that shows the target speed, the detected lead vehicle, the following gap, and a clear indication that it will not react to stationary obstacles answers most of them.

Automation surprises occur when the system does something the operator did not expect and cannot explain. They almost always arise from mode confusion — the operator believes the system is in one mode while it is in another — combined with an interface that does not make the active mode salient. The aviation literature supplies the textbook cases: the 1992 Mont Sainte-Odile crash, in which a flight path angle of −3.3 degrees was plausibly confused with a descent rate of 3,300 feet per minute because the same display field served both modes; or incidents in which an autothrottle silently disengaged and the crew only noticed when the airspeed had decayed dangerously. The same pattern appears in consumer software at lower stakes: a user types for a minute before realising the document is in "suggesting" rather than "editing" mode, or discovers that a smart thermostat has been running an energy-saving schedule they never knowingly enabled. Mitigations include making modes visually unmistakable rather than indicated by a small icon, requiring a deliberate action to enter a consequential mode, announcing uncommanded transitions explicitly ("autopilot disconnected" as both an aural and visual alert), and avoiding overloaded display fields where identical numbers mean different things in different modes.

The costs of automation. Bainbridge's "ironies of automation" remain the sharpest statement of the problem: automation is introduced because designers consider humans unreliable, yet it leaves the human responsible for exactly the situations the designer could not anticipate — the hardest ones — while simultaneously degrading the skills and the situational awareness needed to handle them. Related effects include:

Skill decay. Rarely exercised manual skills atrophy. Airlines now mandate periodic hand-flying; the same logic argues for occasionally letting users perform a step manually rather than always automating it away.
Complacency and automation bias. When automation is usually right, people stop checking. Automation bias produces both errors of commission (following a wrong recommendation) and omission (failing to act because no alert fired). Studies of diagnostic aids repeatedly show that an incorrect computer suggestion can pull expert judgement away from a correct unaided decision.
Clumsy automation. Automation often reduces workload when it is already low and increases it at peak moments, because reprogramming the automation under time pressure costs more than doing the task by hand.
Out-of-the-loop performance decrement. A passive monitor takes significantly longer to detect and diagnose a fault than an active controller, and needs time to rebuild a mental picture before intervening — which is precisely why abrupt hand-backs in partially automated driving are so dangerous.

Practical design responses include keeping the human in a meaningful control loop rather than as a pure monitor, degrading gracefully with staged warnings rather than sudden hand-offs, designing for calibrated trust by communicating the system's competence envelope and confidence honestly, logging automated actions in a reviewable timeline, and providing a universally understood, always-available disengagement control. Confidence communication matters: a system that says "lane keeping unavailable: lane markings unclear" trains far better trust calibration than one that simply stops working.

Display Technologies and Information Presentation

Display choice is a task-and-context decision, not a technology-fashion decision. The relevant question is what the user must perceive, how quickly, while doing what else, and in what physical environment.

Display type	Best-suited tasks	Key limitations
Conventional 2D screens	Reading, writing, precise selection, dense data work, most productivity tasks	Requires attention to be directed at the screen; limited screen real estate; poor for truly volumetric data
Stereoscopic / 3D and volumetric displays	Spatial data where depth relationships matter — medical imaging, molecular structures, seismic or fluid-flow analysis, terrain	Occlusion and depth ambiguity, fatigue from vergence–accommodation conflict, difficulty with precise selection, poor for text
Heads-up displays (HUDs)	Monitoring a few critical values while attention stays on the outside world — flying, driving, surgery	Attentional capture and cognitive tunnelling; clutter obscuring the real scene; must be strictly minimal
Head-mounted AR/VR displays	Hands-busy guided procedures, immersive training, spatial design review	Weight and comfort, limited field of view, social acceptability, battery and thermal limits
Large wall displays and tabletops	Co-located group work, control rooms, situation awareness for teams	Reach and legibility vary with position; text is public; requires physical navigation
Wearable displays (watches, bands)	Glanceable notifications, fitness and health state, quick confirmations	Tiny screen, fat-finger targeting, severe information budget per glance
Ambient and peripheral displays	Continuous, non-urgent background information — air quality, build status, energy use, team presence	Low bandwidth; meaning must be learned; easily ignored, which is sometimes the point

Information density, layout, and visual encoding. Tufte's notion of the data–ink ratio — maximise the proportion of display devoted to actual data and remove decoration that carries no information — remains a reliable heuristic, although it must be tempered: some redundancy aids rapid recognition, and gridlines or labels that look like "chartjunk" may be essential for accurate reading. More fundamental is matching the visual channel to the data type. Position along a common scale is the most accurately judged encoding, followed by length, then angle and slope, then area, then colour saturation and volume; this ranking (from Cleveland and McGill's experiments) explains why a bar chart outperforms a pie chart for comparison and why bubble areas mislead. Hue is excellent for nominal categories but poor for ordered magnitude, and should be limited to roughly seven distinguishable categories; luminance and saturation ramps suit ordered data. Colour must never be the sole carrier of meaning, given that around 8% of men have some form of colour vision deficiency and that displays are read in sunlight, through tinted visors, and on failing projectors.

Layout should exploit pre-attentive processing — features such as colour, orientation, size, and motion that the visual system detects in under 200 milliseconds regardless of the number of distractors. A single red cell in a table of black numbers is found instantly; three overlapping highlight colours destroy that advantage. In control-room and dashboard design, this motivates a deliberate visual hierarchy: a calm, low-contrast baseline so that genuine exceptions can be made loud. The "grey background" convention in modern process-control displays follows exactly this logic — if normal operation is rendered in muted greys, an alarm in saturated colour cannot be missed. Supporting principles include grouping related items by proximity and enclosure (Gestalt laws), aligning elements to reduce scanning effort, maintaining consistent position for recurring items so spatial memory can develop, and applying progressive disclosure so that detail is available on demand rather than permanently competing for attention.

Multi-display environments. When information spans several screens, the costs are attentional rather than pixel-related. Each visual switch between displays incurs a saccade, a possible head turn, re-accommodation of the eyes, and the risk of losing one's place — and if the user must mentally carry values from one screen to another, that burden lands in working memory, which is exactly where it is most fragile. Design responses include co-locating items that must be compared on the same display, using consistent colour coding and orientation across displays so a mapping does not have to be relearned, providing explicit cross-references or links, minimising the need for transcription, and placing the most frequently monitored information in the primary field of view. In control rooms and trading floors this is formalised as display allocation: overview displays for status, detail displays for diagnosis, and a fixed convention for where each category lives. Multi-monitor desktops present the same problem in miniature, which is why window management across displays, pointer transitions, and a clear notion of which display is "primary" materially affect productivity.

Emerging display forms. Wearable displays impose a glanceability budget: the useful interaction may be under two seconds, so the design must convey one thing clearly rather than three things partially. Ambient displays — Weiser and Brown's "calm technology" — move information to the periphery of attention, like the original Dangling String installation that twitched in proportion to network traffic, or a lamp that glows amber when a shared build is broken. Their value is that they inform without interrupting; their risk is habituation. Related forms include e-ink surfaces for persistent low-power information, projection onto walls or desks, shape-changing and haptic displays that convey state through touch, and smart-fabric or skin-worn displays. The common opportunity across all of these is persistent, low-intrusion information delivery: a continuous channel that costs the user almost nothing to sample, which is a genuinely different design target from the attention-grabbing notification.

Mobile Interaction Design in Advanced Contexts

Mobile interaction differs from desktop interaction not primarily because screens are small, but because the context is unstable. The user is walking, cold, in sunlight, holding a bag, sharing attention with traffic, and interruptible at any moment. Designing well for mobility means designing for divided attention and physical variability.

Touch, grip, and one-handed use. The fundamental constraint is that the finger is a blunt, occluding pointer. A fingertip contact patch is roughly 10–14 mm wide, which is why platform guidelines specify minimum touch targets around 44×44 points (iOS) or 48×48 dp (Android), with spacing between adjacent targets so that an imprecise tap does not trigger the wrong control. Occlusion means the user's own hand hides the area under and below the touch point, which argues for placing feedback above the contact point and for the convention of showing selection callouts above the finger.

Grip varies more than designers assume. Research by Hoober on thousands of observations found roughly 49% one-handed use, 36% cradling (one hand holding, other hand or same thumb interacting), and 15% two-handed, with users switching grips constantly within a single session. A one-handed thumb sweeps a comfortable arc anchored at the base of the thumb, which makes the lower-centre of the screen easy, the diagonally opposite top corner hard, and the top of large phones effectively unreachable. Practical consequences:

Place primary actions and navigation within thumb reach — hence bottom tab bars, bottom sheets, floating action buttons in the lower region, and pull-down gestures (such as iOS Reachability) that bring the top of the screen down.
Keep destructive or irreversible actions out of the easiest-reach zone, or require confirmation, since accidental thumb contact is common.
Support both left- and right-handed grips; a control that is comfortable for a right thumb may be in the worst position for a left.
Prefer large, forgiving gestures (swipe, long-press on a sizeable region) over precise targeting when the user is likely to be moving.

Gloved and environmental operation adds further constraints. Capacitive touchscreens may not register thick gloves at all, cold or wet fingers reduce accuracy, and sunlight washes out low-contrast displays. Field applications — logistics, utilities, emergency services, agriculture — therefore favour oversized targets, high-contrast themes, voice input, physical buttons for critical functions, and large simple gestures. The same thinking benefits mainstream users with motor tremor or reduced dexterity, which is a reminder that designing for the extreme case routinely improves the average case.

Sensors and context sensitivity. A modern phone carries GPS and other GNSS receivers, Wi-Fi and Bluetooth scanning for indoor positioning, accelerometer, gyroscope, magnetometer, barometer, ambient light and proximity sensors, microphones, multiple cameras, and sometimes depth or ultra-wideband sensors. Fused together, these support activity recognition (walking, driving, cycling, stationary), geofencing, indoor micro-location, and orientation-aware rendering. Applications include a transit app opening directly on the nearest stop's departures, a retail app surfacing a stored loyalty card when the user enters the shop, a field-service app automatically attaching GPS coordinates and a timestamp to a photograph of a fault, and a driving mode that suppresses notifications when vehicle motion is detected. Three cautions apply. First, sensor inference is probabilistic, so the design must degrade gracefully when the guess is wrong, with an easy manual override. Second, continuous sensing costs battery, and users notice. Third — and most importantly — location and activity data are among the most sensitive data categories there are, so permissions should be requested in context with a clear rationale, precision should be minimised to what the task genuinely needs (coarse rather than precise location, "while using the app" rather than "always"), and the interface should show visibly when sensing is active.

Cross-device interaction. Users increasingly expect tasks to migrate between devices: start an article on a phone during a commute, continue on a laptop at a desk, get the reminder on a watch, finish by casting to a television. Patterns for this include continuity/handoff (resuming the same task with its state on another device), complementarity (the phone acts as a controller or keyboard for a TV or large display), mirroring (the same content on two screens), and distribution (splitting one interface across devices, as when a map appears on a car display while turn prompts go to the driver's cluster). Making these work requires genuine design attention to synchronisation of state and scroll position, conflict handling when the same item is edited on two devices, consistent information architecture so users are not disoriented by a jump, device discovery and pairing that does not demand network knowledge, and above all clear feedback about which device currently "has" the task. Responsive design that merely reflows layout is not cross-device design; the deeper question is which parts of a task are best suited to which device, given each one's input precision, screen size, attention demands, and typical usage posture.

Mobile in collaborative settings. Shared mobile experiences differ from individual ones in ways that are easy to overlook. A phone is a personal, private object: handing it to someone else exposes notifications, open tabs, and photo libraries. Group use therefore benefits from guest or focused modes that constrain what can be reached. Several patterns recur:

Many phones, one display. Audience members use their own device to vote, submit questions, or contribute to a shared visualisation (live polling in lectures, second-screen quiz games). Design concerns are low-friction joining — a short code or QR rather than account creation — and fair aggregation of input.
Phone as personal controller for a shared space. Each participant manipulates a shared wall display from their own device, which preserves private workspace alongside the public artefact and neatly avoids the reach problem of large displays.
Co-located sharing of one device. Passing a phone around to show photos, or two people watching a video on one screen, demands orientation handling, readable-at-an-angle layouts, and privacy guards.
Mobile members of a distributed meeting. A participant joining from a phone has a fraction of the screen area, may be walking, and may be unable to type. Inclusive design here means providing lightweight contribution channels (reactions, voice, short text) rather than assuming everyone has a full workstation — otherwise mobile participants become passive observers, an asymmetry that quietly reproduces status differences in the group.

Emerging Trends and Future Directions in Interface Technologies

Brain–computer interfaces. BCIs create a direct channel between neural activity and a digital system, bypassing muscles entirely. They are usually classified by invasiveness. Non-invasive BCIs — chiefly EEG, plus fNIRS — use scalp electrodes; they are safe and relatively cheap but have low spatial resolution and poor signal-to-noise ratio because the skull smears and attenuates the signal. Partially invasive approaches such as electrocorticography place electrodes on the cortical surface beneath the skull. Invasive BCIs implant microelectrode arrays into cortical tissue, giving single-neuron resolution at the cost of surgery and long-term biocompatibility problems. Established paradigms include the P300 speller (the user attends to a flashing letter and the system detects the characteristic positive deflection about 300 ms later), SSVEP (targets flicker at distinct frequencies and the system identifies which frequency dominates visual cortex activity), and motor imagery (imagining left- or right-hand movement produces distinguishable sensorimotor rhythms). Real achievements include cursor and robotic-arm control by people with tetraplegia and speech decoding research that has restored communication rates of tens of words per minute. Interface design implications are substantial: bandwidth is tiny compared with typing, so vocabularies must be small and predictive; classification is noisy, so confirmation steps and cheap undo are essential; training burdens are real for both user and classifier; and fatigue builds quickly. Perhaps most importantly, BCIs raise acute questions of agency and "mental privacy" — if a system acts on a decoded intention the user did not consciously endorse, who is responsible? For now, the dominant and most defensible applications are assistive, for users for whom conventional input is impossible.

Ubiquitous computing. Mark Weiser's 1991 vision — "the most profound technologies are those that disappear… they weave themselves into the fabric of everyday life until they are indistinguishable from it" — anticipated an environment of tabs, pads, and boards: many devices per person, embedded in the surroundings, mostly unnoticed. Smart homes, connected buildings, industrial IoT, asset tracking, and the quantified-self ecosystem are partial realisations. The interface problems of ubicomp are distinctive. When computing is embedded in the environment, there may be no screen to look at and no obvious place to go when something breaks; intelligibility and accountability — making the system able to explain what it sensed, what it inferred, and what it did, and letting the user correct it — become primary requirements rather than optional extras. Other recurring issues include seamless versus "seamful" design (deliberately exposing system boundaries such as sensing gaps so users can work with them rather than being confused by them), interoperability across vendor ecosystems, graceful behaviour when a device is offline, and the simple question of who in a shared household has authority to change a setting that affects everyone.

AI-powered interfaces. Machine learning now shapes interaction at several levels: ranking and recommendation, predictive text and autocompletion, voice and handwriting recognition, anomaly detection, and increasingly conversational and generative interaction where the user expresses an intent in natural language and the system produces an artefact. These systems change the nature of the interface contract. Deterministic software gives the same output for the same input; probabilistic software does not, which undermines learnability and makes error recovery central. Established guidance — for example Amershi and colleagues' guidelines for human–AI interaction — converges on a few durable principles: make clear what the system can and cannot do before the user forms expectations; scope outputs to the current context; show confidence or alternatives rather than a single answer presented with false certainty; support efficient correction and dismissal; learn from user behaviour but allow the user to inspectand adjust what has been learned; and be careful about the social consequences of automated inferences. Personalisation illustrates the trade-offs sharply: a feed tuned to past behaviour reduces friction but can narrow exposure, entrench stereotypes, and make the system's behaviour unpredictable to the very user it is modelling. Mixed-initiative design — Horvitz's framing in which the system and the user each contribute what they are better at, with the system considering the expected cost of interrupting before it acts — remains the most useful stance: let the AI propose, let the human dispose, and make the cost of rejecting a proposal lower than the cost of accepting a wrong one.

Inclusivity and ethics. Advanced interfaces collect far more personal and behavioural data than a keyboard and mouse ever did: gaze paths, gait, voice timbre, dwell times, room layouts, heart rate, neural signals. Several obligations follow, and they are design obligations rather than legal afterthoughts.

Data minimisation and purpose limitation. Collect the least data that supports the task, retain it for the shortest useful period, and process on-device where possible. An AR headset that needs to detect a flat surface does not need to upload a reconstruction of the user's living room.
Meaningful consent and legibility. Consent buried in a licence agreement is not consent for continuous ambient sensing. Visible indicators that a microphone, camera, or sensor is active — and that bystanders can also see — are part of the interface.
Bystander rights. Many advanced interfaces capture people who never agreed to anything: others in the room during a smart-speaker conversation, passers-by recorded by smart glasses, household members profiled by a shared assistant. Design must consider the non-user.
Accessibility by default. Gesture, voice, and gaze interfaces can be liberating for some users and exclusionary for others. Speech recognition trained predominantly on one accent group underperforms for others; mid-air gestures assume arm mobility; VR assumes stereo vision and vestibular tolerance. Multimodal redundancy — more than one way to do everything important — is the most reliable safeguard.
Algorithmic fairness and contestability. When an interface acts on an inference about a person, that person should be able to see the inference, challenge it, and have it corrected. "The system decided" is not an acceptable terminal explanation.
Attention and wellbeing. Interfaces that are persuasive by design — infinite scroll, variable-ratio notification schedules, streak mechanics — optimise engagement rather than user benefit. Calm, respectful defaults are an ethical as well as a usability choice.

Taken together, these areas describe a shift in what interface design is about. The design object is no longer a screen full of controls operated by one person; it is a distributed arrangement of people, devices, sensors, and autonomous processes, in which the designer's central task is to maintain a shared, accurate, and actionable understanding of state — among collaborators, between a user and an automated system, and across devices and displays. Awareness in CSCW, mode visibility in automation, intelligibility in ubicomp, and confidence display in AI interfaces are all the same requirement wearing different clothes.

Alignment with Learning Outcomes

MO1 — Supported indirectly. The topic repeatedly invokes memory capacity as a design constraint: working-memory load when transferring values across multi-display environments, glanceability budgets on wearables, the limit of roughly seven distinguishable colour categories, the recognition-over-recall problem created by invisible gesture and voice vocabularies, and the loss of long-term skill memory through automation-induced skill decay.
MO2 — Strongly supported. Automation surprises and mode confusion are presented explicitly as mental-model mismatches: the operator's model of what the system is doing diverges from its actual state, producing systematic rather than random errors. The same analysis is applied to context-aware adaptation, probabilistic AI interfaces, and ubicomp systems whose behaviour is unintelligible to users.
MO3 — Addressed only lightly. Hierarchical Task Analysis is not taught here, but the topic supplies the task-decomposition thinking HTA formalises — for example, deciding which stage of a task (acquisition, analysis, decision, action) to automate, and which subtasks to allocate to which device in cross-device interaction.
MO4 — Supported partially. The topic does not compare evaluation methods directly, but it establishes the contexts in which method choice becomes difficult: group-level collaborative use, safety-critical automation, and immersive or sensor-driven settings where expert inspection and conventional lab-based user testing each have clear limits.
MO5 — Supported as design input rather than technique. The interaction principles detailed here — touch target sizing, thumb-reach zones, visual hierarchy, progressive disclosure, feedback for recognition-based input, and cross-device continuity — are directly applicable to the decisions a student makes when building a low-to-mid fidelity desktop or mobile prototype.

NotesKey named sources referenced for accuracy: Greif & Cashman (origin of the term CSCW, 1984); Johansen's time–space matrix; Dourish & Bellotti (awareness, 1992); Grudin's groupware failure analysis; Ishii & Ullmer (tangible bits / metaDESK); Milgram's reality–virtuality continuum; Dey (definition of context); Sheridan & Verplank (10 levels of automation); Parasuraman, Sheridan & Wickens (four-stage automation model); Endsley (three-level situational awareness); Bainbridge (ironies of automation); Tufte (data–ink ratio); Cleveland & McGill (ranking of visual encodings); Weiser (ubiquitous computing, 1991) and Weiser & Brown (calm technology); Hoober (mobile grip observation data); Horvitz (mixed-initiative interaction); Amershi et al. (guidelines for human–AI interaction). Platform figures cited (44×44 pt iOS, 48×48 dp Android, ~20 ms motion-to-photon) reflect current published guidance and should be re-checked against vendor documentation if used in assessment materials. The Mont Sainte-Odile (1992) mode-confusion case is the standard aviation example; instructors may substitute a more recent or domain-relevant incident.

2

Videos on This Topic

▶

Most of this course treats interaction as a conversation between one person and one system. This topic widens the frame. Computer-Supported Cooperative Work (CSCW) studies how groups of people coordinate, communicate, and share artifacts through technology, and groupware frameworks are the tools built to support that work: shared documents, version control, notebooks, messaging, awareness cues, and handoff mechanisms. Alongside CSCW, this topic covers advanced interface paradigms — immersive and spatial displays, mixed reality, mobile and embedded interaction — plus the question of how much a system should automate and how much the human should oversee.

These ideas matter here because the design principles you have been learning do not disappear when the context gets more complex; they get harder to apply. Shared workspaces multiply the number of mental models in play, immersive displays change what information can be presented and how attention is divided, and automation shifts the user's role from doing to monitoring. Advanced technology does not excuse bad task analysis, confusing feedback, or untested prototypes — it raises the cost of getting them wrong.

The three videos below are short conference presentations from ACM SIGCHI, the professional community that produces much of the research in this field. As you watch, listen for how each team defines the collaborative setting, what methods they used to study it, and what design implications they draw. Pay attention to the vocabulary too — terms like teamwork versus taskwork, awareness, workflow, and research agenda are standard in this literature and will help you read further on your own.

3

Video 1: How do Data Science Workers Collaborate? Roles, Workflows, and Tools

▶

ACM SIGCHI · 5:06 · 224 views · 5y ago · captions — Watch on YouTube

About this video

A short CSCW '20 presentation from Dakuo Wang of IBM Research on how data science workers actually collaborate in practice. Based on the title and venue, it likely describes the distinct roles people occupy on data science teams, the workflows that connect them, and the tools they use to hand off work and stay coordinated. Expect an empirical, interview- or survey-based framing rather than a tool demo.

Why this video

It is a direct, accessible entry point to CSCW and groupware: real teams, real handoffs, and the gaps between the tools people have and the coordination they need. Coming from the flagship CSCW conference, it also models how collaboration research is framed and reported.

4

Video 2: "Is It My Turn?" Assessing Teamwork and Taskwork in Collaborative Immersive Analytics

▶

ACM SIGCHI · 9:03 · 94 views · 3y ago · captions — Watch on YouTube

About this video

A CSCW conference talk on collaborative immersive analytics — groups working together with data inside immersive or shared visual environments. The title's question, "Is It My Turn?", signals a focus on turn-taking and coordination, and the talk distinguishes teamwork (how members coordinate with each other) from taskwork (the analytic work itself). Look for how the researchers measured or assessed these two dimensions.

Why this video

It connects CSCW directly to advanced interface paradigms and display technologies, showing how immersive presentation changes group coordination rather than simply making data prettier. The teamwork/taskwork distinction is a useful analytical lens you can carry into your own group-system designs.

5

Video 3: Emerging Technologies in K–12 Education: A Future HCI Research Agenda

▶

ACM SIGCHI · 7:59 · 774 views · 3y ago · captions — Watch on YouTube

About this video

A SIGCHI presentation proposing a future HCI research agenda for emerging technologies in K-12 education, from Van Mechelen, Smith, and colleagues. It likely surveys technologies entering classrooms — which may include AI, data-driven tools, and new interaction modalities — and identifies open questions and design challenges for researchers and practitioners. The framing is agenda-setting rather than reporting a single study.

Why this video

It covers the emerging trends and future directions subtopic explicitly, and it grounds abstract speculation in a concrete setting with real stakeholders, oversight concerns, and constraints. It also shows students what a research agenda looks like, which is useful if you are choosing a project direction.

6

How These Videos Support the Learning Outcomes

▶

These videos extend the module's core outcomes into multi-user and advanced contexts. Discussions of workflows and role handoffs in the data science talk give you a realistic target for Hierarchical Task Analysis (MO3), since a collaborative goal must be decomposed across people as well as steps. The immersive analytics talk makes mental models and memory constraints concrete (MO1, MO2): when several collaborators hold different models of a shared space, and when immersive displays load attention and working memory, systematic coordination errors follow. All three presentations also model evaluation practice (MO4) by showing how researchers study real users in real settings and report findings to a professional audience, and the design implications and open questions they raise are the kind of input that should shape a low-to-mid fidelity prototype (MO5) before it is built.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.