CEN4721: Human-Computer Interaction

Course Description

CEN4721 Human-Computer Interaction is the course on designing software that people can actually use — and on the research methods that establish whether they can.

The course is offered at approximately five Florida institutions, including Florida A&M University, Florida Gulf Coast University, Florida Polytechnic University, the University of Florida and the University of West Florida.

Florida Gulf Coast University describes a course that introduces the area of Human Computer Interaction, in which principles, theory and applications of HCI pertaining to computing devices and ecosystems are discussed and methods, tools and techniques for designing and evaluating interactive systems will be covered, noting that the interdisciplinary nature of HCI will be noted, at 3 credits with a prerequisite of COP 3003. The University of Florida carries it as Human-Computer Interaction.

FGCU's explicit mention of interdisciplinarity is not filler — it is the defining fact about this course. HCI draws on computer science, cognitive psychology, design, human factors engineering, sociology and anthropology, and it is one of the few courses in a computing degree where the readings include experimental psychology and ethnographic method alongside implementation. Students arriving expecting a programming course are surprised; students arriving expecting a visual design course are equally surprised. It is neither, and it uses both.

The course's founding claim is that usability is an engineering property, not a matter of taste. Whether an interface is usable is an empirical question with measurable answers — task completion rate, time on task, error rate, learnability, satisfaction — and the correct response to a disagreement about a design is to test it rather than to argue about it. That reframing is the single most valuable thing the course teaches, and it survives into any career that involves building things for other people.

The second claim, which follows from the first, is that you are not the user. Developers are unrepresentative in almost every relevant way — expertise, hardware, network speed, motivation, familiarity with the domain — and intuitions about what is obvious are systematically unreliable. Nearly every method in the course exists to substitute evidence for that intuition.

The third, and the one with the most consequence, is accessibility. Interfaces that exclude people with disabilities exclude a large population, and in many contexts doing so is unlawful. Accessibility is treated in this course as a design requirement with a standard (WCAG) and a legal framework rather than as an optional enhancement, and a graduate who cannot discuss it is not employable in this area.

Learning Outcomes

Required Outcomes

• Explain usability as a measurable property and define its components.
• Apply relevant human capabilities and limitations — perception, attention, memory, motor control — to design decisions.
• Apply Fitts's law, Hick's law and the constraints of working memory to interface design.
• Apply established design principles — affordance, signifier, mapping, feedback, constraint, consistency — to evaluate and improve an interface.
• Conduct a heuristic evaluation using Nielsen's heuristics and report findings with severity ratings.
• Conduct a cognitive walkthrough.
• Perform user research — interviews, contextual inquiry, surveys, observation — and synthesise the findings.
• Conduct a task analysis and construct personas and scenarios from research rather than invention.
• Produce prototypes at appropriate fidelity, from paper sketches to interactive mock-ups.
• Apply the iterative, user-centred design process and explain why iteration is necessary.
• Plan and conduct a usability test — recruiting, tasks, protocol, facilitation, measurement — and analyse the results.
• Distinguish formative from summative evaluation and select the appropriate method for a question.
• Explain and apply accessibility requirements, including WCAG principles and assistive technology considerations.
• Apply information architecture and navigation design principles.
• Explain interaction styles and paradigms, including mobile, touch, voice and other modalities.
• Apply research ethics to studies involving human participants, including consent and data protection.
• Communicate design decisions with justification to technical and non-technical audiences.

Optional Outcomes

• Conduct a controlled experiment with statistical analysis.
• Apply A/B testing and analytics-based evaluation.
• Design for voice, gesture, augmented or virtual reality.
• Address cross-cultural and internationalisation issues in design.
• Apply computer-supported cooperative work and social computing concepts.
• Address persuasive design and dark patterns critically.
• Conduct an accessibility audit against WCAG with assistive technology.
• Build a working interactive prototype in code.
• Assemble a design portfolio.

Major Topics

Required Topics

