Introduction to Human-Computer Interaction

Human-Computer Interaction (HCI) is the interdisciplinary field that studies how people interact with computing systems and how those systems can be designed to better serve human needs. It draws on computer science, cognitive psychology, design, sociology, and ergonomics. Where traditional software engineering asks "does the system work correctly?", HCI asks a harder and more consequential question: "does the system work well for the people who must use it?" A program can be algorithmically flawless and still fail completely if users cannot discover its features, misinterpret its feedback, or abandon it out of frustration.

This topic establishes the shared vocabulary and mental models you will use for the rest of the course. Before you open a design tool or write a line of interface code, you need a working theory of what makes an interface good, how to evaluate that claim with evidence rather than opinion, and where human-centered activities fit into the way software actually gets built.

What Is HCI?

At its heart, HCI examines the relationship between three elements that form a continuous loop: the user, the task, and the system. The user has goals and intentions shaped by their knowledge, experience, physical abilities, and context. The task is the concrete work that must be accomplished to reach those goals. The system is the technology that mediates the task. Design quality is not a property of any one element alone — it emerges from the fit among all three. A command-line interface is superb for an experienced system administrator batch-renaming 10,000 files, and catastrophic for a first-time user who wants to crop a photo. Same system, different user and task, radically different outcome.

A useful way to formalize this loop is Donald Norman's Seven Stages of Action, which traces one cycle of interaction:

Norman describes two places where this loop breaks. The gulf of execution is the gap between what a user wants to do and what the interface lets them express — the user cannot figure out how to do the thing. The gulf of evaluation is the gap between what the system did and what the user can perceive and understand — the user cannot tell whether it worked. A hidden gesture on a mobile app widens the gulf of execution; a "Save" button that produces no visible confirmation widens the gulf of evaluation. Most usability complaints, when analyzed carefully, reduce to one of these two gulfs.

Reducing cognitive load. Human working memory is extraordinarily limited — classically estimated at about seven items, and in practice closer to four chunks of novel information held for roughly 15–30 seconds without rehearsal. Every element an interface asks a user to remember, decode, or mentally calculate consumes a share of this scarce resource. Cognitive load theory distinguishes intrinsic load (the inherent difficulty of the task — filing taxes is genuinely complex), extraneous load (effort wasted on poor presentation — hunting for a mislabeled button), and germane load (effort that builds useful understanding). Good HCI attacks extraneous load aggressively.

• Recognition over recall. A visible menu of options is easier than remembering a command name. This is why a dropdown of saved payment cards beats "type your card number again."
• Chunking and progressive disclosure. A 40-field form split into four labeled steps of ten feels dramatically shorter than one wall of inputs, even though the total work is identical.
• Offloading computation to the machine. Showing "Total: $47.83 including tax and shipping" is better than making the user add three numbers. Auto-detecting card type from the first digits is better than a card-type dropdown.
• Sensible defaults. Pre-selecting the most common option converts a decision into an optional review.

The payoff is measurable: lower error rates, faster task completion, and higher satisfaction. Satisfaction is not a soft extra — it drives retention, word of mouth, willingness to adopt new features, and in enterprise settings, whether staff use the official tool or quietly build a spreadsheet workaround that fragments the organization's data.

HCI applies everywhere software meets people. The principles are platform-independent, even though their expression changes with context:

Consider a car's cruise control stalk, a hospital infusion pump, and a thermostat. None look like "software," yet each is a textbook HCI problem. Infusion pump design is a well-documented case where ambiguous number entry (a missing leading zero, a misplaced decimal) has caused fatal overdoses — proof that interaction design is sometimes a safety-critical discipline, not a cosmetic one.

Core HCI Principles

Usability is the degree to which a system lets specified users achieve specified goals effectively, efficiently, and satisfactorily in a specified context of use (the ISO 9241-11 definition). Notice how much of that definition is conditional: usability is never absolute, it is always relative to who, what, and where. Jakob Nielsen decomposes usability into five measurable components:

