What Is Human-Computer Interaction?

Almost every rule a product designer applies without thinking came out of a lab. Minimum tap-target sizes trace to a 1954 motor-control experiment. The reason your app shows a spinner instead of freezing comes from research on how long a person will wait before assuming a system is broken. Even the desktop metaphor — a screen full of files and folders and a trash can to drag them into — was an argued-over research proposal before it was a default.

That lab is human-computer interaction, and the distance between the field and the practice has grown wide enough that most people building interfaces have never read a paper from it. They inherit its conclusions as folklore instead, which works until the folklore is wrong.

What is human-computer interaction?

Human-computer interaction is the study of how people use computing systems, and the design of systems around what that study finds. The definition that has held up since ACM's SIGCHI curriculum group wrote it in 1992 puts three obligations together: the design, evaluation, and implementation of interactive computing systems for human use, plus the study of the phenomena surrounding them (overview of the discipline).

Evaluation sits in the middle of that definition, and it's the load-bearing word. A claim about an interface is expected to arrive with a method: a controlled comparison, or a task-completion measurement against a baseline. The field's characteristic output isn't an opinion about a screen. It's a model that predicts something about behavior before the screen exists.

Ergonomics studies the physical fit between people and machines. Cognitive psychology studies the mind with no particular obligation to build anything. HCI borrows from both and is accountable to a working system at the end.

Where the field came from

The prehistory is usually dated to 1945, when Vannevar Bush described the memex — a desk-sized machine for storing and cross-linking a person's documents by association rather than by index — in "As We May Think". No such machine was built. The idea that a computer's job might be to extend a person's memory rather than to run payroll faster was the contribution.

Twenty-three years later Douglas Engelbart demonstrated a working version of most of it. The 1968 demo put the mouse, hypertext links, multiple windows, version control, and a live video call between two collaborators on one stage, in ninety minutes, on hardware roughly a millionth as capable as the phone you're reading this on. Almost everything in it is now ambient.

The discipline got its name and its methodological spine in 1983, when Card, Moran, and Newell published The Psychology of Human-Computer Interaction. Their argument was that interface design could be an engineering discipline: model the human as an information processor with measurable cycle times, and you can predict how long a task will take before anyone builds it. That is where GOMS and the keystroke-level model come from, and it remains the sharpest available tool for the question will this new flow actually be faster.

The field has moved through recognizable phases since. First it was about fit and error rates on industrial systems. Then, through the 1980s and 90s, about cognition and how groups coordinate through software. Since roughly the 2000s it has been about experience, emotion, and context — the shift Susanne Bødker named HCI's "third wave," which produced most of the vocabulary UX practice now uses daily.

The elements of HCI

Textbooks decompose the field into four elements. The decomposition earns its keep because most interface failures can be traced to exactly one of them being ignored.

• The human. Perception, attention, motor control, memory. Real limits, and wide variation between people — not an idealized user who reads everything.
• The computer. Input and output hardware, the software's model of the task, and the latency between an action and its consequence.
• The interaction. The dialogue between the two: what the person can express, what the system can express back, and how errors get noticed and undone.
• The context. Where this happens. A one-handed phone on a train and a shared hospital terminal are different design problems wearing the same UI.

Context is the element that most often goes missing, because it's the only one that can't be observed from inside the office. The first three can be reasoned about at a desk.

HCI vs UX design: what's actually different

They are not competing labels for the same job. HCI is a research discipline; UX is a practice. HCI asks whether something is true about people and interfaces, and answers with methods and models. UX asks what to ship on Thursday, and answers with a design.

The traffic runs mostly one direction. Jakob Nielsen's ten usability heuristics are compressed HCI findings, deliberately made rough enough to apply in an afternoon. Fitts's law arrives in a design system as a minimum touch-target size. The formal experiment behind each one is invisible by the time it reaches a component library, which is efficient and also how the folklore problem starts.

The distinction matters in one specific way: when a rule fails you, knowing whether it's a finding or a convention tells you whether to look for the boundary condition or just discard it.

The two also age differently. UX practice is downstream of platform and taste, so much of it turns over every few years — the mobile conventions of 2014 are unusable now. Results about human motor control and memory don't turn over, because the constraints are biological. A designer who knows the difference between UX, usability, and interface work can also tell which parts of their toolkit have that longer shelf life.

What HCI actually gives a working designer

Four exports do most of the work.