• What HCI is. The field's scope and history — from human factors and the command line through the graphical interface to mobile, ubiquitous and conversational computing; its constituent disciplines and what each contributes; usability defined operationally — effectiveness, efficiency, satisfaction, learnability, memorability, error tolerance — and the point that these are measurable and sometimes in tension; user experience as the broader concept including affect and meaning; the business case, since usability failures produce support costs, abandonment and — in safety-critical systems — injury.
• The human side. Perception — visual acuity, colour vision and colour blindness, which affects roughly eight per cent of men and is why colour alone must never carry information; the Gestalt grouping principles, which explain most of what layout does; attention, selective and divided, and change blindness; memory — working memory limits and the design implication that recognition beats recall; mental models and the trouble caused when the user's model and the system's differ; motor control and Fitts's law, which quantifies target acquisition and explains why screen edges and corners are valuable; Hick's law and choice complexity; error types — slips versus mistakes — and why they need different remedies; individual differences and ageing.
• Design principles. Norman's framework — affordances and signifiers, mapping, feedback, constraints, conceptual models, and the gulfs of execution and evaluation; Nielsen's ten usability heuristics, which are the working vocabulary of the field and should be memorised; Shneiderman's golden rules; consistency, internal and external, and the cases where breaking it is right; visibility of system status, and the general point that a system which does not tell you what it is doing is unusable regardless of what it does; error prevention over error messages, and the design of good messages when prevention fails; undo and reversibility; progressive disclosure; defaults, which are among the most powerful and least discussed design decisions.
• Understanding users. User research methods — interviews, contextual inquiry and observation in the actual setting, diary studies, surveys — and what each can and cannot establish; the recurring finding that what people say they do and what they do differ, which is why observation matters; task analysis, including hierarchical task analysis; personas and scenarios, and the essential qualification that a persona built from research is a summary of evidence while a persona built from imagination is a fiction that launders assumptions; user journey and experience mapping; requirements derived from research.
• The design process. User-centred and iterative design; the design-prototype-evaluate cycle and why one pass is never enough; prototyping at appropriate fidelity — paper and sketch for early concepts, wireframes for structure, interactive mock-ups for flow, code for feel; the argument for low fidelity early: it is faster, it invites criticism that a polished prototype suppresses, and it prevents commitment to a direction before it has been tested; design rationale and documenting why; participatory design; design systems and pattern libraries.
• Inspection methods — evaluation without users. Heuristic evaluation — the procedure, the use of several independent evaluators, severity rating and the aggregation of findings; cognitive walkthrough — stepping through a task as a first-time user and asking at each step whether the right action is visible, identifiable and confirmed; guideline and standards review; the honest limitation that inspection methods are cheap and find different problems from user testing, and do not replace it.
• Usability testing — the course's central practical skill. Planning — objectives, participant recruitment and representativeness, task design, which is where most student tests fail because the tasks lead the participant; the think-aloud protocol; facilitation, and the discipline of not helping, not explaining and not defending the design; measures — completion, time, errors, satisfaction instruments such as SUS; how many participants, and the argument that five users find most problems in formative testing, with the important caveat that this applies to finding problems rather than to measuring anything; remote and unmoderated testing; analysing and prioritising findings; reporting to a team that built the thing you are criticising, which is a communication skill in its own right.
• Accessibility — treated as a requirement, not an option. Disability categories and their design implications — visual, auditory, motor, cognitive, and situational or temporary impairment; assistive technologies — screen readers, magnification, switch access, voice control — and how they actually consume an interface, which is why semantic structure matters more than appearance; WCAG and its principles — perceivable, operable, understandable, robust — and conformance levels; practical requirements — text alternatives, keyboard operability, focus visibility, sufficient contrast, captions, and not conveying information by colour alone; the legal framework, including Section 508 and the application of the Americans with Disabilities Act to digital services, and the substantial and growing volume of litigation; the point that accessible design frequently improves usability for everyone — captions, clear structure and keyboard operability benefit far more people than the population they were designed for.
• Interfaces and interaction paradigms. Interaction styles — direct manipulation, menus, forms, command languages, natural language; widget selection and when each control is correct; forms and input design, which is where most transactional interfaces succeed or fail; information architecture, categorisation, navigation and search; mobile and touch — target size, thumb reach, gesture discoverability, and the constraint of a small screen; responsive design; voice and conversational interfaces and their particular difficulties, notably discoverability and error recovery; visual design fundamentals — hierarchy, alignment, contrast, whitespace, typography — treated as tools for communicating structure rather than as decoration.
• Ethics and responsibility. Research ethics — informed consent, voluntary participation, confidentiality, and the requirement for institutional review board approval for research involving human participants, which students frequently do not realise applies to them; data protection and minimisation; dark patterns — interfaces designed to produce choices against the user's interest — named, catalogued and increasingly regulated; persuasive design and attention capture; bias in design, and the systematic exclusions that follow from designing for a narrow assumed user; the designer's responsibility for consequences.

