The gold standard of human–computer interaction is a system that helps people accomplish meaningful tasks with understandable actions, useful feedback and dependable ways to recover. Quality becomes visible when someone can work out what to do, recognise what happened and continue with appropriate control. It must be examined in the circumstances where the system is actually used.
Human–computer interaction, often shortened to HCI, studies and shapes the relationship between people and computational systems. Its scope includes websites, software, shared workspaces, kiosks, devices and other forms of interaction. The subject brings together questions about human activity, perception, learning, organisation and technology. A visible screen is only part of the experience: waiting, interruption, assistance, privacy and the consequences of an action also matter.
This root guide connects HCI to the existing eduKate ecosystem of human factors, interaction design teaching, user experience teaching, accessibility research, testing and specialist service journeys. A fictional community-workshop booking system provides a continuous example. Follow it from understanding a task through prototype evaluation and into dependable operation.
Find the part you need
Choose a reading route or expand the chapter index. All eighteen chapters stay open below it, with Contents, Previous and Next links for moving through the guide.
Full chapter index · Connected articles · Learning that transfers into life
Chapter index
Understand people and tasks · Chapters 1–4
Design understandable interaction · Chapters 5–8
Evaluate with evidence · Chapters 9–12
Support real use over time · Chapters 13–16
Teach and connect the field · Chapters 17–18
HCI asks how computational systems fit human activities and how those interactions can be designed and evaluated. A person might search a library catalogue, book an appointment, coordinate a team or operate a household device. In each case, the useful question concerns the activity being supported and the experience of carrying it out.
The ACM-hosted HCI curriculum overview describes a field spanning design, evaluation, human abilities and social context. That breadth explains why HCI draws on several disciplines. Software behaviour matters, but so do language, attention, organisational routines and the assumptions people bring to the task. Research and design decisions need to address this whole relationship.
Consider a booking screen whose calendar works perfectly while users cannot tell whether a place has actually been reserved. The technical component may function as implemented, yet the interaction leaves the person’s task unresolved. HCI makes that gap examinable. Define the activity, identify where uncertainty arises, observe what people do and investigate which changes improve the experience. The Human Factors Engineering branch extends these concerns into broader systems where human performance and consequences require careful attention.
A task description should identify a person’s goal and the circumstances that shape it. “Use the booking form” describes a feature. “Find a suitable workshop and receive a confirmed place” describes an outcome. The second version allows the team to investigate alternatives and to notice failures that occur outside the form itself.
For a fictional community repair workshop, a resident may be holding a damaged item, checking dates on a phone and coordinating transport with a family member. They need to know whether the item is accepted, whether the venue is accessible, whether a place is available and what evidence confirms the booking. These needs belong to one practical activity even if several systems or organisations support it.
Map the beginning and end from the participant’s perspective. Where do they first hear about the event? What information do they already have? What happens if places are full? How do they change or cancel a booking? Record assumptions separately from observed behaviour. A task map becomes useful when it reveals a specific dependency, such as a confirmation message that arrives after the resident has already left the website uncertain about their place.
Research can involve observing work, interviewing likely users, reviewing support enquiries and examining existing service evidence. Choose methods according to the question. Interviews can help explain goals and previous experiences; observation can reveal workarounds that participants do not think to mention. Neither automatically tells you how common every finding is across a population.
Recruit people relevant to the activity, including those who encounter access barriers or use different assistance arrangements. A team of confident colleagues may be useful for an early rehearsal, but their familiarity with the system limits what their performance can establish. Explain how participants were selected and whose experience remains missing.
Use questions that invite specific accounts: “Tell me about the last time you booked a community activity” is more informative than “Would you like an easy booking system?” Ask permission for recording and make participation understandable and voluntary. Keep collected material proportionate to the research need. The Accessibility User Research Services article develops the specialist practice of involving people respectfully while producing evidence tied to real tasks. Research should change a decision, reveal an uncertainty or identify a need for further investigation.
A conceptual model is an account of how a system works that helps people predict what actions will do. A booking service might distinguish browsing sessions, reserving a place and receiving confirmation. If the interface blurs these stages, people may reasonably believe that selecting a date has completed the booking.
Use language and relationships that support accurate expectations. Explain whether a place is held temporarily, whether payment is required and what completes the process. Keep the distinction between a request and an accepted booking visible. Familiar-looking controls create expectations too: a selectable calendar date suggests an action, while grey text can suggest that an option is unavailable.
Consistency helps people transfer what they have learned, but it should reflect consistent meaning. Two buttons labelled “Continue” can be misleading if one merely advances a draft and the other submits a consequential request. Review the model with participants by asking what they expect before acting and what they believe afterwards. The purpose is to understand the gap between the system’s actual state and the person’s interpretation. A short explanation placed at the right moment can be more useful than a long instruction page encountered too early.
People need to recognise which actions are available, understand their likely effect and operate the relevant control. Labels, placement, grouping and visible states help them do this. A control can look distinctive while remaining ambiguous; an icon that seems obvious to the design team may carry several possible meanings for someone else.
Use verbs and objects when they clarify an action: “Choose workshop” or “Cancel booking” can provide more information than a generic instruction. Give consequential actions enough context that people can assess them. If cancellation releases a place immediately, explain that effect before the commitment point and provide an appropriate confirmation or recovery arrangement.
Consider the actual method of operation. A control must work through the interaction methods needed by its users, including keyboard or assistive technology where relevant. Hover alone cannot carry essential information for everyone. Physical kiosks introduce reach, posture and environmental constraints. The Teaching Interaction Design branch offers a learning route through actions and predictable responses. The Accessible Kiosk Design Services branch explores conditions that a screen-only sketch cannot capture.
Feedback tells people what the system has received, what is happening and what can happen next. It includes immediate responses to actions, progress during waiting and confirmation of results. A decorative animation may show movement without answering the important question: has my booking been accepted?
Distinguish states explicitly. In the workshop example, “Sending request” describes an operation in progress. “Your place is confirmed for Saturday at 10 am” describes an outcome, if the system has actually established it. “We could not confirm your place; check your booking status before submitting again” describes uncertainty and a next step. The wording must match the real system behaviour.
Plan slow and interrupted conditions as part of the interaction. People may tap again when nothing appears to happen, leave a page during a wait or receive a confirmation through another channel. The system needs appropriate technical handling as well as explanatory content. The Accessible Service Notification Services article connects messages to understandable action. Review feedback with the team responsible for actual processing so the interface never promises a result that has not yet occurred.
Errors can arise from unclear instructions, incompatible expectations, inaccessible controls, interruptions and system failures. Analyse the interaction before treating the person as the problem. If many participants enter a date in a different format, a better label, example or input method may address the cause more effectively than a harsher warning.
Make an error message identify what needs attention and how to proceed. Preserve valid information where appropriate so a small mistake does not force someone to repeat the whole task. Keep the message near the relevant problem while ensuring that users can discover it through their chosen access method. A general alert can orient them, but it still needs a useful path to the affected field or action.
Recovery also concerns consequences. Can an accidental cancellation be reversed? Can a duplicate submission be recognised? What happens when the connection fails after the request is sent? These questions require collaboration between design and implementation. Avoid offering an undo function unless the underlying operation can honour it. The Accessible Forms Design Services and Accessible Account Recovery Services branches develop related recovery problems in greater detail.
Accessibility concerns whether people with disabilities can perceive, understand, navigate and operate the system. It should shape research, content, interaction, implementation and evaluation. A prototype that excludes certain methods of use can conceal barriers until late in development, when the underlying decisions are harder to change.
For web systems, WCAG 2.2 provides testable accessibility requirements. Use the criteria applicable to the work and evaluate the complete relevant experience. A colour change alone may not communicate an error to everyone; a clear text explanation and appropriate programmatic relationships may also be needed. Technical checks and research with disabled participants answer complementary questions.
Record the technology, version, tasks and access methods involved in testing. Someone successfully completing one task with one setup does not demonstrate universal access. Equally, an automated check cannot reveal every difficulty in understanding a booking decision. Follow the Digital Accessibility Testing Services and Assistive Technology Compatibility Testing Services branches for more detailed evidence and remediation work. Keep unresolved barriers visible to those responsible for release and ongoing support.
A prototype represents selected aspects of a possible system. A paper sketch can explore information order; a clickable sequence can explore navigation; an implemented trial can reveal keyboard behaviour or response to real processing delays. Choose the form according to the uncertainty rather than assuming that greater visual polish always produces better evidence.
State what the prototype does and does not represent. A simulated booking confirmation can help investigate whether the wording is understood. It cannot prove that a real place has been reserved, that duplicate requests are handled correctly or that notifications arrive reliably. Participants and stakeholders need to understand these limits.
Make alternatives different enough to investigate a meaningful question. You might compare an event-first route with a date-first route when residents begin from different planning needs. Keep a record of what changed between versions so observations can be interpreted. Test awkward content, no available places and incomplete information as well as the smooth route. A prototype earns its value by reducing uncertainty about a decision. Once the real system is built, revisit properties that the prototype could not reproduce.
Agree the question, task, participant needs and success criteria before observing sessions. For the fictional workshop, independent completion might mean choosing an eligible session, submitting the required information and correctly recognising the confirmed booking. Finding a date without completing the task is a different outcome and should be recorded separately.
Give participants a realistic goal without naming the control they are meant to discover. Observe before offering help. If assistance becomes necessary, record what was said and when. GOV.UK’s moderated usability testing guidance describes observing people attempting specific tasks and planning sessions around relevant research questions.
Combine outcome evidence with observations. Completion time cannot explain whether a long pause reflects confusion, careful reading or an interruption unless the session provides context. Satisfaction questions add another perspective, but a favourable rating does not erase a failed task. Use an accessible research arrangement, explain recording and avoid unnecessary personal data. A useful session record preserves the difference between what happened, what the participant said and what the team thinks it might mean.
Suppose eight participants try the same booking task in a fictional study. Six complete independently and two require help. Independent completion is six divided by eight, or 75% in this sample. Reporting all eight as independent successes would conceal the assistance. Reporting 75% as the success rate for every future user would claim more than these sessions establish.
The six independent completion times are 43, 46, 50, 55, 60 and 70 seconds. Their median is halfway between 50 and 55, giving 52.5 seconds. This calculation excludes the two assisted sessions and must be labelled accordingly. It is not the median time for all participants, and it says nothing by itself about people who abandoned the task.
| Observation | Supported description | Unresolved question |
|---|---|---|
| Six independent completions out of eight | 75% independent completion in these sessions | How would other relevant users perform? |
| Two participants needed help | Assistance was required in two sessions | Which design changes address the underlying barriers? |
| Median 52.5 seconds for six independent completions | A summary of that subset’s recorded times | What happened in assisted, failed or interrupted sessions? |
Investigate the two assisted journeys closely. A barrier affecting fewer participants can still be important, especially when its consequence is exclusion or an irreversible error.
Define the timing convention before collecting results. Decide when a task begins, when it ends, how interruptions are recorded and how assistance is classified. Otherwise identical-looking numbers may measure different things. Keep raw observations available to the authorised research team so a summary can be checked without exposing participant identities in a public report.
Begin with an evidence statement: two participants interpreted “Request received” as a confirmed place, although the system was still checking availability. Then describe the consequence and a proposed change. The next version might distinguish receipt from confirmation and provide a status route. This chain keeps the recommendation connected to the observed problem.
Prioritise using consequence, severity, affected tasks and the strength of evidence. Frequency matters, but it should not be the only criterion. A rare disclosure of private information or an unrecoverable action can deserve urgent attention. Make uncertainty visible when the cause remains unclear, and choose a follow-up method that can investigate it.
Retest changes under relevant conditions. Reusing the same participants may be useful for discussion, but their familiarity can affect task performance. If comparing alternatives, consider task order, learning, differing participant characteristics and sample limitations. A simple before-and-after result does not automatically show that the design alone caused the difference. Maintain a findings log with the observed evidence, decision, owner and verification result. That record makes it possible to see whether a problem was fixed, deferred or merely reworded in a report.
A short decision table can distinguish an observed barrier, the proposed remedy and the evidence still needed. For example, changing a confirmation heading may address a misunderstanding, while testing the actual confirmation process addresses whether the system delivers the promised outcome. Assigning these as separate verification tasks prevents a successful wording review from being mistaken for proof of operational reliability.
A digital interaction often depends on information and actions elsewhere. A booking journey can start on a poster, move to a webpage, continue through a confirmation message and finish at a physical venue. HCI needs to examine the transitions because people experience one activity across those boundaries.
Check that names, dates and status meanings remain consistent. If a message says “arrive fifteen minutes early” while the booking page gives only a start time, the participant has received a new requirement after committing. If a support worker cannot see the booking state, a confusing online step may become a difficult assisted interaction. Map responsibilities as well as screens.
Include alternatives for people who cannot complete the digital route and make those alternatives understandable. They should lead to a dependable outcome with clear handling of changes and cancellations. The Accessible Appointment Booking Services and Government Services articles develop whole-journey responsibilities in related settings. Improvements should reduce uncertainty across the activity, including what happens after the person closes the interface.
Interactions ask people to disclose information and make choices. Explain why information is needed at the point where that explanation helps them decide. Avoid collecting personal details merely because an existing form has a field for them. Research records deserve similar discipline: collect what answers the agreed question and handle it under the appropriate organisational requirements.
Meaningful choice requires understandable consequences and a practical way to act on them. If an optional update subscription appears inside a booking flow, its status should be clear. If people can withdraw from research, explain how to do so and any limits on removing material already incorporated into anonymised findings. Use the applicable policies and specialist advice for the actual setting.
Examine visual emphasis and friction as part of control. Making acceptance prominent while hiding refusal can steer behaviour without improving understanding. An apparently helpful default can create consequences the person has not anticipated. HCI evaluation should ask whether people can explain their choice and revise it where appropriate. The Data Governance and Digital Identity Management roots connect interface decisions to the wider stewardship and identity processes supporting them.
Many systems are used by several people whose actions depend on one another. A family may coordinate attendance; a receptionist may assist a resident; workshop staff may check arrivals against a booking list. The quality of each person’s interaction depends partly on whether the system communicates relevant shared state accurately.
Make roles and permissions understandable. A helper should know whether they are viewing a booking, changing it or acting on another person’s behalf. Staff need enough information to do their work without unnecessary access to unrelated personal details. Responsibility becomes especially important when an action changes another person’s plans or when several staff handle the same case.
Study handovers and workarounds. A printed list may support a low-connectivity venue but can become outdated after late cancellations. A shared note can improve coordination while creating uncertainty about which record is authoritative. Design for the actual workflow and agree how conflicting updates are resolved. Collaborative HCI includes organisational arrangements, training and communication as well as interface controls. Test scenarios involving two roles and a change over time, because an isolated single-user demonstration may miss the coordination problem.
Real use changes the evidence. New content, different devices, staff turnover and altered service rules can expose problems that an earlier evaluation did not cover. Establish responsibility for reviewing support reports, research findings, accessibility barriers and service outcomes after release.
Use operational evidence carefully. A drop in completion could reflect a new interface, an eligibility change, a network issue or a different mix of visitors. Investigate before assigning a cause. A high completion count can coexist with confused users, repeated attempts or people who never reached the start. Choose measures that remain connected to meaningful tasks and supplement them with appropriate qualitative evidence.
Manage changes as changes to an experience. A new date format can affect comprehension, a replacement component can affect keyboard operation and an altered notification can change what confirmation means. Retest relevant journeys and document the version examined. The Accessibility Remediation Services and Accessibility Feedback and Complaint Resolution Services branches show how reported barriers can lead to verified remedies. Dependable operation includes an understandable route for people to report that something no longer works for them.
Begin with an ordinary activity that students can observe ethically: finding a book, choosing a club session or using a simple shared timetable. Ask them to describe the goal, identify assumptions and sketch the interaction. Then have someone attempt a realistic task while students record what happens without coaching.
Teach the difference between observation and interpretation. “The participant selected Back twice” is an observation. “The participant disliked the page” is an interpretation requiring more evidence. Students can revise a prototype, explain which finding motivated the change and describe what another test would need to establish. Include errors, access methods and consequences so the exercise develops more than presentation skill.
The Teaching User Experience Design and Teaching Interaction Design branches provide related teaching routes. The fuller Secondary 1 Mathematics Tutor Clementi guide offers a reference for diagnosis, explanation, guided practice and independent application. In HCI, the principle of learning that transfers into life appears when students can investigate an unfamiliar interaction, explain their reasoning and state the limits of their evidence without copying a familiar interface.
For an assessment, give students a new scenario with an interruption: a resident loses a connection after submitting a request. Ask them to map possible system states, propose truthful feedback and explain how they would test recovery. Strong work identifies what the interface cannot safely infer. It also proposes evidence that could resolve the uncertainty, connecting design judgement with the behaviour of the underlying system.
What is the gold standard of human–computer interaction?
Interaction that supports meaningful tasks through understandable actions, informative feedback, accessibility and practical recovery, evaluated with evidence from relevant people and conditions.
How does HCI relate to user experience and interface design?
The fields overlap. HCI is a broad area of research and practice concerned with people and computational systems. User experience work and interface design address related aspects of understanding and shaping those experiences.
Does a simple-looking interface guarantee usability?
No. A sparse screen can hide essential options or leave outcomes unexplained. Evaluate whether people can complete the actual task and understand the result.
How many participants are enough for a usability study?
The answer depends on the question, diversity of relevant users, risk and intended claim. A small study can reveal important problems, while estimating population performance or comparing alternatives requires an appropriate research design.
Can automated testing replace research with people?
Automated checks can identify particular technical problems and support repeatable verification. They do not establish whether people understand the task, interpret a message correctly or experience a complete service as usable.
Does a prototype prove the finished system will work?
It provides evidence about the properties it represents. Actual processing, accessibility, performance, security and operational handovers may need evaluation in an implemented system.
Should the fastest interaction always win?
Speed is one consideration. People may need time to understand a consequential choice, review information or recover from uncertainty. Assess completion, understanding, control and consequences alongside time.
Where can I explore the specialist branches?
Use the connections below for human factors, teaching, research, accessibility testing, forms, booking, recovery, notifications, privacy and service operation. Each branch develops a particular part of the whole interaction.
Connected articles across the eduKate ecosystem
The field and its teaching foundations
These guides connect HCI’s broad concern for human activity to systems thinking, research and the teaching of usable interactions.
- The Gold Standard of Graphic Design
- Human Factors Engineering | Systems People Can Use Safely
- Research
- Teaching Interaction Design | Actions, Feedback and Predictable Interfaces
- Teaching User Experience Design | Research, Journeys and Inclusive Usability
- Teaching Product Design | Requirements, Usability and Iterative Improvement
Research, accessibility and verification
Continue here to investigate barriers with relevant people, test implementation and verify that remediation changes the experience.
- Accessibility User Research Services | Real Tasks and Respectful Evidence
- Digital Accessibility Testing Services | Reproducible Evidence and Practical Remediation
- Assistive Technology Compatibility Testing Services | Supported Interactions and Reproducible Results
- Accessibility Remediation Services | Fixed Barriers and Verified Outcomes
- Accessibility Feedback and Complaint Resolution Services | Heard Barriers and Verified Remedies
Forms, booking, decisions and recovery
These specialist journeys apply interaction principles to consequential tasks: providing information, reserving a service, paying and regaining access.
- Accessible Forms Design Services | Completable Journeys and Clear Recovery
- Accessible Appointment Booking Services | Independent Scheduling and Reliable Confirmation
- Accessible Account Recovery Services | Secure Access and Usable Verification
- Accessible Payment and Checkout Services | Confirmed Orders and Independent Payments
- Accessible E-Commerce Services | Fair Choice and Operable Checkout
Messages, physical settings and complete services
An interaction continues through notifications, physical terminals and assisted service. These branches examine those transitions and their responsibilities.
- Accessible Service Notification Services | Understandable Alerts and Recoverable Actions
- Accessible Kiosk Design Services | Independent Access and Reliable Service
- Government Services | Accessible Decisions and Accountable Completion
- Accessible E-Learning Production Services | Equivalent Lessons and Usable Assessments
- Digital Inclusion Training Services | Practical Skills and Inclusive Support
Information stewardship and learning transfer
The surrounding organisation must support understandable choices, responsible information handling and skills people can apply independently.
- Data Governance
- Digital Identity Management
- Digital Literacy
- Educational Technology | Learning Value Beyond Screen Engagement
- Education | Learning That Transfers into Life
- Secondary 1 Mathematics Tutor Clementi | Small-Group Tutorials
Sources and scope
The ACM-hosted CS2013 HCI curriculum overview supports the discussion of HCI’s interdisciplinary scope. It is an educational overview, not a product certification or a current software specification.
GOV.UK’s moderated usability testing guide provides practical primary guidance on observing relevant people attempting tasks. Study design must fit the actual research question and participants.
W3C’s Web Content Accessibility Guidelines 2.2 supplies the web-accessibility reference. Conformance claims require evaluation of the relevant requirements and scope; this article does not assess any particular system.
The repair workshop, booking service, participants, timings and findings are fictional teaching examples. The arithmetic describes only the stated sample and subset. Discussion of privacy and research practice is educational; specific obligations depend on the actual setting.
“Gold standard” describes the educational benchmark explained in this guide. It is not an official accreditation or certification.
Back to contents · Explore the Gold Standard article directory