Human-Computer Interaction

HCI is applied cognitive science. To design well, you must understand the architecture of the human mind that users bring to your interface.

Attention is a bottleneck. Humans have selective attention — we process a tiny sliver of available visual information. The spotlight model says attention is like a flashlight: what it illuminates is processed in detail; everything else is suppressed. The implication for design is brutal: important information placed outside the attentional spotlight will be systematically missed, no matter how visible it seems to the designer who already knows where to look. Change blindness experiments (Simons & Chabris, 1999) show that observers miss large, obvious changes to scenes when attention is directed elsewhere. Error messages placed in corners, status indicators outside the action area — these are attentional design failures.

Working memory is the workspace of conscious thought, and it is small. George Miller's 1956 paper established the famous '7 ± 2' limit on the number of chunks that can be held in working memory simultaneously; more recent work by Cowan (2001) revises this to approximately 4 ± 1. A 'chunk' is a meaningful unit: '8675309' is seven digits (hard), but if you know it as 'Jenny's number' it is one chunk (easy). The design implication: never require a user to hold more than 3-4 items in mind simultaneously. Long multi-step wizards without progress indicators, forms that require copying information from a previous page, command-line tools with cryptic syntax that must be memorized — all of these exceed working memory capacity and cause errors.

Long-term memory and mental models are what users bring to your interface from prior experience. Users build mental models — simplified internal representations of how a system works — by analogy with things they already know. The desktop metaphor (files, folders, trash) was successful precisely because it mapped onto a mental model users already had from physical offices. When an interface violates a user's mental model, they make systematic, predictable errors. The designer's job is either to match the existing mental model or to build a new one deliberately and consistently.

Gestalt principles describe how the visual system groups percepts. Proximity (nearby elements are grouped), similarity (similar-looking elements are grouped), closure (incomplete figures are completed), and continuity (smooth curves are followed) all operate preattentively — below conscious control. These principles explain why proper visual grouping reduces cognitive load: when visual structure matches logical structure, the user's perceptual system does organizational work for free.

# Demonstrating chunking in a UI context (Python pseudocode)
# Bad: require user to remember and re-enter a long reference number
reference_number = "TXN20240608-9871234-USD-WIRE"
print(f"Please note your reference number: {reference_number}")
# ... 4 screens later ...
user_input = input("Enter your reference number to confirm: ")
# Users will make errors here — the string exceeds working memory

# Good: chunk the number visually AND persist it on-screen
def format_reference(ref: str) -> str:
    # TXN-20240608-9871234 is 3 meaningful chunks
    parts = ref.split("-")
    return " — ".join(parts[:3])  # visual chunking

# Or better: don't require re-entry at all (recognition > recall)
confirm = input("Confirm transfer of $500 to Alice? [Y/N]: ")

The vocabulary for talking precisely about what an interface communicates was sharpened by Don Norman in 'The Design of Everyday Things' (1988, revised 2013). These concepts are now standard across HCI research and practice.

