Human-computer interaction: design technology around people

Learn how research, interaction design, accessibility, prototyping, and usability evaluation help teams build technology people can use with confidence.

What human-computer interaction studies

Human-computer interaction (HCI) studies how people interact with computing systems and how those systems can be designed, built, and evaluated. It draws on computer science, psychology, design, ergonomics, and other fields.

HCI includes more than visual appearance. It considers the complete experience: the person's goal, the language of controls, the sequence of actions, accessibility needs, physical environment, error recovery, privacy, and the result of using the system.

• Useful: the product supports a real task or need.
• Usable: people can complete tasks effectively and learn the interface.
• Accessible: people with different abilities and technologies can participate.
• Trustworthy: behavior, data use, and consequences are understandable.

A feature can be technically correct and still be difficult to discover, confusing to use, or inaccessible. HCI gives teams methods to identify these problems before they become entrenched.

Understand people and context

Design starts by understanding the people who will use a system and the context in which they will use it. Interviews can reveal goals and constraints; observation can show workarounds that people may not mention; surveys can gather broader responses but depend on question design and sampling.

Research should focus on real tasks and environments. A person using a phone outdoors with one hand faces different constraints from a person using a desktop in a quiet office. A frequent expert user may need efficient shortcuts; a first-time user may need clearer guidance.

Ask open questions and avoid leading users

“Would you use our new dashboard?” encourages a positive answer and does not reveal what the person needs. “Tell me about the last time you checked your account activity. What were you trying to find?” invites a concrete example and uncovers existing behavior.

Do not assume one interview or a small test represents everyone. Recruit participants with varied relevant experiences, document whose perspectives are missing, and interpret findings within that scope. Research participants deserve informed consent and respect for their time and privacy.

Personas and task scenarios

A persona is a research-informed summary of a user group, not a fictional stereotype. It can help a team remember goals and constraints, but should not replace direct engagement with people. A scenario describes a person, a context, and a goal they are trying to accomplish.

For a library catalog, a scenario might be: “A reader on a phone wants to find a book available this week and save its location before entering the building.” This focuses design on an actual outcome rather than on a feature list.

Interaction design principles

Interfaces help people understand what actions are possible and what will happen when they take them. Consistency, clear labels, visible system state, and appropriate constraints reduce the amount users must remember.

• Affordances and signifiers: clues communicate how an object may be used; a label or icon signals where to act.
• Consistency: similar actions should behave similarly across the product.
• Visibility: important status and available actions should be discoverable.
• Recognition over recall: show useful choices rather than requiring users to remember hidden commands.
• Constraints: prevent invalid actions where possible, and explain necessary restrictions.

Icons can save space but may be ambiguous. Pair unfamiliar icons with text labels, support tooltips where helpful, and test whether people interpret the control correctly. Consistency helps users transfer learning, but conventions should not be followed blindly when they conflict with user goals or accessibility.

Navigation and information architecture

Information architecture organizes content and navigation so people can locate what they need. Group items by user meaning, use labels that match users' vocabulary, and make the current location and next steps clear. Search is useful but should not be the only way to find important content.

Test labels and groupings with representative users. A site structure that matches the organization chart may not match the way visitors think about their tasks.

Feedback, errors, and mental models

After an action, people need feedback that the system received it and what happened. A save action may show a confirmation; a long request may show progress. Feedback should be timely and specific, especially when an action changes or removes information.

A mental model is a person's understanding of how a system works. People infer that a shopping cart keeps items until checkout or that a highlighted tab represents the current section. Interfaces that behave contrary to these expectations cause mistakes and reduce trust.

Prevent errors and support recovery

Good design prevents common mistakes without blocking legitimate work. Use clear input requirements, sensible defaults, and inline feedback. When something fails, explain what happened, what information was preserved, and how the person can recover.

For destructive actions, offer a reversible path where practical, such as an undo period or a recoverable trash folder. Confirmation dialogs are useful for consequential and hard-to-reverse actions but become noise if used for every routine step.

Error messages should use plain language, identify the affected field or action, and suggest a correction. Do not rely only on color or place the explanation far from the problem. Preserve valid input when a form submission fails so users do not need to start over.

Prototypes and iteration

A prototype is an early representation used to learn about a design. A paper sketch can test organization; a clickable wireframe can test navigation; a working feature can test performance and technical integration. A prototype should be only as detailed as needed to answer the current question.

Prototyping makes assumptions visible before the team commits to a full implementation. If participants cannot find a primary action in a sketch, polishing production code is unlikely to solve the underlying information problem.

1. State the user task and what is uncertain.
2. Build the simplest prototype that tests the uncertainty.
3. Give participants a realistic task without instructing them where to click.
4. Observe what they try, where they hesitate, and what they expect.
5. Summarize patterns and adjust the design.
6. Repeat with a new version and check whether the intended improvement worked.

Prototypes can create false expectations if people mistake a demo for a finished service. Be clear about what is simulated, how participant feedback will be used, and whether their data is being recorded.