Optional Topics

• Controlled experiments, experimental design and statistical analysis of interaction data.
• A/B testing, analytics and behavioural measurement at scale.
• Augmented and virtual reality, gesture and tangible interaction.
• Computer-supported cooperative work, groupware and social computing.
• Cross-cultural design and internationalisation.
• Designing for children, older adults, or specific clinical populations.
• Safety-critical interface design — medical, aviation, industrial control.
• Design systems and large-scale consistency.
• Portfolio development.

Resources & Tools

• The Design of Everyday Things by Don Norman — the field's foundational popular text, short, entertaining, and the source of affordances, mappings and the gulfs of execution and evaluation. Read it whether or not it is assigned.
• Interaction Design: Beyond Human-Computer Interaction by Rogers, Sharp and Preece — the standard university textbook and the likeliest assignment.
• Designing the User Interface by Shneiderman, Plaisant and colleagues — the other standard, strong on evaluation and on the research literature.
• Don't Make Me Think by Steve Krug — very short, very practical, and the best single introduction to web usability; his Rocket Surgery Made Easy is the most usable guide to running a usability test on no budget.
• About Face by Cooper, Reimann and Cronin — the practitioner's reference on interaction design patterns; Universal Principles of Design (Lidwell) as a browsable reference.
• Free and authoritative, and this field is unusually well served:
  • Nielsen Norman Group (nngroup.com) — the most useful free resource in the field: research-based articles on essentially every HCI topic, including the original ten heuristics.
  • Usability.gov — the United States government's user-experience guidance, free and practical.
  • W3C Web Accessibility Initiative (WAI) — the authority on WCAG, with tutorials, techniques and checklists, all free. This is where accessibility questions get answered.
  • Interaction Design Foundation — extensive free encyclopedia articles.
  • The Apple Human Interface Guidelines and Google Material Design — free, detailed, and worth reading as examples of design systems even if you build for neither platform.
• Tools: Figma — the industry standard for interface design and prototyping, free for individuals and with an education plan, and the tool employers expect; Balsamiq for deliberately low-fidelity wireframes; pen and paper, which remains the fastest prototyping medium and is genuinely used professionally.
• Accessibility testing, all free: WAVE and axe DevTools browser extensions; Lighthouse, built into Chrome; NVDA (Windows) and VoiceOver (macOS/iOS) screen readers — and the single most instructive exercise in this course is to turn off your monitor and navigate your own interface with a screen reader.
• Professional organisations: ACM SIGCHI, whose CHI conference is the field's principal venue and which offers student membership; the User Experience Professionals Association, with local chapters; the Human Factors and Ergonomics Society.

Career Pathways

HCI is one of the clearest routes from a computing degree into a design-adjacent career, and it is also one of the few computing specialities that hires people from psychology and other backgrounds.

• UX Designers and Interaction Designers — classified variously under SOC 15-1255 (web and digital interface designers) and 27-1024. The direct destination.
• UX Researchers (SOC 19-3099, 15-1255) — the research half of the field, and a distinct role; a strong fit for students who like the methods more than the visual work, and one that values psychology and social science training.
• Web and Digital Interface Designers (SOC 15-1255) and front-end developers (SOC 15-1254) — a developer who understands usability and accessibility is markedly more valuable than one who does not, and accessibility competence in particular is in short supply.
• Product Managers — not a single SOC code, but a common destination; user research and evidence-based design argument are core to the role.
• Human Factors Engineers (SOC 17-2112) — safety-critical systems in aerospace, defence, medical devices and industrial control, and a genuinely engineering-flavoured version of this material. Well represented in Florida given the aerospace and simulation industries.
• Accessibility Specialists — a growing speciality driven by regulation and litigation; the IAAP offers professional certification, and demand exceeds supply.
• Information Architects and content designers.
• Technical Writers (SOC 27-3042) — documentation and interface text are adjacent crafts.
• Health informatics and clinical systems — a substantial Florida area, and one where interface design has documented patient-safety consequences.
• Software Developers (SOC 15-1252) generally, with usability as a differentiator.
• Graduate study in HCI, human factors or information science.

