Course & Module Outcomes

Module 1: 1 - HCI Foundations and Course Project Setup

Topics

Introduction to Human-Computer Interaction

• What Is HCI? — Human-Computer Interaction is the study of how people interact with computers and how to design those interactions to be effective, efficient, and satisfying.
• Core HCI Principles — Several foundational principles guide HCI practice, including usability, accessibility, feedback, and consistency.
• The User-Centered Design Process — User-Centered Design (UCD) is an iterative design framework that places the user's needs, goals, and limitations at the forefront of each design decision.
• HCI and the Software Development Lifecycle — HCI considerations appear at every stage of software development, from planning and design through testing and maintenance.
• Why HCI Matters for This Course — This course applies HCI principles directly through a team project that spans design, prototyping, and development using industry tools.

Version Control with GitHub

• What Is Version Control? — Version control is a system that records changes to files over time, allowing teams to track history, collaborate without conflict, and revert to earlier states when needed.
• GitHub as a Collaboration Platform — GitHub is the world's most widely adopted developer platform, providing cloud-hosted Git repositories alongside tools for project planning, code review, and team communication.
• Creating and Configuring a Repository — Each team will create a shared GitHub repository that serves as the single source of truth for all project code and documentation.
• Branching and Pull Requests — Branching allows team members to develop features or fixes in isolation before merging changes into the main codebase through a pull request review process.
• GitHub for Project Management — Beyond code, GitHub provides Issues and Projects boards that help teams track tasks, assign responsibilities, and monitor progress throughout the course.

Design Collaboration with Figma

• What Is Figma? — Figma is a browser-based, multiplayer design tool used by professional designers and engineers to create graphics, wireframes, interactive prototypes, and design systems.
• Setting Up the Education Team Workspace — Students must create a Figma account with their school email, verify their student status, and join or create a team workspace to unlock free professional collaboration features.
• FigJam for Ideation and Brainstorming — FigJam is an online whiteboard tool within the Figma ecosystem designed for brainstorming, diagramming, and collaborative planning activities.
• Designing UI with Figma — Figma's design canvas allows teams to create wireframes, high-fidelity mockups, and interactive prototypes that simulate the final user experience.
• Dev Mode: Bridging Design and Code — Figma's Dev Mode workspace allows developers to inspect designs and extract precise measurements, styles, and auto-generated code snippets, reducing miscommunication between design and development.

AI Tools in HCI and Development

• How AI Supports the Design Process — AI tools assist designers by suggesting UI layouts, identifying design inconsistencies, and automating visual testing, enabling faster and more informed design decisions.
• AI Coding Assistants — AI coding assistants like GitHub Copilot provide real-time code suggestions, generate boilerplate, explain code, and assist with debugging, helping developers work faster and with fewer errors.
• AI Across the Software Development Lifecycle — AI tools support every phase of the SDLC, from analyzing requirements and predicting risks in planning, to monitoring performance and fixing bugs after deployment.
• Responsible Use of AI in This Course — While AI tools are encouraged as productivity aids, students are responsible for understanding, reviewing, and standing behind all AI-assisted work they submit.

Development Environment Setup

• Choosing a Code Editor — A code editor is the primary tool through which developers write and manage code; selecting and configuring it correctly at the start of a project ensures consistency across the team.
• Installing and Configuring Git Locally — Git must be installed on each student's machine and configured with their identity before they can interact with the team's GitHub repository from the command line.
• Cloud Development with GitHub Codespaces — GitHub Codespaces provides a full, cloud-based development environment accessible from any browser, eliminating setup inconsistencies across different machines and operating systems.
• Project Folder Structure and Conventions — Establishing a consistent folder structure and naming convention at the start of the project reduces confusion, prevents merge conflicts, and makes the codebase easier to navigate for all team members.
• Verifying the Complete Setup — Before closing out the first module, every team member should verify that their full environment is working by completing a short end-to-end test: edit a file, commit it, push to GitHub, and confirm it appears in the shared repository.

Team Collaboration and Project Kickoff

• Forming Effective Project Teams — Project teams in this course are structured to mirror cross-functional product teams in industry, combining students with different strengths across design, development, and project coordination.
• Defining Team Roles and Responsibilities — Assigning clear roles at the start of the project ensures accountability and prevents work from falling through the gaps during collaborative development.
• Creating the Team Charter — A team charter is a brief agreement that documents the team's goals, working norms, communication channels, and conflict resolution approach before work begins.
• Scoping the Course Project — Each team selects and defines the scope of their course project in week one, producing a brief problem statement and initial set of user goals that will drive the entire design and development process.
• End-of-Module Readiness Checklist — By the end of this module, every team must have all project infrastructure operational and documented so that week two collaborative work can begin without setup delays.

Learning Outcomes

Module 2: 2 - Project Scoping and App Platform Selection

Topics

Defining Project Scope in HCI Design

• What Is Project Scope? — Project scope defines the boundaries of a design project, including what will and will not be addressed during the design process.
• Identifying Project Goals — Project goals articulate the intended outcomes of the design effort, providing direction for all subsequent design and development decisions.
• Defining Constraints — Constraints are the limitations — such as time, budget, technology, and team expertise — that shape what is feasible within the project.
• Scoping the Target User Audience — Understanding who will use the application is a foundational scoping decision that influences platform choice, feature prioritization, and design style.
• Writing a Formal Project Description — The formal project description is a structured document that captures the project's goals, constraints, target audience, chosen platform, and selected tools in one authoritative reference.

Overview of Target Application Platforms

• The Four Primary Platforms — This course focuses on four main application platforms: Android mobile, iOS mobile, Windows desktop, and Web-based applications, each with distinct design paradigms and audiences.
• Beyond the Four: Additional Platforms — While this course centers on desktop, mobile, and web applications, HCI designers should be aware that interactive applications are also deployed on platforms such as wearables, voice assistants, smart TVs, and AR/VR environments.
• Platform Categories: Mobile, Desktop, and Web — The three broad categories of platforms — mobile, desktop, and web — each represent different user contexts, interaction models, and technical environments.

Android Platform: Characteristics and Constraints

• Android Platform Overview — Android is an open-source mobile operating system developed by Google, running on a vast range of devices from numerous manufacturers worldwide.
• Android Design Conventions — Android applications follow Material Design principles, which emphasize tactile surfaces, motion, and adaptive layouts to create consistent and intuitive user experiences.
• Android Constraints and Considerations — Designing for Android requires awareness of device fragmentation, varied hardware capabilities, and permission-based access to device features.

iOS Platform: Characteristics and Constraints

• iOS Platform Overview — iOS is Apple's mobile operating system, powering iPhone and iPad devices, and is known for its consistency, performance, and tightly controlled hardware-software integration.
• iOS Design Conventions — iOS applications follow Apple's Human Interface Guidelines, emphasizing clarity, deference to content, and depth through layering and translucency.
• iOS Constraints and Considerations — iOS development and distribution are tightly controlled by Apple, which introduces both quality assurances and constraints for designers and developers.

Windows Platform: Characteristics and Constraints

• Windows Platform Overview — Windows is the dominant desktop operating system for personal and enterprise computing, supporting complex, feature-rich applications designed for productivity and professional use.
• Windows Design Conventions — Windows applications follow Microsoft's Fluent Design System, which emphasizes light, depth, motion, material, and scale to create coherent and accessible desktop experiences.
• Windows Constraints and Considerations — Designing for Windows involves accounting for a wide range of hardware configurations, OS versions still in use, and the expectations of productivity-focused users.

Web Platform: Characteristics and Constraints

• Web Platform Overview — Web applications run in browsers and are accessible across virtually all devices and operating systems without requiring installation, making the web the most universally accessible platform.
• Web Design Conventions — Web application design is guided by established usability conventions, WCAG accessibility standards, and responsive design principles rather than a single platform's design system.
• Web Platform Constraints and Considerations — Web applications are constrained by browser compatibility, network dependency, security sandboxing, and the limitations of web APIs compared to native platform APIs.

Platform Selection: Criteria and Decision-Making

• User Audience as a Primary Driver — The most important factor in platform selection is matching the platform to where the target users actually are and how they prefer to interact with technology.
• Platform Capability Alignment — The project's required features must align with what the chosen platform can support, including hardware access, performance requirements, and available APIs.
• Team Skills and Tool Availability — The practical skills of the project team and the availability of appropriate tools should factor into the platform decision, particularly within an academic project context.
• Documenting and Justifying the Platform Choice — The platform selection decision must be explicitly documented in the formal project description, including the rationale based on audience, capability, and team constraints.

Design and Development Tools by Platform

• Design and Prototyping Tools — Regardless of platform, HCI projects typically begin with wireframing and prototyping tools that allow designers to explore and test ideas before committing to development.
• Android Development Tools — Android application development is primarily done using Android Studio, Google's official IDE, with Kotlin as the recommended programming language.
• iOS Development Tools — iOS applications are developed using Xcode, Apple's IDE, with Swift as the primary programming language, both of which require a macOS computer.
• Windows Development Tools — Windows applications are developed primarily using Visual Studio or Visual Studio Code, with languages and frameworks such as C#, WinUI 3, and .NET being the standard choices.
• Web Development Tools — Web application development uses browser-based and cross-platform tools, with HTML, CSS, and JavaScript forming the foundational technology stack.
• Cross-Platform Tools and Frameworks — Cross-platform frameworks allow a single codebase to target multiple platforms, which can be advantageous for teams with limited resources but introduces trade-offs in native experience quality.

Learning Outcomes

Module 3: 3 - Use Case Scenarios and Requirements Gathering

Topics

Introduction to Use Case Scenarios

• What Is a Use Case Scenario? — A Use Case Scenario is a narrative description of how a user interacts with a system to achieve a specific goal. It captures the sequence of steps, decisions, and outcomes involved in a single interaction path.
• Role of Use Cases in Requirements Gathering — Use cases serve as a primary vehicle for eliciting and documenting software requirements by grounding abstract needs in real user behavior. They ensure that requirements reflect actual usage rather than assumed functionality.
• Key Components of a Use Case — A well-formed use case includes a title, actor, preconditions, main success scenario, alternative flows, and postconditions. Each component ensures the scenario is complete and unambiguous.
• Use Cases vs. User Stories — Use cases and user stories are both tools for capturing requirements, but they differ in scope, format, and level of detail. Understanding the distinction helps teams choose the right tool for their methodology.

Identifying Stakeholders and Users