These components can conflict, which is why design involves trade-offs rather than universal right answers. A wizard that walks users through each step maximizes learnability but destroys efficiency for daily users; the usual resolution is to support both paths — a guided flow plus keyboard shortcuts and bulk actions. The System Usability Scale (SUS) is a widely used 10-item questionnaire producing a 0–100 score; roughly 68 is average, and above about 80 is considered good — useful because it lets you compare versions with a number instead of an argument.

Accessibility ensures systems are usable by people across the full range of human ability — including permanent disabilities (blindness, deafness, motor impairment, dyslexia), temporary conditions (a broken arm, an eye infection), and situational limits (bright sunlight on a screen, holding a baby, a noisy train). Microsoft's persona spectrum makes this vivid: a design that serves a person with one arm also serves a person with a temporary arm injury and a parent carrying a child. Accessibility is therefore not a niche accommodation; it expands the reachable audience for everyone.

The practical framework is the Web Content Accessibility Guidelines (WCAG), organized under the POUR acronym:

• Perceivable — information must be presentable in ways users can sense. Text alternatives for images, captions for video, and a minimum 4.5:1 contrast ratio for normal-size text at WCAG AA.
• Operable — all functionality must be available without requiring a mouse, with enough time to act and no content that triggers seizures. Every interactive control must be reachable and activatable by keyboard, with a visible focus indicator.
• Understandable — language should be clear, behavior predictable, and errors explained in plain terms with suggested fixes ("Password must contain at least one number," not "Invalid input").
• Robust — content must work reliably with assistive technologies such as screen readers, which depends on using semantic HTML and correct ARIA roles.

A concrete contrast: a form field labeled only by gray placeholder text disappears the moment the user types, fails contrast guidelines, and is often skipped by screen readers. A persistent <label> element correctly associated with its input solves all three problems at once — and incidentally makes the field easier for sighted mouse users too, because clicking the label focuses the input.

Feedback closes the interaction loop by confirming that an action registered and telling the user what happened. Without it, users repeat actions (double-charging a credit card), assume failure, or abandon the task. Feedback should be matched in weight to the significance of the event and should respect human timing thresholds:

Feedback also includes error messages, which should state what went wrong, why, and how to fix it. Compare:

Poor:  Error 0x80070057. Operation failed.

Better: We couldn't upload "quarterly-report.pdf" because it is 28 MB
        and the limit is 25 MB. Try compressing the file or sharing
        a link instead.  [Compress]  [Share a link]  [Cancel]

Related is visibility of system status more broadly: a "Saved 2 minutes ago" timestamp, an order-tracking stage indicator, or an unread badge all keep the user oriented without them having to ask.

Consistency lets users transfer knowledge rather than relearn it. It operates on several levels:

• Internal consistency — within your product, the same action looks and behaves the same way everywhere. If the primary action button is a filled blue rectangle on the right of a dialog, it should not become a green text link on the left three screens later.
• External consistency — conformance to platform and web conventions. A logo in the top-left returns to home; a magnifying glass means search; on iOS, a back swipe from the left edge goes back. Jakob's Law states that users spend most of their time on other sites, so they expect yours to work like those.
• Conceptual consistency — the mental model stays coherent. If "archive" means "hide from inbox but keep forever," it must never silently delete anything.

Design systems (Material Design, Apple's Human Interface Guidelines, or a team's own component library in Figma) operationalize consistency by making the consistent choice the easiest choice. The counterweight is Nielsen's companion heuristic: deviate from convention only when the deviation delivers a clear, demonstrable benefit — and then test it.

The User-Centered Design Process

User-Centered Design (UCD), codified in ISO 9241-210, is an iterative cycle with four repeating activities: understand the context of use, specify user requirements, produce design solutions, and evaluate against requirements. You loop until the evaluation shows the requirements are met. The defining commitment is that real users inform the design at every stage, rather than designers substituting their own intuitions.

Step 1 — Understanding users through research. The research phase answers who the users are, what they are actually trying to accomplish, and under what constraints. Common methods include:

• Semi-structured interviews — open questions about past behavior ("Walk me through the last time you booked a room") rather than hypotheticals ("Would you use a feature that…"), because people predict their own future behavior poorly.
• Contextual inquiry / observation — watching users work in their real environment. This surfaces workarounds people never think to mention: the sticky note of codes on the monitor, the parallel spreadsheet, the habit of printing a screen because the system can't export.
• Surveys — for breadth and quantification once you know which questions matter.
• Analytics and support-ticket review — evidence of where existing users drop off or ask for help.
• Competitive and heuristic review — establishing conventions and baseline expectations.

Research outputs are synthesized into shareable artifacts: personas (evidence-based archetypes, e.g. "Marcus, 42, warehouse supervisor, uses a rugged tablet with gloves on in a loud, cold environment; needs large targets and audible confirmation"), journey maps charting a user's steps, emotions, and pain points over time, and jobs-to-be-done statements framing the underlying goal ("When a shipment arrives short, I want to flag the discrepancy in under a minute so the driver isn't held up").

Step 2 — Prototyping and testing with representative users. A prototype is a deliberately incomplete artifact built to answer a question cheaply. Fidelity should match the question:

Testing means giving a participant a realistic task and observing silently. Give a scenario, not instructions: say "You need a waterproof jacket under $150 delivered by Friday — find one and buy it," never "Click the Filters button." Ask participants to think aloud. Record where they hesitate, where they look in the wrong place, and what they say they expect to happen. Nielsen's well-known finding is that roughly five participants per round uncover about 85% of the usability problems in a design — which means it is far better to run three small tests across three iterations than one large test at the end.

Step 3 — Iteration is structural, not optional. This is the point students most often underestimate. A first design is a hypothesis; testing is the experiment; the redesign is the result. Teams that treat testing as a one-time validation checkpoint tend to rationalize the findings away ("that participant was unusual") instead of acting on them. A healthy loop looks like: build a rough prototype in a day, test with five users, fix the top three problems, test again with five different users, and confirm the fixes worked without creating new problems. Each pass should narrow in scope — early rounds change the information architecture, later rounds change label wording and button placement.

Step 4 — Why this saves money. The cost of fixing a defect rises sharply the later it is discovered, because more downstream work depends on it. Changing a navigation structure on a paper sketch costs an eraser; changing it after launch costs rewritten code, migrated data, updated documentation, retrained support staff, and broken user habits.

The exact multipliers vary by study and context, but the shape of the curve is uncontested. UCD is best understood as a risk-reduction strategy: it buys cheap information early about expensive decisions.

HCI and the Software Development Lifecycle

HCI is not a separate phase bolted onto the front of a project; it threads through the entire lifecycle, with different methods dominant at different points.

Requirements gathering. Traditional requirements documents list system functions ("the system shall allow filtering by date"). HCI methods reframe requirements around human goals, which keeps teams from building technically correct features nobody needs. Personas give requirements a face, so debates shift from "I think users want X" to "Would Marcus, in gloves, in a loud warehouse, be able to do X?" User stories encode the same idea in a sentence the whole team can read:

As a warehouse supervisor,
I want to flag a short shipment from the receiving screen,
so that I can resolve the discrepancy before the driver leaves.

Acceptance criteria:
- Flagging takes no more than 3 taps from the receiving screen.
- Works with gloves: all targets at least 48 x 48 dp.
- A confirmation is both visible and audible.
- Reachable by keyboard and announced correctly by a screen reader.

Note that acceptance criteria can and should include usability and accessibility thresholds. If "three taps" and "48 dp targets" are not written down, they will be negotiated away under schedule pressure.

Design and development. During these phases, prototyping and usability testing run in parallel with implementation. On an agile team, a common pattern is dual-track development: a discovery track validates designs one or two sprints ahead, while a delivery track builds the already-validated work. Other HCI activities that fit here include heuristic evaluation (two or three evaluators independently inspecting the interface against Nielsen's ten heuristics — a fast, cheap check that complements but does not replace user testing), cognitive walkthroughs (stepping through a task asking at each step whether the user would know what to do and whether they'd see progress), and accessibility audits combining automated scanners with manual keyboard and screen-reader passes. Automated tools typically catch only about a third of real accessibility issues, so manual testing is essential.

