HCI: Preparation Questions
Human–Computer Interaction — usefulness vs. usability, prototypes, and interaction beyond the keyboard.
1. What is HCI, and which disciplines contribute to it?
HCI is the study and design of how people use computing systems —
the interface, the task, and the context around the person.
It's multidisciplinary: computer science (implementation, interaction techniques), cognitive psychology (attention, memory, error), design, human factors and ergonomics, anthropology and sociology (field methods), statistics (evaluation), and accessibility studies. CMU's HCII is a good illustration — it sits inside the School of Computer Science but draws on psychology, design, and learning science at once.
It's multidisciplinary: computer science (implementation, interaction techniques), cognitive psychology (attention, memory, error), design, human factors and ergonomics, anthropology and sociology (field methods), statistics (evaluation), and accessibility studies. CMU's HCII is a good illustration — it sits inside the School of Computer Science but draws on psychology, design, and learning science at once.
2. Useful vs. usable? Give an example of usable but not useful.
Usefulness is whether the system does the thing you need. Usability is
whether you can get it to do that thing without struggle —
learnable, efficient, forgiving of errors. Nielsen pairs them: utility
asks if the functionality is right, usability asks if it's accessible.
You need both.
The distinction matters because usability testing tells you whether people can operate the thing, not whether it was worth building.
Example: a note-taking app with clean design, fast sync, perfect search — but no support for mathematical notation. For a proof-heavy course it's highly usable and close to useless. Nothing is broken; the functionality just doesn't match the task.
The distinction matters because usability testing tells you whether people can operate the thing, not whether it was worth building.
Example: a note-taking app with clean design, fast sync, perfect search — but no support for mathematical notation. For a proof-heavy course it's highly usable and close to useless. Nothing is broken; the functionality just doesn't match the task.
3. An everyday interface that's confusing. What causes the difficulty, and one improvement.
Example: the control panel on a shared laundry machine.
The task: wash darks at low temperature, back within an hour, because you have class.
The problem: cycles are labeled with marketing names — "Eco", "Mix", "Daily" — and neither temperature nor duration appears until after the cycle starts and locks the door. Two failures at once. The mapping between label and behavior is arbitrary, so nothing can be inferred. And the system's state is invisible exactly when the decision is made, breaking Nielsen's first heuristic, visibility of system status.
The fix: print temperature and duration beside each name — "Eco — 30°C, 2h10", "Mix — 40°C, 55min". No new hardware. The information that drives the choice is now there before the choice.
The task: wash darks at low temperature, back within an hour, because you have class.
The problem: cycles are labeled with marketing names — "Eco", "Mix", "Daily" — and neither temperature nor duration appears until after the cycle starts and locks the door. Two failures at once. The mapping between label and behavior is arbitrary, so nothing can be inferred. And the system's state is invisible exactly when the decision is made, breaking Nielsen's first heuristic, visibility of system status.
The fix: print temperature and duration beside each name — "Eco — 30°C, 2h10", "Mix — 40°C, 55min". No new hardware. The information that drives the choice is now there before the choice.
4. What is a prototype? How does testing one help? What wouldn't "Do you like it?" tell you?
A prototype is a deliberately incomplete version of a design, built to
answer one question before committing to a full build — a paper
sketch, a clickable mockup, or a Wizard-of-Oz setup where a human plays
the system. Cheapness is the point; a prototype you're reluctant to throw
away already cost too much.
Testing helps because designers know their own design too well to see it fresh. Watching an unfamiliar person attempt a real task exposes where their mental model diverges from yours — which control they reach for, where they pause, what they expect a button to do. Cheap to fix in a sketch, expensive in shipped code.
What "Do you like it?" misses: whether they could actually complete the task. Liking is an opinion delivered to the person's face, shaped by politeness. People say they like interfaces they just failed to use. Better: give a concrete task, stay quiet, ask them to think aloud, note hesitations and errors, then ask what they expected at the moment they stalled.
Testing helps because designers know their own design too well to see it fresh. Watching an unfamiliar person attempt a real task exposes where their mental model diverges from yours — which control they reach for, where they pause, what they expect a button to do. Cheap to fix in a sketch, expensive in shipped code.
What "Do you like it?" misses: whether they could actually complete the task. Liking is an opinion delivered to the person's face, shaped by politeness. People say they like interfaces they just failed to use. Better: give a concrete task, stay quiet, ask them to think aloud, note hesitations and errors, then ask what they expected at the moment they stalled.
5. An example of interaction beyond keyboard and mouse. Who benefits, and how would you test it?
Example: KIBO, from the DevTech Research Group — a small wooden robot
children program by arranging physical wooden blocks and scanning them. No
screen, no typing. The program is an object you can hold and rearrange on
the floor.
Who benefits: children roughly four to seven, learning to program before they can reliably read or type. The tangible form removes literacy and motor barriers, and several children can reach into a program on the floor at once — awkward around one laptop.
How to test: first define "helps" — "they enjoyed it" isn't measurable. Target: can children build and correct a multi-step sequence unaided? Run the same task with tangible blocks and with an on-screen block editor, comparable groups, and measure completion without help, steps used, and how often they debug rather than restart. Alongside that, observe who touches the program and how often an adult intervenes — that's what tells you why the numbers came out that way.
Who benefits: children roughly four to seven, learning to program before they can reliably read or type. The tangible form removes literacy and motor barriers, and several children can reach into a program on the floor at once — awkward around one laptop.
How to test: first define "helps" — "they enjoyed it" isn't measurable. Target: can children build and correct a multi-step sequence unaided? Run the same task with tangible blocks and with an on-screen block editor, comparable groups, and measure completion without help, steps used, and how often they debug rather than restart. Alongside that, observe who touches the program and how often an adult intervenes — that's what tells you why the numbers came out that way.
Sources: Nielsen, Ten Usability Heuristics (Q2, Q3) · CMU HCII, Research (Q1) · DevTech, KIBO Robot (Q5) · W3C WAI, Introduction to Web Accessibility (background).