• Defining Stakeholders — Stakeholders are any individuals, groups, or organizations that have an interest in or are affected by the software system. Identifying all stakeholders early prevents overlooked requirements later in the project.
• Distinguishing Users from Stakeholders — While all users are stakeholders, not all stakeholders are users. Users are the actors who directly interact with the system interface, whereas other stakeholders may only experience its effects.
• Stakeholder Needs vs. User Goals — Stakeholder needs describe the broader business or organizational outcomes desired from the system, while user goals describe what individual users want to accomplish in a specific interaction. Both must be captured and reconciled.
• User Roles and Permissions — Different user roles often require different levels of access and capability within the same system. Mapping roles to use cases ensures the interface and security model reflect real-world responsibilities.
• Techniques for Stakeholder Identification — Several structured techniques help analysts systematically identify all relevant stakeholders and user roles. Using multiple techniques reduces the risk of omitting important participants.

Requirements Gathering Techniques

• Overview of Requirements Elicitation — Requirements elicitation is the process of discovering, extracting, and articulating what a system must do by engaging with stakeholders and users. Choosing the right elicitation technique for each context improves the quality and completeness of requirements.
• Interviews and Contextual Inquiry — Interviews allow analysts to engage directly with stakeholders to uncover goals, workflows, pain points, and constraints. Contextual inquiry extends this by observing users in their actual work environment.
• Workshops and Focus Groups — Collaborative sessions bring multiple stakeholders together to align on requirements, resolve conflicts, and generate use case ideas collectively. Facilitated workshops are especially effective for complex systems with diverse user groups.
• Surveys and Questionnaires — Surveys allow analysts to gather input from large numbers of stakeholders or users quickly and cost-effectively. They are best suited for validating assumptions or gathering quantitative data about usage patterns.
• Document Analysis and Existing System Review — Reviewing existing documentation, legacy systems, and process manuals provides a baseline of current functionality and workflows. This technique is especially valuable when modernizing or replacing an existing system.

Task Analysis

• What Is Task Analysis? — Task analysis is a technique for understanding how users accomplish goals by breaking their work into discrete, observable steps and decisions. It provides the behavioral foundation for writing realistic use case scenarios.
• Hierarchical Task Analysis (HTA) — Hierarchical Task Analysis decomposes a high-level goal into sub-tasks and further into individual actions, creating a tree structure that maps the full scope of a user's work. HTA is one of the most widely used task analysis methods in requirements engineering.
• Cognitive Task Analysis — Cognitive Task Analysis (CTA) focuses on the knowledge, decisions, and mental processes involved in performing a task, rather than just the observable actions. It is essential for tasks that require expertise, judgment, or complex problem-solving.
• Mapping Task Analysis to Use Cases — The outputs of task analysis feed directly into use case writing by providing the step sequences, decision points, and alternative paths that define each scenario. This mapping ensures use cases reflect real user behavior rather than assumed workflows.
• Validating Task Models with Users — Task models must be verified with actual users to ensure they accurately reflect real work practice rather than idealized or assumed behavior. Validation prevents use cases from being built on incorrect assumptions.

Writing Use Case Scenarios

• Structuring a Use Case Document — A Use Case document follows a consistent template that ensures every scenario is described with the same level of rigor and detail. Consistent structure makes use cases easier to review, trace, and maintain.
• Writing the Main Success Scenario — The main success scenario describes the ideal interaction path where everything goes as expected and the user achieves their goal without errors or exceptions. It is written as a numbered sequence of actor and system actions.
• Documenting Alternative Flows — Alternative flows describe valid variations from the main path that still result in the user achieving their goal or a defined outcome. They capture the realistic diversity of how users interact with a system.
• Documenting Exception Flows — Exception flows capture what happens when an error, system failure, or invalid input interrupts the normal interaction. They ensure the system handles failure states gracefully and the interface provides appropriate feedback.
• Specifying Preconditions and Postconditions — Preconditions define the state the system and user must be in before the use case can begin, while postconditions define the guaranteed state after the scenario completes successfully. Together they define the boundary conditions for each scenario.
• Writing Clear and Unambiguous Steps — Each step in a use case must be written precisely enough to be unambiguous to all readers, including developers, testers, and non-technical stakeholders. Ambiguity in step descriptions is a direct source of requirement defects.

Enumerating Usage Paths and Edge Cases

• What Are Edge Cases? — Edge cases are scenarios that occur at the boundary of normal operating conditions, involving unusual inputs, extreme values, or rare but valid user behaviors. Failing to account for edge cases is a frequent source of system defects and poor user experience.
• Techniques for Enumerating Usage Paths — Systematic enumeration of usage paths ensures that requirements coverage is complete rather than representative. Several structured techniques help analysts move beyond obvious scenarios to discover the full interaction space.
• User Diversity and Context Variation — Users differ in experience level, accessibility needs, device capabilities, and operating environments, all of which create distinct interaction paths. Designing for diverse users requires explicitly documenting how these differences affect use case flows.
• Documenting Frequency and Priority — Not all use cases are equally important or frequent, and documenting their relative frequency and business priority helps teams focus design and development effort appropriately. Priority ratings also guide testing and risk management.
• Reviewing for Completeness — A structured review process is needed to confirm that the complete use case set covers all identified actors, goals, tasks, and interaction contexts without redundancy or gaps. Completeness reviews should involve multiple stakeholders.

Documenting and Communicating Requirements

• Organizing a Use Case Repository — A use case repository organizes all scenarios in a structured, searchable, and version-controlled format that supports ongoing project work. Effective organization ensures that use cases remain a living reference rather than a static document.
• Traceability Between Requirements and Use Cases — Traceability links use cases to the stakeholder needs, system requirements, design decisions, and test cases they relate to. Maintaining traceability ensures that every requirement is implemented and tested.
• Communicating Use Cases to Stakeholders — Use cases must be presented in a format accessible to the intended audience, which varies from technical developers to non-technical business stakeholders. Tailoring communication style and detail level improves stakeholder engagement and review quality.
• Maintaining Use Cases Through Change — Requirements evolve throughout a project, and use cases must be updated to reflect approved changes in a timely and controlled manner. A change management process prevents use cases from becoming outdated or contradictory.
• Use Cases as Input to Design and Testing — Use case scenarios are a primary input for interface design, providing designers with the task flows and interaction contexts needed to create relevant prototypes and wireframes. They also serve as the basis for acceptance test case development.

Learning Outcomes

Module 4: 4 - Task Analysis for Interface Design

Topics

Foundations of Task Analysis

• What Is Task Analysis? — Task analysis is a systematic process for studying and understanding how users accomplish goals, breaking complex behaviors into discrete, observable steps.
• The Role of User Goals — Every task analysis begins with clearly identifying user goals, which define the end state a user is trying to reach through interaction with a system.
• Why Task Analysis Informs Interface Structure — The decomposed steps produced by task analysis directly map onto interface components, navigation flows, and interaction sequences.
• Observable vs. Cognitive Steps — Tasks include both observable physical actions, such as clicking or typing, and internal cognitive steps, such as deciding or recalling information.

Hierarchical Task Analysis (HTA)

• Principles of HTA — Hierarchical task analysis organizes tasks in a parent-child tree structure, where each high-level goal is progressively broken down into smaller, actionable subtasks.
• HTA Notation and Diagrams — HTA is typically represented as a numbered tree diagram or an indented outline, using plans to specify the order and conditions under which subtasks are performed.
• Decomposition Process in HTA — Decomposition in HTA proceeds by asking 'what does the user need to do to accomplish this task?' at each level until reaching steps that are atomic enough to inform design.
• Applying HTA to Interface Design — The completed HTA tree translates directly into design artefacts such as sitemaps, user flows, and screen wireframes.

Cognitive Task Analysis (CTA)

• What CTA Adds Beyond HTA — Cognitive task analysis extends beyond observable actions to capture the knowledge, judgments, and mental models users rely on when performing tasks.
• Key CTA Techniques — Common CTA techniques include think-aloud protocols, critical decision method interviews, and knowledge audits, each suited to different task types and research constraints.
• Identifying Decision Points and Mental Models — CTA explicitly maps the points in a task where users must make judgments, and documents the mental models they use to interpret system states and choose next actions.
• Representing CTA Findings — CTA results are typically documented in annotated task diagrams, decision ladders, or structured tables that capture actions alongside their associated cognitive demands.
• CTA Findings in Interface Design — CTA outputs directly inform decisions about information architecture, feedback mechanisms, error prevention, and the depth of guidance provided within an interface.

Comparing and Selecting Analysis Methods

• Strengths and Limitations of HTA — HTA is highly efficient for structured, procedural tasks and produces clear, actionable documentation, but it can underrepresent cognitive complexity and user variability.
• Strengths and Limitations of CTA — CTA provides deep insight into user cognition and decision-making but is more resource-intensive to conduct, analyze, and document than HTA.
• Choosing the Right Method — Method selection should be guided by task type, project constraints, the target user population, and the specific design questions the analysis must answer.
• Scoping a Task Analysis — Before conducting any analysis, the scope must be defined by specifying which user groups, goals, and task scenarios are included and which are excluded.

Data Collection for Task Analysis

• Observation Methods — Direct observation of users performing tasks in context provides the most accurate baseline data for task analysis, capturing actual behavior rather than reported behavior.
• Interview and Protocol Methods — Structured and semi-structured interviews complement observation by eliciting user explanations of their goals, reasoning, and decision-making during tasks.
• Using Existing Documentation — Existing materials such as user manuals, support logs, and workflow documentation can supplement primary data collection and speed up initial task decomposition.
• Participant Selection — The validity of task analysis data depends on selecting participants who accurately represent the target user population for the interface being designed.

Producing Task Analysis Documentation

• Components of a Task Analysis Document — A complete task analysis document includes a scope statement, user and goal definitions, the hierarchical or cognitive task diagram, plans or annotations, and design implications.
• Writing Clear Task Descriptions — Each task and subtask should be described with an action verb and a clear object, stating precisely what the user does rather than what the system does.
• Validating the Task Analysis — Completed task analyses should be reviewed against user data and evaluated by team members or subject matter experts to identify gaps, errors, or missing steps.
• Linking Task Analysis to Design Artefacts — Each section of the task analysis should be explicitly connected to a corresponding design artefact, ensuring that structural and cognitive findings are traceable through the design process.
• Group Project Documentation Requirements — For the group project, teams are required to produce a full task analysis document covering at least one primary user goal using both HTA and CTA methods.

Applying Task Analysis to the Group Project