Affordance (originally from J.J. Gibson's ecological psychology) describes a relationship between an object and an agent: a door handle affords grasping to a human hand. Norman introduced the design-relevant concept of a perceived affordance — what the object communicates it can do, regardless of what it actually can do. A flat glass door panel affords pushing; a vertical bar affords pulling. When the perceived affordance matches the actual affordance, users act correctly without instructions. When they mismatch, you get the universal experience of pushing a pull door.

Signifiers are Norman's refinement: they are the perceptible signals that communicate affordances. The vertical bar is a signifier that signals the pull affordance. Good design makes signifiers clear, accurate, and self-evident. Bad design either omits signifiers (the unmarked flat plate on a bidirectional door) or provides misleading ones.

Mapping is the relationship between controls and their effects. Natural mappings feel obvious — a steering wheel turns in the same direction as the car's nose. Unnatural mappings require learned, arbitrary associations. Example: a row of four stovetop burners controlled by four knobs in a row — but which knob controls which burner? Spatial correspondence (the left knob controls the left burner) is a natural mapping; a grid arrangement where left-to-right controls bottom-left, top-left, bottom-right, top-right is an unnatural mapping that causes systematic errors even in experienced users.

Constraints limit possible actions to prevent errors. Physical constraints (a USB plug that only fits one way), semantic constraints (you can only 'undo' actions that have been done), logical constraints (a radio button group that only permits one selection), and cultural constraints (red means stop in traffic contexts) all work by reducing the action space the user must navigate. Good design uses constraints generously.

Feedback closes the action-perception loop. When a user clicks a button, they need to know: Did it register? Is it processing? Did it succeed? Absence of feedback forces users to repeat actions, creating double-submissions, or to infer failure when the system is merely slow. The GOMS model (Goals, Operators, Methods, Selection rules) and the Norman Action Cycle both make explicit that feedback is not cosmetic — it is the mechanism by which users learn and correct their behavior.

// Bad mapping: button click with no feedback
document.getElementById('submit-btn').addEventListener('click', async () => {
  await submitForm(); // user has no idea if this registered
});

// Good: signify state, provide feedback at each stage
const btn = document.getElementById('submit-btn');
btn.addEventListener('click', async () => {
  // 1. Immediate visual feedback: signify 'action received'
  btn.textContent = 'Submitting...';
  btn.disabled = true;          // constraint: prevent double-submit
  btn.setAttribute('aria-busy', 'true');

  try {
    await submitForm();
    // 2. Outcome feedback: signify success
    btn.textContent = 'Submitted!';
    btn.classList.add('success');
  } catch (err) {
    // 3. Error feedback: signify failure with recovery path
    btn.textContent = 'Failed — click to retry';
    btn.disabled = false;
    btn.classList.add('error');
  }
});

HCI has a physics — a mathematical law that predicts with high accuracy how long it takes a human to move a pointing device to a target. Fitts's Law (1954) is:

MT = a + b · log₂(2D / W)

where MT is movement time, D is the distance to the target, W is the width (size) of the target, and a, b are empirically fitted constants for the device and user population. The argument of the logarithm is the index of difficulty (ID) in bits. This is not just a curve-fit — Fitts derived it from information theory, treating motor movement as an information channel with a fixed capacity.

The design implications are immediate and quantitative:

• Make targets big. Doubling target width reduces ID by 1 bit, saving ~100ms on typical devices.
• Bring targets close. The start position of the cursor matters; the most accessible targets are at the current cursor position (zero distance, ID = 0 — this is why right-click context menus are faster than menu bars).
• The corners and edges of screens are infinitely large targets in one axis (you cannot overshoot a screen edge). Placing important controls — like the macOS Apple menu — in the corner is a Fitts-optimal choice.
• Tiny click targets are objectively slower and more error-prone. A 44×44px touch target (Apple's HIG recommendation) is not arbitrary; it is calibrated to finger width and Fitts's predictions for touch.

Fitts's Law is one of the few quantitative laws in HCI. Its existence demonstrates that user performance is not subjective or unmeasurable — it can be predicted, tested, and optimized.

import math

def fitts_movement_time(distance_px: float, width_px: float,
                        a_ms: float = 50, b_ms: float = 150) -> float:
    """
    Predict pointing movement time using Fitts's Law.
    a, b are device/user constants (typical mouse values).
    Returns predicted time in milliseconds.
    """
    if width_px <= 0:
        raise ValueError("Target width must be positive")
    index_of_difficulty = math.log2(2 * distance_px / width_px)
    return a_ms + b_ms * index_of_difficulty

# Scenario: menu item 400px away
print(fitts_movement_time(400, 20))   # small target: ~521ms
print(fitts_movement_time(400, 80))   # large target: ~371ms
print(fitts_movement_time(400, 400))  # target = distance: ~200ms

# Screen-edge effect: effectively infinite width in one dimension
# Model as very large W (e.g., screen height for top menu bar)
print(fitts_movement_time(400, 1080)) # menu bar: ~103ms

Jakob Nielsen and Rolf Molich (1990, refined 1994) distilled a set of ten heuristics — empirically derived rules of thumb — that cover the vast majority of usability problems found in practice. These are not aesthetic opinions; they are generalizations from thousands of usability evaluations. Learning to apply them lets you perform heuristic evaluation: a structured expert walkthrough of an interface that identifies problems without requiring user studies.

1. Visibility of system status. Always keep the user informed about what is going on through appropriate feedback within reasonable time. (Loading spinners, progress bars, confirmation messages.)

2. Match between system and the real world. The system should speak the users' language, using words, phrases, and concepts familiar to the user, rather than system-oriented terms. (Use 'Save' not 'Serialize to persistent storage'.)

3. User control and freedom. Users often choose system functions by mistake and need a clearly marked 'emergency exit' — undo/redo, cancel, back. (Every action should be reversible where possible.)

4. Consistency and standards. Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. (Ctrl+Z for undo everywhere, not just sometimes.)

5. Error prevention. Even better than good error messages is careful design that prevents problems from occurring in the first place. (Confirm dialogs before destructive actions; disable submit until required fields are complete.)

6. Recognition over recall. Minimize the user's memory load by making objects, actions, and options visible. (Dropdown menus externalize options; command-line interfaces require recall.)

7. Flexibility and efficiency of use. Accelerators — unseen by the novice user — may speed up interaction for the expert. Allow users to tailor frequent actions. (Keyboard shortcuts alongside menu items.)

8. Aesthetic and minimalist design. Dialogues should not contain irrelevant or rarely needed information. Every extra unit of information competes with relevant information and diminishes its relative visibility.

9. Help users recognize, diagnose, and recover from errors. Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution. ('File not found' is worse than 'Could not open report.pdf — check that the file exists in /Documents'.)

10. Help and documentation. Even though it is better if the system can be used without documentation, it may be necessary to provide help. Such information should be easy to search, focused on the user's task, and not too large.

Heuristic evaluation with 3-5 trained evaluators typically surfaces 75% of major usability problems — making it one of the most cost-effective evaluation methods available.

User-Centered Design (UCD) — formalized by Norman and Draper (1986) and standardized in ISO 9241-210 — is a design philosophy and process that places the needs, goals, and limitations of end users at the center of each stage of design and development.

The core loop has four phases:

1. Understand context of use. Who are the users? What tasks do they perform? In what environment? Methods include contextual inquiry (observing users in their actual environment), interviews, surveys, and personas (archetypal user descriptions that synthesize research findings into a memorable, concrete character). A persona is not a stereotype — it is a hypothesis about a user segment, grounded in research data.

2. Specify requirements. Translate observed user needs into concrete design requirements. User stories ('As a nurse, I need to see all current medications at a glance so that I can prevent interactions') are one format. Task analysis — breaking down what users do into hierarchical task structures — is another.

3. Produce design solutions. Start rough and cheap. Paper prototypes (hand-drawn sketches) are appropriate for early ideation; they are fast to make and modify, and their roughness encourages feedback (users don't hesitate to criticize a napkin sketch). Wireframes add structure without visual polish. High-fidelity mockups and interactive prototypes come later, after the core interaction model is validated.

4. Evaluate against requirements. Test with real users. The evaluation drives the next iteration. Studies show that five participants are sufficient to expose ~85% of usability problems — a result from Nielsen (1993) based on the binomial probability model. Each additional participant reveals fewer new problems; the optimal cost-benefit point is at n=5.

The key insight is that the loop must be traversed multiple times, with fidelity increasing as understanding deepens. Committing to a polished design before testing the core interaction model is the most expensive mistake in interface design — the cost of change grows exponentially as development progresses.

# Persona representation (simplified data model)
from dataclasses import dataclass, field
from typing import List

@dataclass
class Persona:
    name: str
    age: int
    role: str
    goals: List[str]      # What they are trying to accomplish
    frustrations: List[str]  # Pain points with current solutions
    tech_comfort: str     # 'novice' | 'intermediate' | 'expert'
    quote: str            # A synthesized representative quote

nurse_alice = Persona(
    name="Alice",
    age=34,
    role="ICU Charge Nurse",
    goals=[
        "See all patient vitals at a glance during rounds",
        "Quickly flag abnormal values without navigating menus"
    ],
    frustrations=[
        "Current EHR requires 4 clicks to reach medication list",
        "Alert fatigue: too many low-priority notifications"
    ],
    tech_comfort="intermediate",
    quote="I need the information to come to me — I can't be hunting for it."
)

Prototyping is the practice of building approximate representations of a design to test ideas before full implementation. The central principle, due to Fred Brooks ('Plan to throw one away'), is that you will build the wrong system on your first attempt — prototypes make that mistake cheap.

The fidelity spectrum runs from low to high:

Paper prototypes are hand-drawn interfaces on paper. They are the fastest, cheapest form of prototype. In a paper prototype test, one team member plays the 'computer' — swapping paper panels, writing outputs by hand — while a user attempts real tasks. The roughness is a feature: it prevents users from commenting on color and font, and keeps focus on interaction structure.

Wireframes are schematic diagrams that show layout, hierarchy, and information architecture without visual design. Tools like Balsamiq or Figma in wireframe mode produce wireframes. They answer: 'Is the information in the right place? Does the navigation model make sense?'

Interactive prototypes simulate behavior — clickable mockups built in Figma, InVision, or code. They enable realistic usability testing of the interaction model without implementing backend logic. For a web application, a Figma prototype linked to realistic dummy data can test the entire user journey in a day, not a sprint.

Wizard of Oz prototyping deserves special mention: the prototype appears to function automatically but is secretly controlled by a human operator. This is invaluable for testing AI or conversational interfaces before any NLP is built — the 'Wizard' provides ideal responses, letting you test whether the interaction model works before investing in a model.

The choice of fidelity should track the stage of the design process and the specific question being asked. Early in design, when exploring 'should we build this at all?' — paper. When validating 'does this navigation make sense?' — wireframe. When testing 'does this microinteraction feel right?' — high-fidelity interactive prototype.

# Wizard of Oz simulation for a chatbot interface
# The 'Wizard' (human) responds via a shared channel;
# the user sees responses as if they came from an AI.

import asyncio

async def wizard_of_oz_chat():
    """Simulates a conversational AI by routing user messages
    to a human operator for manual responses.
    
    In practice: operator terminal + user terminal share a queue.
    This captures interaction logs for later analysis.
    """
    log = []
    print("[USER TERMINAL] Type your messages below.")
    while True:
        user_msg = input("You: ")
        log.append({"role": "user", "content": user_msg})
        # In a real WoZ setup, this message appears on the Wizard's screen;
        # the Wizard types a response that appears here.
        wizard_response = input("[WIZARD CONSOLE] Respond as AI: ")
        print(f"Assistant: {wizard_response}")
        log.append({"role": "assistant", "content": wizard_response})
        if user_msg.lower() in ("quit", "exit"):
            break
    return log

Usability testing is the empirical evaluation of an interface by observing representative users attempting realistic tasks. Unlike focus groups (which produce opinions about design), usability tests produce behavioral evidence of what users can and cannot do.

Setting up a usability test: Recruit participants matching your target persona (5 per segment is the Nielsen heuristic). Define concrete, realistic tasks — not 'explore the app' but 'find the return policy for an item you bought three weeks ago'. Use a think-aloud protocol: ask participants to verbalize their thoughts continuously while working. This externalizes the user's mental model and reveals why they made choices, not just what they did.

Metrics: Usability has three primary dimensions (ISO 9241):

• Effectiveness: Can users complete the task? (% task completion rate)
• Efficiency: How much effort is required? (time on task, error count, number of clicks)
• Satisfaction: How do users feel about the experience? (Likert-scale questionnaires: SUS, UMUX)

The System Usability Scale (SUS) is a 10-item questionnaire with alternating positive/negative items, scored 0-100. A SUS score above 68 is above average; above 80 is excellent. It is quick, validated, and comparable across studies.

Remote vs. lab testing: Lab testing (users in a controlled room, eye-tracking cameras) gives maximum data density. Remote unmoderated testing (tools like UserTesting.com run tasks asynchronously) gives larger sample sizes and more ecological validity at lower cost. The right choice depends on the research question.

Quantitative methods: For comparing two designs (A/B testing), you need enough statistical power to detect real differences. With typical effect sizes in UX, you need n > 30 per condition for reliable between-subjects comparisons. Beware of the 'false positive' trap in A/B testing: with many simultaneous tests, familywise error rates inflate — use Bonferroni correction or Bayesian methods.

Qualitative methods: Think-aloud data, post-task interviews, and affinity diagramming (clustering observations by theme) complement quantitative metrics. The goal is to identify why problems occur, not just that they occur.

import statistics

def sus_score(responses: list[int]) -> float:
    """
    Calculate System Usability Scale score from 10 Likert responses (1-5).
    Odd-indexed items (1,3,5,7,9) are positively worded: score = response - 1
    Even-indexed items (2,4,6,8,10) are negatively worded: score = 5 - response
    Final score = sum * 2.5 (scales 0-40 to 0-100)
    """
    if len(responses) != 10:
        raise ValueError("SUS requires exactly 10 responses")
    total = 0
    for i, r in enumerate(responses):
        if i % 2 == 0:   # odd item (0-indexed even)
            total += r - 1
        else:            # even item (0-indexed odd)
            total += 5 - r
    return total * 2.5

# Example: a participant's responses to the 10 SUS items
participant_responses = [4, 2, 4, 1, 4, 2, 4, 1, 5, 1]
print(f"SUS score: {sus_score(participant_responses)}")  # Should be 87.5

# Average across participants
all_scores = [87.5, 72.5, 80.0, 65.0, 77.5]
print(f"Mean SUS: {statistics.mean(all_scores):.1f}")    # 76.5
print(f"Grade: {'Excellent' if statistics.mean(all_scores) > 80 else 'Good' if statistics.mean(all_scores) > 68 else 'Below average'}")

Information Architecture (IA) is the structural design of shared information environments — how content is organized, labeled, and navigated. Poor IA is one of the most common sources of usability failure on information-dense systems like websites, dashboards, and enterprise software.

Card sorting is the primary method for discovering a users' mental model of how information should be categorized. Participants sort index cards (each labeled with a piece of content) into groups that feel natural to them, then name the groups. Open card sorts reveal natural categories; closed card sorts test a proposed taxonomy. Clustering the sort results across participants produces a dendrogram that directly informs IA design.

Tree testing is the complementary evaluation method: given a proposed site structure (no visual design, just a text hierarchy), users attempt to find specific items. Success rates and wrong-turn data reveal where the labeling or hierarchy is broken.

Navigation patterns have been empirically studied. The 'hub and spoke' model (apps that launch mini-experiences from a home screen, with no cross-spoke navigation) suits shallow task-focused apps. Hierarchical navigation (drill-down menus) suits deep content. Flat navigation (tab bars with 3-5 top-level sections) suits applications with a small number of major modes.

The paradox of choice (Schwartz, 2004; psychologically grounded in Hick's Law) says that reaction time to choose among alternatives grows as: RT = a + b · log₂(n+1) where n is the number of equal-probability alternatives. More choices = slower decisions = more errors and less satisfaction. This is why Amazon's navigation has a limited number of primary categories despite having millions of products: the categories compress choice space.

Labels deserve careful attention. Navigation labels should be domain-language terms that are instantly meaningful to the target user, not internal product names, technical jargon, or creative marketing terms. 'Account' is better than 'My Space'; 'Return an Item' is better than 'Post-Purchase Engagement'.

Accessibility is the practice of designing interfaces that can be used by people with disabilities — visual, auditory, motor, or cognitive. Inclusive design is the broader principle: designing for the full range of human diversity, including age, culture, and context of use.

The Web Content Accessibility Guidelines (WCAG 2.1), published by W3C, organize accessibility requirements into four principles, known as POUR:

• Perceivable: Information must be presentable to users in ways they can perceive. (Alt text for images, captions for video, sufficient color contrast — minimum 4.5:1 for normal text.)
• Operable: UI components and navigation must be operable. (All functionality available from keyboard, no keyboard traps, timing is adjustable.)
• Understandable: Information and UI operation must be understandable. (Predictable behavior, input assistance, error identification.)
• Robust: Content must be robust enough to be interpreted reliably by assistive technologies. (Valid HTML, ARIA roles properly used.)

ARIA (Accessible Rich Internet Applications) is a W3C specification for adding semantic meaning to interactive components that HTML alone doesn't express. A custom dropdown built from <div> elements needs role="combobox", aria-expanded, and aria-activedescendant to be usable by screen readers.

The curb-cut effect is a sociological observation that accessibility features designed for people with disabilities are widely used by people without disabilities — curb cuts benefit wheelchair users, cyclists, parents with strollers, and delivery workers equally. Closed captions were designed for deaf users; they are widely used in noisy offices, language learning, and by people who prefer to read. Accessible design is better design for everyone.

From an engineering standpoint, accessibility is significantly cheaper to build in from the start than to retrofit. Screen reader testing, keyboard navigation testing, and color contrast auditing should be part of the definition of 'done' for every component.

<!-- Bad: custom button with no accessibility -->
<div onclick="handleClick()" style="cursor:pointer">
  Submit
</div>
<!-- Not focusable, not announced as button, no keyboard support -->

<!-- Good: semantic HTML with ARIA enhancements -->
<button
  type="submit"
  aria-label="Submit payment form"
  aria-busy="false"
  id="submit-btn">
  Submit
</button>

<!-- Good: custom interactive component with full ARIA -->
<div
  role="combobox"
  aria-expanded="false"
  aria-haspopup="listbox"
  aria-labelledby="country-label"
  tabindex="0"
  id="country-select">
  Select country
</div>
<ul role="listbox" aria-label="Countries" id="country-list" hidden>
  <li role="option" aria-selected="false">Australia</li>
  <li role="option" aria-selected="false">Brazil</li>
  <li role="option" aria-selected="false">Canada</li>
</ul>

Don Norman's Action Cycle provides a framework for analyzing where interface failures occur. It describes how a user moves from a goal to an action and from an action to understanding the result.

The cycle has seven stages:

1. Forming a goal — the user decides what they want to achieve
2. Forming an intention — the user decides to do something
3. Specifying the action — the user decides the exact action
4. Executing the action — the user physically performs it
5. Perceiving the state of the world — the user observes the outcome
6. Interpreting the state — the user makes sense of what they see
7. Evaluating the outcome — the user compares outcome to goal

The Gulf of Execution is the gap between what a user wants to do and the actions the system makes available. 'I want to move this email to a folder' — but where is that affordance? How do I drag? Right-click? There's a keyboard shortcut? The gulf of execution is wide when the interface's action vocabulary doesn't match the user's mental model of available actions.

The Gulf of Evaluation is the gap between the actual state of the system and how that state is represented to the user. 'Did my file save? Is the upload done? Did my message send?' A spinning cursor with no progress information leaves a wide gulf of evaluation. The user cannot tell whether the system is working, stuck, or done.

Both gulfs are design defects, not user failures. Narrowing the gulf of execution means exposing the right actions at the right time, with clear signifiers. Narrowing the gulf of evaluation means providing accurate, timely, informative feedback that maps the system's internal state onto something meaningful to the user.

# Gulfs illustrated through a command-line file rename

# Wide Gulf of Execution: user's goal is 'rename a file'
# but the action vocabulary is 'mv' — not obvious!
# $ mv old_name.txt new_name.txt
# The user must know 'mv' means both move AND rename.

# Narrow Gulf of Execution: expose the goal-aligned action
# $ rename old_name.txt new_name.txt  <- clear verb

# Wide Gulf of Evaluation:
# $ cp large_file.iso /backup/
# (cursor hangs for 30 seconds with no output — did it work?)

# Narrow Gulf of Evaluation: provide feedback
# $ rsync --progress large_file.iso /backup/
# large_file.iso
#  1,073,741,824 100%   98.36MB/s  0:00:10 (xfr#1, to-chk=0/1)
# -> user can perceive, interpret, and evaluate progress in real time