The full course, mapped session by session.

SESSION 1 · LIVE IN-PERSON

Introduction to HCI

Objective: understand what HCI is, where it came from, and why it matters.

Overview of the course — logistics, deliverables, the five-planes throughline.

Overview of HCI — HCI sits at the intersection of computer science, cognitive psychology and design. It studies how people interact with systems and how to make that interaction effective (users reach their goal), efficient (with little wasted effort) and satisfying (they'd choose to do it again). To apply it, you treat the human, the machine and the dialogue between them as one system to be designed — not just the software.

Historical perspectives — The field's arc explains why interfaces look as they do today. Vannevar Bush's "Memex" (1945) imagined associative information; Engelbart's 1968 "Mother of All Demos" introduced the mouse, hypertext and windows; Xerox PARC and the Macintosh popularised the GUI (1980s); the web (1990s) and the smartphone (2007) each redefined interaction; and we are now in an AI-driven era of conversational and generative interfaces. Knowing this lineage helps you recognise which "new" patterns are genuinely new and which are old ideas re-skinned.

Importance of HCI in modern technology — When most products are technically capable, experience becomes the differentiator: people abandon a banking app that is secure but baffling. HCI is also an accessibility and ethics obligation — a confusing medical or voting interface can cause real harm. It is a discipline, not a coat of paint applied at the end.

Concrete example: the iPod's click-wheel won not because it stored more songs than rivals, but because "1,000 songs in your pocket" became findable with one thumb — an interaction win, not a storage win.

Common pitfall: assuming you are a representative user. You are an expert who built (or studies) the system; your fluency hides friction that real first-time users will hit.

Connects to → everything: this session's three pillars reappear as the five planes (Sessions 2–10), the research that grounds them (11–14), and the ethics that constrain them (25–26).

SESSION 2 · LIVE IN-PERSON

Developing a Strategy

Objective: define why a product exists before deciding what it does.

User experience and the web — The web turned software into a service people choose rather than tolerate: switching cost is one click, so experience drives adoption and retention. This is why UX went from niche to mainstream in two decades.

Introduction to Strategy — The bottom plane and the most abstract. Everything above it (scope, structure, skeleton, surface) inherits its assumptions, so a clear strategy is the cheapest insurance against expensive rework later.

Objectives — The product and business goals: what the organisation wants to achieve (e.g. "increase trial-to-paid conversion," "reduce support tickets"). Stated concretely enough to argue about.

Target audience — Who the users are, segmented by needs and context — not demographics for their own sake. "Time-pressed parents booking on mobile" is a useful segment; "ages 25–45" usually is not.

Success metrics — Measurable indicators (task success rate, time-on-task, retention, conversion, SUS score) that tell you whether the strategy is working. Agree them before building so you can actually tell later.

Concrete example: Google's homepage objective (search ad revenue) and the user need (find an answer fast) align so well that a deliberately empty page became iconic — strategy made visible in the design.

Common pitfall: the "vanity metric." Tracking page-views or sign-ups that look good but don't map to a real user need or business goal lets a failing product appear healthy.

Connects to → Scope (Sessions 4–5): strategy decides why; scope turns that into what. A requirement that serves no objective or user need is a candidate to cut.

SESSION 3 · LIVE IN-PERSON

Strategy Part 2 — Personas & Scenarios

Objective: represent target users as concrete personas grounded in research.

User personas and scenarios — A persona is a fictional-but-evidence-based archetype capturing one user type's goals, frustrations and context; a scenario narrates that persona accomplishing a task ("Maya, a nurse on a night shift, needs to log a patient observation in under 20 seconds"). To apply them, you design for the persona and test designs by walking them through scenarios.

Conducting user interviews and surveys — Qualitative interviews surface the "why" behind behaviour (open questions, follow "tell me about the last time you…"); surveys scale the "how many." Together they ground personas in reality rather than assumption. The classic mistake is asking what people want instead of observing what they do.

Concrete example: Alan Cooper introduced personas while designing an airline-IT tool — naming and grounding a user ("Kathy") stopped the team designing for themselves and ended circular feature debates.

Common pitfall: the "elastic user" — a persona so vague it can be stretched to justify any decision. If your persona would happily use every feature, it isn't doing its job.

Connects to → user research (Sessions 11–14), which supplies the evidence; and Scope (Sessions 4–5), where persona goals become the requirements you prioritise.

SESSION 4 · LIVE IN-PERSON

Scope — Requirement Analysis

Objective: decide what the product will and won't do.

Requirement analysis — Elicit, document and validate functional requirements (what the system does — "user can reset password") and content requirements (what it must contain — "a 200-word product description with one image"). Good requirements are testable: you can later check whether each was met.

Working out what you want to build — Scope is the bridge from abstract strategy to concrete specification. Ambiguity here ("make it user-friendly") becomes expensive rework later, because every plane above scope is built on it. Choosing a CMS or platform is itself a scoping decision — it bounds what's cheap vs. costly to build.

Concrete example: the difference between "users can share a document" and "users can generate a read-only link that expires in 7 days" is the difference between a vision and a scope — and the second one can actually be built and verified.

Common pitfall: gold-plating — specifying features nobody asked for because they're interesting to build. Every requirement should trace back to a strategy objective or persona goal, or it's a candidate to cut.

Connects to → Strategy (Session 2) above it and prioritisation (Session 5) right after; the requirements you write here become the MoSCoW list you triage next session.

SESSION 5 · LIVE IN-PERSON

Scope Part 2 — Prioritising Requirements

Objective: separate the essential from the nice-to-have.

Requirements analysis (cont.) — Refine and disambiguate requirements into testable statements, removing duplicates and resolving conflicts (two stakeholders often "must have" incompatible things).

Prioritising requirements — Techniques such as MoSCoW make trade-offs explicit and defensible. Related tools include value-vs-effort mapping (do high-value/low-effort first) and the Kano model (distinguish must-be features from delighters). The point is to decide deliberately, not by whoever argues loudest.

Concrete example: the original iPhone shipped with no copy-paste and no app store — deliberately a "Won't (yet)." Cutting beloved features to ship a coherent core is prioritisation working as intended.

Common pitfall: "Must-have" inflation. When everything is labelled Must, the list stops guiding decisions; force a real ranking and protect the "Won't" column.

Connects to → the group project (Sessions 19–24), where a tight MoSCoW list is what makes a one-semester prototype achievable; and back to Strategy, the tie-breaker when two requirements compete.

SESSION 6 · LIVE IN-PERSON

Skeleton — Metaphor & Familiarity

Objective: use existing mental models so interfaces feel instantly learnable.

How to build apps that don't frustrate users — Frustration usually comes from violated expectations: a button that doesn't look clickable, a gesture that does the opposite of every other app. Matching conventions removes that friction so users spend their attention on their goal, not on decoding your interface.

Using familiarity to our advantage — Metaphors (desktop, trash can, shopping cart) and platform conventions let users transfer knowledge instead of re-learning. A cart icon instantly communicates "items I intend to buy" because the physical metaphor does the explaining for you — no tutorial required.

Concrete example: when Snapchat radically redesigned its navigation in 2018, millions of users revolted and engagement dropped — a textbook violation of Jakob's Law on an interface people had deeply internalised.

Common pitfall: a broken or mixed metaphor — e.g. a "trash" that actually archives, or a save icon that no younger user recognises as a floppy disk. A metaphor that lies is worse than none.

Connects to → Nielsen's "consistency & standards" and "match between system and real world" heuristics (Session 13), and the whole Skeleton plane (Session 9) where these conventions get laid out as wireframes.

SESSION 7 · LIVE IN-PERSON

The Structure — Interaction Design

Objective: design how the system behaves and how it recovers from mistakes.

Interaction design — Defining the states a system can be in, the flows between them and the responses to each user action, so behaviour is predictable and forgiving. Think in terms of "what can the user do here, what happens, and how do they know?" — every action needs visible feedback (Nielsen #1, visibility of system status).

Error handling — Prevent errors where possible (disable invalid actions, use sensible defaults, confirm destructive ones); when they still happen, explain them in plain language, say what went wrong and how to fix it, and never blame the user. "Email already in use — sign in instead?" beats "Error 409."

Concrete example: form fields that validate inline ("password needs a number") prevent the error before submit, rather than rejecting the whole form afterward — prevention beating recovery.

Common pitfall: destructive actions with no confirmation or undo. A "Delete" that fires instantly with no way back turns a slip of the finger into lost work — violating "user control & freedom."

Connects to → Nielsen's heuristics (Session 13), which formalise this; and Information Design (Session 8), its partner half of the Structure plane.

SESSION 8 · LIVE IN-PERSON

Structure Part 2 — Information Design

Objective: organise content so users can find and understand it.

Information design — Presenting information so it communicates effectively and supports decisions: grouping, ordering, visual hierarchy and the Gestalt principles (proximity, similarity, common region) that make a screen read at a glance rather than as a wall of text.

Architecture diagrams — Sitemaps and flow diagrams that map organisational structure and navigation paths before any pixels are drawn. They let the team agree on "what links to what" cheaply, on paper.

Metadata descriptions — The labels, tags and attributes that make content findable and machine-organisable (categories, author, date, alt text). Good metadata powers search, filtering and accessibility alike.

Concrete example: IKEA's site uses users' task words ("store & organise," "sleep") rather than internal jargon ("modular shelving systems") — IA shaped by the user's mental model, not the org chart.

Common pitfall: mirroring your company's org chart in the navigation. Users don't know (or care) which department owns a page; they navigate by task and by their own vocabulary.

Connects to → the Skeleton plane (Session 9), where this structure becomes concrete navigation and wireframes; and Gestalt principles in the glossary, which govern how grouped information is perceived.

SESSION 9 · LIVE IN-PERSON

The Skeleton — Metaphor

Objective: shape layout and navigation so the experience feels enjoyable and intuitive.

Making apps that people enjoy — Delight comes first from effortlessness (the task just works), then from small, well-placed moments of personality — a satisfying confirmation animation, a friendly empty-state. Delight layered on friction is lipstick; remove the friction first.

Familiarity — Reuse interface patterns users already know (tabs, cards, pull-to-refresh) to minimise the learning curve, reducing the choices a user must make to reach a goal (a Hick's-Law concern — more options means slower decisions).

Using metaphor to aid the CX — Metaphors carry meaning from the physical world into the interface (folders, swipe-to-refresh, the "card" you can flick away). They let you skip explanation because the user already knows how the real-world object behaves.

Concrete example: a greyscale wireframe of a sign-up screen reveals that the "Skip" link competes with "Create account" for attention — a layout problem you'd never spot if you'd jumped straight to choosing brand colours.

Common pitfall: decorating the wireframe. Adding real colours, photos and copy too early turns layout reviews into colour debates and hides structural problems.

Connects to → Jakob's Law and metaphor (Session 6) feeding the layout, and prototyping fidelity (Session 10), which takes these wireframes toward the Surface plane.

SESSION 10 · LIVE IN-PERSON

Prototyping & Wireframing

Objective: externalise ideas as testable artefacts at the right fidelity.

Importance of prototyping & the product design lifecycle — Prototypes turn debates into experiments: instead of arguing whether a flow works, you build a rough version and watch someone use it. They fail cheaply and early, which is exactly the point — a problem caught in a paper sketch costs minutes, the same problem caught after launch costs a release.

Prototyping tools and techniques — Paper sketches, click-through tools (Figma, Marvel), and coded prototypes — chosen by the question being asked. To find broken flows, paper is enough; to test a tricky animation or real performance, you need higher fidelity. Use the cheapest tool that answers your question.

Low- vs. high-fidelity prototypes — Low-fi (paper, greyscale) tests structure, flow and concept and invites blunt feedback because it looks unfinished; high-fi tests look, feel and micro-interactions but risks people reacting to polish instead of substance.

Concrete example: the famous "paper-prototype usability test" — a facilitator swaps hand-drawn screens while a user "taps" them — routinely uncovers navigation flaws in an afternoon for the price of a marker and Post-its.

Common pitfall: the "too-pretty prototype" trap — a high-fi mockup makes testers (and stakeholders) reluctant to suggest big changes because it looks done, and makes them critique pixels instead of the concept.

Connects to → the Skeleton wireframes (Session 9) that prototypes build on, and the usability testing methods (Sessions 13–14) you'll use to evaluate them. This module's skills power the whole group project (Sessions 19–24).

SESSION 11 · LIVE IN-PERSON

User Research: Overview (1 of 2)

Objective: understand what UX research is and why it de-risks design.

What is and isn't UX research? — Structured, systematic inquiry into user behaviour and needs — not asking friends, not designer intuition, and not analytics read in isolation. Research means a question, a method chosen to answer it, and findings you can act on. "We think users want X" is a hypothesis; UX research is how you test it.

Importance in the product design lifecycle — Research isn't a single phase — it informs strategy (discovery), validates scope, checks designs before launch (formative testing) and measures them after (summative). De-risking decisions with cheap research early prevents costly wrong-product mistakes later.

Quantitative vs. qualitative methods — Qual explains why (interviews, usability tests — small N, rich, generates hypotheses); quant measures how much / how many (surveys, analytics, A/B tests — large N, generalisable, tests hypotheses). They answer different questions and are strongest together.

Concrete example: analytics show 60% abandon a form (the what) but can't say why; five moderated usability sessions reveal the password rule is hidden until submit (the why) — behavioral-quant plus qual, triangulated.

Common pitfall: leading or loaded questions ("How much did you love the new design?") that manufacture the answer you hoped for. Ask neutrally and, where possible, observe rather than ask.

Connects to → personas (Session 3), which this research grounds; and the concrete evaluation methods (Sessions 13–14) that sit inside this landscape.

SESSION 12 · LIVE IN-PERSON

User Research: Overview (2 of 2)

Objective: turn the research-methods landscape into a concrete plan.

What is and isn't UX research? (cont.) — Deepening insight vs. anecdote: one vivid complaint is a hypothesis, not a finding. A finding is a pattern you've seen recur across participants or confirmed with data.

Importance in the lifecycle (cont.) — Matching method to project phase, budget and risk: lightweight discovery interviews early, formative usability tests mid-design, summative metrics near launch. Higher-risk decisions justify heavier methods.

Quantitative vs. qualitative (cont.) — Combining methods so each covers the other's blind spot — qual generates the hypothesis, quant tests how widespread it is. Sample sizing matters: ~5 users per round for qual usability, far larger N for statistical claims.

Concrete example: a team planning a redesign runs 6 interviews (why), a 400-person survey (how many), and reviews 3 months of analytics (what actually happens) — agreement across all three gives them confidence to commit budget.

Common pitfall: over-generalising from a tiny qualitative sample ("3 of 5 users disliked it, so 60% of users will") — qual finds problems, it doesn't measure their prevalence.

Connects to → the methods landscape (Session 11) it builds on, and the research-instrument assignment you'll pilot in Sessions 13–14.

SESSION 13 · LIVE IN-PERSON

Usability Testing, UI Evaluation & Surveys (1 of 2)

Objective: evaluate an interface with expert and user-based methods.

Heuristic evaluation & expert reviews — A few evaluators independently inspect an interface against recognised principles (Nielsen's 10 heuristics), then merge findings — fast, cheap, no users required, ideal for catching obvious problems before you spend test sessions on them. NN/g recommends 3–5 evaluators because no single expert finds everything.

Usability tests & cognitive walkthroughs — In a usability test, real users attempt real tasks while thinking aloud and you watch where they struggle. A cognitive walkthrough is an expert method: you step through a task as a first-timer asking "will the user know what to do, and know it worked?" at each step.

User surveys — Scale attitudes and satisfaction across many users. Standardised instruments like the SUS (System Usability Scale, 10 items → 0–100 score) let you benchmark and compare over time.

Concrete example: evaluating a flight-booking site against #6 (recognition over recall), you flag that the return-date field expects you to remember your outbound date instead of showing it — a recall burden a small change removes.

Common pitfall: the facilitator leading the participant ("you'd tap the blue button here, right?"). The moment you hint, the test stops measuring the interface and starts measuring your prompting.

Connects to → error handling (Session 7) and consistency/familiarity (Session 6), which heuristics formalise; and the heuristics audit you'll deepen in Session 14.

SESSION 14 · LIVE IN-PERSON

Usability Testing, UI Evaluation & Surveys (2 of 2)

Objective: run a pilot evaluation and interpret the findings.

Heuristic evaluation & expert reviews (cont.) — Rating each finding for severity (frequency × impact × persistence) so the team fixes the painful, common problems first instead of bikeshedding cosmetic ones. A severity scale (0 = not a problem … 4 = usability catastrophe) makes triage defensible.

Usability tests & cognitive walkthroughs (cont.) — Moderating well: set tasks not instructions, stay quiet, count silently before prompting, and capture quotes and behaviours, not just opinions. The hardest skill is not helping when you watch someone struggle.

User surveys (cont.) — Writing neutral, single-barrelled questions; using validated scales where possible; and analysing closed responses quantitatively while coding open responses into themes.

Concrete example: after a pilot test, findings get a severity rating — "can't find logout (sev 2)" vs "checkout fails on mobile (sev 4)" — and the team fixes sev-4 first, a defensible priority backed by evidence.

Common pitfall: confirmation bias in analysis — hearing only the feedback that supports the design you already love. Pre-define tasks and success criteria so the data, not your hopes, decides.

Connects to → usability-driven iteration in the group project (Session 21), where these findings directly drive the next design revision.

SESSION 15 · LIVE IN-PERSON

Accessibility & Inclusive Design (1 of 2)

Objective: treat accessibility as a baseline requirement, not an extra.

Principles of accessibility — Content must be Perceivable, Operable, Understandable and Robust (WCAG's POUR): don't rely on colour alone, ensure sufficient contrast (4.5:1 for normal text at AA), make everything reachable by keyboard, write clear language, and use valid semantic markup. These are concrete, testable success criteria, not vibes.

Assistive technologies — Screen readers (VoiceOver, NVDA), magnifiers, switch access and voice control. They rely on the interface exposing semantics — real headings, button/link elements, form labels, alt text, ARIA roles — so a div styled as a button but lacking the role is invisible to them.

Inclusive design practices — Designing for the full range of human diversity, including situational ("solve for one, extend to many"). Microsoft's inclusive-design framing shows a one-armed person, a parent holding a baby, and someone with an arm injury all benefit from the same one-handed design.

Concrete example: the UK government's GOV.UK service manual mandates WCAG AA — and the resulting high-contrast, keyboard-friendly, plain-language pages are routinely cited as some of the easiest sites to use for everyone, not just disabled users.

Common pitfall: "accessibility overlay" widgets or last-minute audits bolted on at the end. Accessibility designed in from the wireframe stage is cheap; retrofitted onto a finished product it is expensive and incomplete.

Connects to → the curb-cut effect (Session 16), semantic structure from the Skeleton plane (Session 9), and the colour-not-information rule that recurs on the Surface plane.

SESSION 16 · LIVE IN-PERSON

Accessibility & Inclusive Design (2 of 2)

Objective: audit accessibility and design with assistive technology in mind.

Principles of accessibility (cont.) — Applying POUR to the hard cases: forms (labels, error association, no time-outs without warning), media (captions, transcripts, audio description) and navigation (skip links, logical focus order, visible focus rings).

Assistive technologies (cont.) — Hands-on testing: navigate your own product with the keyboard only (Tab/Enter/arrows), then with a screen reader running and the screen off. The gaps you hit are exactly what disabled users hit daily.

Inclusive design practices (cont.) — Writing accessible content (plain language, descriptive link text, meaningful alt text) and designing for situational and temporary impairments — glare outdoors, a broken arm, a noisy train — which affect everyone sometimes.

Concrete example: the OXO Good Grips peeler was designed for arthritic hands but became a best-seller because its fat, soft handle is more comfortable for everyone — the curb-cut effect in a physical product.

Common pitfall: conveying status by colour alone — a red/green dot, or a form field that only turns red on error. ~8% of men can't reliably tell red from green; add an icon or label.

Connects to → heuristic/usability evaluation (Sessions 13–14): an accessibility audit is a specialised expert review, and assistive-tech testing is usability testing for a wider population.

SESSION 17 · LIVE IN-PERSON

Mobile & Multi-Platform Design (1 of 2)

Objective: design one experience that adapts across devices.

Design considerations for mobile & multi-platform apps — Different input methods (touch vs. mouse vs. voice), screen sizes, sensors, and contexts of use: mobile users are often distracted, one-handed, on flaky networks and in bright sun. Designing for the worst case (the bus, not the desk) makes the best case effortless.

Responsive design — Fluid grids, flexible media and breakpoints so layout adapts to the viewport while content stays intact. A responsive page reflows from three columns on desktop to one on mobile without hiding or losing anything essential.

Mobile UX best practices — Touch targets large enough to hit reliably (~44–48px), primary actions in the thumb-reachable bottom zone, minimal typing (pickers, autofill, sensible keyboards), and fast loads on slow connections.

Concrete example: iOS moved Safari's address bar to the bottom precisely so it sits in the thumb zone — a direct application of Fitts's Law to one-handed phone use.

Common pitfall: hover-dependent interactions (tooltips, hover menus) that simply don't exist on touch, and tap targets crammed so close together that users hit the wrong one — both violations of Fitts's Law on mobile.

Connects to → the Skeleton plane (Session 9) at multiple sizes, accessibility (Sessions 15–16) where large targets and reflow also help motor- and vision-impaired users, and multimodal interaction (Session 18).

SESSION 18 · LIVE IN-PERSON

Mobile & Multi-Platform Design (2 of 2)

Objective: extend the design into multimodal and cross-device contexts.

Design considerations (cont.) — Continuity across devices — start a task on the phone, finish on the laptop — while respecting each platform's native conventions (iOS vs. Android vs. web) so the app feels at home everywhere rather than uncanny.

Responsive design (cont.) — Content-out breakpoints (let the content decide where it breaks, not arbitrary device widths) and performance budgets so the experience stays fast on a 3G connection, not just office Wi-Fi.

Mobile UX best practices (cont.) — Gestures with visible affordances, graceful offline states, and permissions/notifications requested in context and used sparingly — pestering users is the fastest route to an uninstall.

Concrete example: a smart speaker + phone combo — you ask the speaker to set a timer (voice, hands busy cooking) and glance at the phone for the remaining seconds (visual) — one task, two modalities, chosen by context.

Common pitfall: "voice-first" or "AR" applied as a gimmick where a tap would be faster and more reliable. A modality should be chosen because it fits the context, not because it's novel.

Connects to → accessibility (multimodality is giving users alternative ways in) and emerging tech / human-centered AI (Sessions 25–26), where conversational and ambient interfaces dominate.

SESSION 19 · LIVE IN-PERSON

Project Kickoff

Objective: form teams and frame the design problem.

Group project kickoff — define the problem space, target users and scope.

Designing & prototyping a user-centered project — plan the process across the five planes.

Regular project check-ins — establish the iteration/feedback cadence.

Common pitfall: falling in love with a solution before defining the problem (skipping the first diamond). Teams that start by naming features instead of the user's problem usually build the wrong thing well.

Connects to → the whole course: this is where Strategy, Scope, Structure, Skeleton, Surface, research and accessibility all get applied at once. Treat your earlier weekly assignments as raw material.

SESSION 20 · LIVE IN-PERSON

Project Work — Design & Prototype

Objective: produce a first working prototype.

Designing & prototyping (cont.) — translate research and IA into wireframes and a clickable prototype.

Regular check-ins — surface blockers early; align the team.

Common pitfall: polishing one screen to perfection before the end-to-end flow exists. Build a thin, complete walking skeleton first, then deepen — a broken flow with beautiful screens still fails the user.

Connects to → prototyping fidelity (Session 10) — keep this first prototype low enough fidelity that the team still feels free to change it.

SESSION 21 · LIVE IN-PERSON

Project Development & Refinement (1 of 2)

Objective: refine the prototype against feedback.

Project development & refinement — iterate on flows, IA and visual design based on test findings.

Regular check-ins — track progress against the plan.

Common pitfall: treating test findings as a wish-list to debate rather than a prioritised to-do. Tie each change to an observed problem; ignore "wouldn't it be cool if…" until the core works.

Connects to → usability testing & severity rating (Sessions 13–14), which feed this loop directly.

SESSION 22 · LIVE IN-PERSON

Project Development & Refinement (2 of 2)

Objective: reach a presentation-ready prototype.

Project development & refinement (cont.) — polish, fix accessibility issues, finalise the design system.

Regular check-ins — rehearse the narrative of the work.

Common pitfall: leaving the accessibility and rationale work to the final night. Run a quick WCAG-AA pass (contrast, keyboard, labels) and capture decisions as you make them — reconstructing "why" from memory at the end is painful and unconvincing.

Connects to → accessibility (Sessions 15–16) for the final audit, and the Week-24 assessment (15% delivery + 15% presentation).

SESSION 23 · LIVE IN-PERSON

Project Presentation (1 of 2)

Objective: present the project and defend its decisions.

Finalizing & presenting the group project — tell the story: problem → research → design → evidence.

Class discussion — peer critique and Q&A.

Common pitfall: a feature tour ("and then we added…") with no story. Stakeholders remember the user's problem and your evidence, not a list of screens.

Connects to → the design rationale (Session 22) you documented, and reflective practice (Session 24).

SESSION 24 · LIVE IN-PERSON

Project Presentation (2 of 2)

Objective: complete presentations and reflect across teams.

Finalizing & presenting (cont.) — remaining team presentations.

Class discussion — cross-team comparison and shared lessons.

Common pitfall: a blameful or vague retro. Focus on the process ("we tested too late") not people, and commit to specific changes, or the same mistakes recur.

Connects to → the reflective-practitioner thread that closes the course (Session 30) and the cross-team lessons in the case-study module (Sessions 27–28).

SESSION 25 · LIVE IN-PERSON

Future Trends in HCI (1 of 2)

Objective: examine where HCI is heading and the ethics it raises.

Emerging technologies (VR, GenAI) — Immersive (VR/AR) and generative (LLM) interfaces change how — and whether — users stay in control. VR raises presence, motion-sickness and consent issues; GenAI raises trust, hallucination and over-reliance issues. New interaction paradigms bring new failure modes.

Ethical considerations in HCI — Dark patterns, persuasive design, privacy, algorithmic bias, manipulation and the attention economy. As a CS/AI student you'll build these systems — this is where you decide what you'll refuse to build.

HCI research & innovation — How the field investigates novel interactions responsibly: informed consent, participant wellbeing, and ethics review for studies involving immersive or AI systems.

Concrete example: the US FTC fined companies over "negative option" cancellation traps, and the EU's GDPR/DSA restrict manipulative consent banners — ethics here is increasingly law, not just principle.

Common pitfall: optimising a single metric (engagement, conversion) without an ethical guardrail — the path by which well-meaning teams ship addictive feeds and manipulative funnels one A/B test at a time.

Connects to → Strategy & success metrics (Session 2) — a metric chosen without ethics is how dark patterns are born — and human-centered AI (Session 26).

SESSION 26 · LIVE IN-PERSON

Future Trends in HCI (2 of 2)

Objective: connect emerging tech to responsible innovation.

Emerging technologies (cont.) — Multimodal AI, conversational and ambient interfaces where the "UI" is increasingly invisible — language, voice and proactive suggestions instead of buttons. Designing these means designing behaviour and trust, not just screens.

Ethical considerations (cont.) — Accountability (who is responsible when the AI is wrong?), explainability (can the user understand and contest a decision?), and inclusion (does it work and behave fairly across groups?).

HCI research & innovation (cont.) — Turning research into responsible products: designing for appropriate trust — neither blind reliance nor reflexive rejection — and surfacing model uncertainty.

Concrete example: Microsoft's Human-AI Interaction (HAX) guidelines — "make clear what the system can do," "support efficient correction," "convey uncertainty" — are Nielsen-style heuristics adapted for AI interfaces.

Common pitfall: over-trust by design — a confident, fluent AI that hides its uncertainty leads users to accept wrong answers. Calibrated confidence and easy correction are usability requirements, not nice-to-haves.

Connects to → your AI/ML coursework in the degree, the heuristics (Session 13) that HAX guidelines extend, and accessibility/inclusion (Module 6).

SESSION 27 · LIVE IN-PERSON

HCI Industry Case Studies (1 of 2)

Objective: learn from real successes and failures in industry.

Working with cross-functional teams — Designers, engineers, PMs and researchers collaborating through shared language and artefacts (personas, journey maps, design systems). The designer rarely has authority, so influence comes from evidence and communication.

Analyzing real-world HCI successes & failures — Reverse-engineering what made famous products usable — or notoriously not — and naming the principle behind each outcome rather than just admiring or mocking it.

Guest speakers from industry — Practitioner perspectives on how UX actually works inside organisations (TBD).

Concrete example: the 2018 Hawaii false-missile alert — an operator picked the wrong item from a confusing dropdown that mixed "test" and "real" alerts — is a canonical HCI failure showing how a bad interface can have life-or-death consequences.

Common pitfall: hindsight storytelling — calling a success "obvious" or a failure "stupid." Good case analysis names the specific heuristic, law or process gap involved, so the lesson transfers.

Connects to → every principle in the course (heuristics, Fitts's law, error handling, accessibility) — case studies are where you see them succeed and fail in the wild.

SESSION 28 · LIVE IN-PERSON

HCI Industry Case Studies (2 of 2)

Objective: present and discuss case-study analyses.

Working with cross-functional teams (cont.) — Handling conflict and aligning incentives: when engineering optimises for ship-speed and product for revenue, the designer reframes the debate around shared user evidence rather than winning on authority.

Analyzing successes & failures (cont.) — Student presentations and discussion — practising the evidence-based critique you'll use professionally.

Guest speakers (cont.) — Practitioner Q&A on real organisational dynamics (TBD).

Concrete example: Spotify's Discover Weekly is a frequently-cited success — personalisation that respects user agency — exactly the contrast case to dark-pattern personalisation from Session 25.

Common pitfall: presenting opinion dressed as analysis. Without a cited heuristic, metric or documented outcome, a case-study "analysis" is just a review.

Connects to → design rationale (Session 22) and the final exam, which rewards exactly this evidence-based reasoning.

SESSION 29 · LIVE IN-PERSON

Course Wrap-Up & Exam Prep

Objective: consolidate the whole syllabus.

Review of key concepts & takeaways — Re-walk the five planes plus the cross-cutting threads — research, accessibility and ethics — and connect each named law/principle (Nielsen, Fitts, Hick, Jakob, Gestalt, POUR, Double Diamond) to where it's applied.

Prepare for the final exam — Clarify scope and format; practise applying principles to short scenarios, since the exam rewards application and synthesis over rote recall.

Common pitfall: memorising definitions without the connections. The exam asks you to apply principles to a described interface — practise diagnosis, not flashcards.

Connects to → the glossary below (your revision checklist) and every prior module.

SESSION 30 · LIVE IN-PERSON

Final Exam & Course Retro

Objective: demonstrate mastery and reflect on the journey.

Final exam on course material — Comprehensive, covering all modules (30% of the final grade). Expect to define vocabulary, place topics on the five planes, and apply named principles to short interface scenarios.

Course retro — Look back on lessons learned and your growth as an HCI practitioner — and look forward to where these skills lead (UX, research, front-end, design systems, responsible AI).

Connects to → the reflective retro from the project (Session 24) and the career paths named in Learning Objective 10 — this is the bridge from course to profession.