• Identifying Your Project's Primary User Goal — The first step in applying task analysis to the group project is agreeing on a single, well-defined primary user goal that is sufficiently complex to require full decomposition.
• Dividing Data Collection Responsibilities — Effective group task analysis requires clear allocation of data collection roles, with each team member responsible for gathering data from at least one participant or source.
• Building the HTA as a Team — The hierarchical task diagram should be constructed collaboratively, with the full team reviewing and agreeing on the structure before it is finalized.
• Integrating CTA Findings into the Document — Once the HTA structure is agreed upon, the team adds cognitive annotations by reviewing interview and think-aloud data for decision points, knowledge requirements, and cognitive load indicators.
• Reviewing and Finalizing the Project Document — Before submission, the full task analysis document must be reviewed for completeness, consistency, and clear linkage between findings and design implications.

Learning Outcomes

Module 5: 5 - AI-Assisted Design and Development Workflows

Topics

Introduction to AI Coding Assistants in HCI

• What Are AI Coding Assistants? — AI coding assistants are software tools powered by large language models that can generate, complete, explain, and refactor code in response to natural language prompts or partial code input.
• Key Tools: Claude Code, GitHub Copilot, and Codex — Claude Code, GitHub Copilot, and OpenAI Codex represent three distinct but complementary approaches to AI-assisted development, each offering unique integration points and interaction models.
• The Role of AI in the HCI Pipeline — Within the HCI pipeline, AI assistants can contribute at multiple stages including requirements gathering, wireframing support, component generation, and usability testing scaffolding.
• Opportunities and Limitations of AI-Assisted Design — While AI coding assistants can significantly accelerate development velocity, they also introduce risks such as generating technically correct but design-inappropriate code, reinforcing common patterns over novel solutions, and producing inaccessible interfaces.

Effective Prompting Strategies for Design Tasks

• Principles of Effective Prompting — Effective prompting involves providing the AI with sufficient context about the task, the target user, the technology stack, and the desired output format to generate relevant and actionable results.
• Iterative Prompt Refinement — AI-assisted design is rarely a single-step process; effective practitioners treat initial outputs as drafts and use follow-up prompts to refine, constrain, or redirect the AI toward better solutions.
• Prompting for Accessibility and Usability — AI assistants require explicit instruction to generate code that meets accessibility standards such as WCAG 2.1, as they default to common patterns that may not be fully accessible.
• Design System Integration Through Prompting — AI assistants can be guided to produce outputs consistent with an existing design system by providing component token names, style guide excerpts, or example components as part of the prompt context.
• Avoiding Common Prompting Pitfalls — Several common mistakes reduce the quality of AI-assisted design outputs, including underspecifying context, accepting first outputs without review, and treating AI-generated code as production-ready.

AI-Accelerated Prototyping Workflows

• From Wireframe to Code with AI — AI coding assistants can dramatically reduce the time required to translate wireframes into interactive HTML, CSS, and JavaScript prototypes by generating layout scaffolding from natural language descriptions of the wireframe.
• Rapid Component Generation — One of the highest-value applications of AI in prototyping is the rapid generation of reusable UI components such as navigation bars, modal dialogs, forms, and data tables.
• Iterating on Prototypes with AI Assistance — After an initial prototype is generated, AI assistants can support rapid iteration by modifying specific components, adjusting layouts, and incorporating feedback from usability evaluations.
• Balancing Speed and Design Quality — The speed advantage of AI-assisted prototyping must be balanced against the risk of accumulating design debt, where rapid generation produces code that is difficult to maintain, extend, or align with the broader design vision.
• Integrating AI Tools into Team Workflows — When working in teams, AI coding assistants must be integrated thoughtfully to ensure consistency, shared understanding, and equitable contribution across team members.

Maintaining Design Quality in AI-Assisted Projects

• Defining Design Quality in the AI Context — Design quality in AI-assisted projects encompasses not only visual fidelity but also usability, accessibility, performance, and alignment with user needs as surfaced through the HCI research process.
• Heuristic Evaluation of AI-Generated Interfaces — Nielsen's ten usability heuristics provide a structured framework for evaluating AI-generated interface components and identifying usability issues that automated tools may miss.
• Accessibility Auditing of AI-Generated Code — AI-generated interface code frequently requires accessibility remediation, making systematic auditing with both automated tools and manual testing an essential quality assurance step.
• Code Review Practices for AI-Generated Output — AI-generated code should be subject to the same code review practices as human-authored code, with additional attention to areas where AI tools commonly introduce errors, including security, performance, and semantic correctness.
• Preserving the Designer's Voice and Intent — A critical challenge in AI-assisted design is ensuring that the final product reflects deliberate design decisions rooted in user research rather than defaulting to the generic patterns that AI tools favor.

Ethical Considerations and Professional Responsibility

• Attribution and Transparency in AI-Assisted Work — Designers and developers using AI coding assistants have a professional responsibility to be transparent about the role AI played in their work, particularly in academic, professional, and client-facing contexts.
• Bias and Representation in AI-Generated Interfaces — AI coding assistants trained on historical code and design data may reproduce biases related to cultural representation, gender, disability, and other dimensions of diversity in the interfaces they help generate.
• Intellectual Property and Licensing Concerns — AI coding assistants generate outputs derived from training data that may include proprietary or copyrighted code, raising unresolved questions about the intellectual property status of AI-generated artifacts.
• Maintaining Professional Competence — Reliance on AI coding assistants without developing foundational design and development skills can create brittle competency, where practitioners are unable to critically evaluate, debug, or extend AI-generated outputs.
• Responsible AI Use in User-Facing Products — When AI-assisted design and development produces interfaces that will be used by real people, designers bear responsibility for ensuring those interfaces are safe, trustworthy, and respectful of user autonomy.

Learning Outcomes

Module 6: Interface Prototyping with Figma

Topics

Introduction to Figma and the Prototyping Workflow

• The Figma Interface at a Glance — Figma's browser-based environment is divided into a toolbar, layers panel, canvas, and properties panel, all of which work together in real time.
• Pages and File Organisation — Organising work across named pages and clearly labelled frames keeps large projects navigable and supports smooth handoff to developers or evaluators.
• Collaboration and Sharing Basics — Figma is built around real-time multiplayer collaboration, allowing team members and evaluators to view, comment on, or edit a file simultaneously.
• From Mockup to Prototype: The Module Workflow — This module follows a structured sequence: framing screens, building a component library, applying auto-layout, and finally wiring interactions into a navigable prototype.

Frames, Grids, and Screen Layout

• What Is a Frame? — In Figma, a frame is the primary artboard-like container that defines the boundaries of a screen, dialog, or component, and it carries layout and clipping properties not available to basic groups.
• Applying Layout Grids — Layout grids overlay the frame canvas with columns, rows, or a uniform grid, giving designers a visual alignment scaffold that can be hidden before handoff or presentation.
• Constraints and Responsive Anchoring — Constraints determine how child elements reposition or resize when their parent frame is resized, laying the groundwork for designs that adapt across screen sizes.
• Working with Device Presets and Safe Areas — Figma's frame presets provide accurate pixel dimensions for common devices, and designers must account for system UI areas such as status bars and home indicators.
• Organising Screens with Flows — Grouping related frames into named flows helps both the design team and evaluators understand which screens belong to which user journey before prototype wiring begins.

Building a Component Library

• What Is a Component? — A component is a reusable design element defined once as a master and instantiated across screens, so that changes to the master propagate automatically to all instances.
• Creating Components from Existing Elements — Any frame, group, or selection of elements can be converted into a component via the right-click menu or keyboard shortcut, after which it is accessible in the assets panel for reuse.
• Component Variants — Variants allow a single component to encapsulate multiple states — such as default, hover, disabled, and active — organised in a variant container that designers can switch between at the instance level.
• Slots, Nesting, and Component Composition — Complex UI elements are best built by nesting simpler components inside a parent component, a pattern called component composition, which maximises reuse and reduces maintenance overhead.
• Using the Assets Panel and Team Library — The assets panel centralises access to all components, styles, and plugins, and team libraries extend this to share design tokens across an entire organisation or project team.

Auto-Layout for Responsive Elements

• What Is Auto-Layout? — Auto-layout converts a frame into a container that automatically arranges its children in a horizontal or vertical stack, adjusting size based on content, padding, and spacing rules.
• Sizing Modes: Hug, Fill, and Fixed — Each dimension of an auto-layout frame or its children can independently use hug, fill, or fixed sizing, giving fine-grained control over how space is distributed within a layout.
• Spacing, Padding, and Alignment — Auto-layout exposes independent padding controls for top, right, bottom, and left, as well as gap settings and alignment options that determine how children are positioned within the container.
• Building Reusable List and Card Patterns — List items and card components are the most common applications of auto-layout, and building them correctly enables entire list sections to reflow automatically when items are added or removed.
• Auto-Layout and Component Interaction — When auto-layout frames are used as or within components, size changes triggered by variant switching or text overrides propagate automatically, eliminating manual resizing during prototyping.

Interactive Prototyping and Connections

• The Prototype Panel Overview — The prototype panel replaces the design panel when prototyping mode is active, exposing controls for adding interactions, choosing triggers, selecting actions, and configuring transitions between frames.
• Triggers and Actions — An interaction consists of a trigger — the user event that starts it — and an action — what happens as a result, such as navigating to a frame, opening an overlay, or scrolling to a position.
• Transitions and Animation — Figma provides built-in transition types — Instant, Dissolve, Smart Animate, Move In, Move Out, Push, and Slide In — that control how the screen changes during navigation, adding polish to the prototype.
• Scrollable Frames and Fixed Elements — Figma frames can be configured to scroll vertically or horizontally, and individual elements can be pinned to remain fixed during scroll, enabling realistic navigation bars and sticky headers.
• Overlays and Modal Patterns — Overlays allow a second frame to appear on top of the current screen without navigating away, enabling modals, drawers, tooltips, and dropdown menus within a single prototype flow.
• Previewing and Sharing the Prototype — The Figma prototype preview launches a full-screen interactive session directly from the browser, and the share link exposes the same experience to peer evaluators without requiring a Figma account.

High-Fidelity Design and Visual Polish

• Defining and Applying Colour Styles — Colour styles store named fill or stroke values that can be applied across the design and updated globally, functioning as the visual equivalent of CSS custom properties.
• Typography Styles and Text Hierarchy — Text styles standardise combinations of font family, size, weight, line height, and letter spacing, ensuring typographic consistency across all screens without manual reapplication.
• Working with Images and Fills — Figma supports image fills on any shape or frame, enabling realistic photo placement for profile pictures, banners, and product imagery within the mockup.
• Icons and Vector Assets — Icons reinforce meaning in UI design, and Figma supports SVG import, the built-in icon resources, and community icon libraries to provide scalable, stylable icon assets.
• Effects: Shadows, Blurs, and Overlays — Figma's effects panel provides drop shadows, inner shadows, layer blurs, and background blurs that add depth and realism to interface elements such as cards, modals, and frosted-glass navigation bars.

Building and Submitting the Group Project Prototype

