Human-Computer Interaction

Human-computer interaction is the discipline this entire series has been relying on without naming, since every single topic so far was deployed, then checked not just for technical correctness but by actually looking at how it renders for a real reader on a real screen. Interface design is how a program presents itself and takes input, building directly on the event-driven programming the programming-paradigms topic introduced: a button waits for a click, a text field waits for typed input, and the whole interface is really just a collection of event handlers wrapped around whatever the program is actually doing underneath. Usability asks a sharper question than correctness alone: not just "does this work" but "can a real person actually accomplish their task with it, without confusion or wasted effort" — and this is exactly the gap this series' own testing checklist from the software-engineering topic couldn't close by itself, since a passing JSON-validity check or a clean overflow audit says nothing about whether a flowchart is actually readable on a narrow phone screen, which is precisely why every topic in this series has also been checked with an actual live screenshot on a simulated mobile device, not just the automated checklist alone. Accessibility narrows usability to a specific, often legally required case: making an interface usable by people with different abilities, like enough color contrast to be readable with low vision, a layout that still makes sense to a screen reader, and controls that can be operated by keyboard alone for anyone who can't use a mouse or touchscreen — none of which a program can verify about itself, since passing automated tests says nothing about what an actual assistive technology experiences. User evaluation is the practice of checking a design against real people, or at minimum a close, honest simulation of them, rather than trusting that a design that makes sense to its own creator will make sense to anyone else — the exact reason this series takes a literal mobile screenshot and reads it rather than only trusting its own content-validation script, which has in fact caught real problems the automated checks alone missed. None of interface design, usability, accessibility, or user evaluation can be fully automated away, because they are all, at bottom, questions about a human being on the other end of the screen, not questions about the code — and the final topic in this series, computing ethics, is what happens when that same question — who is this system actually for, and how does it treat the people who use it — gets asked about fairness, privacy, and consequences instead of interface design.

Design the interface
event handlers around whatever the program actually does
Check usability
can a real person accomplish their task without confusion
Check accessibility
contrast, screen readers, keyboard-only operation
Evaluate with real users, or a close simulation
a passing automated test is not the same as a usable interface
Iterate on what was actually found
the same loop this series ran for every single topic
Passing Tests Is Not the Same as Usable This series ran both checks, separately, every single topic Automated checklist valid JSON, no backslashes, no element overflowing its box answers: is the code correct? cannot answer: is it readable, clear, or usable on a real screen? Live user-facing check an actual screenshot on a simulated phone screen answers: can a person actually read and use this? caught real problems the checklist alone missed neither check replaces the other — both ran on every topic in this series correctness and usability are genuinely separate questions
Accessibility: Specific, Checkable Requirements Not a vague goal — concrete things a design either has or doesn't enough color contrast to read with low vision a structure that still makes sense to a screen reader every control operable by keyboard alone none of these are things a program can verify about itself — passing every automated test says nothing about what an actual screen reader or keyboard-only user experiences which is exactly why user evaluation has to be a separate step

Take human-computer interaction further

Ask the copilot about this term, or have our engineers assess it against your process.