↑ 1 - HCI Foundations and Course Project Setup

1 - HCI Foundations and Course Project Setup

Introduction to Human-Computer Interaction

1

Introduction to Human-Computer Interaction

▶

Human-Computer Interaction (HCI) is the interdisciplinary field that studies how people interact with computing systems and how those systems can be designed to better serve human needs. It draws on computer science, cognitive psychology, design, sociology, and ergonomics. Where traditional software engineering asks "does the system work correctly?", HCI asks a harder and more consequential question: "does the system work well for the people who must use it?" A program can be algorithmically flawless and still fail completely if users cannot discover its features, misinterpret its feedback, or abandon it out of frustration.

This topic establishes the shared vocabulary and mental models you will use for the rest of the course. Before you open a design tool or write a line of interface code, you need a working theory of what makes an interface good, how to evaluate that claim with evidence rather than opinion, and where human-centered activities fit into the way software actually gets built.

What Is HCI?

At its heart, HCI examines the relationship between three elements that form a continuous loop: the user, the task, and the system. The user has goals and intentions shaped by their knowledge, experience, physical abilities, and context. The task is the concrete work that must be accomplished to reach those goals. The system is the technology that mediates the task. Design quality is not a property of any one element alone — it emerges from the fit among all three. A command-line interface is superb for an experienced system administrator batch-renaming 10,000 files, and catastrophic for a first-time user who wants to crop a photo. Same system, different user and task, radically different outcome.

A useful way to formalize this loop is Donald Norman's Seven Stages of Action, which traces one cycle of interaction:

StageWhat the user is doingExample: sending an email attachment
1. Form the goalDeciding what outcome is wanted"My colleague needs this report."
2. Form the intentionChoosing a general approach"I'll email the PDF to her."
3. Specify the actionPlanning the concrete steps"Click the paperclip, pick the file, click Send."
4. Execute the actionOperating the interfaceClicking and typing.
5. Perceive system stateNoticing what changedA filename chip appears; a progress bar fills.
6. Interpret the stateMaking sense of the change"The file is attached."
7. Evaluate the outcomeComparing result to the goal"Sent — she'll receive the report."

Norman describes two places where this loop breaks. The gulf of execution is the gap between what a user wants to do and what the interface lets them express — the user cannot figure out how to do the thing. The gulf of evaluation is the gap between what the system did and what the user can perceive and understand — the user cannot tell whether it worked. A hidden gesture on a mobile app widens the gulf of execution; a "Save" button that produces no visible confirmation widens the gulf of evaluation. Most usability complaints, when analyzed carefully, reduce to one of these two gulfs.

Reducing cognitive load. Human working memory is extraordinarily limited — classically estimated at about seven items, and in practice closer to four chunks of novel information held for roughly 15–30 seconds without rehearsal. Every element an interface asks a user to remember, decode, or mentally calculate consumes a share of this scarce resource. Cognitive load theory distinguishes intrinsic load (the inherent difficulty of the task — filing taxes is genuinely complex), extraneous load (effort wasted on poor presentation — hunting for a mislabeled button), and germane load (effort that builds useful understanding). Good HCI attacks extraneous load aggressively.

  • Recognition over recall. A visible menu of options is easier than remembering a command name. This is why a dropdown of saved payment cards beats "type your card number again."
  • Chunking and progressive disclosure. A 40-field form split into four labeled steps of ten feels dramatically shorter than one wall of inputs, even though the total work is identical.
  • Offloading computation to the machine. Showing "Total: $47.83 including tax and shipping" is better than making the user add three numbers. Auto-detecting card type from the first digits is better than a card-type dropdown.
  • Sensible defaults. Pre-selecting the most common option converts a decision into an optional review.

The payoff is measurable: lower error rates, faster task completion, and higher satisfaction. Satisfaction is not a soft extra — it drives retention, word of mouth, willingness to adopt new features, and in enterprise settings, whether staff use the official tool or quietly build a spreadsheet workaround that fragments the organization's data.

HCI applies everywhere software meets people. The principles are platform-independent, even though their expression changes with context:

ContextDominant constraintsTypical HCI concerns
Web applicationsVariable screen sizes, browser capabilities, shared links, back buttonResponsive layout, page load perception, keyboard and screen-reader support, URL as state
Mobile appsSmall screen, touch targets, one-handed use, interruptions, battery and bandwidthThumb-reachable controls, minimum ~44 pt touch targets, offline tolerance, permission requests
Desktop softwareLong sessions, expert users, multi-window workflowsKeyboard shortcuts, undo history, customizability, dense information display
Embedded and IoTFew or no screens, physical controls, safety consequencesMapping of control to effect, audible/haptic feedback, failure modes, constrained input

Consider a car's cruise control stalk, a hospital infusion pump, and a thermostat. None look like "software," yet each is a textbook HCI problem. Infusion pump design is a well-documented case where ambiguous number entry (a missing leading zero, a misplaced decimal) has caused fatal overdoses — proof that interaction design is sometimes a safety-critical discipline, not a cosmetic one.

Core HCI Principles

Usability is the degree to which a system lets specified users achieve specified goals effectively, efficiently, and satisfactorily in a specified context of use (the ISO 9241-11 definition). Notice how much of that definition is conditional: usability is never absolute, it is always relative to who, what, and where. Jakob Nielsen decomposes usability into five measurable components:

ComponentQuestion it answersExample metric
LearnabilityHow easy is the first encounter?Time for a new user to complete first checkout
EfficiencyHow fast are experienced users?Average clicks or seconds per repeat order
MemorabilityHow easily do returning users regain proficiency?Task time after a 30-day absence
ErrorsHow often do users slip, and how bad is it?Error rate per task; recovery time
SatisfactionHow pleasant is the experience?SUS score, post-task rating

These components can conflict, which is why design involves trade-offs rather than universal right answers. A wizard that walks users through each step maximizes learnability but destroys efficiency for daily users; the usual resolution is to support both paths — a guided flow plus keyboard shortcuts and bulk actions. The System Usability Scale (SUS) is a widely used 10-item questionnaire producing a 0–100 score; roughly 68 is average, and above about 80 is considered good — useful because it lets you compare versions with a number instead of an argument.

Accessibility ensures systems are usable by people across the full range of human ability — including permanent disabilities (blindness, deafness, motor impairment, dyslexia), temporary conditions (a broken arm, an eye infection), and situational limits (bright sunlight on a screen, holding a baby, a noisy train). Microsoft's persona spectrum makes this vivid: a design that serves a person with one arm also serves a person with a temporary arm injury and a parent carrying a child. Accessibility is therefore not a niche accommodation; it expands the reachable audience for everyone.

The practical framework is the Web Content Accessibility Guidelines (WCAG), organized under the POUR acronym:

  • Perceivable — information must be presentable in ways users can sense. Text alternatives for images, captions for video, and a minimum 4.5:1 contrast ratio for normal-size text at WCAG AA.
  • Operable — all functionality must be available without requiring a mouse, with enough time to act and no content that triggers seizures. Every interactive control must be reachable and activatable by keyboard, with a visible focus indicator.
  • Understandable — language should be clear, behavior predictable, and errors explained in plain terms with suggested fixes ("Password must contain at least one number," not "Invalid input").
  • Robust — content must work reliably with assistive technologies such as screen readers, which depends on using semantic HTML and correct ARIA roles.

A concrete contrast: a form field labeled only by gray placeholder text disappears the moment the user types, fails contrast guidelines, and is often skipped by screen readers. A persistent <label> element correctly associated with its input solves all three problems at once — and incidentally makes the field easier for sighted mouse users too, because clicking the label focuses the input.

Feedback closes the interaction loop by confirming that an action registered and telling the user what happened. Without it, users repeat actions (double-charging a credit card), assume failure, or abandon the task. Feedback should be matched in weight to the significance of the event and should respect human timing thresholds:

Response timeUser perceptionAppropriate feedback
Under 0.1 sFeels instantaneous; direct manipulationImmediate visual state change (button press, hover)
About 1 sFlow of thought preserved, but delay noticedNo spinner needed; a simple state change suffices
Up to 10 sAttention held with effortSpinner or indeterminate indicator, disable resubmission
Over 10 sAttention wanders; user may leavePercent-complete progress bar, time estimate, option to cancel or continue elsewhere

Feedback also includes error messages, which should state what went wrong, why, and how to fix it. Compare:

Poor:  Error 0x80070057. Operation failed.

Better: We couldn't upload "quarterly-report.pdf" because it is 28 MB
        and the limit is 25 MB. Try compressing the file or sharing
        a link instead.  [Compress]  [Share a link]  [Cancel]

Related is visibility of system status more broadly: a "Saved 2 minutes ago" timestamp, an order-tracking stage indicator, or an unread badge all keep the user oriented without them having to ask.

Consistency lets users transfer knowledge rather than relearn it. It operates on several levels:

  • Internal consistency — within your product, the same action looks and behaves the same way everywhere. If the primary action button is a filled blue rectangle on the right of a dialog, it should not become a green text link on the left three screens later.
  • External consistency — conformance to platform and web conventions. A logo in the top-left returns to home; a magnifying glass means search; on iOS, a back swipe from the left edge goes back. Jakob's Law states that users spend most of their time on other sites, so they expect yours to work like those.
  • Conceptual consistency — the mental model stays coherent. If "archive" means "hide from inbox but keep forever," it must never silently delete anything.

Design systems (Material Design, Apple's Human Interface Guidelines, or a team's own component library in Figma) operationalize consistency by making the consistent choice the easiest choice. The counterweight is Nielsen's companion heuristic: deviate from convention only when the deviation delivers a clear, demonstrable benefit — and then test it.

The User-Centered Design Process

User-Centered Design (UCD), codified in ISO 9241-210, is an iterative cycle with four repeating activities: understand the context of use, specify user requirements, produce design solutions, and evaluate against requirements. You loop until the evaluation shows the requirements are met. The defining commitment is that real users inform the design at every stage, rather than designers substituting their own intuitions.

Step 1 — Understanding users through research. The research phase answers who the users are, what they are actually trying to accomplish, and under what constraints. Common methods include:

  • Semi-structured interviews — open questions about past behavior ("Walk me through the last time you booked a room") rather than hypotheticals ("Would you use a feature that…"), because people predict their own future behavior poorly.
  • Contextual inquiry / observation — watching users work in their real environment. This surfaces workarounds people never think to mention: the sticky note of codes on the monitor, the parallel spreadsheet, the habit of printing a screen because the system can't export.
  • Surveys — for breadth and quantification once you know which questions matter.
  • Analytics and support-ticket review — evidence of where existing users drop off or ask for help.
  • Competitive and heuristic review — establishing conventions and baseline expectations.

Research outputs are synthesized into shareable artifacts: personas (evidence-based archetypes, e.g. "Marcus, 42, warehouse supervisor, uses a rugged tablet with gloves on in a loud, cold environment; needs large targets and audible confirmation"), journey maps charting a user's steps, emotions, and pain points over time, and jobs-to-be-done statements framing the underlying goal ("When a shipment arrives short, I want to flag the discrepancy in under a minute so the driver isn't held up").

Step 2 — Prototyping and testing with representative users. A prototype is a deliberately incomplete artifact built to answer a question cheaply. Fidelity should match the question:

FidelityFormBest for answeringTypical cost
LowPaper sketches, whiteboard flowsIs the overall structure and flow right?Minutes
MediumFigma wireframes with clickable hotspotsCan users find things and complete a task?Hours
HighFigma prototype with real styling, or coded front endDo visual hierarchy, microcopy, and micro-interactions work?Days

Testing means giving a participant a realistic task and observing silently. Give a scenario, not instructions: say "You need a waterproof jacket under $150 delivered by Friday — find one and buy it," never "Click the Filters button." Ask participants to think aloud. Record where they hesitate, where they look in the wrong place, and what they say they expect to happen. Nielsen's well-known finding is that roughly five participants per round uncover about 85% of the usability problems in a design — which means it is far better to run three small tests across three iterations than one large test at the end.

Step 3 — Iteration is structural, not optional. This is the point students most often underestimate. A first design is a hypothesis; testing is the experiment; the redesign is the result. Teams that treat testing as a one-time validation checkpoint tend to rationalize the findings away ("that participant was unusual") instead of acting on them. A healthy loop looks like: build a rough prototype in a day, test with five users, fix the top three problems, test again with five different users, and confirm the fixes worked without creating new problems. Each pass should narrow in scope — early rounds change the information architecture, later rounds change label wording and button placement.

Step 4 — Why this saves money. The cost of fixing a defect rises sharply the later it is discovered, because more downstream work depends on it. Changing a navigation structure on a paper sketch costs an eraser; changing it after launch costs rewritten code, migrated data, updated documentation, retrained support staff, and broken user habits.

Stage problem is foundWhat must changeRelative cost
Research / conceptAn assumption in a document1×
Wireframe / prototypeA few screens in Figma~5×
DevelopmentComponents, state logic, tests~10–20×
After releaseCode, data migration, docs, support, user retraining, reputation~100×

The exact multipliers vary by study and context, but the shape of the curve is uncontested. UCD is best understood as a risk-reduction strategy: it buys cheap information early about expensive decisions.

HCI and the Software Development Lifecycle

HCI is not a separate phase bolted onto the front of a project; it threads through the entire lifecycle, with different methods dominant at different points.

Requirements gathering. Traditional requirements documents list system functions ("the system shall allow filtering by date"). HCI methods reframe requirements around human goals, which keeps teams from building technically correct features nobody needs. Personas give requirements a face, so debates shift from "I think users want X" to "Would Marcus, in gloves, in a loud warehouse, be able to do X?" User stories encode the same idea in a sentence the whole team can read:

As a warehouse supervisor,
I want to flag a short shipment from the receiving screen,
so that I can resolve the discrepancy before the driver leaves.

Acceptance criteria:
- Flagging takes no more than 3 taps from the receiving screen.
- Works with gloves: all targets at least 48 x 48 dp.
- A confirmation is both visible and audible.
- Reachable by keyboard and announced correctly by a screen reader.

Note that acceptance criteria can and should include usability and accessibility thresholds. If "three taps" and "48 dp targets" are not written down, they will be negotiated away under schedule pressure.

Design and development. During these phases, prototyping and usability testing run in parallel with implementation. On an agile team, a common pattern is dual-track development: a discovery track validates designs one or two sprints ahead, while a delivery track builds the already-validated work. Other HCI activities that fit here include heuristic evaluation (two or three evaluators independently inspecting the interface against Nielsen's ten heuristics — a fast, cheap check that complements but does not replace user testing), cognitive walkthroughs (stepping through a task asking at each step whether the user would know what to do and whether they'd see progress), and accessibility audits combining automated scanners with manual keyboard and screen-reader passes. Automated tools typically catch only about a third of real accessibility issues, so manual testing is essential.