Post-launch. Release is the start of the richest feedback stream, not the end of design. Sources include:

• Behavioral analytics — funnel drop-off rates, task success rates, time on task, rage clicks (rapid repeated clicking on an unresponsive element), and dead clicks on non-interactive items.
• Session replays and heatmaps — aggregate views of where attention and interaction actually land, which frequently contradict assumptions.
• Support tickets and app-store reviews — the most expensiveform of user feedback, because the user has already been frustrated enough to complain; clustering them by theme turns anecdotes into a prioritized backlog.
• In-product surveys — short, targeted prompts (a one-question SUS-style rating after a completed task) that connect sentiment to a specific moment.
• A/B testing — controlled comparison of two variants on live traffic. Powerful for settling local questions (button wording, form length) but blind to problems with the option you never tested, which is why it supplements rather than replaces qualitative research.

A healthy team closes the loop: analytics reveal what is happening (62% of users abandon the address step), qualitative testing reveals why (the postcode field silently rejects lowercase letters), and the fix is validated by watching the metric move. This is the mechanism by which an interface improves continuously instead of drifting.

Why HCI Matters for This Course

Everything above is only useful once you have practiced it on something real, which is the purpose of the course project. You will take an interface from research through prototype to a tested, revised design, and you will have to defend your decisions with evidence rather than taste. Expect the project to apply the full cycle in miniature: identify a user group and a genuine task, interview or observe a handful of people, build a low-fidelity prototype, test it with at least five representative participants, document the problems you found, and ship a revised version that demonstrably addresses them. The deliverable that matters most is not the prettiest screen — it is the trail of reasoning connecting a user's observed difficulty to a specific design change.

You will work in the same toolchain professionals use, which is deliberate. Figma is the industry standard for interface design because it is browser-based, real-time collaborative, and supports reusable components, shared styles, clickable prototypes, and inline commenting — so a developer, a designer, and a stakeholder can all be in the same file. Learning its component and auto-layout model teaches you consistency in a tangible way: when a button is a component, updating it once updates it everywhere, and inconsistency becomes the harder path. GitHub provides version control, branching, pull requests, and issue tracking. Even for design-heavy work, GitHub is where the record of decisions lives — issues capture usability findings, pull requests tie a code change to the problem it solves, and commit history makes your iteration visible. Being fluent in both tools is a baseline expectation in most product teams, and a portfolio repository with a clear README and commit trail is often the first thing an employer looks at.

Finally, the peer collaboration built into the course is not administrative convenience; it mirrors how real cross-functional teams operate. In industry, interfaces are produced by designers, developers, product managers, researchers, content writers, and accessibility specialists who must negotiate competing constraints — a visually elegant layout that is expensive to build, a fast-to-implement pattern that fails a WCAG check, a feature the business wants that research says users do not. Practicing those conversations now builds skills that are as valuable as any technique in this module:

• Giving and receiving critique on the work, not the person — "a user searching for refunds would scan this column first and miss the link" is actionable; "I don't like the layout" is not.
• Making decisions traceable — recording why a design changed so the team does not relitigate it in three weeks.
• Testing on someone outside your team — you cannot usability-test your own design, because you already know where everything is; peers provide fresh eyes and you provide the same for them.
• Negotiating trade-offs explicitly — naming which usability component (learnability vs. efficiency, for instance) you are optimizing for, and for whom.

Carry three ideas forward into the rest of the course. First, you are not your user — your fluency with the interface you designed is the single biggest source of bias in your judgment. Second, design is a claim that must be tested, and five people watching a prototype will teach you more than five hours of internal debate. Third, accessibility and usability are the same project, not competing ones; designing for the edges of human ability almost always produces a clearer, more robust experience for everyone in the middle.