• Project Scope and Screen Inventory — Before building, each group should define the exact set of screens required for their prototype, mapped to identified user tasks, to prevent scope creep and ensure complete coverage for evaluation.
• Dividing Work Across Team Members — Effective team collaboration in Figma requires clear ownership of files, pages, or components, combined with a shared component library to ensure visual consistency regardless of who designs each screen.
• Self-Review and Design QA — Before sharing with peers, each group should conduct a structured self-review against a design quality checklist covering layout consistency, component usage, interaction completeness, and content accuracy.
• Setting Up for Peer Evaluation — Preparing the prototype for peer evaluation involves setting the correct starting frame, configuring share permissions, and providing a brief written description of the flows evaluators should test.
• Conducting and Receiving Peer Evaluation — Peer evaluators interact with the shared prototype as a simulated end user, documenting usability observations, navigation breakdowns, and visual inconsistencies using Figma's comment tool.
• Iterating Based on Feedback — After receiving peer evaluation, groups prioritise and address identified issues within the remaining session time, applying fixes directly in Figma and updating the shared prototype link.

Learning Outcomes

Module 7: Cognitive Walkthrough Evaluation Method

Topics

Foundations of the Cognitive Walkthrough Method

• What Is a Cognitive Walkthrough? — A Cognitive Walkthrough is a structured usability inspection method in which evaluators simulate the step-by-step experience of a new user attempting to complete a task.
• Core Theoretical Basis: Exploratory Learning — The Cognitive Walkthrough is grounded in theories of exploratory learning, which describe how users learn interfaces by attempting actions and interpreting feedback without reading manuals.
• Learnability as the Primary Focus — Unlike broader usability evaluations, the Cognitive Walkthrough specifically targets learnability — the ease with which a new user can begin using an interface productively.
• Cognitive Walkthrough vs. Other Inspection Methods — The Cognitive Walkthrough is one of several usability inspection methods, but it is distinguished by its narrow focus on step-by-step task cognition rather than broad heuristic compliance.

Preparing for a Cognitive Walkthrough

• Defining the User Profile — Before conducting the walkthrough, evaluators must establish a clear description of the intended user, including their prior knowledge, experience level, and goals.
• Identifying Task Sequences — A task sequence is a specific, goal-oriented series of actions a user must perform to accomplish something meaningful in the interface.
• Gathering Required Materials — Evaluators need access to the interface prototype, the defined task sequences, the user profile, and a documentation template before beginning the walkthrough.
• Assembling the Evaluation Team — Cognitive Walkthroughs can be conducted by a single evaluator or a small team, with each approach offering different tradeoffs in coverage and efficiency.

The Step-by-Step Cognitive Walkthrough Procedure

• Overview of the Four Evaluative Questions — At each step of a task sequence, evaluators apply four diagnostic questions to determine whether a novice user could successfully complete that action.
• Question 1 — Will Users Try to Achieve the Right Goal? — The first question asks whether the user's current goal aligns with what the interface requires them to do at this step.
• Question 2 — Will Users Notice the Correct Action Is Available? — The second question evaluates whether the relevant control, link, or affordance is visible and perceivable to the user at the moment it is needed.
• Question 3 — Will Users Recognize the Action as Correct? — The third question asks whether users will understand that the available action is the right one to take to progress toward their goal.
• Question 4 — Will Users Understand the Feedback They Receive? — The fourth question evaluates whether the interface provides clear, interpretable feedback after the user completes an action, confirming progress or indicating an error.

Identifying and Documenting Failure Points

• What Constitutes a Failure Point? — A failure point occurs when the answer to any of the four walkthrough questions suggests that a novice user would be unable or unlikely to proceed successfully at that step.
• Categorizing Failures by Type — Failures can be organized by which of the four evaluative questions they violate, which helps prioritize redesign efforts and identify systemic patterns.
• Writing Effective Failure Descriptions — Each documented failure should include the task step where it occurs, the specific question it violates, a description of the problem, and the likely impact on the user.
• Using a Documentation Template — A standardized documentation template ensures consistent recording of findings across all tasks, steps, and prototypes evaluated.
• Distinguishing Severity Levels — Not all failure points carry equal weight; evaluators should assign a severity rating to help designers prioritize their remediation efforts.

Applying the Method to Peer Prototypes

• Understanding the Peer Prototype Evaluation Context — Evaluating a peer's prototype requires maintaining an objective, constructive mindset, applying the method rigorously without personal bias toward the designer or design.
• Selecting Tasks for Each Prototype — For each peer prototype, evaluators must define or confirm at least one representative task sequence that reflects the prototype's intended primary use case.
• Conducting the Walkthrough on Each Prototype — Apply the four-question framework to every action step of the selected task for each prototype, recording pass/fail outcomes and documenting all failure points.
• Comparing Findings Across Three Prototypes — After completing all three walkthroughs, evaluators should reflect on patterns across prototypes to identify common failure types and broader design insights.
• Preparing and Submitting the Evaluation Report — The completed evaluation report consolidates all walkthrough documentation, failure descriptions, severity ratings, and reflective analysis into a structured deliverable.

Interpreting Results and Communicating Findings

• Synthesizing Findings into Patterns — Individual failure points become more meaningful when grouped into patterns that reveal underlying design problems affecting multiple steps or tasks.
• Writing Actionable Recommendations — Each identified failure pattern should be accompanied by a concrete, feasible recommendation that the designer can act upon to improve the interface.
• Presenting Findings to Designers — Communicating Cognitive Walkthrough findings effectively requires framing results constructively, focusing on the user experience rather than designer error.
• Limitations of the Cognitive Walkthrough Method — While powerful for identifying learnability issues, the Cognitive Walkthrough has recognized limitations that evaluators should acknowledge when interpreting and presenting findings.

Learning Outcomes

Module 8: Heuristic Evaluation and Nielsen's 10 Principles

Topics

Introduction to Heuristic Evaluation

• What Is Heuristic Evaluation? — Heuristic Evaluation is a discount usability engineering method that allows experts to identify usability problems in a user interface design without the need for live user testing.
• Origins and Context — Nielsen and Molich developed the heuristic evaluation method in 1990, later refining the set of heuristics to the ten canonical principles that are widely used today.
• When to Use Heuristic Evaluation — HE is appropriate at multiple points in the design lifecycle, from sketches and wireframes through high-fidelity prototypes and live products.
• Advantages and Limitations — HE offers speed, low cost, and the ability to evaluate interfaces without recruiting participants, but it also carries inherent limitations related to evaluator expertise and coverage.

Nielsen's Ten Usability Heuristics

• Heuristic 1 — Visibility of System Status — The system should always keep users informed about what is going on through appropriate feedback within reasonable time.
• Heuristic 2 — Match Between System and the Real World — The system should speak the users' language, using words, phrases, and concepts familiar to the user rather than system-oriented terminology.
• Heuristic 3 — User Control and Freedom — Users often choose system functions by mistake and need a clearly marked 'emergency exit' to leave the unwanted state without having to go through an extended dialogue.
• Heuristic 4 — Consistency and Standards — Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions consistently.
• Heuristic 5 — Error Prevention — Even better than good error messages is a careful design that prevents problems from occurring in the first place.
• Heuristic 6 — Recognition Over Recall — Minimize the user's memory load by making objects, actions, and options visible; the user should not have to remember information from one part of the dialogue to another.
• Heuristic 7 — Flexibility and Efficiency of Use — Accelerators — unseen by novice users — may often speed up interaction for expert users so that the system can cater to both inexperienced and experienced users.
• Heuristic 8 — Aesthetic and Minimalist Design — Dialogues should not contain irrelevant or rarely needed information, as every extra unit of information competes with and diminishes the relative visibility of relevant information.
• Heuristic 9 — Help Users Recognize, Diagnose, and Recover from Errors — Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution.
• Heuristic 10 — Help and Documentation — Even though it is better if the system can be used without documentation, it may be necessary to provide help; such information should be easy to search and focused on the user's task.

The Heuristic Evaluation Process

• Preparing for the Evaluation — Before beginning an evaluation, evaluators must understand the system's intended users, primary use cases, and scope of the interface to be reviewed.
• Conducting the Individual Evaluation — Each evaluator independently inspects the interface, walking through it multiple times and noting any elements that violate one or more of the ten heuristics.
• Documenting Usability Problems — Each usability problem must be recorded with enough detail that someone unfamiliar with the evaluation can locate and understand the issue.
• Number of Evaluators — Research shows that the optimal number of evaluators for HE is between three and five, as this range captures the best return on investment for problem discovery.

Severity Rating

• Purpose of Severity Ratings — Severity ratings help design and development teams prioritize which usability problems to fix first given limited time and resources.
• Nielsen's Severity Rating Scale — Nielsen's standard severity scale runs from 0 to 4, with 0 indicating no usability problem and 4 indicating a usability catastrophe that must be fixed before launch.
• Factors Influencing Severity — Severity is determined by three key factors: the frequency with which the problem occurs, the impact it has on users, and the persistence of the problem across the interface.
• Assigning and Recording Ratings — Each evaluator assigns severity ratings independently before any aggregation discussion to prevent anchoring and groupthink from distorting individual assessments.

Aggregating Findings Across Evaluators

• Why Aggregation Is Necessary — Because different evaluators identify different subsets of problems, combining findings from multiple evaluators produces a more complete and reliable picture of the interface's usability issues.
• The Aggregation Meeting — Evaluators come together in a structured meeting to present their findings, deduplicate overlapping issues, and negotiate final severity ratings for each problem.
• Deduplication and Problem Merging — Deduplication involves identifying problems that multiple evaluators reported and deciding whether they represent the same underlying issue or distinct but related problems.
• Negotiating Severity Across Evaluators — When evaluators assign different severity ratings to the same problem, the group must reach a consensus rating through evidence-based discussion.

Writing Formal Heuristic Evaluation Reports

• Report Structure and Components — A well-structured HE report typically includes an executive summary, evaluation context, methodology description, consolidated findings table, and recommendations section.
• Writing Effective Problem Descriptions — Problem descriptions must be precise, neutral, and specific enough that a designer can locate and understand the violation without having been part of the evaluation.
• Formulating Recommendations — Recommendations translate each identified problem into actionable design guidance that the team can implement in the next iteration.
• Using Visual Evidence — Annotated screenshots and screen recordings significantly increase the clarity and credibility of HE reports by providing direct visual evidence of each violation.
• Report Quality Standards — Professional HE reports must be clear, consistent, and credible — free of vague language, unsupported claims, and internal contradictions.

Evaluating Peer Prototypes