Post-launch. Release is the start of the richest feedback stream, not the end of design. Sources include:

  • Behavioral analytics — funnel drop-off rates, task success rates, time on task, rage clicks (rapid repeated clicking on an unresponsive element), and dead clicks on non-interactive items.
  • Session replays and heatmaps — aggregate views of where attention and interaction actually land, which frequently contradict assumptions.
  • Support tickets and app-store reviews — the most expensiveform of user feedback, because the user has already been frustrated enough to complain; clustering them by theme turns anecdotes into a prioritized backlog.
  • In-product surveys — short, targeted prompts (a one-question SUS-style rating after a completed task) that connect sentiment to a specific moment.
  • A/B testing — controlled comparison of two variants on live traffic. Powerful for settling local questions (button wording, form length) but blind to problems with the option you never tested, which is why it supplements rather than replaces qualitative research.

A healthy team closes the loop: analytics reveal what is happening (62% of users abandon the address step), qualitative testing reveals why (the postcode field silently rejects lowercase letters), and the fix is validated by watching the metric move. This is the mechanism by which an interface improves continuously instead of drifting.

Lifecycle phasePrimary HCI activitiesTypical artifacts
Discovery / requirementsInterviews, contextual inquiry, competitive reviewPersonas, journey maps, user stories with acceptance criteria
DesignSketching, wireframing, interactive prototyping, early usability testsFigma flows, component library, test findings report
DevelopmentDesign reviews, heuristic evaluation, accessibility audits, QA against criteriaAnnotated specs, issue list, audit report
Release and beyondAnalytics instrumentation, in-product surveys, A/B tests, support triageDashboards, prioritized improvement backlog

Why HCI Matters for This Course

Everything above is only useful once you have practiced it on something real, which is the purpose of the course project. You will take an interface from research through prototype to a tested, revised design, and you will have to defend your decisions with evidence rather than taste. Expect the project to apply the full cycle in miniature: identify a user group and a genuine task, interview or observe a handful of people, build a low-fidelity prototype, test it with at least five representative participants, document the problems you found, and ship a revised version that demonstrably addresses them. The deliverable that matters most is not the prettiest screen — it is the trail of reasoning connecting a user's observed difficulty to a specific design change.

You will work in the same toolchain professionals use, which is deliberate. Figma is the industry standard for interface design because it is browser-based, real-time collaborative, and supports reusable components, shared styles, clickable prototypes, and inline commenting — so a developer, a designer, and a stakeholder can all be in the same file. Learning its component and auto-layout model teaches you consistency in a tangible way: when a button is a component, updating it once updates it everywhere, and inconsistency becomes the harder path. GitHub provides version control, branching, pull requests, and issue tracking. Even for design-heavy work, GitHub is where the record of decisions lives — issues capture usability findings, pull requests tie a code change to the problem it solves, and commit history makes your iteration visible. Being fluent in both tools is a baseline expectation in most product teams, and a portfolio repository with a clear README and commit trail is often the first thing an employer looks at.

Finally, the peer collaboration built into the course is not administrative convenience; it mirrors how real cross-functional teams operate. In industry, interfaces are produced by designers, developers, product managers, researchers, content writers, and accessibility specialists who must negotiate competing constraints — a visually elegant layout that is expensive to build, a fast-to-implement pattern that fails a WCAG check, a feature the business wants that research says users do not. Practicing those conversations now builds skills that are as valuable as any technique in this module:

  • Giving and receiving critique on the work, not the person — "a user searching for refunds would scan this column first and miss the link" is actionable; "I don't like the layout" is not.
  • Making decisions traceable — recording why a design changed so the team does not relitigate it in three weeks.
  • Testing on someone outside your team — you cannot usability-test your own design, because you already know where everything is; peers provide fresh eyes and you provide the same for them.
  • Negotiating trade-offs explicitly — naming which usability component (learnability vs. efficiency, for instance) you are optimizing for, and for whom.

Carry three ideas forward into the rest of the course. First, you are not your user — your fluency with the interface you designed is the single biggest source of bias in your judgment. Second, design is a claim that must be tested, and five people watching a prototype will teach you more than five hours of internal debate. Third, accessibility and usability are the same project, not competing ones; designing for the edges of human ability almost always produces a clearer, more robust experience for everyone in the middle.

NotesSuggested teaching aids: (1) open with a two-minute "norman door" or confusing-appliance example to ground the gulfs of execution and evaluation before formal definitions; (2) a quick in-class exercise where pairs rewrite a real error message using the state-what/why/how-to-fix pattern; (3) have students run the SUS questionnaire on an app they use daily so the 68-point benchmark becomes concrete. Common misconceptions to pre-empt: that HCI equals visual styling, that accessibility is a late-stage compliance checkbox, and that "I asked my friend and they liked it" constitutes usability testing. Terminology students should be able to define by the end: usability (ISO 9241-11), the five Nielsen usability components, POUR, persona, journey map, prototype fidelity, iteration, heuristic evaluation. Assessment hook: the cost-of-change table pairs naturally with a short written justification of why the project requires testing before implementation.
2

Videos on This Topic

▶

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.

3

Video 1: Chapter 1: What is Interaction Design

▶

Vasiliki - HCI · 16:16 · 14,628 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Chapter 2: The Process of Interaction Design

▶

Vasiliki - HCI · 12:04 · 8,018 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Explain UX with User-Centered Design

▶

NNgroup · 3:44 · 11,791 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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).

7

About These Videos

▶

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 with GitHub

1

Version Control with GitHub

▶

Every software project — from a one-file script to a system with millions of lines of code — accumulates change. Files get edited, deleted, renamed, and restored. Features are added, then abandoned. Bugs are introduced by a "small tweak" that nobody remembers making. Without a disciplined way to record those changes, a team quickly loses the ability to answer the three questions that matter most: What changed? Who changed it? Why? Version control answers all three automatically, and GitHub turns that answer into a shared, cloud-hosted workspace where an entire team can plan, build, review, and ship together. This topic walks through version control from first principles and then builds up the practical GitHub workflow you will use for the course project.

What Is Version Control?

A version control system (VCS) is a tool that records snapshots of a project over time and lets you move between those snapshots at will. Git — the engine underneath GitHub — is a distributed VCS: every contributor holds a complete copy of the project's entire history on their own machine, not just the latest files. That design makes most operations instant (they happen locally) and makes the history remarkably resilient, since dozens of full backups exist by default.

A complete history of every change. The atomic unit of Git history is the commit: a snapshot of the project plus metadata (author, timestamp, parent commit, and a message explaining the change). Each commit is identified by a SHA-1 hash such as a3f91c7, which is derived from the content itself, so history cannot be silently altered. Because the chain of commits is preserved, you can inspect exactly how a file evolved:

$ git log --oneline -5
a3f91c7 Fix off-by-one error in pagination
7d2e04b Add unit tests for pagination helper
1c8b55a Refactor query builder into its own module
9f0ad31 Add pagination to results page
4e77b12 Initial project scaffold

$ git log -p src/pagination.js      # see every change ever made to one file
$ git blame src/pagination.js       # see which commit and author touched each line
$ git diff 9f0ad31 a3f91c7          # compare any two points in history

This history is not bookkeeping for its own sake — it is a debugging tool. When a bug appears, git bisect can binary-search the commit history to find the exact commit that introduced it, often narrowing hundreds of commits down to the culprit in eight or nine steps.

Multiple contributors without overwriting each other. Before version control, teams passed around folders named project_final, project_final_v2, project_final_REAL_v2. Two people editing the same file meant one person's work was lost. Git solves this by tracking changes at the line level and merging them. If Amara edits the header of index.html while Ben edits the footer, Git combines both edits automatically. Only when two people change the same lines does Git stop and declare a merge conflict, marking the file so a human can decide:

<<<<<<< HEAD
<h1>Campus Event Finder</h1>
=======
<h1>Campus Events</h1>
>>>>>>> feature/rename-title

You edit the file to the desired final state, remove the marker lines, then git add and commit. Conflicts feel intimidating at first but are routine; the important insight is that Git never silently discards anyone's work.

Restoring any version at any point. Because every commit is a full snapshot, "undo" is always available and always safe:

GoalCommandEffect
Discard uncommitted edits to a filegit restore src/app.jsFile returns to its last committed state
View the project as it was last Tuesdaygit checkout a3f91c7Working directory matches that commit (detached HEAD)
Recover a single deleted filegit checkout 9f0ad31 -- docs/spec.mdPulls one file back from history
Undo a published commit safelygit revert a3f91c7Creates a new commit that inverts the old one
Rewind local history (not yet shared)git reset --hard 7d2e04bMoves the branch pointer back; destructive

The distinction between revert and reset matters on a team: revert preserves history and is safe for shared branches; reset --hard rewrites history and should be reserved for commits you have not pushed.

GitHub as a Collaboration Platform

Git manages history; GitHub manages people working on that history together. It is a hosting service built around Git repositories, layered with review, automation, and planning tools.

Cloud-hosted repositories. A GitHub repository is a remote — a canonical copy of the project that every contributor pushes to and pulls from. Practically, this means your work is backed up off your laptop, accessible from the lab machine, a teammate's computer, or a browser-based editor (press . on any repo page to open it in a web VS Code instance). The basic rhythm is:

$ git clone https://github.com/team-orion/event-finder.git
$ cd event-finder
# ...edit files...
$ git add src/calendar.js
$ git commit -m "Add month-view rendering for the calendar widget"
$ git pull --rebase origin main   # bring in teammates' work first
$ git push origin main

A repository can be public (visible to anyone, the basis of open source) or private (visible only to invited collaborators). Public repos double as a portfolio: employers routinely read candidates' commit histories and READMEs.

Issues, Projects, and Discussions. GitHub deliberately keeps planning next to the code rather than in a separate tool. Issues are tickets for bugs, features, and chores. Projects are kanban boards and tables built from those issues. Discussions are threaded forums for open-ended questions, design debates, and announcements that would clutter an issue tracker ("Should we switch the database to Postgres?" belongs in Discussions; "Login button is misaligned on Safari" belongs in Issues). Because all three live beside the code, an issue can reference a commit, a commit can close an issue, and a pull request can appear automatically on the project board.

GitHub Actions. Actions is GitHub's built-in automation engine. You define workflows as YAML files in .github/workflows/, and GitHub runs them on hosted virtual machines in response to events such as a push, a pull request, a schedule, or a manual trigger. The classic use is continuous integration: run the test suite on every pull request so broken code is caught before review.

name: CI
on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage

Each pull request then displays a green check or red X. Teams commonly make these checks required, so a PR physically cannot be merged while tests fail. Beyond testing, Actions handles deployment (publishing a site to GitHub Pages, pushing a container image, releasing a package), scheduled maintenance (nightly data refreshes), and housekeeping (auto-labelling PRs, greeting first-time contributors).

GitHub Copilot. Copilot is an AI pair programmer that integrates into editors such as VS Code, JetBrains IDEs, and the GitHub web interface. It suggests completions ranging from a single line to whole functions based on your current file, surrounding code, and comments. Writing a descriptive comment or function signature is the most reliable way to steer it:

// Return events that start within the next `days` days, sorted soonest first.
function upcomingEvents(events, days) {
  // Copilot proposes an implementation here; press Tab to accept.
}

Copilot Chat extends this to conversational use — explaining unfamiliar code, drafting unit tests, proposing fixes for a failing build, or writing a commit message. Treat suggestions as drafts, not truth: they can be subtly wrong, use outdated APIs, or invent functions that do not exist. Always read, test, and understand the code before committing it, and check your course or employer's policy on AI assistance.

Creating and Configuring a Repository

Creating a repository takes thirty seconds; configuring it well is what makes a project pleasant to join six months later.

What a repository stores. A repo holds the working files, the entire commit history, branches and tags, and collaboration metadata — issues, pull requests, releases, wiki pages, and settings. All of the Git data lives in a hidden .git directory at the project root; deleting it would leave the files but erase the history. You can create a repo from the GitHub UI (and clone it), or start locally and connect it afterwards:

$ git init
$ git add .
$ git commit -m "Initial commit"
$ git branch -M main
$ git remote add origin https://github.com/team-orion/event-finder.git
$ git push -u origin main

The README. README.md is rendered automatically on the repository's front page and is the single highest-leverage file in the project. A strong README answers, in order: what this project is, why it exists, how to run it, and how to contribute. A workable skeleton:

# Campus Event Finder

A web app that aggregates student-club events into a single searchable calendar.

## Features
- Browse events by club, date, or tag
- Save events to a personal watchlist
- ICS export for Google/Apple Calendar

## Getting Started
```bash
git clone https://github.com/team-orion/event-finder.git
cd event-finder
npm install
cp .env.example .env     # then fill in your API keys
npm run dev              # serves at http://localhost:3000
```

## Project Structure
- `src/` — application code
- `tests/` — Jest test suite
- `docs/` — design notes and API reference

## Contributing
Branch from `main` using `feature/`, open a pull request,
and request review from at least one teammate. All PRs must pass CI.

## License
MIT

Larger projects split the contributor guidance into CONTRIBUTING.md and add CODE_OF_CONDUCT.md and LICENSE; GitHub surfaces all of these in the interface automatically.

The .gitignore file. Not everything in your working folder belongs in version control. Build artefacts bloat the repo, machine-specific files cause pointless conflicts, and credentials in a public repo are a genuine security incident — automated bots scan GitHub for leaked keys within minutes of a push. .gitignore lists patterns Git should not track:

# Dependencies
node_modules/
venv/

# Build output
dist/
build/
*.pyc
__pycache__/

# Environment and secrets
.env
.env.local
*.pem
credentials.json

# Editor and OS noise
.vscode/
.idea/
.DS_Store
Thumbs.db

# Logs
*.log
npm-debug.log*

Two important caveats. First, .gitignore only prevents untracked files from being added; if a file is already tracked, you must run git rm --cached .env to stop tracking it. Second, if a secret has already been pushed, removing it in a later commit is not enough — it remains in history. The correct response is to rotate the credential immediately and then, if necessary, purge it from history with a tool such as git filter-repo. The safe pattern is to commit a placeholder .env.example with blank values and keep the real .env ignored.

Access permissions. GitHub controls who can do what through repository roles. For a personal repo you invite collaborators directly; in an organization you typically grant access to teams.

RoleTypical capabilitiesWho gets it
ReadClone, pull, open issues, comment, reviewStakeholders, instructors, observers
TriageRead, plus manage issues and PRs (label, assign, close)Community moderators, QA helpers
WriteTriage, plus push branches and merge approved PRsCore team members
MaintainWrite, plus most repository settings (not destructive ones)Team leads
AdminFull control: permissions, branch protection, delete, transferProject owner(s)

