Human-Computer Interaction (HCI) is the study and design of the points where people and technology meet. It asks how interfaces should be shaped so that real users, with real goals, limits, and contexts, can accomplish what they came to do. In this topic you will build the shared vocabulary of the field: what HCI is, the core principles that guide good interaction design, how the user-centered design process works, and where HCI activities fit inside the software development lifecycle.
This matters here because the course project will be judged not only on whether your software runs, but on whether it is usable, understandable, and appropriate for the people you design it for. Before you install tools or write a project plan, you need mental models for terms you will use all semester: usability, user experience, accessibility, iteration, prototyping, and evaluation. Getting these distinctions straight early prevents the common mistake of treating interface design as decoration added at the end.
As you watch, look for three things. First, notice how each speaker defines interaction design or UX and compare the definitions rather than memorizing one. Second, track the activities named in the design process (understanding users, establishing requirements, designing alternatives, prototyping, evaluating) and think about which ones your team can realistically run on the course project. Third, collect the examples of good and bad design that are mentioned, and ask yourself what principle each example illustrates.
This lecture-style video introduces interaction design as a field and works through what distinguishes it from related disciplines, drawing on the standard Chapter 1 material of an HCI course. The description points to examples of bad design and to the classic Xerox PARC copier ethnography video, so expect concrete illustrations of why interfaces fail and why studying real users matters. It is the longest of the three videos and serves as the main conceptual foundation for the topic.
It maps directly onto the "What Is HCI?" and "Core HCI Principles" subtopics, and its chapter-based structure mirrors how foundational HCI textbooks present the field, which makes it a reliable starting point for shared vocabulary.
The follow-on chapter in the same series turns from definitions to process: how interaction design actually proceeds from understanding users through to evaluation. The description references the Design Council's Double Diamond and the Design Squiggle, two widely used models for portraying divergent and convergent thinking and the messy early stages of a design project. Expect an overview of the iterative cycle rather than a deep dive into any single method.
It is the clearest fit for the "User-Centered Design Process" and "HCI and the Software Development Lifecycle" subtopics, and the Double Diamond and Squiggle give you vocabulary for explaining your own project's iteration cycles.
A short, focused explainer from the Nielsen Norman Group that reframes how to describe UX. Its description notes that most quick definitions of UX are internally focused on the build process, suggesting this video argues instead for defining UX through user-centered design and the user's perspective. In under four minutes it offers a compact way to articulate what UX is to someone outside the field.
NNgroup is a long-standing authority on usability and UX research, and this video directly supports distinguishing user experience from the narrower mechanics of software production, which is exactly the distinction the course needs you to make.
Together the three videos cover the foundational ground of this module. The two chapter lectures supply the definitions, classic examples, and historical touchpoints of interaction design that support recalling foundational principles and milestones (MO1), while the NNgroup explainer sharpens the line between user experience and the internal build process, helping you separate usability, UX, and accessibility as distinct concepts (MO2). The process-focused chapter on the Double Diamond and iterative design gives you a concrete framework for scoping work and sequencing activities, which you will apply when drafting your team's initial project plan, platform choice, and role assignments (MO3).
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Version control is the practice of tracking changes to files over time so that you can see what changed, who changed it, and why — and roll back when something breaks. Git is the tool that does this tracking on your own machine; GitHub is the hosted platform that stores Git repositories online and adds collaboration features such as issues, pull requests, code review, and project boards. For the rest of this course, GitHub is where your team's prototype code, design assets, and documentation will live.
This topic matters because your course project is a team effort. Without a shared workflow, teammates overwrite each other's work, lose files, and lose track of who is responsible for what. A clean repository, a sensible branching strategy, and a habit of reviewing changes through pull requests will save your team far more time than it costs to set up in Module 1.
As you watch, keep three questions in mind. First, what is happening locally (on your computer) versus remotely (on GitHub)? Second, what is the minimum set of commands you actually need day to day — clone, add, commit, push, pull, branch, merge? Third, how does a pull request function as both a technical merge and a human conversation about the work? Try to follow along in a scratch repository rather than just watching passively.
This video draws the distinction between Git, the distributed version control system, and GitHub, the cloud platform built around it. Based on the title and description, it covers repositories, how changes are tracked, and how GitHub layers collaboration features such as issue tracking and integrations on top of Git. Expect a whiteboard-style conceptual overview rather than a hands-on terminal demo.
It directly addresses the "What Is Version Control?" and "GitHub as a Collaboration Platform" subtopics, and clearing up the Git-versus-GitHub confusion early prevents a lot of later frustration. IBM Technology's explainer format is clear and vendor-neutral enough for an introductory course.
A beginner-oriented walkthrough of the Git commands you will use most often, with worked examples. The description indicates it starts with configuring your Git setup and moves through the core workflow, so expect coverage of initializing or cloning a repository, staging and committing changes, and syncing with a remote. Branching is typically part of this essential command set as well.
Produced by GitHub itself, so the commands and terminology match what you will see in the platform's own documentation. It supports the "Creating and Configuring a Repository" and "Branching" subtopics with the practical, typo-level detail you need to actually get your team repository running.
A short, focused tutorial that walks through opening a pull request from start to finish. It demonstrates proposing changes to a repository and routing them to others for review before they are merged. At under four minutes, it is a procedural demo rather than a deep discussion of review etiquette.
Pull requests are the heart of collaborative work on GitHub, and this video covers the exact mechanics your team will repeat all semester. Its brevity makes it easy to rewatch while you are actually submitting your first pull request.
These videos primarily serve MO3: before a team can execute a project plan, it needs a shared place to store work and an agreed way of dividing and merging it. Setting up a repository, assigning branch and review responsibilities, and using issues or project boards turns an abstract plan of scope, platform, and team roles into something visible and trackable. The conceptual Git-versus-GitHub explainer also supports the broader Module 1 goal of building shared vocabulary, so that when you move on to usability, user experience, and accessibility work (MO1 and MO2), your team can document and version design artifacts and findings alongside code rather than scattering them across personal drives.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Figma is a browser-based design and prototyping tool that teams use to sketch ideas, build user interface screens, link those screens into clickable prototypes, and hand specifications off to developers. In this course it is the primary tool you will use for your project: you will create an education team workspace (free for students through Figma's education plan), use FigJam boards for brainstorming and affinity mapping, build UI mockups and prototypes in Figma design files, and use Dev Mode to inspect spacing, colors, and generated code snippets when you move from design to implementation.
What makes Figma especially useful here is collaboration. Multiple teammates can work in the same file at the same time, leave comments directly on a screen, and share a single link instead of emailing files back and forth. That matters for the course project, where you will be assigning team roles and iterating on designs based on feedback rather than producing one final artifact alone.
The videos below are hands-on tutorials. As you watch, focus less on memorizing menu locations (Figma's interface changes over time) and more on the workflow: how a rough wireframe becomes a styled screen, how frames are connected into a prototype that someone can actually click through, and how reusable components keep a design consistent. Try following along in your own file rather than just watching, and pause to recreate each step.
A beginner-oriented walkthrough of building wireframes in Figma, aimed at people who have not used the tool before. Based on the title and channel, expect coverage of the basic canvas, frames, shapes and text, and how to lay out low-fidelity screens that represent structure before visual polish. It is framed from a UX practitioner's perspective rather than a pure graphics-tool perspective.
Wireframing is the natural first step after ideation, so this video supports the "Designing UI with Figma" subtopic by showing how to get from a blank file to a usable screen layout. The beginner framing matches students who are opening Figma for the first time in this course.
A follow-up tutorial in the same beginner series that moves from static screens to interactive prototypes. It is likely to cover connecting frames with prototype links, choosing triggers and transitions, and previewing or sharing the resulting clickable flow. This is the step that turns a set of mockups into something a user can test.
Prototyping is central to the course project because it is what you will share for feedback and usability evaluation, and this video pairs directly with the wireframing tutorial to complete the design-to-prototype workflow.
An official Figma tutorial on interactive components, a feature that lets you define states such as default, hover, and pressed inside a single reusable component. The description indicates it explains how to set up those states so interactions carry through everywhere the component is used, instead of being wired up screen by screen.
It comes straight from Figma, so the terminology and workflow are authoritative, and it introduces the component thinking behind design systems that makes Dev Mode handoff and team collaboration far more consistent.
These tutorials are the practical counterpart to the module's conceptual material. While MO1 and MO2 are addressed through readings on HCI history and the distinctions among usability, user experience, and accessibility, Figma is where those ideas become visible artifacts: wireframes and prototypes you can actually put in front of a user to evaluate. The videos most directly support MO3, since planning scope, platform, and team roles is only meaningful if your team shares a workspace and a common toolset. Setting up the education team workspace, agreeing on who ideates in FigJam, who builds components, and who prepares the Dev Mode handoff gives your project plan concrete substance for the rest of the course.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Artificial intelligence has moved from a research curiosity into the everyday toolkit of designers and developers. Generative models now help teams brainstorm interface concepts, draft wireframes and copy, generate and refactor code, write tests, and summarize user research. In this topic we survey where these tools actually fit in the design and development workflow, what they do well, and where human judgment still has to carry the work.
This matters for CEN3722 because your course project will run through the same lifecycle these tools touch: scoping and planning, sketching and prototyping, building, and evaluating. Knowing which tasks an AI assistant can accelerate — and which ones it tends to make worse, such as understanding real users, justifying design decisions, or ensuring accessibility — will make you a faster and more credible team member. It also sets up the course policy on responsible use: AI assistance is a tool you disclose and verify, not a substitute for your own reasoning or a source you can cite blindly.
As you watch the videos below, pay attention to three things. First, which stage of the workflow is each tool being applied to (ideation, visual design, coding, documentation)? Second, what verification step does the presenter take — or fail to take — after the AI produces output? Third, notice how quickly specific tools and features change; the underlying workflow patterns will outlast any particular product shown on screen.
A developer-focused walkthrough of practical ways to fold AI coding assistants into a day-to-day programming workflow, framed around building apps, websites and programs faster. The video is organized as a list of concrete use cases rather than a single tool demo, so you see several different jobs an assistant can take on. Expect coverage of things like generating boilerplate, explaining unfamiliar code, and speeding up routine implementation tasks.
It maps directly onto the AI Coding Assistants and lifecycle subtopics by showing assistance applied at multiple points in development rather than as a novelty. The list format makes it easy to pick out which techniques you might realistically use on your team project.
A full UI/UX workflow guide built around avoiding low-quality, generic AI output — what the channel calls "AI slop." It positions AI as an automation layer for manual design work while the designer retains control over direction and quality. The video walks through a start-to-finish process rather than isolated tool tricks.
This is the clearest fit for the Responsible Use subtopic: it frames AI as something to be steered and quality-checked, not trusted by default. It also connects AI support to a recognizable design process, which is useful as you plan your own project workflow.
A beginner-level tutorial on Figma's AI features, aimed at designers who already use or are learning Figma. It introduces the AI capabilities built into the tool and demonstrates how they speed up common design tasks. The short runtime keeps it focused on getting started rather than on advanced technique.
Figma is the environment many student teams use for wireframing and prototyping, so this grounds the How AI Supports the Design Process subtopic in a tool you are likely to touch during the project. It is a widely viewed introductory tutorial, which makes it a reasonable first exposure for students new to design software.
These videos sit alongside the module's conceptual material rather than replacing it. By showing where AI fits into ideation, visual design, and implementation, they help you see the distinction between surface-level interface polish and the deeper usability, user experience, and accessibility concerns that AI output does not automatically satisfy (MO2) — a gap you should be able to name after watching. The Figma and workflow guides are most directly useful for MO3: they give you a realistic sense of what your team can produce and how fast, which informs the scope, platform choice, and role assignments in your initial project plan. The coding-assistant video similarly helps you estimate development effort when dividing responsibilities. Throughout, treat the tools shown as current examples of a longer HCI trajectory of making interface work easier and more accessible (MO1), and apply the course's disclosure-and-verification expectations to anything you generate.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Before you can design or evaluate an interface, you need a place to build it. This topic walks you through setting up the tools your team will use all semester: a code editor, Git for version control, a GitHub repository for sharing work, and GitHub Codespaces as a cloud-based option when a local setup is inconvenient or when a teammate's machine won't cooperate. You will also establish a sensible project folder structure and naming conventions, then verify that everything works end to end by making a change, committing it, and pushing it.
This matters because your course project is a team effort. Version control is what lets several people edit the same project without overwriting each other, and it gives you a history you can roll back to when an experiment goes wrong. Agreeing on a folder structure and workflow now saves hours of confusion later, and it is a skill employers assume you already have.
As you watch, focus on the sequence of actions rather than memorizing menus: initialize or clone a repository, stage changes, commit with a clear message, push, and pull. Notice where each tool overlaps (the editor's Git panel versus the command line versus the browser) and pick the path you will actually use. Pause and perform each step on your own machine or in a Codespace as you go, and finish by confirming that your commits appear on GitHub.
An official Visual Studio Code tutorial that demonstrates Git basics directly inside the editor, including initializing a repository, renaming a branch, and working with the built-in source control interface. The chapter markers suggest a step-by-step walkthrough of the common commit-and-push cycle without needing to memorize terminal commands. It is short and demonstration-driven, so you can follow along in your own editor.
It comes from the VS Code team itself, so the interface shown matches the editor most students will install, and it directly covers both the choosing-an-editor and installing-and-configuring-Git-locally subtopics.
A beginner-oriented guide from GitHub that breaks down creating your first repository, covering the setup options you choose when a repo is made and the first steps of getting content into it. Expect coverage of the repository's role as the shared home for a team's code and files. The pacing is aimed at people who have never used GitHub before.
Produced by GitHub, it is authoritative on the platform your team will use for collaboration, and it fills the gap between a local Git setup and a shared remote repository where folder structure and conventions begin to matter.
A CS50 workshop session introducing GitHub Codespaces, a browser-based development environment that runs VS Code in the cloud. It is framed for educators and students, so it likely explains why a hosted environment removes installation headaches and how a Codespace connects to a GitHub repository. Expect a tour of launching and working inside a Codespace.
It is the clearest fit for the cloud development subtopic and offers a practical fallback for teammates whose local setup fails, delivered by a well-known and reliable course production team.
These videos are the hands-on counterpart to the module's conceptual outcomes. While MO1 and MO2 ask you to recall HCI principles and distinguish usability, user experience, and accessibility, you need a working environment in which to apply those ideas to the course project, and the VS Code and GitHub tutorials give you that foundation. The Codespaces session supports MO3 most directly: knowing whether your team will work locally, in the cloud, or both is part of defining platform and team roles in your initial project plan, and a shared repository is where scope, task assignments, and project files are recorded and tracked.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Almost everything you produce in this course will be produced with other people. This topic is about setting up that collaboration deliberately rather than letting it happen by accident: forming a team, agreeing on who does what, writing it down in a team charter, and bounding the course project so the scope is something your team can actually finish in a semester.
The practices here come straight from project management. A team charter, a roles-and-responsibilities list, a communication plan, and a scope statement are all standard project documents, and the vocabulary around them (stakeholder, deliverable, milestone, scope creep) is vocabulary you will see again in industry. Learning it now makes your design work later in the course easier to coordinate and easier to explain to a client or instructor.
The three videos below come from a project management practitioner channel and cover the documents, the communication planning, and the terminology side of kickoff. As you watch, map what you hear onto your own team: which documents does our project actually need, how will we decide when and how we talk to each other, and where exactly does our project stop? Take notes you can paste directly into your charter and project plan drafts.
A short walkthrough of five project documents the presenter considers essential during planning, with an explanation of what each one is for and when it gets created. Expect coverage of foundational artifacts such as a charter or scope-defining document and the supporting plans that follow from it. The format is practical and aimed at people who are about to start a project rather than at theory.
It maps directly onto the "Creating the Team Charter" and "Scoping the Course Project" subtopics by showing which written artifacts a kickoff should produce and why each one exists.
A step-by-step guide to building a project communication plan: who needs information, what information they need, how often, and through which channel. The video is longer and more procedural, walking through the structure of the plan rather than just describing it. It also touches on stakeholders and why communication breakdowns derail projects.
Communication norms are the operational half of a team charter, and this video gives you a concrete template-style process for deciding meeting cadence, channels, and reporting responsibilities for your team.
An explanation of ten commonly used project management terms, with plain-language definitions and examples. Based on the title and description, expect terms around scope, deliverables, stakeholders, milestones, and similar planning vocabulary. It is the most-viewed of the three and is pitched at people new to the field.
Shared vocabulary is what lets a new team talk about scope and roles without talking past each other, so this is useful groundwork before you draft the charter and project plan.
These videos chiefly support MO3: building an initial project plan that defines scope, platform, and team roles. The documents video shows what artifacts a kickoff should produce, the communication plan video shows how to specify who is responsible for what and how the team will coordinate, and the terminology video gives you the shared language for scope, deliverables, and stakeholders that the plan is written in. They do not address MO1 or MO2 directly; the HCI history and the usability, user experience, and accessibility distinctions come from the other readings and videos in this module, and you should bring those concepts with you when you decide what your team's project is actually about.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.