Fitts's law (1954) predicts that the time to hit a target depends on its distance and its size: small and far is slow, big and near is fast. Its useful consequences are non-obvious. Screen edges and corners are effectively infinite targets because the pointer stops there, which is why the macOS menu bar sits flush at the top of the display rather than in the window it controls. NN/g's treatment covers the design implications. The floor is now codified: WCAG 2.2 requires a 24×24 CSS-pixel minimum target at Level AA, with 44×44 the common practical figure.

Working-memory limits. This is where the folklore is worst. "Users can hold seven items in mind" is a misreading of Miller's 1956 paper, and the number is wrong in the direction that matters. The better-supported estimate is about four chunks, and lower under any real-world distraction. NN/g's short-term memory guidance draws the interface consequence: don't make people carry information between screens. Every checkout that shows the shipping total on one step and asks for the payment decision two steps later is charging the user for that.

Response-time thresholds. Roughly 0.1 second for an action to feel instantaneous, 1 second before the flow of thought breaks, 10 seconds before attention leaves entirely. These are the most portable numbers in the field, and they're what decides whether a slow operation needs a spinner, a progress bar, or an email when it's done.

Hick's law is the export to treat most carefully. It says choice time grows with the number of options, which is true under its original conditions: equally probable options, no meaningful labels. Menus aren't that. Real options are unequally likely and scannable by label, so "fewer choices are always faster" is a conclusion the law does not license. Halving a nav bar and citing Hick's law for it is a citation standing in for a measurement.

Hick's law is the one that breaks in transfer, and it's worth knowing why the other three don't. Fitts's law survives because a pointer and a target behave the same in a product as in the 1954 apparatus. The response-time thresholds survive because a second is a second. Miller's seven fails for a different reason again — the finding was misread on the way out of the lab, not misapplied once it arrived.

What every one of them shares is a set of stated conditions. That's the question to ask of any HCI result before you spend a design decision on it: are your conditions close enough to the ones it was measured under.

Why HCI got interesting again

For most of the past two decades, interface design converged. Platform conventions settled and design systems spread, and a large share of the discipline's open questions quietly became implementation details.

Generative interfaces reopened them. A control whose result you can't predict breaks the feedback loop the whole field was built on, and an interface where the user proposes and the machine improvises makes questions of initiative urgent again: who acts first, who can interrupt, what happens to the work when the model is confidently wrong. Research on mixed-initiative interaction has been circling exactly that since the late 1990s, when it was a niche concern.

The other live front is the one the field started with: who gets counted as a user. Accessibility standards made a floor mandatory, and WCAG 2.2's target-size criterion is the sort of thing that reaches every product on earth once it lands in a compliance checklist. The harder work is the sampling problem behind it — research populations that skew Western, high-bandwidth, and voluntary, in a world where a great deal of software is used by people with none of those three.

Frequently asked questions

What is HCI in simple terms?

The study of how people and computers interact, and the design of systems that account for what that study finds. In practice: test interfaces on actual people, build models that predict how they'll behave, feed both back into the design.

What are the elements of HCI?

The human, the computer, the interaction between them, and the context they occur in. Context — where and under what pressure the software gets used — is the one most likely to be skipped, and the one that most often explains why a design that tested well fails in the field.

Is human-computer interaction the same as UX design?

No. HCI is the academic discipline that produces findings and methods; UX design is the professional practice that applies them to a product on a deadline. The heuristics a designer works from daily, including target sizing and the response-time thresholds, are HCI results in compressed form.

Do I need to study HCI to work in UX?

Not formally, and most practitioners haven't. What the background buys is diagnostic: when a familiar rule stops working, you can tell whether you've hit the edge of a real finding or a convention that was never load-bearing. That is a different skill from knowing the rule.

Is HCI a good field to go into?

The research side is a graduate-level career with a small number of positions, concentrated in universities and a handful of industrial labs. The applied side — design, research, and interaction work informed by that literature — is far larger, and the AI-interface shift has made the specifically HCI-trained parts of it more valuable, not less.

What's the difference between HCI and usability?

Usability is one property HCI studies: whether a system can be used effectively, efficiently, and with satisfaction for a defined task. HCI is the broader discipline, and it also studies what a usability test can't see in an hour — how a tool reshapes work over months, and what people do when it fails.

The reason to know where the rules came from

You can build a good interface with no knowledge of any of this. The heuristics are downstream of the research precisely so they can be used by people who don't have time to read it, and that compression is a feature.

It stops being enough at the boundaries. When a pattern isn't working and the available advice contradicts itself, the question that resolves it is whether the underlying claim was ever a measurement, and that's answerable only from the record. Human-computer interaction is that record: the part of what designers believe about people that somebody has actually checked.