Apply the principle of least privilege: give each person the lowest role that lets them do their job. External contributors do not need write access at all — they fork the repository (make their own copy) and submit pull requests from the fork, which the maintainers review before merging. Admins should also enable two-factor authentication and, for the main branch, configure branch protection rules (described below).

Branching and Pull Requests

A branch is simply a movable pointer to a commit. Creating one is instantaneous and costs essentially nothing, which is why branching is the backbone of team workflow rather than an advanced technique.

Keeping main stable. The main branch is the project's source of truth: at any moment, the code on main should build, pass tests, and be safe to demo or deploy. Nobody commits half-finished work directly to it. Mature teams enforce this with branch protection rules on main:

  • Require a pull request before merging (direct pushes blocked).
  • Require at least one approving review, and dismiss stale approvals when new commits arrive.
  • Require status checks (the CI workflow) to pass.
  • Require branches to be up to date with main before merging.
  • Restrict who can force-push or delete the branch.

Feature branches. Each unit of work — a feature, a bug fix, a documentation update — gets its own short-lived branch cut from main. Naming conventions make the branch list self-documenting: feature/ics-export, fix/142-safari-login, docs/setup-instructions, chore/upgrade-eslint.

$ git switch main
$ git pull origin main                 # start from the latest code
$ git switch -c feature/ics-export     # create and switch in one step
# ...work, committing in small logical steps...
$ git add src/export/ics.js tests/ics.test.js
$ git commit -m "Add ICS export for saved events

Generates RFC 5545 output and streams it as a download.
Closes #87."
$ git push -u origin feature/ics-export

Keep branches small and short-lived — ideally merged within a few days. A branch that lives for three weeks drifts far from main and produces a painful conflict-ridden merge. If main moves on while you work, integrate regularly with git pull --rebase origin main (or git merge main) so conflicts are resolved in small doses.

Pull requests. A pull request (PR) proposes merging your branch into another and opens a structured conversation around the change. It shows the full diff, the commit list, CI results, and a comment thread where reviewers can leave line-level remarks. A good PR description tells the reviewer what they need to know:

## What
Adds an "Export to Calendar" button that downloads saved events as an .ics file.

## Why
Closes #87 — users asked for a way to get events into Google Calendar.

## How
- New `src/export/ics.js` builds RFC 5545 VEVENT blocks
- Route `GET /api/export` streams the file with the correct MIME type
- 12 unit tests covering timezones, all-day events, and empty watchlists

## Testing
`npm test` passes locally; manually verified import into Google Calendar and Apple Calendar.

## Screenshots
(attached)

Reviewers can Comment (feedback without a verdict), Approve, or Request changes. GitHub also supports suggested changes — a reviewer writes the corrected code in a comment and the author applies it with one click. Useful review etiquette: review promptly (a stalled PR blocks a teammate), critique the code rather than the person, distinguish blocking issues from preferences ("nit:" is a common prefix for the latter), and as the author, respond to every comment even if just to say you've addressed it. Draft pull requests let you open a PR early for visibility while signalling it is not ready to merge.

Merging and a clean history. Once approved and green, the branch is merged. GitHub offers three strategies:

StrategyWhat it doesWhen to use it
Merge commitKeeps every branch commit and adds a merge commit with two parentsWhen the individual commits are meaningful and you want the full branch structure recorded
Squash and mergeCollapses all branch commits into one commit on mainMost team workflows — gives main one tidy commit per feature and hides "fix typo" noise
Rebase and mergeReplays branch commits on top of main with no merge commitTeams that want a strictly linear history and write clean commits

After merging, delete the feature branch (GitHub offers a one-click button) to keep the branch list meaningful; the commits remain in history. Then everyone runs git switch main && git pull before starting their next branch. Used consistently, this loop — branch, commit, push, PR, review, merge, delete — gives you a main branch whose history reads like a changelog of completed features.

GitHub for Project Management

Because planning artefacts live in the same place as the code, GitHub can link intent to implementation automatically.

Issues as task tickets. An issue is a unit of work with a title, a markdown body, and rich metadata:

  • Assignees — who is responsible. One assignee is clearer than three.
  • Labels — categorisation such as bug, enhancement, documentation, good first issue, priority:high, blocked.
  • Milestone — which release or sprint it belongs to.
  • Linked pull requests — the code that implements it.
  • Task lists — checkboxes inside the body that render as a progress bar.

A well-written bug issue is reproducible by someone who has never seen it:

Title: Login button unresponsive on Safari 17

**Steps to reproduce**
1. Open https://events.example.edu in Safari 17.2 (macOS 14)
2. Click "Log in with university SSO"

**Expected:** redirect to the SSO provider
**Actual:** nothing happens; console shows
`TypeError: undefined is not an object (evaluating 'e.target.closest')`

**Environment:** Safari 17.2 / macOS 14.3 — works in Chrome 121 and Firefox 122
**Severity:** blocks all Safari users from signing in

- [ ] Reproduce locally
- [ ] Add polyfill or fallback
- [ ] Add a regression test

Issues and code are linked through keywords in commit messages or PR descriptions. Writing Closes #142, Fixes #142, or Resolves #142 in a PR causes GitHub to close issue 142 automatically the moment the PR merges, and to display a permanent cross-reference in both directions. Mentioning #142 without a keyword creates the link without closing. You can also type @username to pull someone into the conversation, and use issue templates (stored in .github/ISSUE_TEMPLATE/) so every bug report arrives with the same required fields.

Project boards. GitHub Projects turns a pile of issues into a visual workflow. The classic view is a kanban board with columns representing states:

ColumnMeaningExit criteria
BacklogCaptured but not scheduledPrioritised into the current sprint
To DoCommitted for this sprint, not startedSomeone assigns themselves and starts a branch
In ProgressActively being worked onBranch pushed and pull request opened
In ReviewPR open, awaiting approval and CIApproved, checks green, merged
DoneMerged into main and verifiedShipped in a release

Modern GitHub Projects are more than sticky notes: the same set of items can be viewed as a board, a spreadsheet-style table, or a timeline/roadmap, and you can add custom fields such as Estimate (number), Sprint (iteration), Area (single select), or Target date. Built-in automations keep the board honest without manual dragging — common rules include "when an issue is opened, add it to the board in To Do", "when a linked PR is opened, move the item to In Review", and "when the issue is closed, move it to Done". Group by assignee to spot an overloaded teammate, filter by label:bug is:open to run a defect triage, or sort the table by priority before a planning meeting.

Two practices make boards genuinely useful rather than decorative. First, limit work in progress: if every member has four cards in In Progress, nothing is finishing and reviews are piling up. A rule of thumb is one or two in-flight items per person. Second, update the board as part of the work, not as a weekly chore — if the board does not reflect reality, people stop trusting it and revert to asking in chat.

Milestones. A milestone is a named, optionally dated bucket of issues and pull requests that represents a deliverable: v1.0 — Public Beta, Sprint 3, Final Demo. GitHub shows a progress bar (closed versus total items) and the number of days remaining, giving an at-a-glance answer to "are we going to make it?"

MilestoneDueIssues closed / totalStatus
v0.1 — Walking SkeletonWeek 414 / 14Complete
v0.5 — Core FeaturesWeek 819 / 2673% — on track
v1.0 — Public BetaWeek 123 / 2114% — at risk, needs scope cut

When a milestone is clearly at risk, the healthy response is to move lower-priority issues out of it rather than to let the date slip silently; the milestone then stays an honest signal. Milestones pair naturally with releases and tags: once every issue in v1.0 is closed, you tag the merge commit (git tag -a v1.0.0 -m "Public beta"), push the tag, and publish a GitHub Release whose notes GitHub can auto-generate from the merged pull requests.