Usability evaluation

Usability is commonly discussed through effectiveness, efficiency, and satisfaction in a specified context. Effectiveness asks whether users complete goals; efficiency asks what effort or time it takes; satisfaction asks how people experience the interaction.

A usability test gives participants tasks and observes how they use a design. Choose tasks that resemble real goals. Ask participants to think aloud if that fits the study, but remember that narrating can change behavior and should not be the only source of evidence.

Observation	Possible measure	Interpret carefully
Can a user complete the task?	Task success rate	Define what counts as success and partial success
How hard is the task?	Time, errors, or requests for help	Longer is not always worse; task complexity matters
Where do users struggle?	Observed confusion or repeated actions	Look for patterns without blaming participants
How did the experience feel?	Interview or rating scale	Self-report is useful but not the same as behavior

Small usability tests often reveal major interaction problems, but they do not prove that the design works for every person. Combine methods as appropriate: analytics show aggregate patterns, interviews explain context, and accessibility audits check specific requirements.

Worked example: test a checkout flow

Give a participant a scenario: “You are buying a book as a gift and want it delivered to a different address.” Observe whether they can find the delivery option, understand the total cost, and correct an address error. Avoid saying “click the shipping button”; that tests instruction following rather than discoverability.

Record the task outcome, confusing labels, and unexpected behavior. If several participants miss the same control, consider changing its placement or wording. Then test the revised design with a fresh task and ensure the new layout still works on mobile and with assistive technology.

Accessibility and inclusive design

Accessibility means people with disabilities can perceive, understand, navigate, and use a product. Accessibility benefits many users: captions help in noisy spaces, keyboard support helps people who cannot use a mouse, and readable text helps on small screens.

• Use semantic headings, buttons, labels, and landmarks.
• Make every interactive control usable with a keyboard and show a visible focus indicator.
• Provide text alternatives for meaningful images and captions or transcripts for media.
• Use sufficient contrast, and never rely on color alone to convey meaning.
• Support zoom, text resizing, and reduced-motion preferences.
• Announce important dynamic changes to assistive technologies where appropriate.

Automated checks can find some issues, such as missing labels or low contrast, but they cannot determine whether a page is understandable or every workflow is usable. Test with assistive technologies and, when possible, include people with relevant disabilities in research.

Accessibility guidelines such as WCAG provide testable success criteria. Compliance is important, but accessible experiences also require meaningful content, clear interactions, and inclusive product decisions.

Privacy, trust, and ethical design

Interfaces shape choices. Defaults, wording, and visual emphasis can help people or manipulate them. Avoid deceptive patterns that make it easier to accept tracking than decline it, hide cancellation, or pressure people into a decision they did not intend.

Request only data needed for a clear purpose. Explain what will be collected, how it will be used, and how a person can change their choice. Consent should be understandable and revocable where appropriate, rather than bundled into an unrelated task.

Design for the consequences of errors. A confusing medical interface, inaccessible emergency alert, or misleading financial prompt can cause real harm. Include safety, privacy, and accessibility as requirements from the start and provide clear ways to report problems.

A practical human-centered workflow

1. Learn: talk with people and observe real tasks and environments.
2. Define: state the user need, context, constraints, and evidence of success.
3. Explore: sketch multiple approaches before committing to one.
4. Prototype: build a representation that can answer a specific question.
5. Evaluate: observe representative users and check accessibility.
6. Iterate: use evidence to refine the experience and retest important workflows.
7. Monitor: learn from real use while respecting privacy and collecting only what is needed.

Do not treat user research as a final sign-off. Needs change, new features interact with old ones, and real-world usage reveals conditions that prototypes cannot fully simulate. Keep feedback channels open and make product changes reversible when possible.

A compact glossary

Affordance

A property that suggests how an object or control can be used.

Usability

How effectively, efficiently, and satisfactorily people achieve goals in context.

Prototype

An early representation used to test a design idea or assumption.

Information architecture

The organization and labeling of information and navigation.

Assistive technology

Hardware or software that helps people interact with digital content.

Inclusive design

A design approach that considers a wide range of people and circumstances.

References and further reading

1. Ben Shneiderman et al. Designing the User Interface: Strategies for Effective Human-Computer Interaction, 6th edition. Pearson, 2016. Author resources.
2. Don Norman. The Design of Everyday Things, revised edition. Basic Books, 2013. Author information.
3. World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2. Standard.
4. U.S. Digital Services. U.S. Web Design System: Accessibility. Practical guidance.

Try it yourself

1. Choose a sign-in screen and list the user's goal, possible confusion, and one accessibility improvement.
2. Write a neutral usability-test task for finding and saving an item in a catalog.
3. Why is a visible keyboard focus indicator important? Test a page without using a mouse.
4. Find one interface default that could influence a user's choice and assess whether it is fair.
5. Sketch two designs for an error message and explain which better supports recovery.

Remember: good interfaces come from understanding people, testing assumptions, and making access and recovery part of the design.