Human Computer Interfaces

Course Description

Human Computer Interfaces examines the basic elements of design and evaluation of computer interfaces along with standard evaluation methods. Students complete a design project involving development of a prototype to fulfil a set of requirements, together with a full evaluation of the prototype's usability.

Within the SCNS taxonomy, CEN is the Computer Engineering prefix, and the 3000-level number places this in the upper division. Daytona State publishes it at 3 credits, prerequisites COP2800, COP2001C, COP2220, or COP2360, offered fall and spring, giving approximately 45 contact hours consistent with the published CEN4010 in this repository.

The distinctive feature of this course within a computing curriculum is that correctness is not sufficient. Software that implements the specification exactly and that users cannot operate has failed, and the failure is not visible in any test the developer would normally write. HCI is the discipline that makes that failure detectable — through evaluation methods that are systematic rather than impressionistic.

Learning Outcomes

Required Outcomes

• Describe the field of human-computer interaction and its relationship to software engineering.
• Describe human perceptual, cognitive, and motor capabilities relevant to interface design.
• Describe memory, attention, and cognitive load and their design implications.
• Apply models of human performance, including Fitts's law, to interface decisions.
• Apply the user-centred design process and describe its iterative structure.
• Conduct requirements gathering through interviews, observation, and task analysis.
• Develop personas and scenarios grounded in research.
• Perform task analysis and model user workflows.
• Apply interface design principles, including visibility, feedback, consistency, and constraints.
• Apply recognized usability heuristics to design and evaluation.
• Design information architecture and navigation structures.
• Apply visual design fundamentals: layout, grouping, hierarchy, typography, and colour.
• Design for error prevention, and for recovery when errors occur.
• Design interaction styles appropriate to the task and the platform.
• Produce wireframes and low-fidelity prototypes.
• Build a working interactive prototype fulfilling stated requirements.
• Conduct heuristic evaluation and report findings with severity ratings.
• Plan and conduct usability testing with representative users.
• Select and apply appropriate usability metrics.
• Analyze evaluation data and prioritize findings for remediation.
• Iterate a design in response to evaluation evidence.
• Apply accessibility requirements and standards to interface design.
• Apply research ethics when working with human participants.

Optional Outcomes

• Describe mobile and touch interaction design.
• Describe voice, conversational, and multimodal interfaces.
• Describe A/B testing and analytics-informed design.
• Describe computer-supported cooperative work.
• Describe design systems and component libraries.
• Describe ethical issues in persuasive interface design.

Major Topics

Required Topics

• The field of HCI and its relation to software engineering
• Human perception, cognition, and motor capability
• Memory, attention, and cognitive load
• Models of human performance; Fitts's law
• The user-centred design process
• Requirements gathering and task analysis
• Personas and scenarios
• Design principles: visibility, feedback, consistency, constraints
• Usability heuristics
• Information architecture and navigation
• Visual design fundamentals
• Error prevention and recovery
• Interaction styles and platform conventions
• Wireframing and low-fidelity prototyping
• Building an interactive prototype
• Heuristic evaluation
• Usability testing methodology
• Usability metrics
• Analyzing and prioritizing findings
• Iteration from evidence
• Accessibility standards
• Ethics of human participant research

Optional Topics

• Mobile and touch interaction
• Voice and conversational interfaces
• A/B testing and analytics
• Computer-supported cooperative work
• Design systems
• Ethics of persuasive design

Resources & Tools

• The Design of Everyday Things (Don Norman) — the foundational text on affordances, signifiers, and feedback; short and genuinely changes how you look at objects.
• Designing the User Interface (Shneiderman et al.) — the standard HCI textbook for a course at this level.
• Don't Make Me Think (Steve Krug) — practical, and the best short account of low-cost usability testing.
• Rocket Surgery Made Easy (Krug) — a step-by-step guide to running your own tests; directly applicable to the course project.
• Nielsen Norman Group (nngroup.com) — free articles and the ten usability heuristics, which are the evaluation framework this course teaches.
• Figma — industry-standard prototyping with a free tier and education plan; Penpot is free and open-source.
• WCAG (w3.org/WAI) — free and authoritative; the accessibility standard your work is measured against legally.
• WebAIM — free contrast checker and accessibility evaluation tools.
• Apple Human Interface Guidelines and Google Material Design — free platform conventions.
• System Usability Scale (SUS) — free, ten items, and the most widely used standardized usability questionnaire; use it in the project.

Career Pathways

• Software developer — with interface competence, which is a genuine differentiator in front-end and application roles.
• UX engineer — the role that sits between design and implementation; the programming prerequisite makes this the natural target.
• UX designer and product designer — with portfolio development; see this repository's GRA2134C guide on the design-side pathway.
• UX researcher — evaluation-focused, and this course's methods are the foundation.
• Front-end developer — where design decisions become code.
• Accessibility specialist — a growing, well-paid niche driven by legal exposure.
• Product manager — understanding users is the core of the role.
• Quality assurance and usability testing.
• Human factors engineering — safety-critical interfaces in aviation, medical devices, and defence; Florida's aerospace and simulation sector is relevant here.
• SOC codes 15-1255 Web and Digital Interface Designers, 15-1252 Software Developers, and 17-2112 Industrial Engineers for human factors roles.

Special Information

⚠ You are not the user — this is the course's central correction

The finding that makes systematic evaluation necessary rather than optional.

Developers are systematically miscalibrated about their own software. You know where every feature is, you understand the underlying model because you built it, and you are far more technically fluent than the people who will use the system. Your intuitions about clarity are unreliable in a specific, predictable direction, and no amount of care corrects for it.