• Module Assignment Overview — Each student independently evaluates three peer prototypes using Nielsen's ten heuristics, assigns severity ratings, and produces a formal HE report for each prototype evaluated.
• Maintaining Evaluator Independence — The independence requirement means students must complete their individual evaluations and draft reports before viewing or discussing findings with any other evaluator of the same prototype.
• Professional Conduct in Peer Evaluation — Evaluating a peer's prototype requires maintaining a professional, constructive tone that focuses on interface design decisions rather than on the designer's choices or abilities.
• Calibrating Evaluations Across Prototypes — Applying a consistent standard across three different prototypes requires active calibration — evaluators must ensure they are not applying stricter or looser criteria as they progress through evaluations.

Learning Outcomes

Module 9: Functional Prototype Development and Testing Preparation

Topics

From Mockup to Functional Prototype

• Defining Functional Prototypes — A functional prototype is a coded, interactive artifact that simulates real system behavior and can be deployed for user interaction. Unlike a mockup, it responds to user inputs and reflects actual logic flows.
• Limitations of High-Fidelity Mockups for Testing — High-fidelity mockups excel at communicating visual design intent but fall short when realistic interaction data is needed. They cannot capture navigation errors, load behaviors, or user recovery patterns.
• Criteria for Transition Readiness — Before beginning prototype development, teams should assess whether their mockup designs are stable enough to code against. Premature coding of unstable designs wastes development effort.
• Scoping the Prototype for Usability Testing — A common mistake is building too much functionality into a test prototype. Scope should be limited to the features and flows directly relevant to the research questions being tested.

Transition Strategies from Design to Code

• Design Handoff and Asset Preparation — Effective handoff from design to development begins with organizing and exporting mockup assets in formats suitable for coding. Poorly prepared handoffs result in inconsistent implementations.
• Component-First Development Approach — Building reusable interface components before assembling full screens reduces duplication and makes the prototype easier to maintain and update. This mirrors modern front-end development practices.
• Iterative Build and Continuous Review — Prototype development should proceed in short build cycles, with frequent reviews against the original mockup to catch deviations early. Waiting until the end to compare code output to design leads to costly corrections.
• Managing Design Drift During Development — Design drift occurs when coding decisions gradually diverge from the approved mockup, producing a prototype that no longer reflects the intended design. Systematic practices prevent unintentional drift.

Development Environment Setup and Use

• Choosing an Appropriate Technology Stack — The technology stack for a usability testing prototype should prioritize speed of development and ease of deployment over long-term scalability. The goal is a testable artifact, not a production system.
• Setting Up Version Control — Version control is essential for collaborative prototype development, enabling the team to track changes, revert mistakes, and work in parallel without overwriting each other's contributions.
• Local Development and Live Preview Workflows — A smooth local development workflow allows developers to see the effect of code changes immediately, reducing the iteration cycle between writing code and observing results.
• Deploying the Prototype for Testing — Deploying the prototype to an accessible environment before the test session ensures that participants can access it reliably without the need for local setup on their devices.

Designing User Proficiency Surveys

• Purpose and Value of Proficiency Surveys — A user proficiency survey collects structured background information from participants before a usability test, allowing researchers to interpret performance data in light of participant experience levels.
• Identifying Relevant Proficiency Dimensions — Not all background information is relevant to every usability study. Teams must identify the specific dimensions of user experience and knowledge that are most likely to influence performance on the test tasks.
• Writing Effective Survey Questions — Survey question quality directly affects data reliability. Ambiguous, leading, or double-barreled questions produce unreliable data that cannot support valid conclusions about participant proficiency.
• Structuring and Administering the Survey — The survey should be organized logically, moving from general background questions to more specific proficiency items. Administration timing and format should be designed to minimize burden and maximize completion.

Designing Usability Testing Protocols

• Anatomy of a Usability Testing Protocol — A usability testing protocol is a formal document that defines every aspect of how a test session will be conducted, ensuring consistency across participants and enabling replication of the study.
• Writing Task Scenarios — Task scenarios describe realistic situations that prompt participants to interact with the prototype in ways that reveal usability strengths and weaknesses. Well-written scenarios feel natural and do not inadvertently guide participants toward correct actions.
• Developing Facilitator Scripts — A facilitator script provides standardized language for introducing the session, delivering tasks, and responding to common participant behaviors such as asking for help or expressing frustration.
• Planning Data Collection Methods — The protocol must specify what data will be collected, how it will be recorded, and who is responsible for each data collection activity during the session.
• Session Logistics and Environment Planning — Logistical details such as session scheduling, participant arrival procedures, room or virtual meeting setup, and equipment checks must be planned and documented to prevent disruptions during testing.
• Pilot Testing the Protocol — Running a pilot session with a colleague or peer before recruiting actual participants reveals gaps in the protocol, ambiguous task wording, and logistical issues that are not apparent from reading the document alone.

Integrating Prototype and Testing Preparation

• Aligning Prototype Scope with Test Tasks — The prototype must be capable of supporting every task scenario defined in the testing protocol. Misalignment between what the prototype can do and what participants are asked to do invalidates test results.
• Preparing Test Data and Prototype State — Usability tests require the prototype to begin each session in a consistent, predefined state with appropriate test data pre-loaded so that every participant starts from the same conditions.
• Coordinating Team Roles Across Development and Testing — The transition from prototype development to test facilitation requires clear role assignments so that team members know their responsibilities during both phases and can support each other effectively.

Learning Outcomes

Module 10: Controlled User Testing and Data Collection

Topics

Foundations of Experimental Design for Usability Testing

• What Is Experimental Design in Usability Testing? — Experimental design in usability testing is the systematic planning of a study to ensure results are valid, reliable, and actionable. It defines what will be tested, how it will be measured, and how variables will be controlled.
• Independent and Dependent Variables — In a usability study, the independent variable is the condition being manipulated (such as interface version), while the dependent variables are the outcomes being measured (such as task completion time or error rate).
• Study Validity: Internal and External — Internal validity refers to the degree to which the study accurately measures what it intends to, while external validity refers to how well the findings generalize to real-world contexts.
• Choosing a Study Type: Formative vs. Summative — Formative usability tests are conducted during development to identify and fix problems, while summative tests are conducted after development to evaluate the overall quality of a finished product.
• Ethical Considerations in Usability Studies — Conducting usability testing involves ethical responsibilities including informed consent, participant confidentiality, the right to withdraw, and data handling practices.

Participant Selection and Recruitment

• Defining the Target User Population — The target user population is the group of people for whom the product is designed, and all participant selection decisions should reflect meaningful characteristics of this group.
• Inclusion and Exclusion Criteria — Inclusion criteria specify the characteristics a participant must have to qualify for the study, while exclusion criteria identify characteristics that would disqualify a candidate.
• Screening and Recruitment Methods — Screening involves vetting potential participants against selection criteria, typically using a screener survey or questionnaire administered before the study begins.
• Sample Size Considerations — Determining how many participants to recruit depends on the study type, the diversity of the user population, and the depth of insights needed.
• Scheduling and Logistics — Participant scheduling involves coordinating session times, confirming locations or remote access links, and communicating all logistical details to participants in advance.

Task Scenario Scripting

• What Makes a Good Task Scenario? — A good task scenario is realistic, goal-oriented, and specific enough to be measurable without revealing how the user should complete the task.
• Writing Scenario Context and Prompts — Scenario prompts include a brief narrative context that situates the participant in a realistic use case, followed by a specific action prompt that tells them what goal to accomplish.
• Task Measurability and Success Criteria — Before testing begins, teams must define what constitutes successful task completion and how partial or failed completion will be recorded.
• Piloting and Refining Task Scenarios — Pilot testing involves running one or more trial sessions with non-study participants to identify ambiguities, timing issues, or errors in the task scenarios before live testing.
• Sequencing and the Test Script — The test script is the facilitator's master document that sequences all tasks, instructions, and transitions in the exact order they will occur during each session.

Think-Aloud Protocol

• What Is the Think-Aloud Protocol? — The think-aloud protocol asks participants to verbalize their thoughts, decisions, and reactions continuously as they interact with the product, giving evaluators direct access to the user's mental model.
• Concurrent vs. Retrospective Think-Aloud — Concurrent think-aloud requires participants to verbalize during the task, while retrospective think-aloud asks them to narrate their thoughts after completing the task, often while reviewing a session recording.
• Training Participants to Think Aloud — Most participants are not naturally accustomed to verbalizing their thoughts while working, so a brief training exercise at the start of the session is essential to establish the behavior.
• Facilitator Techniques During Think-Aloud Sessions — During the session, the facilitator must prompt participants who go silent without interfering with their problem-solving or revealing information about the interface.
• Recording and Capturing Think-Aloud Data — Think-aloud sessions should be audio or video recorded so that verbal data can be accurately transcribed and analyzed after the session.

Quantitative Data Collection

• Core Usability Metrics — Quantitative usability metrics provide objective, numerical evidence of how well users can interact with a product, enabling comparison across tasks, sessions, and design iterations.
• Standardized Usability Questionnaires — Post-task and post-session questionnaires provide standardized quantitative measures of perceived usability and user satisfaction that complement behavioral observation data.
• Designing Data Collection Instruments — Data collection instruments such as observation logs, timing sheets, and error tally forms must be designed before testing begins to ensure all relevant data is captured consistently across sessions.
• Timing and Measurement Consistency — For timing data to be meaningful and comparable across participants, start and end points for each task must be precisely defined and consistently applied by the team.
• Aggregating Quantitative Data — After all sessions are complete, quantitative data from individual participants must be aggregated into summary statistics that represent the overall study findings.

Qualitative Data Collection

• Types of Qualitative Data in Usability Testing — Qualitative data in usability testing includes verbal utterances, observable behaviors, emotional reactions, and participant-reported preferences that cannot be meaningfully reduced to numbers.
• Structured Observation and Note-Taking — Effective note-taking during usability sessions requires a structured approach that captures specific, observable behaviors rather than interpretations or evaluations.
• Post-Test Interviews and Debrief — A brief post-test interview or debrief at the end of each session gives participants the opportunity to reflect on their overall experience and raise issues that did not emerge during task performance.
• Affinity Diagramming for Qualitative Synthesis — Affinity diagramming is a team-based method for organizing and synthesizing large volumes of qualitative observations into grouped themes and patterns.
• Documenting Quotes and Critical Incidents — Direct participant quotes and critical incidents — moments of significant struggle, surprise, or delight — are among the most compelling qualitative evidence in a usability report.

Conducting Live User Testing Sessions