⚠ The advice that matters most in this field: build a portfolio, because you will not be hired without one. UX hiring is portfolio-driven to a degree unusual in computing — employers want to see two or three case studies showing your process: the problem, the research you did, the alternatives you considered, why you chose what you chose, how you tested it, and what you changed as a result. The process is what is being assessed, not the visual polish, and a case study that honestly reports a design that tested badly and was revised is more persuasive than one that presents a finished screen.

The coursework in this class is portfolio material if you treat it as such. Document the research, keep the low-fidelity prototypes, record the usability test findings and the revisions. Students who assemble this as they go finish the course with a portfolio; students who do not finish with a grade.

The Florida picture: aerospace, defence and simulation in Orlando and on the Space Coast, where human factors work is genuine engineering; healthcare systems across the state; the theme park and hospitality sector, which operates enormous customer-facing digital systems; financial services in Miami, Tampa and Jacksonville; state government digital services, where accessibility is a legal requirement; and a growing technology and startup sector in Miami.

Special Information

Prerequisites and position in the curriculum

FGCU requires COP 3003 — object-oriented programming — which places the course after the core programming sequence. Practice varies; some institutions require data structures, and some run HCI with a lighter prerequisite specifically so that students from psychology, design and information science can take it, which is a defensible choice given the field's interdisciplinarity.

What the prerequisite actually buys is the ability to build a working prototype. A course gated on programming can require an implemented interface; one that is open to non-programmers will use design tools instead. Neither is better, and it is worth knowing which yours is — a computer science student hoping to write code may find a design-tool-based section frustrating, and vice versa.

CEN4721 is an upper-division elective in computer science and software engineering, normally junior or senior year. The CEN prefix is the SCNS software engineering prefix, which situates the course as engineering rather than as design. It pairs with software engineering, web development, mobile development, database systems and — for the research methods — with psychology's statistics and experimental design courses.

⚠ Sections vary substantially: design-led, research-led, or implementation-led

HCI is broad enough that instructors make genuine choices, and three designs are common:

• Design-led — heavy on the design process, prototyping in Figma, heuristics and design critique. Produces the strongest portfolio pieces.
• Research-led — heavy on user research methods, experimental design, statistics and evaluation. The best preparation for UX research roles and for graduate study.
• Implementation-led — students build working interactive systems and evaluate them. The most natural fit inside a computer science degree and the one the CEN prefix suggests.

Most sections mix them; the weighting differs. Read the syllabus if you have a specific goal, and note that a research-led section may require statistics you have not taken.

Course format and workload

Taught as a lecture and studio combination, almost always with a term-long team project that runs the full design cycle: research, requirements, prototype, evaluate, iterate. Assessment weights the project heavily, alongside individual design exercises, a heuristic evaluation or usability test report, and examinations.

Expect six to ten hours a week outside class. The reading is accessible; the project is the workload, and it is unevenly distributed — user research and usability testing both require scheduling other people, which students consistently underestimate.

⚠ Three practical warnings.

• Recruit participants early. Finding five people who will give you forty minutes is harder than it sounds, and it cannot be done the night before. Start in week two.
• ⚠ Check whether your project needs IRB approval. Research involving human participants generally requires institutional review board review — classroom exercises are often exempt or covered by a blanket protocol, but this varies by institution and by whether you intend to publish or present the results. Ask your instructor in the first week; discovering the requirement after collecting data is a genuine problem and the data may not be usable.
• Do not skip the low-fidelity stage. Teams reliably want to start building the polished thing. Paper prototypes tested on real people in week three prevent building the wrong thing for ten weeks, and that is the entire argument of the course demonstrated on your own project.

⚠ What students most often get wrong