• The curse of knowledge is measurable. Once you know something, you cannot accurately estimate how difficult it is for someone who does not — which is why "it's obvious" is a warning sign rather than a defence.
• Test with representative users, not with classmates who share your background, and not with yourself.
• Five participants find most usability problems. The well-known finding from the usability literature is that serious problems are encountered by nearly everyone, so a small sample surfaces the large majority — beyond that you are re-finding the same issues. This makes testing cheap enough that there is no excuse for skipping it.
• Give tasks, not tours. "Book a flight to Atlanta under $300" produces data; "what do you think of this screen?" produces politeness.
• Say nothing while they work. The urge to help is strong and it destroys the data. Silence is the method.
• Watch behaviour, not opinion. People are unreliable narrators of their own behaviour and are reliably kind about your work — where they hesitate matters more than what they say afterwards.
• Test early and rough. A paper prototype tested in week three is worth more than a polished build tested in week twelve, because in week three the structure can still change.

⚠ Accessibility is a legal requirement, not a feature request

The professional obligation that a computing course must state plainly, because it carries real exposure.

• Inaccessible software creates legal risk in the United States. The ADA has been applied to websites and applications in a substantial and growing body of litigation; Section 508 governs federal agencies and their contractors; and public institutions — including Florida's colleges and universities — operate under accessibility obligations. WCAG is the standard courts and procurement documents reference.
• Keyboard operability is the baseline. Everything must be reachable and operable without a mouse, with a visible focus indicator and a sensible focus order. Removing focus outlines because they are ugly is the single most destructive small decision in interface development.
• Colour contrast has numeric minimums, and light grey on white fails them however fashionable it looks.
• Colour alone must never convey meaning — pair it with text, shape, or an icon.
• Semantic markup does most of the work. Using correct elements, labelling form controls, and providing meaningful alternative text gives assistive technology what it needs; a wall of unlabelled generic containers does not.
• Test with a screen reader and with the keyboard only. Both are free and take an hour to try, and the experience is instructive in a way guidelines are not.
• Automated checkers catch a minority of issues. They are necessary and not sufficient.

The framing worth internalizing: accessible design is better design for everyone — captions help in noisy rooms, keyboard operability helps power users, and clear focus states help everybody. Designing for the edge improves the middle. Rule 11 applies; WCAG versions and the legal landscape both change.

⚠ Evaluate systematically — heuristics and testing do different jobs

The methodological content, and knowing which method answers which question is the professional skill.

• Heuristic evaluation is expert inspection against a set of principles — Nielsen's ten are the standard. It is fast, cheap, requires no participants, and finds a broad set of problems. It also reflects expert judgement rather than actual user behaviour, and different evaluators find different issues, which is why several evaluators are used.
• Usability testing observes real users attempting real tasks. It finds the problems that matter and it is the only method that tells you what people actually do. It costs more and covers less of the interface.
• Use both. Heuristic evaluation first to remove the obvious problems, then testing so participants' time is spent on the issues inspection cannot find.
• Rate severity. A finding without a severity rating gives no basis for prioritization, and reporting fifty equally weighted issues is not actionable.
• Report findings, not opinions. "Three of five participants could not locate the export function; two abandoned the task" is a finding. "The navigation is confusing" is not.
• Measure appropriately — task completion, time on task, error rate, and a standardized instrument such as the SUS. Standardized instruments allow comparison across iterations, which is what demonstrates improvement.
• Ethics apply. Working with human participants requires informed consent, the right to withdraw, and appropriate data handling — and university projects may require review. Ask your instructor about institutional requirements before recruiting.

⚠ Build the prototype to be tested, not to be admired

Practical guidance on the course's central deliverable.

• Fidelity should match the question. Early structural questions are answered by paper or wireframes; interaction and flow need a clickable prototype; performance and real-data behaviour need working code. Building high fidelity too early wastes effort and, worse, makes people reluctant to change the design.
• Prototype the risky part. Build the interaction you are least sure about rather than the one you know how to build.
• The prototype is disposable. Its purpose is to generate information, and becoming attached to it defeats that.
• Document the requirements it fulfils, since the course specifies a prototype against stated requirements — traceability between requirement, design decision, and evaluation finding is what makes the project rigorous.
• Show your iterations. The evidence of a design changing in response to findings is the substance of the project, and a report that presents only the final design has omitted the argument.
• Use it as portfolio material. A documented case study — problem, research, alternatives considered, prototype, evaluation, changes made, outcome — is exactly what UX and front-end employers read, and it is more persuasive than a screenshot.

One connected ethical point worth naming: the same techniques that make interfaces easy to use make them effective at manipulation. Interfaces that exploit habit and attention to produce decisions users would not otherwise make — hard-to-cancel subscriptions, pre-checked consent, hidden costs revealed late — are collectively called dark patterns, and they now draw regulatory enforcement. A designer's obligation runs to the user as well as to the client.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement.

CEN3722 is 3 credits and approximately 45 contact hours, offered fall and spring, matching the published CEN4010. Assessment centres on the design project — requirements, prototype, and full usability evaluation — with supporting written work and examination on principles and methods.

CEN3722 is upper division and will not be satisfied by a lower-division web design or programming course. Students arriving from an A.S. should note that A.S. degrees are applied and do not carry the A.A.'s guaranteed junior-status transfer, though Florida institutions publish B.S. in Information Technology pathways designed for that population.