• Team Roles During a Testing Session — Each usability testing session should have clearly assigned team roles — typically a facilitator, a note-taker, and one or more observers — to ensure all data is captured without overwhelming any one person.
• Session Environment Setup — The testing environment must be prepared before each session to ensure the product is in the correct starting state, recording tools are functioning, and the space is free from distractions.
• Opening the Session — The session opening establishes rapport with the participant, confirms consent, explains the think-aloud protocol, and sets expectations for how the session will proceed.
• Managing In-Session Challenges — Facilitators must be prepared to handle common session challenges such as participant silence, off-task conversation, technology failures, and requests for guidance.
• Closing the Session and Post-Session Debrief — Closing the session involves thanking the participant, administering any final questionnaires, debriefing on the study's purpose, and distributing any participant incentives.

Compiling Structured Results for Analysis

• Organizing Raw Data After Testing — Before analysis can begin, all raw data from every session must be compiled, labeled, and organized in a consistent format that allows comparison across participants and tasks.
• Identifying Usability Problems and Patterns — Analysis involves reviewing the compiled data to identify recurring usability problems, patterns of behavior, and areas of the product that consistently caused difficulty across participants.
• Structuring the Results Report — The results report is the primary deliverable of the usability study and should present findings in a clear, logical structure that moves from study overview to findings to recommendations.
• Presenting Quantitative Findings — Quantitative findings should be presented using tables, charts, and summary statistics that make numerical patterns immediately visible and interpretable.
• Presenting Qualitative Findings and Recommendations — Qualitative findings are most effectively communicated through a combination of themed summaries, direct participant quotes, and specific critical incident descriptions.

Learning Outcomes

Module 11: Analyzing User Testing Results and Iterative Redesign

Topics

Foundations of Usability Test Data

• Quantitative vs. Qualitative Data — Usability tests produce two broad categories of data: quantitative measures that are numerical and statistically comparable, and qualitative observations that capture the richness of user behavior and experience.
• Task Completion Rates — Task completion rate measures the percentage of participants who successfully finish a defined task without assistance, making it one of the most direct indicators of interface effectiveness.
• Error Rate Analysis — Error rate measures how frequently users make mistakes while attempting to complete tasks, providing insight into which interface elements cause confusion or misdirection.
• Time on Task — Time on task measures how long a user takes to complete a given activity, serving as a proxy for efficiency and learnability of the interface.
• Satisfaction Scores — Satisfaction scores capture the subjective user perception of the interface through standardized questionnaires, providing a self-reported measure of usability and emotional response.

Collecting and Organizing Test Data

• Data Collection Methods — Reliable analysis depends on consistent and thorough data collection during test sessions, using a combination of automated tools, observer notes, and recording technologies.
• Affinity Diagramming — Affinity diagramming is a collaborative method for grouping qualitative observations into thematic clusters, making it easier to identify patterns across multiple participants.
• Usability Issue Logs — A usability issue log is a structured document that records each identified problem along with contextual information needed to understand and address it.
• Synthesizing Across Participants — Analysis must look across all participants to distinguish widespread usability failures from individual edge cases, ensuring that redesign efforts address the broadest possible impact.

Interpreting Error Analysis

• Classifying Error Types — Not all errors are equal — distinguishing between different error types allows designers to target the correct layer of the interface when implementing fixes.
• Root Cause Analysis — Root cause analysis moves beyond describing what went wrong to diagnosing why, connecting interface design choices to specific user failures.
• Mapping Errors to Interface Elements — Linking specific errors to the exact interface elements that caused them creates a direct connection between the analysis and the redesign work that follows.
• Distinguishing Critical from Minor Errors — Errors vary in their impact on the user experience, and correctly distinguishing critical failures from minor inconveniences is essential for efficient resource allocation in redesign.

Prioritizing Usability Improvements

• Severity Rating Frameworks — Severity rating frameworks provide a systematic way to score usability issues so that teams can rank them objectively rather than relying on intuition or internal politics.
• Impact vs. Effort Mapping — Impact versus effort mapping plots usability issues on a two-axis grid to identify quick wins — high-impact fixes that require minimal effort — and to deprioritize low-impact, high-effort changes.
• Aligning Priorities with Design Goals — Prioritization must be anchored to the core usability goals and user needs established at the start of the project, ensuring that fixes reinforce rather than undermine the intended user experience.
• Communicating Priorities to Stakeholders — Translating usability findings into a clear, evidence-based priority list is essential for gaining stakeholder support and aligning cross-functional teams on redesign decisions.

Principles of Iterative Redesign

• The Iterative Design Cycle — Iterative design is a repeating process in which each round of testing produces findings that inform targeted improvements, which are then tested again in the next cycle.
• Targeted vs. Wholesale Redesign — Effective iterative redesign involves making targeted, evidence-based changes to specific problem areas rather than reimagining the entire interface after each round of testing.
• Maintaining Design Rationale — Design rationale documentation records the reasoning behind each redesign decision, creating an institutional memory that prevents teams from inadvertently reverting to previously tested and rejected solutions.
• Setting Success Criteria for Each Iteration — Before beginning a redesign iteration, teams should establish measurable success criteria that define what 'better' looks like for the issues being addressed.

Implementing Redesign Changes in Prototypes

• Choosing the Right Prototype Fidelity — The fidelity of a prototype — from low-fidelity paper sketches to high-fidelity interactive mockups — should match the questions being tested in the next iteration rather than defaulting to the highest possible fidelity.
• Translating Findings into Design Changes — Each prioritized usability finding must be converted into a specific, actionable design change that addresses its root cause — not merely its surface symptom.
• Annotating Redesigned Prototypes — Annotations on redesigned prototypes explain the reasoning behind each change, making it easier for team members, developers, and stakeholders to understand the intent and context of updates.
• Version Management for Iterative Prototypes — Managing prototype versions systematically ensures that previous iterations are preserved for comparison, preventing accidental loss of design history and enabling regression analysis.
• Validating Changes Before the Next Test — Before conducting the next formal usability test, teams should conduct informal internal reviews or expert walkthroughs of the redesigned prototype to catch obvious errors or unintended regressions.

Documenting and Communicating Redesign Outcomes

• Usability Testing Reports — A usability testing report synthesizes findings from a test session into a structured document that can be shared with the broader team and stakeholders to drive aligned decision-making.
• Before-and-After Comparison Documentation — Side-by-side comparisons of prototype versions before and after redesign changes provide clear visual evidence of progress and help stakeholders appreciate the value of the iterative process.
• Tracking Metrics Across Iterations — Tracking the same usability metrics — task completion rates, error rates, satisfaction scores — across multiple iterations creates a longitudinal view of how the design is improving over time.
• Presenting Findings to Non-Technical Audiences — Communicating usability findings effectively to non-technical stakeholders requires translating data-heavy analysis into clear narratives, visual evidence, and business-relevant framing.
• Lessons Learned and Process Reflection — Reflecting on the testing and redesign process itself — not just the design outcomes — helps teams continuously improve their usability practice across projects.

Learning Outcomes

Module 12: Accessibility Standards and Inclusive Interface Design

Topics

Foundations of WCAG Guidelines

• What WCAG Is and Why It Matters — WCAG is an internationally recognized set of guidelines published by the W3C that defines how to make web and interface content accessible to people with disabilities.
• WCAG Conformance Levels: A, AA, and AAA — WCAG organizes its success criteria into three conformance levels that indicate the degree of accessibility support provided by an interface.
• The Four POUR Principles — WCAG is built on four foundational principles — Perceivable, Operable, Understandable, and Robust — that together define what it means for content to be accessible.
• Applying WCAG Success Criteria — Each WCAG principle contains specific, testable success criteria that designers and developers use to evaluate whether an interface meets accessibility requirements.

Accessible Color and Visual Design

• Color Contrast Ratios — WCAG defines minimum contrast ratios between foreground text and background colors to ensure readability for users with low vision or color deficiencies.
• Avoiding Color as the Sole Indicator — Relying on color alone to convey information excludes users who are color blind or who use monochrome displays.
• Typography and Readability — Font size, line spacing, and text layout directly affect the readability of interface content for users with cognitive or visual impairments.
• Focus Indicators and Visual State — Visible focus indicators are essential for keyboard and switch-access users to understand which element is currently active on the screen.

Keyboard Navigation and Motor Accessibility

• Keyboard Operability Requirements — Every interactive function in an interface must be reachable and operable using only a keyboard, without requiring specific timing or simultaneous key combinations.
• Logical Tab Order and Focus Management — The order in which keyboard focus moves through an interface must follow a logical, predictable sequence that reflects the visual and functional layout.
• Skip Navigation Links — Skip links allow keyboard users to bypass repetitive navigation blocks and jump directly to the main content of a page.
• Interaction Patterns for Custom Components — Custom UI components such as carousels, dropdowns, and date pickers require explicit keyboard interaction patterns to be operable by keyboard users.

Screen Reader Compatibility

• Semantic HTML and Landmark Roles — Using correct HTML elements and landmark roles provides screen readers with the structural context needed to interpret and navigate interface content.
• ARIA Labels and Descriptions — ARIA attributes extend semantic meaning to custom components and provide additional context for screen reader users when native HTML semantics are insufficient.
• Image and Media Accessibility — All non-text content must have a text alternative that conveys equivalent information to users who cannot perceive the visual or auditory content.
• Dynamic Content and Live Regions — Content that updates dynamically on a page, such as status messages, alerts, or live data feeds, must be announced to screen reader users without requiring a page reload.

Inclusive Design Principles Beyond WCAG

• The Social Model and Inclusive Design Mindset — Inclusive design recognizes that disability is often created by environments and systems that fail to accommodate human diversity, rather than by individual impairment alone.
• Cognitive Accessibility — Designing for cognitive accessibility ensures that interfaces are understandable and usable by people with cognitive, learning, and neurological differences.
• Responsive and Adaptive Design for Accessibility — Interfaces must remain accessible across a range of screen sizes, orientations, input methods, and user-defined display settings.
• Animation and Motion Sensitivity — Excessive or unexpected motion in interfaces can cause discomfort or harm to users with vestibular disorders, epilepsy, or motion sensitivity.

Accessibility Auditing

• Audit Methods and Tools — Accessibility auditing combines automated scanning tools with manual evaluation and assistive technology testing to surface a comprehensive set of accessibility issues.
• Auditing Your Own Prototype — Students will apply audit techniques directly to their own prototypes, using a structured checklist to evaluate each component against relevant WCAG success criteria.
• Prioritizing Accessibility Findings — Not all accessibility issues carry equal weight; findings must be ranked by severity and user impact to guide remediation efforts efficiently.
• Writing Accessibility Findings and Recommendations — Effective audit reports clearly describe each issue, its impact on users, the relevant guideline, and a concrete recommended fix.

Applying Corrective Design Patterns