• Designing for themselves. The most fundamental error, and the reason every method in the course exists.
• Inventing personas. A persona assembled from imagination is an assumption with a photograph attached, and it makes the assumption harder to question.
• Leading the participant during a usability test. "Now you'd click here, wouldn't you?" produces nothing. The facilitator's job is to be nearly useless, and it is uncomfortable.
• Defending the design when it fails. If a participant cannot complete the task, the interface is wrong — explaining what they should have done is a data point about you, not about them.
• Treating accessibility as a final checklist. Retrofitting is expensive and produces worse results than designing for it from the start.
• Confusing aesthetics with usability. They are related — the aesthetic-usability effect is real — but an attractive interface can be unusable and a plain one excellent.
• Testing too late. Evaluation after the build is a report card; evaluation during the design is the method.

⚠ Accessibility is a legal matter, not only an ethical one

Worth stating plainly because students consistently underestimate it. Digital accessibility litigation in the United States has grown substantially, the Americans with Disabilities Act has been applied to websites and applications in a large body of case law, Section 508 governs federal procurement, and public institutions — including Florida's universities and state agencies — operate under accessibility obligations.

The practical consequence for a graduate: an employer will expect you to know what WCAG is and to be able to work to it. The skills are learnable in a few weeks — semantic structure, keyboard operability, contrast, text alternatives, focus management — and accessibility competence is in genuine short supply, which makes it one of the more reliable ways for a new graduate to be immediately useful.

Articulation and transfer

CEN4721 carries the same SCNS number across Florida public institutions and SCNS equivalency governs transfer of the credit. As an upper-division course it does not appear in A.A. programmes.

Two notes. The section variation above means a receiving department may ask what was covered where the course satisfies a specific requirement; keep the syllabus. And as elsewhere in computing, the artefacts are better evidence than the transcript — keep the project, the research findings and the usability report, since in this field they are simultaneously the transfer evidence and the portfolio.

AI Integration

HCI is a field where these tools are both a design material and a design problem, and the course should treat them as both.

Where the tools help a student or practitioner. Generating design alternatives quickly to widen the space before converging, which is a legitimate use of speed. Drafting interface copy — button labels, error messages, empty states — which is real design work that is frequently done badly. Summarising user research, such as clustering themes across interview transcripts, with the important caveat below. Generating realistic test data and content for prototypes, which beats lorem ipsum. Writing prototype code. And producing a first-pass heuristic evaluation as a checklist to work from.

⚠ Where they fail, and the failures cut to the field's core commitment.

Generated "user research" is not user research. Asking a model what users would want produces a plausible summary of what is commonly written about users — which is precisely the intuition-substituting-for-evidence that this entire discipline exists to prevent. Synthetic personas and simulated user feedback are the most dangerous application in this domain, because they produce a confident, well-organised artefact that looks like research and contains no contact with any actual person. If your project's persona came from a model, you have designed for an average of the internet.

Summarising real transcripts requires care, and consent. Clustering themes across interviews you actually conducted is a reasonable use — but participant data is subject to the consent you obtained and to your institution's data rules, and pasting transcripts into a general-purpose tool may breach both. Check before doing it.

Accessibility cannot be established by automated checking. Automated tools — WAVE, axe, Lighthouse — detect a well-documented minority of accessibility problems, commonly cited at around a third. Keyboard operability, focus order, meaningful alternative text, and whether a screen reader announces something comprehensible all require a human and, ideally, a user of the technology. A page that passes automated checks can be unusable.

Generated designs converge on convention. That is often correct — conventions exist because they work — but it means these tools reproduce the current average, including its exclusions, and cannot tell you that your particular users need something different.

The other half: AI as a design material, which is now core HCI content. Designing interfaces for probabilistic systems raises genuinely new problems that the field is actively working on, and a student should be able to name them:

• Communicating uncertainty — how an interface conveys that an output may be wrong, without either undermining the feature or inviting overtrust.
• Calibrated trust — the documented tendency toward automation bias, where people accept system output uncritically, set against the opposite failure of ignoring a system that is usually right.
• Explanation and contestability — whether a user can find out why, and whether they can disagree and be heard.
• Graceful failure — designing for the case where the model is confidently wrong, which is the normal case rather than an edge case.
• Non-determinism in the interface, which breaks the consistency and predictability that this course teaches as fundamental — a genuinely unresolved tension worth raising in class.

Academic integrity. Read your instructor's policy. The point specific to this course: the research and the usability testing are the assessment because they are the only route to the discipline's central habit — replacing your assumption about what works with evidence about what does. A student who generates their user research has practised exactly the error the course was designed to correct.