Putting it together. A single day on a well-run project looks like this: you pick the top card in To Do (issue #87, labelled enhancement, milestone v0.5), assign it to yourself, and create feature/ics-export from an up-to-date main. You commit in small steps, push, and open a pull request whose description ends with Closes #87 — which moves the card to In Review automatically and kicks off the CI workflow. A teammate reviews, leaves two suggested changes, you accept them, checks turn green, and they approve. You squash-and-merge, GitHub closes issue #87, moves the card to Done, bumps the v0.5 milestone progress bar, and deletes the branch. The history on main gains one clean, tested, reviewed commit that is permanently traceable back to the conversation that produced it. That traceability — code, reason, review, and plan all linked — is the real payoff of using version control and GitHub together.

NotesSuggested hands-on lab: each student creates a repository with README, .gitignore, and MIT license; adds a teammate as a collaborator; enables branch protection on main requiring one review; opens an issue, fixes it on a feature branch, and merges via pull request using "Closes #N". Deliverable: a screenshot of the merged PR and the auto-closed issue. Common student pitfalls to call out in class: committing <code>node_modules/</code> or a <code>.env</code> file; working directly on main; forgetting <code>git pull</code> before branching; writing commit messages like "update" or "stuff"; letting a feature branch live for weeks; resolving a merge conflict by deleting the teammate's half. Useful extensions if time allows: forking workflow for open-source contribution, <code>git stash</code>, GitHub Pages deployment via Actions, CODEOWNERS files, and conventional commit message formats (<code>feat:</code>, <code>fix:</code>, <code>docs:</code>).
2

Videos on This Topic

▶

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.

3

Video 1: Git vs. GitHub: What's the difference?

▶

IBM Technology · 10:06 · 512,102 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Beginner Git commands you need to know (WITH EXAMPLES)

▶

GitHub · 14:28 · 310,605 views · 2y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: How to create a pull request in 4 min | GitHub for Beginners

▶

GitHub · 3:44 · 324,810 views · 2y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.

Design Collaboration with Figma

1

Design Collaboration with Figma

▶

Figma is the connective tissue between an idea sketched on a whiteboard and a working interface rendered in a browser. For this course it serves as the single place where your team ideates, designs screens, prototypes interactions, collects feedback, and hands specifications to whoever writes the code — which, on a student project, is usually the same people wearing different hats. Understanding Figma is therefore less about memorising a toolbar and more about learning a collaborative workflow: how a product idea travels from a sticky note to a CSS declaration without being lost in translation.

What Is Figma? Figma is a browser-based interface design and prototyping tool. Unlike traditional desktop design applications, which install locally and store proprietary binary files on one machine, Figma keeps the document on a server and streams the editing experience to your browser. You open a URL and you are editing. There is a desktop app, but it is essentially the same browser engine in a native wrapper — the file still lives in the cloud, so there is no "which version is the real one" problem.

  • No installation, no platform lock-in. A student on a Chromebook, a teammate on Windows, and a mentor on a Mac all open the identical file with identical rendering. Fonts, plugins, and component libraries resolve from the cloud rather than from each person's hard drive, so the classic "this looks broken on my machine because I don't have that font" failure disappears. Updates ship continuously; nobody is ever on an old version.
  • Real-time multiplayer editing. Multiple collaborators can be in the same file at the same moment. Each person appears as a coloured, labelled cursor. If one teammate is adjusting a navigation bar while another builds a card component three frames away, both sets of changes merge instantly — there is no checkout, no lock, no merge conflict. You can click a collaborator's avatar in the toolbar to "follow" their viewport and watch the file through their eyes, which is extraordinarily useful during a design review or a remote class demo.
  • A shared tool across roles. Figma is not used only by designers. Product managers write requirements as comments on the frames they describe. Engineers inspect spacing and copy code values. QA testers click through prototypes to understand intended behaviour. Content writers edit real text in real layouts rather than handing over a document of disconnected strings. Because viewing and commenting require only a link, stakeholders who will never draw a rectangle still participate meaningfully.
  • The Education plan. Figma offers verified students and educators free access to features that are otherwise paid — the practical effect is that a class team gets the same capabilities a professional studio pays for. This matters for coursework because the free Starter tier caps you at a small number of files and three pages per file, and limits version history to 30 days. On Education you get the professional feature set without those constraints.
CapabilityStarter (free)Education (verified)
Figma design files per teamLimited (3 files, 3 pages each)Unlimited
Version history30 daysUnlimited
Shared team component librariesNoYes
Advanced prototyping (Smart Animate, overlays, conditions)LimitedYes
Dev ModeNo / restrictedYes
Team projects and granular permissionsNoYes

Setting Up the Education Team Workspace. Before any design work begins, get the team container right. A team in Figma holds projects, and projects hold files. Setting this up properly at the start prevents the common student disaster where the final deliverable lives in one person's personal drafts and that person goes on holiday the week before submission.

  • Verify with a school email address. Education verification is tied to an academic institution. Sign up or add your .edu (or equivalent institutional) address as a verified email on your Figma account, then complete the education application form, which asks for your institution, your role (student or educator), field of study, and expected graduation date. Some institutions verify automatically by email domain; others require a document such as a student ID, enrolment letter, or transcript. Verification typically completes within a few days, and the plan is renewable annually, so plan a buffer — do not apply the night before your first studio session.
  • What verification unlocks. Once approved, create a team and apply the education plan to it. The team then gains unlimited files and projects (so each sprint, experiment, or dead-end exploration can live in its own file), unlimited version history (so you can recover the layout you deleted three weeks ago, and so your instructor can see the evolution of your work), shared libraries (publish your button and colour styles once, consume them in every file), and advanced prototyping — overlays for modals, Smart Animate for motion, scroll behaviours, and interactive components.
  • Structure the team workspace. Invite every teammate to the team itself, not just to individual files; team membership is what guarantees the work survives any one person leaving. A workable structure for a semester project: 
    Team: CS-340 Group 4 — CampusEats
  Project: 01 Research & Ideation
      FigJam — Stakeholder interview synthesis
      FigJam — Feature brainstorm & dot voting
  Project: 02 Design System
      Figma — Foundations (color, type, spacing, icons)  [published library]
  Project: 03 Product Design
      Figma — Mobile app v1
      Figma — Responsive web
  Project: 04 Handoff & Presentation
      Figma — Dev-ready screens
      Figma — Final deck
  • Roles and permissions. Team members can be admins, editors, or viewers. Make at least two people admins for redundancy. Give instructors and external reviewers viewer access with commenting enabled — they can annotate without any risk of nudging a frame 3 pixels left. Use branch or duplicate-file conventions for risky explorations so the main file stays presentable at all times.

FigJam for Ideation and Brainstorming. FigJam is Figma's online whiteboard: a deliberately loose, low-fidelity canvas designed for thinking rather than pixel-perfect making. The visual language is intentionally informal — marker-style strokes, chunky sticky notes — because polished-looking artefacts discourage people from criticising them. Use FigJam at the divergent stages of the process and Figma at the convergent ones.

  • Sticky notes, shapes, and images. The core loop is: everyone writes one idea per sticky, nobody talks for five minutes, then the team clusters stickies into themes by dragging them together. Shapes with connector lines produce user flows, site maps, and service blueprints; connectors stay attached when you move a shape, so diagrams survive rearrangement. Drop in screenshots of competitor apps, photos of paper sketches, or embedded links to research documents so all raw material sits in one visual space.
  • Cursor chat, stamps, and voting. Press / and type to broadcast an ephemeral message that floats beside your cursor — perfect for quick reactions during a live session without cluttering the board. Emoji stamps let people react to specific stickies. The built-in voting tool is the workhorse for convergence: the facilitator sets a vote limit (typically three to five dots per person), everyone votes silently and simultaneously, and the results tally per item. Silent simultaneous voting avoids the anchoring problem where the loudest or most senior voice determines the outcome. Timers keep exercises time-boxed; audio chat and music support remote sessions.
  • Templates for structured exercises. Rather than starting from an empty board, pull a FigJam template for affinity mapping, Crazy 8s sketching, a "How Might We" wall, an empathy map, a retrospective (Start / Stop / Continue), or a user journey map. A journey map template, for instance, gives you rows for stages, actions, thoughts, emotions, and pain points — pain points discovered there become the design problems you solve in Figma.
  • Linking ideation to execution. FigJam boards and Figma design files live in the same project and share the same link-and-comment infrastructure. Paste a Figma frame link into FigJam and it renders as a live preview thumbnail that updates as the design changes — so a cluster of research stickies can sit directly beside the screen that answers them. You can also copy objects out of FigJam and paste them into Figma, where they convert to editable vector shapes and text. In practice: run a voting session, take the three winning "How Might We" statements, paste them as a text block in the Figma file, and design against them. Reviewers in week ten can then trace any UI decision back to the research sticky that motivated it.

Designing UI with Figma. Once ideas converge, you move to the design file. Figma's object model maps closely to how interfaces are actually built, which is a large part of why the design-to-code handoff works as well as it does.

  • Frames mirror real interface structure. A frame is a container with its own coordinate space, clipping behaviour, and layout rules — conceptually very close to a <div> or a native view. Frames nest, so a screen frame contains a header frame which contains a logo and a nav frame. Preset device sizes (iPhone 15, Pixel, Desktop 1440) start you at realistic dimensions. Constraints pin children to edges or centre them so layouts respond when the frame resizes, and Auto Layout is effectively Flexbox: you set direction, gap, padding, and alignment, and children reflow automatically. A card built with vertical Auto Layout grows taller when its description text gets longer, exactly as it would in the browser. 
    Frame "Product Card"  →  Auto Layout: vertical, gap 12, padding 16
  ├─ Image           (fill width, fixed height 180)
  ├─ Text "Title"    (fill width, hug height)
  ├─ Text "$24.00"
  └─ Frame "Actions" →  Auto Layout: horizontal, gap 8
       ├─ Button "Add to cart"
       └─ Button "Save"

Rough CSS equivalent:
.product-card { display:flex; flex-direction:column; gap:12px; padding:16px; }
.actions      { display:flex; flex-direction:row;  gap:8px; }
  • Components, variants, and styles. A component is a reusable master; instances inherit from it, so editing the master updates every instance everywhere. Variants group related states of one component — a Button with properties type = primary | secondary | ghost, size = sm | md | lg, and state = default | hover | disabled — which developers recognise immediately as props. Colour, text, and effect styles (and the newer variables) function as design tokens: define color/brand/600 once and you can retheme the whole product, or add a dark mode, by swapping values rather than repainting rectangles.
  • Interactive prototypes. In Prototype mode you drag a connection from a layer to a destination frame and define a trigger (On click, On drag, While hovering, After delay) and an animation (Instant, Dissolve, Smart Animate, Move In). Smart Animate interpolates between matching layer names across frames, producing convincing motion from two static screens. Overlays model modals, toasts, and bottom sheets without duplicating the underlying screen. Interactive components let a toggle flip or a dropdown open inside a single frame. With variables and conditional logic you can even store state — an incrementing cart counter, a login form that branches on whether a field is filled. The result is a clickable artefact you can put in front of a real user for testing long before any code exists, or run full screen in Presentation view for a class demo.
  • Community templates and shared libraries. The Figma Community hosts thousands of free, duplicable files: design system kits, iOS and Material Design UI kits, icon sets, wireframe kits, device mockups, and plugins such as content generators and accessibility contrast checkers. Duplicating a mature UI kit means you are not redrawing a date picker from scratch at 2 a.m. Internally, publish your own Foundations file as a team library; every other file then subscribes to it, and when you change the brand colour, all subscribing files get an update notification and apply it in one click. Always check licences on community assets and credit sources in your documentation.
  • Feedback on the canvas. Press C and click anywhere to leave a comment pinned to that exact location — or pin it to a specific layer so it travels with the element when the layout moves. Threads support replies, @mentions that trigger notifications, emoji reactions, image attachments, and a resolve action that archives the thread while keeping it retrievable. Because feedback lives on the artefact rather than in email or chat, there is no ambiguity about which button "the button" refers to. A healthy team ritual: before each critique, reviewers leave comments asynchronously; the session is then spent discussing only the contested ones, and every resolved thread is a traceable decision record.

Dev Mode: Bridging Design and Code. Historically, handoff meant a designer exporting a folder of PNGs and a redlined PDF that was out of date within a day. Dev Mode replaces that with a live, developer-oriented view of the same file. Switching to Dev Mode changes the entire interface: the canvas becomes read-only for layout, frames marked "Ready for dev" are highlighted, and the right panel turns into an inspection and code panel.

  • Exact measurements and values. Select any element and read its precise width, height, padding, corner radius, border, opacity, and shadow. Hover a sibling element while holding a selection and distance measurements appear between them — no more guessing whether that gap is 14 or 16 pixels. Typography shows family, weight, size, line height, letter spacing, and the name of the applied text style. Colours display as the token name plus HEX, RGB, HSL, or CSS variable form, so a developer implements --color-brand-600 rather than hard-coding #2563EB in forty places. 
    Inspect — "Button / primary / md"
  Layout     Auto layout, horizontal, gap 8
  Padding    10px 16px
  Radius     8px
  Fill       color/brand/600  #2563EB
  Text       Inter SemiBold 14 / 20, letter-spacing 0
  Shadow     0 1px 2px rgba(16,24,40,0.05)
  • Auto-generated code snippets. Dev Mode emits CSS by default and can switch to iOS (Swift/SwiftUI) or Android (Compose/XML); plugins extend this to React, Tailwind, Vue, Flutter, and others. A selected card might produce: 
    .product-card {
  display: flex;
  flex-direction: column;
  align-items: flex-start;
  gap: 12px;
  padding: 16px;
  background: #FFFFFF;
  border: 1px solid #E4E7EC;
  border-radius: 12px;
  box-shadow: 0 1px 3px rgba(16, 24, 40, 0.10);
}
    Treat this output as a head start, not a deliverable. It describes one element in isolation at one breakpoint; it knows nothing about your grid system, your utility classes, semantic HTML, responsive behaviour, or accessibility. The real value is that it eliminates transcription errors on dozens of numeric values and makes the designer's intent unambiguous. Teams that connect a code component library can go further and have Dev Mode point directly at the actual repository component — so the panel says "use <Button variant="primary" size="md" />" instead of dumping CSS.
  • Comparing versions to see what changed. Dev Mode's compare-changes view diffs the current state of a frame against an earlier saved version or against the point at which it was marked ready for dev, highlighting moved, added, removed, and restyled elements. This answers the question developers ask constantly mid-sprint: "the designer touched this screen yesterday — do I need to redo my work?" Instead of re-reading the whole screen, you see that only the empty-state illustration and one label changed. Combined with named version history ("v1.2 — post usability test"), status flags on frames, and the annotation tool (which lets designers pin written specs such as "truncate after two lines" or "this list virtualises above 50 items" directly onto elements), you get a handoff that documents not just appearance but behaviour.

Put together, the workflow for your course project looks like this: verify the Education plan and create a team workspace; run divergent exercises in FigJam with sticky notes, clustering, and dot voting; carry the winning concepts into a Figma file built from frames, Auto Layout, and a published component library; wire the screens into a clickable prototype and test it with real users; gather critique as on-canvas comments; then flip to Dev Mode to extract tokens, measurements, and starter code. Every stage lives in one linked, versioned, permanently shareable place — which is precisely the argument for using Figma rather than a pile of disconnected documents.

Notes<p><strong>Suggested hands-on checkpoints:</strong></p> <ul> <li>Apply for Education verification in week 1 — approval can take several days and the plan must be renewed annually.</li> <li>Deliverable 1: a FigJam board containing at least 30 ideation stickies, one clustering pass, and a completed dot-voting round with the top three concepts labelled.</li> <li>Deliverable 2: a Figma file with a published Foundations library (colour styles, text styles, spacing tokens) and at least one multi-variant component.</li> <li>Deliverable 3: a prototype of a complete end-to-end user flow (minimum 5 connected frames, including one overlay).</li> <li>Deliverable 4: three frames marked "Ready for dev" with annotations, inspected in Dev Mode, plus the corresponding hand-written CSS/JSX compared against the auto-generated output.</li> </ul> <p><strong>Useful shortcuts to teach early:</strong> <code>F</code> frame, <code>R</code> rectangle, <code>T</code> text, <code>C</code> comment, <code>Shift+A</code> add Auto Layout, <code>Ctrl/Cmd+Alt+K</code> create component, <code>Shift+E</code> export panel, <code>Shift+D</code> present prototype, <code>/</code> cursor chat in FigJam.</p> <p><strong>Common pitfalls:</strong> files left in personal Drafts instead of the team; only one admin on the team; detaching component instances instead of adding variants; pasting auto-generated CSS verbatim without accounting for responsiveness or accessibility; unnamed layers (<code>Rectangle 47</code>) that break Smart Animate and make Dev Mode inspection confusing.</p>
2

Videos on This Topic

▶

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.

3

Video 1: Figma UX tutorial for beginners - Wireframe

▶

Aliena Cai · 8:41 · 799,395 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Figma UX tutorial for beginners - Prototype

▶

Aliena Cai · 11:42 · 464,411 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Figma tutorial: Interactive components

▶

Figma · 8:45 · 671,061 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.

AI Tools in HCI and Development

1

AI Tools in HCI and Development

▶

Artificial intelligence has moved from being a research curiosity to an everyday presence in the toolchains of designers and software engineers. In the context of Human–Computer Interaction (HCI) and software development, AI tools now participate in nearly every stage of work: sketching interface layouts, generating boilerplate code, writing test cases, reviewing pull requests, and watching production systems for signs of failure. Understanding what these tools do well — and, just as importantly, where they fail — is now part of basic professional competence. This topic surveys how AI is used across the design and development workflow, and then establishes a clear set of expectations for how you may use AI assistance in this course.

A useful mental model throughout: AI tools are probabilistic pattern-matchers, not reasoning engines with accountability. They produce output that looks like what a competent practitioner would produce, because they were trained on enormous quantities of such output. That makes them excellent at generating plausible starting material and terrible at guaranteeing correctness. The human in the loop supplies judgement, context, and responsibility.

How AI Supports the Design Process

Interface design has historically relied on a mix of designer intuition, design systems, usability heuristics, and user testing. AI inserts itself into this process mainly as an accelerator for the early, divergent phases of design — the moment when you need many options quickly and none of them have to be perfect.

Suggesting layouts and colour schemes from behavioural data. Modern design tools can propose UI arrangements informed by aggregated data about how users actually behave. Several well-established behavioural findings are baked into these recommendations:

  • Scanning patterns — eye-tracking research shows users scan text-heavy pages in an F-shaped pattern and image-rich pages in a Z-pattern. An AI layout suggester trained on high-performing pages will tend to place primary calls-to-action along those paths.
  • Fitts's Law — the time to acquire a target is a function of its distance and size. Tools will flag a 24 px tap target on a mobile layout and suggest enlarging it toward the 44–48 px recommended minimum.
  • Contrast and accessibility — a colour-palette generator can be constrained to produce only combinations meeting WCAG AA (4.5:1 for body text) or AAA (7:1) contrast ratios, and can simulate deuteranopia or protanopia to check that information is not conveyed by hue alone.
  • Hick's Law — decision time grows with the number of choices, so AI tools often recommend collapsing a 12-item navigation bar into grouped categories.

A concrete example: a designer gives a prompt such as "checkout screen for a mobile grocery app, trustworthy and calm, high accessibility". The tool returns four variants — one with a single-column form and a persistent sticky "Pay" button, one with a progress stepper, and so on — each with a generated palette (e.g. a desaturated blue-green primary at #2E7D6B with #FFFFFF text, contrast ratio 4.9:1). The designer has in thirty seconds what might have taken an hour of manual mock-up work.

Automated visual testing. This is one of the most mature and least controversial uses of AI in the design/development boundary. Visual regression tools (Applitools, Percy, Chromatic and similar) capture screenshots of your UI across a matrix of browsers, operating systems, and viewport widths, then compare them against an approved baseline. Naïve pixel-by-pixel comparison is almost useless in practice — a one-pixel font-rendering difference between Chrome on macOS and Chrome on Windows would flag thousands of false positives. AI-based visual comparison instead uses computer vision to classify differences the way a human would:

Difference detectedPixel diff verdictAI visual verdict
Anti-aliasing variation on text edgesFail (thousands of pixels differ)Pass — perceptually identical
Button shifted 2 px due to font metricsFailPass — within tolerance
Footer overlapping content at 375 px widthFailFail — layout break, flagged as high severity
Submit button missing entirely on SafariFailFail — missing element, flagged critical
Legitimate new feature banner addedFailFlagged for human approval, then becomes new baseline

These checks run in continuous integration, so a developer who accidentally breaks the responsive layout at tablet width learns about it from a failed build within minutes rather than from a user complaint weeks later. The same infrastructure can automatically run accessibility audits (axe-core, Lighthouse) on every commit, catching missing alt attributes, unlabelled form controls, and insufficient contrast.

Recommendations are starting points, not decisions. This caveat deserves genuine weight rather than lip service. AI design suggestions are derived from what was common and popular in the training data, which creates three systematic problems:

  • Homogenisation. If every tool recommends the statistically average pattern, every product starts to look identical. Distinctiveness, brand identity, and delight are precisely the qualities that averaging destroys.
  • Context blindness. The model does not know that your users are warehouse staff wearing gloves in cold storage, or elderly patients with tremor, or air-traffic controllers who must never be shown a modal dialogue. A statistically optimal consumer-app pattern can be actively dangerous in a safety-critical domain.
  • Bias inheritance. Training data over-represents Western, young, able-bodied, high-bandwidth users. Suggestions may assume left-to-right reading order, fast connections, large screens, and familiarity with conventions (such as the hamburger menu) that are not universal.

The professional workflow therefore remains: generate candidates with AI → critique them against heuristics (Nielsen's ten usability heuristics, your design system, accessibility standards) → test with real users → iterate. AI compresses the first step; it cannot replace the third. A dark pattern is still a dark pattern even if an AI suggested it, and the designer who shipped it is the one accountable.

AI Coding Assistants

AI coding assistants — GitHub Copilot, Amazon Q Developer, Cursor, Codeium, JetBrains AI, Claude Code and others — have become the most visible application of AI in software engineering. They operate in several distinct modes.

Inline completion. As you type, the assistant predicts the rest of the line, the rest of the function, or the next several lines, using the surrounding file, open tabs, and sometimes the whole repository as context. The productivity gain is largest on repetitive, low-novelty code. For example, after writing a function signature and docstring:

def celsius_to_fahrenheit(temps: list[float]) -> list[float]:
    """Convert a list of Celsius temperatures to Fahrenheit."""
    # assistant proposes the entire body:
    return [(t * 9 / 5) + 32 for t in temps]

Here the assistant saves keystrokes and a context switch. The same applies to writing data classes, mapping JSON fields onto model objects, generating CRUD methods, or recalling the exact argument order of an unfamiliar library call. Empirical studies (including GitHub's own controlled experiments and subsequent independent replications) report task-completion speedups in the range of roughly 20–55% on well-defined, self-contained tasks — with the gains shrinking sharply on tasks requiring architectural decisions or domain knowledge.

Natural-language generation of code, tests, and documentation. Chat-style and prompt-driven interfaces let you describe intent in prose. A prompt such as:

Write an Express.js middleware that rate-limits requests to 100 per
IP per 15 minutes, returns HTTP 429 with a Retry-After header, and
uses Redis so it works across multiple server instances.

will produce a credible implementation in seconds. Equally valuable — and often more reliable — is using the assistant in the reverse direction, on code that already exists:

  • Test generation: "Generate pytest unit tests for this function, including edge cases for empty input, negative numbers, and non-numeric types." The assistant is good at enumerating boundary conditions a tired human skips.
  • Documentation: generating docstrings, README sections, API reference tables, and inline comments explaining why rather than what.
  • Explanation: "Explain what this regular expression does, step by step" — invaluable when inheriting unfamiliar code.
  • Translation and refactoring: converting a callback-based function to async/await, migrating a class component to hooks, or porting a script from Python 2 idioms to Python 3.

AI-assisted code review. Tools such as CodeRabbit, Codacy, SonarQube's AI features, Amazon CodeGuru and GitHub's own review suggestions attach comments to pull requests before a human reviewer looks at them. They are effective at the mechanical layer of review:

Review concernAI reviewer effectivenessWhy
Style and formatting inconsistencyVery highDeterministic, rule-expressible
Unused variables, dead code, missing null checksHighDetectable by static analysis patterns
Common vulnerability patterns (SQL injection, hardcoded secrets)HighWell-represented signatures
Missing test coverage for new branchesHighMeasurable
Race conditions, subtle concurrency bugsLow–mediumRequires reasoning about execution interleaving
"Is this the right architecture for our roadmap?"Very lowRequires organisational and business context
"Does this match what the customer actually asked for?"Very lowRequires requirements knowledge and human intent

The practical benefit is that human reviewers stop spending their limited attention on comma placement and can concentrate on design and correctness.

Why critical review is non-negotiable. AI-generated code fails in characteristic ways, and knowing the failure modes is what separates safe use from dangerous use:

  • Hallucinated APIs. The model invents a method that sounds right but does not exist — array.removeDuplicates() in JavaScript, for instance. Worse is slopsquatting: attackers register package names that AI models commonly hallucinate, so a developer who blindly runs pip install on a suggested dependency installs malware.
  • Insecure patterns. Research has repeatedly found that a meaningful fraction of AI-generated code contains security weaknesses — string-concatenated SQL queries, eval() on user input, missing output encoding leading to XSS, weak hashing such as MD5 for passwords, disabled TLS certificate verification, or secrets written directly into source.
  • Plausible but wrong logic. Off-by-one errors, inverted boundary conditions, incorrect handling of empty collections, or silently swallowing exceptions. The code runs; it simply produces the wrong answer on inputs nobody tested.
  • Outdated practice. Training cutoffs mean suggestions may use deprecated libraries or superseded idioms.
  • Context mismatch. The suggestion may be technically fine but inconsistent with your project's architecture, error-handling conventions, or logging standards.
  • Automation bias. Humans systematically under-scrutinise machine output. Studies have found developers with AI assistance sometimes write less secure code while being more confident it is secure — a dangerous combination.

A worked example of a plausible-but-dangerous suggestion:

# AI suggestion — looks fine, is not
def get_user(conn, username):
    query = "SELECT * FROM users WHERE username = '" + username + "'"
    return conn.execute(query).fetchone()

# Correct version — parameterised, injection-safe
def get_user(conn, username):
    return conn.execute(
        "SELECT id, username, email FROM users WHERE username = ?",
        (username,)
    ).fetchone()

The practical discipline: never accept code you could not have written yourself and cannot explain line by line. Run it. Test it. Read the documentation for any unfamiliar API it uses. Treat every AI suggestion the way you would treat a code snippet from an anonymous forum post of unknown vintage — potentially helpful, definitely unverified.

AI Across the Software Development Lifecycle

Coding assistants get the attention, but AI now touches every phase of the SDLC. The pattern is consistent: AI is applied where there is a large volume of historical data and a need to spot patterns humans would miss or find tedious.

PhaseTypical AI applicationHuman responsibility retained
Requirements & planningGap and ambiguity detection, user-story generation, effort estimation, risk predictionDeciding what to build and for whom; stakeholder negotiation
DesignLayout and palette suggestion, accessibility checking, architecture option sketchingDesign judgement, brand, user research, ethics
ImplementationCode completion, refactoring, translation, documentationCorrectness, architecture, maintainability
TestingTest-case generation, fuzzing, visual regression, SAST/DAST security scanning, flaky-test detectionDefining acceptance criteria; exploratory and usability testing
DeploymentRelease-risk scoring, intelligent canary analysis, automated rollback triggersGo/no-go decisions; communication
OperationsAnomaly detection, alert correlation, root-cause suggestion, capacity forecastingIncident command, post-mortems, remediation

Planning: requirement gaps and timeline risk. Natural-language processing can be pointed at a requirements document or backlog and asked to find problems. Typical findings include:

  • Ambiguity: "the system should respond quickly" — quickly compared to what, under what load, at which percentile?
  • Missing non-functional requirements: a specification that describes twenty features but never mentions authentication, data retention, localisation, or accessibility.
  • Contradictions: one section says sessions expire after 30 minutes, another says users stay logged in for 7 days.
  • Untestable statements: "the interface shall be intuitive" cannot be verified; "90% of new users shall complete first checkout within 3 minutes without assistance" can.
  • Unhandled paths: the happy path is specified but nothing says what happens when payment fails, the network drops mid-upload, or two users edit the same record.

On the estimation side, models trained on an organisation's historical issue tracker can flag risk signals: tickets whose descriptions resemble past tickets that overran, sprints where too much work depends on a single person, dependencies on an external team with a history of late delivery, or a steadily rising defect-reopen rate. The output is a probability, not a prophecy — "this epic has a 70% chance of slipping past the sprint boundary" is a prompt for a conversation, not a substitute for one.

Testing: generation and security scanning. AI test generation operates at several levels:

  • Unit tests derived from function signatures and bodies, often with better edge-case coverage than hand-written tests because the model is not bored.
  • Property-based and fuzz testing, where the AI generates thousands of structurally valid but adversarial inputs — enormous strings, Unicode edge cases, nulls, deeply nested JSON — to find crashes.
  • End-to-end UI tests that are "self-healing": when a developer changes a button's CSS selector, a brittle Selenium test breaks, whereas an AI-driven locator recognises the same button by its text, role, and position and repairs the selector automatically — dramatically reducing test-suite maintenance cost.
  • Security scanning, where static analysis augmented with ML triages findings. Traditional SAST tools are notorious for false positives; ML layers learn which findings your team historically dismissed and rank accordingly. Tools also scan dependencies against vulnerability databases and detect committed secrets.

A caution specific to AI-generated tests: a test generated from the implementation will faithfully encode whatever the implementation does, bugs included. If calculate_discount() wrongly applies the discount twice, the generated test will assert the doubled value and turn the bug into a permanent requirement. Tests should be derived from the specification, with AI used to expand coverage rather than to define correctness.

Post-deployment: monitoring and predictive maintenance (AIOps). A modern distributed system emits millions of metrics, log lines, and traces per minute. No human can watch that. AI here does three things:

  • Anomaly detection. Rather than static thresholds ("alert if CPU > 80%"), models learn the normal seasonal shape of each metric — weekday peaks, Sunday troughs, end-of-month batch spikes — and alert on deviation from the learned baseline. This catches the 40% error rate at 3 a.m. that a static threshold tuned for daytime traffic would miss.
  • Alert correlation and noise reduction. When a database fails, 200 downstream services alarm simultaneously. Correlation engines group these into a single incident and point at the probable root cause, reducing alert fatigue and mean time to resolution.
  • Failure prediction. Leading indicators — a memory-usage curve climbing 2% per hour indicating a leak, disk filling on a trajectory to hit 100% in 36 hours, p99 latency creeping upward, a thread pool nearing exhaustion — allow automated or human intervention before users notice. A system can restart a leaking pod during low-traffic hours or auto-provision storage, turning a would-be outage into a non-event.

Real-user monitoring closes the loop back to HCI: session replay and interaction analytics can surface "rage clicks" (repeated rapid clicking on an unresponsive element), dead clicks, and form-abandonment hot spots, feeding concrete usability defects straight back into the design backlog.

Responsible Use of AI in This Course

The purpose of this course is to develop your capability. AI tools are permitted and in many cases encouraged, because learning to work with them is part of contemporary practice — but they are permitted under conditions designed to make sure the learning actually happens. The following four principles govern their use.

1. Read, understand, and verify everything. You are responsible for every line you submit, regardless of its origin. Before any AI-generated code enters your project, you should be able to answer, unprompted:

  • What does each line do, and why is it necessary?
  • What are the inputs, outputs, and failure modes? What happens with empty, null, or malformed input?
  • What external libraries does it use — do they exist, are they maintained, what licence do they carry?
  • Does it handle errors, or does it silently swallow them?
  • Does it introduce a security weakness (injection, unvalidated input, exposed secrets)?
  • Is it consistent with the rest of my codebase's style and architecture?

A useful self-test: close the AI tool and re-implement the solution from memory. If you cannot, you have not learned it — you have transcribed it. A second test: can you explain the code to a classmate and answer their follow-up questions? Viva-style questioning on submitted work is a legitimate assessment method, and "the AI wrote that part" is not an acceptable answer.

2. Over-reliance masks skill gaps that surface in assessment. The risk is subtle because AI assistance feels like learning. You produce working output, the project progresses, and the feedback loop is positive — but the cognitive work of structuring a problem, recalling syntax, forming a hypothesis about a bug, and reasoning through control flow is exactly the effortful practice that builds durable skill. Psychologists call this desirable difficulty; removing it produces fluency illusions. The gap becomes visible under exam conditions, in whiteboard interviews, in live debugging sessions, and in any situation where the tool is absent or the problem is novel enough that the tool is wrong.

A practical compromise is to stage your use of AI according to where you are in the learning curve for a given skill:

StageRecommended AI useUse to avoid
Learning a concept for the first timeAsk for explanations, analogies, and worked examples; ask it to quiz youAsking it to produce the solution you were set to write
Practising a newly learned skillUse it as a reviewer after your own attemptAutocomplete-driven writing that bypasses recall
Applying a skill you already haveGenerate boilerplate, tests, docs; refactor; translateAccepting output without reading it
DebuggingForm your own hypothesis first, then ask for alternativesPasting the error and applying the first fix blindly
Design workGenerate option sets to critiqueShipping a generated design without user validation

3. Intellectual property and licensing. AI-generated content raises genuine legal and ethical questions that you should be aware of as an emerging professional:

  • Training data provenance. Code models were trained on public repositories carrying a range of licences, including copyleft licences such as GPL. A model can occasionally reproduce a substantial, recognisable chunk of licensed source. Some assistants offer a "filter suggestions matching public code" setting — enable it, and treat any suspiciously complete or idiosyncratic block (an unusual algorithm, a distinctive comment style) as worth checking.
  • Copyright status of output. In several jurisdictions, including the United States, works produced without human authorship are not eligible for copyright protection. That means purely machine-generated material may not be protectable, which matters if you ever want to own or licence what you build.
  • Confidentiality. Never paste credentials, API keys, personal data about real users, unpublished assessment material, or an employer's proprietary code into a consumer AI service. Some providers retain prompts for training unless you opt out or use an enterprise tier. Treat the prompt box as a public forum.
  • Third-party assets. AI-generated images, icons, and copy may resemble existing trademarked or copyrighted work. Check before you put a generated logo on a submitted prototype.
  • Terms of service. Different tools impose different conditions on commercial use and attribution. Read them for anything that leaves the classroom.

4. Document your use. Transparency is the simplest protection for both you and your marker, and it mirrors the disclosure norms emerging in industry and in academic publishing. For this course, maintain an AI usage log alongside your project and include it in your submission. A short, honest entry is sufficient:

## AI Usage Log — Sprint 2

| Date  | Tool            | Purpose                              | What I did with the output                      |
|-------|-----------------|--------------------------------------|-------------------------------------------------|
| 04/03 | ChatGPT         | Explain CSS grid vs flexbox          | Used for understanding only; wrote layout myself |
| 06/03 | Copilot         | Autocomplete form-validation helpers | Reviewed line by line; rewrote regex, which was
|       |                 |                                      | too permissive (allowed "a@b"); added 4 tests    |
| 08/03 | Claude          | Generate pytest cases for cart logic | Kept 6 of 9 tests; 3 asserted wrong totals, so I
|       |                 |                                      | corrected them against the spec                  |
| 09/03 | Midjourney      | Placeholder hero imagery for mockup  | Prototype only; flagged for replacement with
|       |                 |                                      | licensed stock before any public release         |

In addition, mark generated code at the point of use where it is substantial, for example:

// Initial implementation generated with GitHub Copilot (2024-03-06).
// Reviewed and modified: replaced naive email regex with RFC-5322-
// compliant pattern, added null guard, added unit tests in
// tests/test_validation.py.
function validateEmail(value) { ... }

Note what the good entries have in common: they record not just that AI was used but what you did to verify it. That verification record is the evidence of your learning, and it is what distinguishes legitimate tool use from academic misconduct. Undisclosed wholesale submission of generated work — particularly where you cannot explain it — falls under the institution's academic integrity policy in the same way that submitting a classmate's work would.

Putting it together

A reasonable way to summarise the whole topic is a division of labour. AI is strong at breadth, speed, recall, and tireless repetition: enumerating options, remembering API signatures, generating the ninth edge-case test, watching ten thousand metrics overnight. Humans remain responsible for depth, context, judgement, and accountability: deciding what problem is worth solving, knowing who the users really are, recognising when a plausible answer is wrong, and standing behind what ships.

  • Use AI to go faster on things you already understand.
  • Use AI to learn things you don't — by asking for explanations, not answers.
  • Never use AI to produce things you cannot evaluate.
  • Always disclose, always verify, always own the result.

Applied to your course project, this means AI may legitimately help you scaffold a component, draft tests, explain an unfamiliar error, or generate three layout variants to critique. It may not substitute for your understanding of the HCI principles you are being assessed on, for your own usability testing with real participants, or for your ability to explain and defend every artefact you submit.

NotesSuggested in-class activities and assessment hooks for this topic: • "Spot the flaw" exercise — give students three AI-generated code snippets (one with SQL injection, one with an off-by-one error, one calling a hallucinated API) and have them identify and fix the problems in 15 minutes. Debrief on how plausible each looked. • Design critique lab — have teams prompt a UI-generation tool for the same brief, then evaluate the outputs against Nielsen's ten heuristics and WCAG AA contrast requirements, documenting what the tool got right and what it missed about the target users. • Require the AI Usage Log as a mandatory submission artefact for every sprint; allocate a small percentage of marks to its quality (specificity and evidence of verification), not to the quantity of AI used. • Consider a short individual viva or code walkthrough on submitted project code — announce it in advance, since the deterrent effect on uncritical AI use is the main benefit. Key terminology to reinforce: hallucination, slopsquatting, automation bias, desirable difficulty, visual regression testing, SAST/DAST, AIOps, WCAG AA/AAA, Fitts's Law, Hick's Law. Useful references to point students at: NIST AI Risk Management Framework; OWASP Top 10 for LLM Applications; GitHub Copilot Trust Center documentation; WCAG 2.2 quick reference; the institution's own academic integrity and generative-AI policy (students should be directed to read the authoritative local version, as it supersedes anything stated here).
2

Videos on This Topic

▶

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.

3

Video 1: 10 Ways To Implement AI Coding Assistants Into Your Workflow

▶

Tiff In Tech · 12:25 · 12,060 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: The “No Slop” AI Workflow | Full UI/UX Guide

▶

AI Tooltip · 14:27 · 13,994 views · 4mo ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Figma AI Tutorial for Beginners

▶

Aliena Cai · 8:02 · 294,879 views · 1y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.

Development Environment Setup

1

Development Environment Setup

▶

Before a single line of project code is written, every member of a team needs a working, verified development environment. An environment is more than "having an editor installed" — it is the combination of a code editor, version control tooling, authentication credentials, a shared folder structure, and a verified communication path to the remote repository on GitHub. When these pieces are configured consistently across a team, collaboration becomes almost invisible: people clone, branch, commit, and push without thinking about it. When they are configured inconsistently, teams lose entire weeks to "it works on my machine," broken file paths, rejected pushes, and commits attributed to the wrong person. This topic walks through each layer of the setup, explains why each configuration choice matters, and ends with a concrete end-to-end verification procedure that every individual must complete independently.

Choosing a Code Editor

A code editor is the primary interface to the project, so the choice has a real effect on productivity and on how easily teammates can help each other. The practical recommendation for most teams — and the default assumption for the rest of this module — is Visual Studio Code (VS Code). It is free, it runs on Windows, macOS, and Linux with a near-identical interface, and it is overwhelmingly common in both industry and education. That ubiquity matters: when a teammate says "open the Command Palette and run Git: Clone," everyone knows exactly what that means, and the same keyboard shortcuts and screenshots work for the whole group.

It is worth distinguishing an editor from a full IDE. A traditional IDE such as IntelliJ IDEA or Visual Studio ships with a compiler toolchain, debugger, profiler, and project model bundled in. VS Code starts as a lightweight editor and becomes an IDE through extensions — you add only the language tooling you actually need. Other reasonable choices exist, and the table below summarizes the trade-offs, but a team should pick one primary editor and document it.

EditorCostPlatformsBest suited toMain trade-off
VS CodeFree, open source coreWindows, macOS, Linux, browserWeb, Python, JavaScript, general-purpose, student teamsNeeds extensions for deep language support
JetBrains IDEs (IntelliJ, PyCharm, WebStorm)Paid (free student licences, free Community editions)Windows, macOS, LinuxLarge Java/Kotlin/Python codebases, heavy refactoringHeavier, slower startup, licence management
Visual StudioFree Community editionWindows (limited macOS)C#/.NET, C++ on WindowsPlatform-limited; large install
Neovim / VimFreeAll, including over SSHRemote servers, keyboard-driven workflowsSteep learning curve; hard to standardize across a team

Extensions. Extensions are what turn a generic editor into a project-specific workbench. They fall into a handful of recognizable categories:

  • Language support — syntax highlighting, IntelliSense/autocomplete, go-to-definition, and inline type errors. Examples: the official Python extension (which bundles Pylance), ESLint for JavaScript/TypeScript, C/C++ from Microsoft, Extension Pack for Java.
  • Linters — tools that flag suspicious or non-conforming code before it runs: unused variables, undefined names, shadowed parameters. ESLint, Pylint, Ruff, and Flake8 are typical.
  • Formatters — tools that rewrite code into a canonical style automatically: Prettier for web languages, Black for Python, clang-format for C/C++. Formatters are the single highest-value team extension because they eliminate whitespace-only diffs and style arguments in code review.
  • Version control helpers — GitLens (blame annotations and history), GitHub Pull Requests and Issues (review PRs without leaving the editor).
  • AI assistance — GitHub Copilot, Copilot Chat, or similar tools that suggest completions and explain code. These are productivity aids, not authorities: suggestions must still be read, tested, and understood, and many courses or employers have explicit policies about their use.
  • Collaboration and environment — Live Share for pair programming, Dev Containers and Remote–SSH for working inside containers or on remote machines.

Sharing a recommended extensions list. Rather than telling teammates in chat which extensions to install, commit the list to the repository. VS Code reads a file at .vscode/extensions.json and, when someone opens the folder, prompts them to install anything missing. This makes the toolchain part of the project itself, versioned alongside the code.

// .vscode/extensions.json
{
  "recommendations": [
    "ms-python.python",
    "ms-python.vscode-pylance",
    "charliermarsh.ruff",
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "eamodio.gitlens",
    "github.vscode-pull-request-github"
  ],
  "unwantedRecommendations": []
}

Pair it with a committed .vscode/settings.json so that formatting behaviour is identical for everyone — otherwise one person's editor reformats a whole file on save and the pull request becomes unreviewable:

// .vscode/settings.json
{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.tabSize": 2,
  "files.eol": "\n",
  "files.insertFinalNewline": true,
  "files.trimTrailingWhitespace": true,
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.tabSize": 4
  }
}

A complementary .editorconfig file at the repository root does the same job for teammates on other editors, since EditorConfig is supported natively or via plugin almost everywhere.

Installing and Configuring Git Locally

Git is the version control system; GitHub is a hosting service for Git repositories. Installing Git gives you the command-line program git, which is what actually performs clones, commits, merges, and pushes — the editor's buttons are just a friendly front end for those same commands.

  • Windows: install Git for Windows from git-scm.com, which also provides Git Bash (a Unix-like shell) and the Git Credential Manager. Alternatively winget install Git.Git.
  • macOS: brew install git, or trigger Apple's Command Line Tools with xcode-select --install. The system Git is often an old version; Homebrew's is current.
  • Linux: sudo apt install git (Debian/Ubuntu) or sudo dnf install git (Fedora).

Confirm the install before going further:

$ git --version
git version 2.45.1

Identity configuration. Every Git commit permanently records an author name and email in its metadata. If you skip this step, Git either refuses to commit or guesses from your machine's hostname, producing commits attributed to student@LAPTOP-7F3K2. Those commits will not link to your GitHub profile, will not appear in contribution graphs, and — in a graded group project — may not be credited to you at all. Set the identity once, globally:

$ git config --global user.name "Amara Okafor"
$ git config --global user.email "amara.okafor@university.edu"
$ git config --global init.defaultBranch main
$ git config --global pull.rebase false
$ git config --global core.autocrlf input    # on macOS/Linux; use 'true' on Windows
$ git config --list --show-origin            # verify, and see which file each value came from

The email must be one that is registered on your GitHub account (Settings → Emails), otherwise GitHub cannot associate the commit with your profile. If you prefer not to publish a personal address, enable email privacy on GitHub and use the supplied 12345678+username@users.noreply.github.com address instead. For a repository that needs a different identity (e.g. a work account), omit --global inside that repository to set a local override.

SSH key authentication. There are two ways to talk to GitHub: HTTPS, which requires a personal access token typed or cached as a password, and SSH, which uses a public/private key pair. SSH is preferred because the private key never leaves your machine, nothing password-like is transmitted, the key can be protected by a passphrase held in an agent, and you can revoke a single device's key without changing anything else. HTTPS tokens, by contrast, are bearer secrets that can be accidentally pasted into a chat, committed to a file, or captured by a shoulder-surfer; classic GitHub account passwords have not been accepted for Git operations since 2021 at all.

$ ssh-keygen -t ed25519 -C "amara.okafor@university.edu"
# Press Enter to accept ~/.ssh/id_ed25519, then set a passphrase

$ eval "$(ssh-agent -s)"
$ ssh-add ~/.ssh/id_ed25519

$ cat ~/.ssh/id_ed25519.pub        # copy this PUBLIC key only
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... amara.okafor@university.edu

Paste the public key (the .pub file) into GitHub → Settings → SSH and GPG keys → New SSH key. Never share or commit the private key, which has no extension. Then test the connection:

$ ssh -T git@github.com
Hi amara-okafor! You've successfully authenticated, but GitHub does not provide shell access.

That message is the success case — the "does not provide shell access" part is expected and not an error.

AspectHTTPS + personal access tokenSSH key pair
What is sentA reusable secret tokenA cryptographic signature; the key itself never leaves the device
Setup effortLow — works immediately, token generated on GitHubModerate — generate key, add to agent, upload public half
RevocationRevoke token (may affect several machines)Delete one key; other devices unaffected
Firewall friendlinessWorks on port 443 almost everywherePort 22 sometimes blocked; can fall back to ssh.github.com:443
ExpiryTokens typically expire and must be regeneratedKeys do not expire

Cloning. git clone downloads the full repository — every file, branch, and commit in its history — and sets up a remote named origin pointing back at GitHub. This is how each team member gets their own complete working copy:

$ cd ~/projects
$ git clone git@github.com:team-aurora/inventory-tracker.git
Cloning into 'inventory-tracker'...
remote: Enumerating objects: 248, done.
Receiving objects: 100% (248/248), 1.21 MiB | 4.02 MiB/s, done.

$ cd inventory-tracker
$ git remote -v
origin  git@github.com:team-aurora/inventory-tracker.git (fetch)
origin  git@github.com:team-aurora/inventory-tracker.git (push)
$ git log --oneline -3

If you already cloned over HTTPS and want to switch, you do not need to re-clone: git remote set-url origin git@github.com:team-aurora/inventory-tracker.git.

Cloud Development with GitHub Codespaces

GitHub Codespaces provides a development environment that runs on a GitHub-hosted virtual machine and is accessed either through the browser or by connecting your desktop VS Code to it. The entire toolchain — compilers, runtimes, package managers, Git itself — lives on that remote machine. This changes several things that routinely derail team setups:

  • The local operating system stops mattering. A teammate on a locked-down school Windows laptop, another on an M-series Mac, and a third on a Chromebook all get the same Linux container. Platform-specific breakages — PowerShell versus Bash commands, missing build tools, CRLF line endings, a Python version that is two releases behind — simply do not arise.
  • No local install burden. Nothing has to be installed with administrator rights, which is decisive on managed lab or corporate machines.
  • Built-in GitHub integration. A codespace is created from a repository, so the clone is already done, authentication is already in place via a scoped token, and git push works immediately with no SSH key setup. Forwarded ports let you preview a running web server in the browser, and the port can be shared privately with teammates.
  • Disposability. If an environment gets into a broken state, delete the codespace and recreate it in a couple of minutes.

The trade-offs are real too: codespaces consume a monthly quota of core-hours and storage (generous on free and education plans, but finite), they require a reliable internet connection, and they stop automatically after a period of inactivity, so uncommitted work should not be left sitting indefinitely.

The devcontainer configuration. The mechanism that makes a codespace reproducible is a file at .devcontainer/devcontainer.json, committed to the repository. It declares the base image, additional tooling ("features"), VS Code extensions and settings, forwarded ports, and commands to run after creation. Because it is version-controlled, every teammate — and every future contributor — gets a byte-identical environment, and changes to it are reviewed like any other code change. The same file also works locally with the Dev Containers extension plus Docker, so people can run the identical container on their own machine.

// .devcontainer/devcontainer.json
{
  "name": "Inventory Tracker",
  "image": "mcr.microsoft.com/devcontainers/python:3.12",
  "features": {
    "ghcr.io/devcontainers/features/node:1": { "version": "20" },
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "charliermarsh.ruff",
        "esbenp.prettier-vscode",
        "eamodio.gitlens"
      ],
      "settings": {
        "editor.formatOnSave": true,
        "python.defaultInterpreterPath": "/usr/local/bin/python"
      }
    }
  },
  "forwardPorts": [8000],
  "postCreateCommand": "pip install -r requirements.txt && npm ci",
  "remoteUser": "vscode"
}

With this in place, a new team member's onboarding is: open the repository on GitHub → Code → Codespaces → Create codespace on main. Two minutes later they have Python 3.12, Node 20, all dependencies installed, the agreed extensions loaded, and port 8000 forwarded — with no instructions to follow and nothing to get wrong.

Project Folder Structure and Conventions

A repository's layout is a form of documentation. If a newcomer can guess where things live, they can contribute; if files are scattered at the root with names like final_v2_REAL.py, every change becomes archaeology. Agree on a structure in week one, write it into the README.md, and create the directories immediately — even if some are nearly empty — so that the first commits land in the right place.

inventory-tracker/
├── README.md               # what it is, how to set up, how to run, folder map
├── LICENSE
├── .gitignore
├── .editorconfig
├── .vscode/
│   ├── extensions.json
│   └── settings.json
├── .devcontainer/
│   └── devcontainer.json
├── .github/
│   └── workflows/ci.yml    # automated tests on every push
├── src/                    # application source code only
│   ├── models/
│   ├── services/
│   └── main.py
├── tests/                  # mirrors src/ structure
│   ├── test_models.py
│   └── test_services.py
├── assets/                 # images, fonts, sample data, icons
├── docs/                   # design notes, meeting minutes, API reference
└── scripts/                # one-off or utility scripts (seeding, deploys)

Why separate source, assets, docs, and tests? Each directory has a different audience and lifecycle. Separating them means you can run the whole test suite with one path (pytest tests/), package or deploy only src/, let non-developers edit docs/ without touching code, keep large binary assets out of the import path, and configure tooling cleanly — linters scan src/ and tests/, the bundler reads assets/. It also makes code review diffs legible: a pull request touching only docs/ obviously carries no runtime risk.

Document it in the README from day one. The README is the first thing anyone reads. It should contain, at minimum: a one-paragraph description of the project, prerequisites, setup commands, how to run the app and the tests, and a short folder map explaining what belongs in each directory. A folder structure that exists only in one person's head is not a convention — it is a bottleneck.

File naming conventions and case sensitivity. This is the single most common source of baffling cross-platform bugs. Linux file systems are case-sensitive: UserCard.js and usercard.js are two different files. Windows and the default macOS file system are case-insensitive but case-preserving: they treat those names as the same file. So a developer on macOS can write import Card from './components/userCard' while the file is actually named UserCard.js, commit it, and everything works locally — then the Linux CI build or the Codespaces container fails with "module not found." Worse, renaming usercard.js to UserCard.js on a case-insensitive system may not even register as a change in Git unless you use git mv or enable core.ignorecase=false.

Practical rules that avoid the whole class of problem:

  • Pick one convention per file type and record it in the README: kebab-case for web assets and URLs (user-card.css), snake_case for Python modules (user_card.py), PascalCase for class/component files where the framework expects it (UserCard.tsx).
  • Never rely on case alone to distinguish two files.
  • Avoid spaces and special characters in filenames — they break shell commands and URLs. Use hyphens or underscores.
  • Keep paths reasonably short; Windows historically limits total path length to 260 characters.
  • Make imports exactly match the on-disk spelling, every time.
  • Use a .gitignore from the start so that node_modules/, __pycache__/, .venv/, .env, dist/, and .DS_Store never enter the history. Committed secrets and build artefacts are painful to remove later.

Verifying the Complete Setup

Installing things is not the same as proving they work together. The purpose of verification is an end-to-end test: a tiny change that travels from the editor, through local Git, over the authenticated connection, into the GitHub repository, and back down to a teammate. Only a round trip proves that all four links in the chain — editor, Git, credentials, repository permissions — are sound.

A workable verification script for each person:

  • Confirm the tools exist: git --version and, if relevant, python --version / node --version.
  • Confirm identity: git config user.name and git config user.email return your real details.
  • Confirm authentication: ssh -T git@github.com greets you by your GitHub username.
  • Clone the team repository and open it in the editor; accept the recommended extensions prompt.
  • Create a branch, make a trivial but real change, commit, and push.
  • Open a pull request, have a teammate review and merge it, then pull the merged result back down.
$ git switch -c setup/amara-verify
$ echo "- Amara Okafor — environment verified $(date +%F)" >> docs/team-roster.md
$ git add docs/team-roster.md
$ git commit -m "chore: verify local environment for Amara"
$ git push -u origin setup/amara-verify
$ gh pr create --fill          # or open the PR in the browser

# after the PR is merged
$ git switch main
$ git pull
$ git log --oneline -1         # your commit should be at the tip

A useful team artefact is a docs/team-roster.md or a checklist issue in which each person appends their own line as part of the exercise. The file itself then becomes the evidence that the verification happened: if a name is missing, that person's setup is unproven.

Catch authentication and permission errors in week one. Setup failures are cheap to fix on day three and expensive to fix the night before a deadline, because they block the delivery of work that is already finished. The most common failures and their usual causes are predictable enough to triage quickly:

SymptomLikely causeFix
Permission denied (publickey)SSH key not generated, not added to the agent, or public key not uploaded to GitHubRe-run ssh-add ~/.ssh/id_ed25519; confirm the key is listed in GitHub settings; test with ssh -T git@github.com
remote: Permission to org/repo.git denied to userNot a collaborator on the repository, or authenticated as the wrong accountRepository owner adds the user as a collaborator; check cached credentials in the OS credential manager
Support for password authentication was removedUsing an account password over HTTPSSwitch the remote to SSH, or use a personal access token
Commits show the wrong author or no avataruser.email not set, or not registered on the GitHub accountgit config --global user.email with a verified or noreply GitHub address
! [rejected] main -> main (fetch first)Remote has commits you do not have locallygit pull (resolve any conflict), then push again
CI passes locally but fails in the cloud with "module not found"Filename case mismatch between the import and the file on diskgit mv the file to the correct casing and fix the import

Everyone verifies independently. It is tempting for the most confident member of a team to set things up, push the first commit, and declare the environment "working." That proves exactly one person's configuration. Authentication, identity, permissions, installed runtimes, and operating-system quirks are all per-machine and per-account, so a single successful push says nothing about the other four people. Make individual verification an explicit deliverable: each member pushes their own branch from their own machine under their own GitHub account, and the team confirms that every name appears in the commit history before any feature work begins. The cost is fifteen minutes each; the alternative is discovering in week six that one teammate has been emailing zip files because their push has never once worked.

Notes<p>Suggested in-class sequence: (1) install/confirm Git and VS Code, (2) configure identity, (3) generate and upload an SSH key, (4) clone the team repo, (5) each student pushes a one-line addition to <code>docs/team-roster.md</code> via a pull request. Completion is checked by inspecting the commit history for every student's verified GitHub identity.</p> <p>Instructor cautions: the <code>core.autocrlf</code> value differs by platform (<code>true</code> on Windows, <code>input</code> elsewhere); committing <code>.vscode/settings.json</code> is a team decision — some teams commit only <code>extensions.json</code> and leave personal preferences uncommitted; Codespaces quotas vary by plan, so confirm the course's allocation before relying on it exclusively.</p> <p>Possible extensions to the material: adding a <code>.gitattributes</code> file to force line endings, enabling branch protection on <code>main</code>, and wiring a minimal GitHub Actions workflow so that the week-one verification push also proves CI works.</p>
2

Videos on This Topic

▶

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.

3

Video 1: Using Git with Visual Studio Code (Official Beginner Tutorial)

▶

Visual Studio Code · 6:56 · 1,982,388 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: How to create your first GitHub repository: A beginner's guide | Tutorial

▶

GitHub · 9:32 · 332,965 views · 2y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: VS Code in the Cloud with GitHub Codespaces - CS50 Educator Workshop 2022

▶

CS50 · 16:09 · 16,800 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.

Team Collaboration and Project Kickoff

1

Team Collaboration and Project Kickoff

▶

Every successful software project begins long before the first line of production code is written. It begins with people agreeing on how they will work together, what they are building, and who is accountable for what. This module establishes the social and operational infrastructure of your team: the roles you will play, the norms you will hold each other to, the problem you intend to solve, and the tooling that lets you collaborate without stepping on each other's work. The artifacts you produce here — a team charter, a role matrix, a scope statement, and a configured shared repository — are not busywork. They are living documents that you will consult, amend, and be evaluated against for the remainder of the course.

Teams that skip this stage rarely fail immediately. They fail three weeks later, when two people have independently built conflicting versions of the same feature, when a deadline passes because everyone assumed someone else was handling it, or when a quiet team member's excellent idea never surfaced because there was no channel for it. The investment you make now is insurance against those predictable failures.

Forming Effective Project Teams

A cross-functional team is one whose members collectively possess all the skills needed to deliver the product end to end — design, implementation, testing, documentation, and stakeholder communication — rather than a team of specialists who must hand work off across organizational boundaries. Research on team performance consistently shows that diverse teams outperform homogeneous ones on complex, non-routine problems, precisely because the work benefits from being examined through multiple lenses. A developer looks at a login screen and thinks about token storage and error states; a designer looks at the same screen and thinks about affordances, contrast ratios, and what happens on a 375-pixel-wide phone. Neither perspective alone produces a good login screen.

Diversity here means more than academic background. It includes prior industry experience, cultural context, accessibility needs, and simply how people prefer to think — some teammates reason best out loud in a whiteboard session, others need to read a written spec and sit with it overnight. The cost of diversity is that communication takes more effort; the benefit is that blind spots get caught. Your job as a team is to capture the benefit while deliberately managing the cost.

Begin with a structured skills inventory. Rather than asking "what are you good at?" — a question that invites both bragging and false modesty — ask each member to rate themselves on concrete capabilities and, crucially, to state what they want to learn. A simple shared spreadsheet or Markdown table works well:

Member Design / UI Frontend Code Backend / Data Writing & Comms User Research Wants to Grow In
Amara Strong (Figma, design systems) Moderate (React basics) Low Strong Moderate API integration
Devin Low Strong (React, CSS) Strong (Node, SQL) Low Low Presenting to stakeholders
Priya Moderate Moderate Low Strong Strong (interviews, surveys) Component architecture
Luis Low Moderate Moderate (Git, CI/CD) Moderate Low Visual design fundamentals

Two things immediately become visible in a table like this. First, the team has a coverage gap: nobody rates themselves strong in backend except Devin, which is a single point of failure. Second, there are growth pairings available — Amara wants API integration experience and Devin wants presentation practice, so pairing them on a feature demo serves both goals. A skills inventory is therefore not just a staffing document; it is the raw material for a deliberate learning plan.

The final piece of team formation is establishing shared expectations before work begins. Psychologists describe this as reducing ambiguity, and it is the single cheapest intervention available to a new team. Hold an explicit conversation covering questions such as:

  • Availability: What hours does each person realistically work? Who has a job, a commute, caregiving duties, or a time zone offset?
  • Response time: If I message the team channel at 9 p.m., should I expect an answer tonight or tomorrow morning? (Agree on a number — "within 24 hours on weekdays" is a real commitment; "pretty fast" is not.)
  • Quality bar: Are we aiming for a polished portfolio piece or the minimum that satisfies the rubric? Both are legitimate; a mismatch between members is corrosive.
  • Working style: Does the team prefer long synchronous sessions or short check-ins plus independent work?
  • Conflict: How will we raise it when someone is unhappy — directly, through a designated facilitator, or in a scheduled retrospective?

It helps to expect the classic stages of group development: forming (polite, tentative), storming (friction as real preferences surface), norming (agreements settle), and performing (fluid, productive work). Knowing that storming is normal — not evidence that your team is broken — makes it far easier to move through it quickly.

Defining Team Roles and Responsibilities

A role is a named bundle of responsibilities with a single accountable owner. The value of naming roles is not bureaucracy; it is the elimination of the diffusion of responsibility effect, in which a task everyone could do ends up done by no one. When the build breaks at 11 p.m. before a demo, "the Build/Release Lead decides whether we roll back or hotfix" is an answer. "Someone should probably look at that" is not.

For a typical four-to-six person course project, the following roles cover the necessary ground:

Role Core Responsibilities Typical Deliverables Decides (Final Say)
Project Manager / Scrum Lead Maintains the backlog and schedule, runs standups and retrospectives, tracks blockers, liaises with the instructor Sprint board, meeting notes, status reports Sprint scope and meeting cadence
Design Lead Owns the Figma file, wireframes, component library, accessibility and visual consistency Wireframes, high-fidelity mockups, style guide Visual and interaction design conflicts
Tech Lead / Architect Chooses stack and project structure, reviews architectural decisions, sets coding standards Architecture diagram, coding conventions doc, ADRs Technical approach and dependency choices
Build / Release & Repo Lead Owns branch strategy, CI configuration, merge hygiene, environment setup docs README, CONTRIBUTING.md, CI pipeline Merge policy and release timing
QA / Test Lead Writes test plans, defines acceptance criteria, triages bugs, verifies fixes Test plan, bug tracker, definition of done Whether a story meets acceptance criteria
Research / Documentation Lead Runs user interviews and usability tests, maintains project documentation and the final report Research findings, personas, final write-up Interpretation of user evidence

Note that holding a role does not mean doing all the work in that area. The Design Lead does not draw every screen; they ensure every screen gets drawn to a consistent standard. This distinction is often clarified with a RACI matrix, which separates who is Responsible (does the work), Accountable (owns the outcome — exactly one person), Consulted (gives input before the decision), and Informed (told after):

Activity Amara (Design) Devin (Tech) Priya (Research/Docs) Luis (Build/QA)
High-fidelity mockups A / R C C I
Database schema I A / R I C
Usability test sessions C I A / R R
Merge to main I C I A / R

These assignments must be documented in the repository, not merely agreed verbally. Create a file such as docs/TEAM.md so that any member, and the instructor, can resolve an ownership question in ten seconds without asking anyone:

# Team Roles — Project Lumen (Section 04)

| Member | Primary Role        | Secondary Role       | GitHub       | Preferred Contact |
|--------|---------------------|----------------------|--------------|-------------------|
| Amara  | Design Lead         | Documentation        | @amara-k     | Slack #lumen      |
| Devin  | Tech Lead           | Backend dev          | @dnwankwo    | Slack DM          |
| Priya  | Research Lead       | Project Manager      | @priya-s     | Slack #lumen      |
| Luis   | Build/Release + QA  | Frontend dev         | @luisr-dev   | Slack #lumen      |

## Rotation Schedule
- Project Manager role rotates each sprint (2 weeks):
  Sprint 1 Priya -> Sprint 2 Luis -> Sprint 3 Devin -> Sprint 4 Amara
- Every member must author at least one ADR and review at least six pull requests.

## Escalation Path
1. Raise in #lumen channel.
2. If unresolved in 24h, the role owner decides (see RACI in docs/RACI.md).
3. If the team is split on a scope question, escalate to the instructor at
   the weekly check-in.

Last updated: 2024-09-18 (PR #12)

Storing roles in the repository rather than a chat message means the document is version-controlled: you can see when roles changed and why, and updates go through the same pull request review as code. It also prevents the common failure in which the role assignment lives in a Google Doc that only two people can find.

Finally, consider which responsibilities should be shared or rotated. In a course setting, the learning objective competes with efficiency: the fastest path is to let the strongest coder write all the code, but that leaves three students without coding experience and one student exhausted. Effective compromises include rotating the Project Manager role each sprint (as above), requiring that every member authors at least one component and reviews a quota of pull requests, and using pair rotation so that the Design Lead pairs with a developer on implementation while a developer pairs with the Design Lead on a Figma component. Make the rotation explicit and calendared, or it will quietly not happen.

Creating the Team Charter

A team charter is a short written agreement — typically one to three pages — that records how the team will operate. Its real function is assumption surfacing. Every member arrives with an internal model of what "we'll meet regularly" or "we'll get it done on time" means, and those models differ far more than people expect. One student's "done" is a merged pull request with tests; another's is code that runs on their laptop. Writing the charter forces these private definitions into the open at a moment when disagreement is cheap, rather than at 2 a.m. before a deadline when it is expensive.

A workable charter covers at minimum:

  • Purpose and success criteria: what the team is building and what "a good outcome" means for this group (a strong grade, a portfolio piece, a specific skill gained).
  • Communication channels: which tool is used for what, and what the expected response time is for each.
  • Meeting cadence: when the team meets synchronously, who runs the meeting, and what happens if someone cannot attend.
  • Decision-making rules: consensus by default, with a named tie-breaker or a majority vote after a fixed time box.
  • Definition of done and deadline norms: internal deadlines that sit before external ones, and what counts as complete work.
  • Accountability and escalation: the agreed sequence of steps when a commitment is missed.
  • Inclusion norms: explicit practices that ensure quieter members are heard.

Documenting communication channels deserves particular attention, because the most common way a team member gets excluded from a decision is not malice but channel fragmentation. Two teammates make a design decision over lunch, a third sees it in a pull request, and a fourth never hears about it at all. Prevent this by assigning a purpose to each channel and declaring one of them authoritative:

Channel Used For Expected Response Authoritative?
Slack #lumen-general Day-to-day questions, quick coordination Within 12h on weekdays No
GitHub Issues & PR comments Task tracking, code review, technical decisions Review within 24h of request Yes — decisions recorded here
Figma comments Design feedback on specific frames Within 24h Yes, for design details
Weekly video call (Tue 7 p.m.) Planning, demos, retrospective Attendance expected; notes posted same night Yes — notes in docs/meetings/
Direct messages Personal/sensitive matters only Best effort No — decisions must be reposted publicly

The last row encodes a rule worth stating outright: a decision made in a DM is not a decision until it is written in a public channel. This single norm eliminates most "I never heard about that" conflicts.

Norms around deadlines and accountability work best when they are specific and pre-agreed, because they then feel like applying a shared rule rather than a personal attack. A charter excerpt might read:

# Team Charter — Project Lumen

## 3. Deadlines
- Every task has an owner and a due date in the GitHub Project board.
- Internal deadlines are set 48 hours before any instructor deadline.
- "Done" means: merged to `main`, reviewed by one other member, passing CI,
  and the acceptance criteria in the issue are checked off.

## 4. Accountability Ladder
1. If you will miss a deadline, post in #lumen-general BEFORE the deadline
   with a new committed date. No penalty for an early heads-up.
2. Missed with no notice: the PM checks in privately within 24 hours.
3. Second missed deadline: raised at the retrospective; team reallocates work.
4. Third: the team notifies the instructor together, with a written record
   of steps 1-3.

## 5. Decision Making
- Default: consensus after everyone has spoken.
- Time box: 20 minutes of discussion. If unresolved, the role owner
  (see docs/TEAM.md) decides and records an ADR explaining the trade-off.
- Any member may request a re-vote once if new evidence appears.

## 6. Inclusion Norms
- Round-robin check-in at the start of each meeting; everyone speaks first
  before open discussion begins.
- Asynchronous written feedback window of 24 hours after every major decision,
  so members who think best in writing are not disadvantaged.
- No design or architecture decision is final until it appears in writing.

Signed: Amara, Devin, Priya, Luis — 2024-09-18

Two details make a charter effective in practice. First, everyone signs it — literally adding their name in the commit — which converts a document into a commitment. Second, it is revisited. Add "Does the charter still match how we actually work?" as a standing retrospective question; a charter that no longer describes reality is worse than none, because it teaches the team that written agreements are decorative.

Scoping the Course Project

Scope is the boundary around what you will and will not build. Student teams fail far more often from over-scoping than under-scoping: an ambitious idea consumes the entire term in design and arrives at the demo as a half-working prototype. Disciplined scoping is therefore a survival skill, and it starts with a problem statement.

A good problem statement describes a situation in the world that is unsatisfactory, for identifiable people, with evidence — and conspicuously avoids naming a solution. It anchors everything downstream: when someone proposes a feature, you test it by asking whether it moves the needle on the stated problem. A useful template is: [User group] needs a way to [accomplish goal] because [constraint or pain point], but currently [what goes wrong]. We know this matters because [evidence].

  • Weak: "We're building a mobile app with a calendar and push notifications for students." (This is a solution and a feature list; it names no problem and no evidence.)
  • Strong: "Commuter students at our university need a way to find unreserved quiet study space between classes, because they cannot return home during gaps and the library's open seating is fully occupied from 11 a.m. to 3 p.m. Today they wander between buildings, losing an average of 18 minutes per gap. In a survey of 42 commuters, 31 reported this happening at least three times a week."

The strong version is testable, bounded, and immediately suggests how you would measure success (reduce the time spent searching). It also leaves the solution space open — the answer might be an app, a sensor-driven occupancy map, a scheduling policy, or a simple shared spreadsheet.

Next, articulate user goals, which describe what a person is trying to achieve in their own life — not what your software does. This distinction is the difference between designing for outcomes and designing for features. A user goal is stated from the user's perspective, in the user's vocabulary, and would still be true if your product did not exist.

User Goal (correct) System Behavior (not a user goal)
"I want to find a quiet place to work within a five-minute walk, right now." "The system queries the room occupancy API and renders results on a map."
"I want to be confident the space will still be free when I get there." "The app displays a timestamp and confidence score."
"I want to avoid embarrassment from walking into an occupied room." "Users can filter by room status."

Expressing goals this way keeps multiple solutions on the table and gives you acceptance criteria that are meaningful to real people. The user-story format As a <role>, I want <capability>, so that <benefit> is a convenient scaffolding — but only if the "so that" clause names a genuine human benefit rather than restating the capability.

With a problem and goals in hand, bound the scope explicitly. The most effective technique is a two-column in scope / out of scope list plus a MoSCoW prioritization (Must, Should, Could, Won't). The "Won't have — this term" column is the most valuable one in the entire document, because it is what you point to when a teammate or stakeholder proposes an exciting new feature in week nine.

Priority Item Rationale
Must have Map of buildings with per-room availability; manual "I'm here / I left" check-in; mobile-responsive web UI Without these the core problem is untouched
Should have Filter by noise level and outlet availability; "last verified" timestamp Directly supports the confidence goal but the product works without it
Could have Saved favorite rooms; dark mode Nice polish if the schedule allows after the Must items ship
Won't have (this term) Native iOS/Android apps; integration with the campus card-swipe system; room reservations; user accounts with social features Requires institutional approval, app-store review, or backend scale beyond the course timeline

Scope should also be expressed in terms of constraints and assumptions, because these are the hidden drivers of feasibility: the number of weeks available, the total person-hours per week the team can realistically commit (be honest — four students at eight hours each is thirty-two hours, not a full-time engineering team), the technologies the course requires, the data you can legally obtain, and the accessibility standard you intend to meet. Writing "we assume the facilities office will share the room list as a CSV" exposes a risk you can validate in week two rather than discover in week eight.

Finally, review the scope with your instructor before investing in design. This is not a formality. The instructor sees every team's plan and knows from experience which ideas collapse under their own weight, which require data that will never be approved, and which fail to exercise the skills the course is assessing. A twenty-minute conversation at this stage can save two weeks of wasted wireframing. Come to that review with a one-page scope statement containing the problem statement, three to five user goals, the MoSCoW table, constraints and assumptions, and a list of open questions. Leave with written notes recorded in the repository — for example as docs/SCOPE.md with a changelog entry — so that any later scope change is visible as a diff rather than a vague memory of what was approved.

# Project Scope Statement — Project Lumen

## Problem
Commuter students need a way to find unreserved quiet study space between
classes, because they cannot return home during gaps and open seating is
full 11:00-15:00. Survey of 42 commuters: 31 report this 3+ times/week.

## Primary Users
Commuter undergraduates with 60-180 minute gaps between classes.

## User Goals
1. Find a quiet, free space within a 5-minute walk, right now.
2. Trust that the space will still be free on arrival.
3. Avoid walking into an occupied room.

## Success Measures
- Median search time drops from 18 min to under 5 min in usability testing.
- 8 of 10 test participants locate a usable room on the first attempt.

## Constraints
- 10 weeks; ~32 team-hours/week; React + Node required by course.
- No access to card-swipe data (privacy review not feasible this term).
- Must meet WCAG 2.1 AA.

## Assumptions (to validate by Week 2)
- Facilities will provide a room list as CSV.  [Owner: Priya]
- Crowd-sourced check-ins will reach useful density with ~30 pilot users.

## Open Questions for Instructor
- Is a seeded/simulated dataset acceptable if facilities data is delayed?

Reviewed with instructor: 2024-09-20. Approved with note: seeded data OK
for Sprint 1; must document the simulation clearly in the final report.

End-of-Module Readiness Checklist

The module concludes with a verification pass. The point of a readiness checklist is that each item is demonstrably true for every member — not "probably fine." The most common way a team loses a week is discovering in sprint one that one teammate's environment never worked, or that the Figma file is owned by a personal account nobody else can edit. Verify by producing an artifact, not by asking "everyone good?"

GitHub accounts and repository access. Each member needs an account added as a collaborator (or added to the organization team) with at least write permission, and each must prove access by pushing something. A reliable smoke test: every member creates a branch, adds their name and role to docs/TEAM.md, opens a pull request, and has it reviewed and merged by a teammate. That single exercise verifies account access, write permission, branch creation, the pull request workflow, review permissions, and merge rights all at once. Members should also confirm their authentication method works for the long term — an SSH key or a personal access token rather than a password — and that their commit email matches their GitHub account so contributions are attributed correctly.

# Verify identity and remote access
git config user.name            # should match your display name
git config user.email           # must match a verified GitHub email
ssh -T git@github.com           # "Hi username! You've successfully authenticated..."

# Smoke-test the collaboration workflow
git checkout -b chore/add-me-to-team-doc
# ...edit docs/TEAM.md...
git add docs/TEAM.md
git commit -m "docs: add Luis to team roles table"
git push -u origin chore/add-me-to-team-doc
# then open a PR on GitHub and request a review

While you are there, have the Build/Release Lead configure the repository itself: a branch protection rule on main requiring one approving review, a .gitignore appropriate to the stack, a README.md with setup instructions, a CONTRIBUTING.md describing branch naming and commit conventions, and issue/PR templates. A docs/ folder should hold TEAM.md, CHARTER.md, SCOPE.md, and a meetings/ directory.

Figma Education workspace. Each student should apply for the free Figma Education plan using their institutional email; approval can take time, so start early. The Design Lead creates a team (not a personal draft) named for the project, creates project files inside it, and invites every member by email with at least "can edit" rights. Verification is behavioral: every member opens the file, creates a frame or leaves a comment, and confirms it appears for the others. The critical failure to avoid is designing in a personal "Drafts" space — files there are not shared with the team, cannot be recovered by teammates if the owner's access lapses, and will not appear in the team's version history. Agree now on a file structure (for example, separate pages for Research, Wireframes, Components, and High-Fidelity screens) and link the Figma URL from the repository README so there is one discoverable source of truth.

Local development environments. "It works on my machine" is a project-management failure, not a joke. Every member must install the required runtime and tooling at the pinned versions, clone the repository, install dependencies, run the application, and run the test suite successfully. Pin versions explicitly — an .nvmrc file, an engines field in package.json, or a containerized dev environment removes an entire class of mysterious bugs. The smoke test is that each member pastes their version output into the team channel or a checklist issue:

git clone git@github.com:lumen-team/lumen.git
cd lumen
nvm use                 # reads .nvmrc -> v20.11.0
npm ci                  # install exact locked dependency versions
npm run dev             # app serves at http://localhost:5173
npm test                # all tests pass

# Paste this output into issue #3 "Environment smoke test"
node -v && npm -v && git --version

Record any platform-specific gotchas (Windows line endings, missing build tools, Apple Silicon differences) in the README as you hit them — the next person to set up, including a future teammate or the instructor, will need them.

Charter and scope documented in the repository. Both documents must be committed to the repo, merged into main via pull request, linked from the README, and signed or acknowledged by all members. Storing them alongside the code means they are version-controlled, diffable, reviewable, and impossible to lose in a chat history.

A compact team-level checklist makes the state of readiness visible at a glance:

Readiness Item Verification Method Owner Status
All members have repo write access Each merged a PR editing docs/TEAM.md Build/Release Lead 4 / 4 complete
main branch protection configured Screenshot of settings in issue #2 Build/Release Lead Complete
Figma Education team created, all invited Each member left a comment on the cover frame Design Lead 4 / 4 complete
Local environment runs app + tests Version output posted in issue #3 Tech Lead 3 / 4 — Devin blocked on build tools
CHARTER.md merged and signed PR #8 approved by all members Project Manager Complete
SCOPE.md merged and instructor-reviewed PR #9 + instructor notes appended Research Lead Complete

When every row reads complete, the team has more than paperwork: it has a shared vision of the problem, named owners for every decision, agreed rules for how disagreements get resolved, and infrastructure that lets four people change the same codebase and the same design file without destroying each other's work. That is the real deliverable of this module — and every subsequent module assumes it is in place.

NotesSuggested in-class activities: (1) 20-minute skills-inventory workshop producing the capability table; (2) charter-drafting sprint with a required signature commit; (3) instructor scope review slots booked before any high-fidelity design begins. Common pitfalls to call out: designing in a personal Figma Drafts space, roles agreed verbally but never documented, over-scoped problem statements that name a solution, and unverified environment setups discovered in sprint one. Assessment tip: grade the artifacts (TEAM.md, CHARTER.md, SCOPE.md, RACI) on specificity — vague norms like "communicate well" earn no credit, measurable ones like "review PRs within 24h" do.
2

Videos on This Topic

▶

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.

3

Video 1: 5 Essential Project Documents [YOU NEED THESE]

▶

Adriana Girdler · 6:36 · 49,842 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Project Communication Plan [STEP-BY-STEP INSTRUCTIONS]

▶

Adriana Girdler · 12:36 · 92,598 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: 10 Project Management Terms You Need to Know

▶

Adriana Girdler · 13:57 · 453,683 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.