• Designing Accessible Form Components — Forms are among the most common sources of accessibility failures and require careful attention to labeling, error handling, and input structure.
• Accessible Navigation Patterns — Navigation components must be structured and coded so that all users can orient themselves within a site and move between sections efficiently.
• Accessible Modals and Overlays — Modal dialogs require careful focus management and ARIA implementation to ensure screen reader users understand the context and can interact with and dismiss the overlay.
• Accessible Data Visualization — Charts, graphs, and other data visualizations must communicate their information through means beyond color and visual representation alone.
• Iterating on Accessibility in Design Workflows — Accessibility is most effectively integrated as a continuous practice throughout the design process rather than addressed only at the end through remediation.

Learning Outcomes

Module 13: App Publication Strategies and Store Requirements

Topics

Google Play Store Submission Process

• Google Play Developer Account Setup — Before submitting an app, developers must register a Google Play Developer account and agree to the Developer Distribution Agreement.
• Android Build Preparation and Signing — Android apps must be compiled into a release build and signed with a cryptographic key before they can be submitted to the Play Store.
• Store Listing Assets and Metadata — A complete Google Play listing requires specific graphical assets, descriptive text, and categorization metadata to appear in search and browsing results.
• App Review and Release Tracks — Google Play uses a tiered release track system that allows developers to test their app with limited audiences before a full public release.
• Google Play Policies and Compliance — All apps submitted to Google Play must comply with the Google Play Developer Program Policies, covering content, privacy, and monetization practices.

Apple App Store Submission Process

• Apple Developer Program Enrollment — Developers must enroll in the Apple Developer Program to access the tools and entitlements needed to distribute apps on the App Store.
• Provisioning Profiles and Code Signing — iOS and macOS apps must be code-signed using certificates and provisioning profiles issued through Apple's developer portal before they can be submitted.
• App Store Connect Configuration — App Store Connect is Apple's web-based portal where developers manage app metadata, pricing, builds, and release scheduling for App Store listings.
• App Store Asset Requirements — Apple requires specific screenshots, app previews, and icons tailored to each supported device size in order to create a compliant App Store listing.
• App Review Guidelines and Common Rejections — Apple's App Review Guidelines define the standards apps must meet for safety, performance, business practices, design, and legal compliance before approval.

Microsoft Store Submission Process

• Microsoft Partner Center Account Setup — To publish apps on the Microsoft Store, developers must register through Microsoft Partner Center and create a developer account.
• Windows App Packaging with MSIX — Windows applications must be packaged in the MSIX format to be submitted to the Microsoft Store, providing a modern, reliable installation experience.
• Store Listing and Asset Requirements for Microsoft Store — Microsoft Store listings require screenshots, logos, and descriptive metadata to ensure the app is discoverable and accurately represented.
• Microsoft Store Certification and Policies — All apps submitted to the Microsoft Store undergo a certification process that checks for technical quality, content compliance, and policy adherence before publication.

Web Deployment Strategies

• Web Hosting Options and Platforms — Web applications can be deployed across a range of hosting solutions, from traditional shared hosting to modern cloud platforms and static site hosts.
• Build Pipelines and Continuous Deployment — Modern web deployment relies on automated build pipelines that compile, test, and deploy application code whenever changes are pushed to a repository.
• Domain Configuration and SSL Certificates — Deploying a web application to a custom domain requires DNS configuration and the installation of an SSL/TLS certificate to enable secure HTTPS connections.
• Progressive Web App Deployment — Progressive Web Apps (PWAs) are web applications that can be installed on a user's device and offer app-like experiences including offline functionality and push notifications.
• Web App Performance and SEO Considerations — A successfully deployed web application should meet performance benchmarks and be optimized for search engine discoverability before being considered publication-ready.

Asset Requirements and Store Listing Optimization

• App Icons and Branding Standards — App icons are a primary visual identifier on store listings and device home screens, and each platform has specific size and format requirements that must be met.
• Screenshots and App Previews — Screenshots and preview videos give potential users a visual preview of the app's interface and functionality, directly influencing download decisions.
• App Store Optimization (ASO) Fundamentals — App Store Optimization (ASO) is the process of improving an app listing's visibility and conversion rate within app store search results through strategic use of metadata.
• Privacy Policies and Legal Requirements — Every major app store requires apps that collect or process user data to provide a publicly accessible privacy policy that clearly describes data practices.

Build Finalization and Submission Readiness

• Release Build Configuration — A release build differs from a development build in that it is optimized, minified, and stripped of debug tooling, making it suitable for distribution to end users.
• Pre-Submission Testing Checklist — Before submitting an app to any store, developers should conduct a thorough round of testing to identify crashes, broken features, and policy violations that would result in rejection.
• Version Numbering and Release Notes — Each app submission must include an updated version number and, for updates to existing apps, release notes that communicate changes to users and reviewers.
• Submission Packages and Deliverables — Assembling all required files, assets, and documentation into a complete submission package ensures a smooth review process and reduces the likelihood of rejection due to missing materials.

Learning Outcomes

Module 14: HCI Design Documentation and Development Reporting

Topics

Introduction to HCI Development Reporting

• Purpose of an HCI Development Report — An HCI development report provides a structured, professional account of the entire design process, communicating decisions, rationale, and outcomes to stakeholders.
• Audience and Tone — A professional HCI report is written for a technically informed audience and must maintain a formal, objective tone throughout.
• Report as a Design Artefact — The development report itself is considered a design artefact, representing the intellectual and practical work of the project team.

Requirements Documentation

• Documenting User Research — The report must describe the methods used to gather user needs, including observations, interviews, surveys, or contextual inquiry, along with key findings.
• Stating Functional and Non-Functional Requirements — Requirements must be clearly categorized as functional or non-functional and written in precise, testable language.
• Rationale for Design Constraints — Any constraints placed on the design — such as platform, accessibility standards, or scope limitations — must be explicitly stated and justified.
• Linking Requirements to Design Goals — The report should show how gathered requirements were translated into concrete design goals that guided the project.

Design Process Documentation

• Documenting Concept Generation — The report should describe early ideation activities, such as sketching, brainstorming, or design workshops, and explain how initial concepts were generated and evaluated.
• Describing Low-Fidelity Prototypes — Low-fidelity prototypes such as paper sketches or wireframes must be documented with annotated images and an explanation of what each prototype was intended to test.
• Documenting Design Rationale — Design rationale explains why specific design choices were made, grounding decisions in HCI principles, guidelines, or user research evidence.
• Describing High-Fidelity Prototypes — High-fidelity prototypes represent near-final interface designs and should be documented with annotated screenshots and a clear account of how they differ from earlier iterations.
• Capturing Design Evolution — The report should present the design process as an iterative journey, showing how early decisions were refined in response to evaluation findings and emerging insights.

Evaluation Documentation

• Documenting Evaluation Methodology — The report must specify the evaluation method used, such as usability testing, heuristic evaluation, or cognitive walkthrough, along with the rationale for selecting that method.
• Presenting Evaluation Findings — Findings from evaluation activities must be presented clearly, distinguishing between observed problems, participant feedback, and analyst interpretations.
• Linking Evaluation Findings to Design Iterations — The report must explicitly connect evaluation findings to subsequent design changes, demonstrating that evaluation informed and improved the design.
• Reflecting on Evaluation Limitations — A professional report acknowledges the limitations of its evaluation activities, such as small sample sizes, time constraints, or method choices that may affect the validity of findings.

Final Implementation Documentation

• Describing the Final Interface — The final implementation section presents the delivered interface design, using annotated screenshots or walkthroughs to describe its key features and interactions.
• Documenting Implementation Decisions — Any design decisions made specifically during the implementation phase must be documented, including choices about interaction patterns, visual design, or technical constraints.
• Documenting Deviations from the Prototype — Where the final implementation differs from the approved prototype, the report must explain the reasons for any deviations and assess their impact on usability.
• Tracing Design Decisions to Outcomes — The implementation section should close by demonstrating how the final design addresses the requirements and design goals established at the start of the project.

Group Collaboration and Contribution Documentation

• Documenting Team Roles and Responsibilities — The report should identify the roles taken by each team member and describe how responsibilities were allocated across the project phases.
• Describing Collaborative Design Processes — The report should describe how the team made collective design decisions, including any structured processes such as design critiques, team reviews, or voting methods.
• Documenting Project Management Activities — Brief documentation of project management activities such as scheduling, task tracking, and version control demonstrates professional practice.
• Reflecting on Group Process — The report should include a reflective component in which the team honestly evaluates the effectiveness of their collaborative process.

Report Structure, Referencing, and Presentation

• Standard Report Structure — An HCI development report follows a conventional academic and professional structure that includes front matter, a body organized by project phase, and supporting appendices.
• Writing Cohesive Narratives Across Sections — Each section of the report must connect logically to adjacent sections, ensuring the overall document reads as a coherent account of an integrated design process.
• Academic Referencing — All sources cited in the report, including HCI guidelines, design principles, and research methods, must be referenced using the required academic referencing style.
• Use of Visual Evidence — Figures, screenshots, diagrams, and tables must be used strategically to support written arguments and are subject to the same presentation standards as text.
• Presentation and Formatting Standards — Professional formatting — including consistent fonts, heading hierarchies, appropriate line spacing, and accurate word counts — reflects the quality of the team's work.

Learning Outcomes

Module 15: Final HCI Evaluation, Reflection, and Lessons Learned

Topics

Connecting HCI Theory to Design Outcomes

• Role of HCI Theory in Design Decisions — HCI theory provides the conceptual foundation that guides designers in making informed, user-centered choices at every stage of the design process.
• From Concepts to Real-World Application — Translating abstract HCI concepts into concrete design artifacts requires deliberate effort to bridge theory and practice.
• Evaluating Theory Alignment in Final Products — Assessing the final product for alignment with HCI theory reveals how well the team integrated course concepts into their design.

Review of the Analysis Phase

• User Research Methods and Their Impact — The user research methods chosen at the start of a project establish the foundation of empathy and understanding that informs every subsequent design decision.
• Task Analysis and User Needs Definition — Task analysis translates raw user research into structured representations of what users need to accomplish and how they currently do so.
• Requirements Gathering and Scope Management — Well-defined functional and non-functional requirements provide a shared understanding between team members and serve as a benchmark for design success.

Review of the Prototyping Phase

• Low-Fidelity Prototyping and Ideation — Low-fidelity prototypes such as sketches and paper mockups enable rapid exploration of design concepts without significant investment of time or resources.
• High-Fidelity Prototyping and Design Refinement — High-fidelity prototypes closely simulate the look and behavior of the final product, enabling more realistic usability testing and stakeholder review.
• Iteration Between Prototype Versions — Effective prototyping is not linear; it involves cycling between design, testing, and refinement based on user and stakeholder feedback.

Review of the Evaluation Phase

• Usability Testing Methods — Usability testing exposes how real users interact with a prototype or product, revealing problems that designers and team members cannot detect through self-review alone.
• Heuristic and Expert Evaluation — Heuristic evaluation involves experts reviewing a design against established usability principles to identify violations without requiring user participants.
• Translating Evaluation Findings into Design Changes — The value of any evaluation method is only realized when findings are systematically analyzed and translated into concrete design improvements.
• Measuring Design Quality Against Initial Goals — Evaluating the final product against the user needs and requirements established during the analysis phase closes the loop on the design process.

Structured Feedback on Design Quality

• Dimensions of Design Quality in HCI — Design quality in HCI is multi-dimensional, encompassing usability, accessibility, aesthetic integrity, and consistency across the user experience.
• Providing and Receiving Constructive Critique — Structured critique is a professional skill that enables teams to give and receive feedback that is specific, evidence-based, and actionable.
• Using Feedback to Identify Design Patterns — Recurring themes across multiple feedback sources indicate systematic design patterns—either strengths to preserve or weaknesses to address.

Process Execution and Team Collaboration

• Design Process Planning and Execution — A structured design process plan helps teams allocate time and resources effectively across research, prototyping, and evaluation phases.
• Role Distribution and Contribution — Clearly defined roles within a design team prevent duplication of effort, ensure all competencies are utilized, and promote individual accountability.
• Communication and Conflict Resolution — Effective team communication and proactive conflict resolution are essential for maintaining momentum and psychological safety throughout a design project.
• Collaboration Tools and Documentation Practices — Digital collaboration tools and consistent documentation practices enable distributed teams to work coherently and maintain a shared record of design decisions.

Reflection and Lessons Learned

• Individual Reflective Practice — Individual reflection encourages each team member to assess their personal growth, skill development, and contribution to the project.
• Team-Level Lessons Learned — A team lessons-learned session synthesizes individual reflections into shared insights about process, collaboration, and design outcomes.
• Connecting Course Concepts to Project Experience — Synthesizing the connection between course concepts and lived project experience cements learning and prepares students to transfer knowledge to new contexts.
• Actionable Improvements for Future Projects — Lessons learned only create lasting value when translated into specific, actionable commitments for how future projects will be approached differently.

Learning Outcomes

Module 16: Video Lectures

Topics

Human Cognition and Perception

• Foundations of Human Cognition — Human cognition refers to the mental processes by which people acquire, process, store, and use information. Understanding these processes is fundamental to designing interfaces that align with how users naturally think and behave.
• Human Perception — Perception is the process through which humans interpret sensory information from the environment to form a meaningful understanding of the world. In interface design, visual perception is most critical, though auditory and tactile perception also play roles.
• Attention and Its Limits — Attention is the cognitive process of selectively concentrating on one aspect of the environment while ignoring others. Because human attention is a limited resource, interfaces must be designed to direct it effectively.
• Memory: Types and Implications for Design — Human memory is not a single system but comprises distinct types — including sensory, working (short-term), and long-term memory — each with different capacities and durations. Interface design must respect these memory constraints to reduce user error.
• Information Processing Models — Information processing models describe the stages through which human cognition transforms sensory input into meaningful responses or actions. These models provide a framework for predicting how users will interact with interface elements.
• Perception of Time and Feedback — Users' perception of time — particularly response latency from a system — significantly affects their experience and confidence in an interface. Timely and appropriate feedback bridges the gap between user action and system response.

Knowledge, Mental Models, and Conceptual Frameworks

• Types of Knowledge Users Bring to Interactions — Users approach systems with different forms of stored knowledge that shape how they interpret and interact with interfaces.
• Mental Models: Internal Representations of Systems — A mental model is a user's internal, cognitive representation of how a system works, built through experience and inference.
• Conceptual Models Provided by Designers — A conceptual model is the designer's intended representation of a system, communicated to users through the interface, documentation, and feedback.
• Interface Metaphors as Cognitive Bridges — Interface metaphors leverage familiar real-world concepts to help users build accurate mental models of digital systems more quickly.
• How Mental Models Evolve Through Interaction — Mental models are dynamic and are continuously updated as users receive feedback, encounter errors, and explore system features.
• Implications of Mental Models for Interface Design — Understanding how users form and apply mental models is foundational to designing interfaces that are intuitive, learnable, and error-resistant.

Human Error and Learning

• Types of Human Error — Human errors in interactive systems can be categorized into distinct types that help designers understand and mitigate failure points.
• Causes and Contributing Factors of Error — Understanding why errors happen requires examining cognitive, environmental, and design-related factors that increase the likelihood of mistakes.
• Error Prevention in Interface Design — Effective interface design proactively reduces the opportunity for errors to occur through thoughtful constraints and affordances.
• Forgiving Interfaces and Error Recovery — Forgiving interfaces are designed to minimize the damage caused by errors and make recovery straightforward and intuitive.
• Learning Principles and Interface Design — Principles from cognitive learning theory directly inform how interfaces can be designed to support skill acquisition and knowledge transfer.
• Novice vs. Expert Users and Learning Curves — Interfaces must account for users at different stages of learning, balancing the needs of beginners with the efficiency demands of experts.
• Mental Models and Error-Prone Interactions — Mismatches between a user's mental model and the system's actual behavior are a primary source of systematic errors.

Understanding Users and Task Analysis

• Who Are the Users? — Understanding users begins with identifying who they are, what they know, and what they need from a system.
• Methods for Researching User Needs — A variety of research methods are used to gather data about user goals, behaviors, and pain points to inform user-centered design.
• User Goals and Mental Models — Understanding what users are trying to achieve and how they conceptualize a system is central to designing effective interfaces.
• Introduction to Task Analysis — Task analysis is a systematic process of studying and describing what users do to achieve their goals, forming a foundation for interface design.
• Hierarchical Task Analysis (HTA) — Hierarchical Task Analysis decomposes high-level user goals into subtasks and operations organized in a structured hierarchy.
• Cognitive Task Analysis — Cognitive Task Analysis (CTA) extends traditional task analysis by capturing the mental processes — such as decisions, judgments, and problem-solving — involved in task performance.
• Applying Task Analysis to User-Centered Design — The findings from task analysis are translated into concrete design decisions that align system functionality with real user workflows.

Interaction Design and Prototyping

• Core Principles of Interaction Design — Interaction design focuses on creating meaningful, usable, and effective interfaces by applying foundational design principles that guide how users interact with systems.
• Desktop Interaction Design — Desktop interaction design addresses the conventions, patterns, and standards that govern how users engage with applications on traditional computing platforms.
• Mobile Interaction Design — Mobile interaction design addresses the unique constraints and opportunities of touchscreen devices, requiring adapted design strategies compared to desktop environments.
• Prototyping Strategies and Fidelity Levels — Prototyping is a core activity in interaction design that enables designers to explore, test, and communicate design concepts at varying levels of detail and completeness.
• Prototyping as a Communication Tool — Beyond exploration, prototypes serve as a shared artifact that facilitates communication between designers, developers, stakeholders, and users throughout the design process.
• Iterative Design Through Prototyping — The prototyping process supports an iterative design cycle in which concepts are continuously refined based on feedback and evaluation findings.
• Tools and Techniques for Prototyping — A wide range of tools and techniques are available for creating prototypes, from physical materials to sophisticated digital platforms designed for interaction simulation.

Usability Evaluation and User Testing

• Introduction to Usability Evaluation — Usability evaluation is the systematic process of assessing how well an interactive system supports users in achieving their goals effectively, efficiently, and satisfactorily.
• Structured Evaluation Techniques — Structured evaluation techniques are expert-driven methods that assess interface usability without necessarily involving end users directly.
• User Testing Methods — User testing involves observing real users as they interact with a system to uncover usability problems that may not surface through expert reviews alone.
• Identifying and Documenting Usability Issues — A core outcome of any usability evaluation is the identification, categorization, and prioritization of usability problems to guide design improvements.
• Metrics and Measures in Usability Testing — Quantitative and qualitative metrics are used during user testing to objectively measure the usability of a system and track improvements over time.
• Iterative Testing and Design Refinement — Usability evaluation is most effective when integrated into an iterative design cycle, where findings continuously inform and refine the interface design.

Human Factors, Ergonomics, and Automation

• Introduction to Human Factors — Human factors is the scientific discipline concerned with understanding how humans interact with systems, tools, and environments to optimize performance and safety.
• Ergonomics: Physical and Cognitive Dimensions — Ergonomics examines both the physical and cognitive aspects of human performance in work environments, aiming to design tasks and tools that match human abilities.
• Display Design Principles — Effective display design ensures that information is presented to users in a clear, timely, and appropriately formatted manner to support accurate perception and decision-making.
• Automation in Work Systems — Automation involves the use of technology to perform tasks previously carried out by humans, fundamentally changing the role of the human operator in work systems.
• Human Error and Automation Interaction — The interaction between human operators and automated systems is a major source of errors, particularly when automation behaves unexpectedly or fails silently.
• Situational Awareness and Mental Workload — Situational awareness refers to an operator's perception and understanding of their environment, while mental workload describes the cognitive demand placed on them by a task.
• Applying Human Factors in Interface and System Design — Human factors principles are applied throughout the design process to create systems that are safe, efficient, and satisfying for users to operate.

Collaborative and Advanced Interface Technologies

• Computer-Supported Cooperative Work (CSCW) — CSCW examines how technology can be designed to support groups of people working together, addressing the social and organizational dimensions of collaborative computing.
• Groupware and Collaboration Frameworks — Groupware refers to software specifically designed to help people collaborate, and it is organized by dimensions such as time and place of interaction.
• Advanced Interface Paradigms — Advanced interfaces move beyond traditional keyboard and mouse interactions to encompass richer, more immersive, and context-sensitive forms of human-computer interaction.
• Automation and Human Oversight in Interfaces — Automation in interfaces reduces manual user effort by having systems perform tasks autonomously, but it introduces new challenges around user control, trust, and situational awareness.
• Display Technologies and Information Presentation — Display technologies form the primary output channel between computers and users, and their design significantly affects how efficiently and accurately information is perceived and acted upon.
• Mobile Interaction Design in Advanced Contexts — Mobile interaction design addresses the unique constraints and opportunities of portable devices, and it increasingly intersects with advanced interface technologies such as wearables and location-aware systems.
• Emerging Trends and Future Directions in Interface Technologies — The frontier of interface technology encompasses brain-computer interfaces, ubiquitous computing, and AI-driven adaptive systems that fundamentally reshape how humans interact with machines.

Learning Outcomes