Every interface project begins with a question that is easy to skip and expensive to ignore: what exactly are we building, for whom, and within what limits? Project scope is the agreed boundary around your work. It states the goals the interface must achieve, the constraints you must design within (time, budget, team skills, device capabilities, accessibility and platform requirements), the users you are designing for, and the criteria that will tell you whether you succeeded. Without that boundary, teams drift, features multiply, and the final product satisfies no one in particular.
In this course, scoping is the step that makes the rest of Module 2 possible. You cannot sensibly compare mobile, web, and desktop platforms until you know what your users need to do, where they will do it, and what your project can realistically support. The formal project description you write is both a planning tool and a communication tool: it aligns your team, and later it gives you something concrete to evaluate your design against.
The three videos below approach scoping from different angles. As you watch, pay attention to how each one frames decisions: What questions get asked before design work starts? Who is in the room? How are goals separated from solutions? Where do constraints enter the conversation? Try to collect a short list of questions you could ask about your own project, and note any vocabulary (goals, requirements, deliverables, users, affordances) you can reuse when you write your scope document.
Nielsen Norman Group breaks the wide variety of UX workshop exercises down into seven foundational activities that underlie most of them. The video is likely to cover activities such as generating ideas, clarifying and organizing information, converging on decisions, and prioritizing — the kinds of structured group work teams use to agree on goals and boundaries early in a project. It is a short, practical overview rather than a deep dive into any single exercise.
Scoping is rarely a solo act, and this video from a widely respected UX research organization gives you a vocabulary for the collaborative activities that produce agreed goals, priorities, and constraints — directly supporting the "Identifying Project Goals" and "Defining Constraints" subtopics.
A practicing designer walks through an end-to-end web design process, from initial client contact and discovery through planning, design, and delivery, with a shared project template. Expect discussion of how requirements are gathered, how work is organized into phases, and how expectations are set with a client before design begins. The perspective is professional practice rather than academic theory.
It shows scoping in a real workflow — how goals, audience, deliverables, and limits get written down and communicated before any interface is built — which is a useful model for the "Writing a Formal Project Description" subtopic.
The Interaction Design Foundation explains affordances: the properties of an object or interface that signal what actions are possible, illustrated with concrete examples. The video is likely to connect affordances to user expectations and to how design choices communicate function without explicit instructions.
Affordances differ across platforms and user groups, so this concept helps you reason about target audience assumptions and platform constraints — the kind of thinking that turns a vague goal into a scoped, defensible design requirement.
Together these videos move from understanding users and their expectations to structuring team decisions to documenting a plan. The affordances video builds the user-centered reasoning behind MO1, since what an interface can plausibly afford depends on whether it runs on a phone, a browser, or a desktop. The workshop activities video supplies methods for surfacing goals, weighing options, and converging on a justified choice, which is the core skill behind MO2. The full design process video models how discovery, requirements, and deliverables get captured in writing, giving you a concrete reference as you draft the objectives, constraints, and success criteria required by MO3.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Before you design an interface, you have to decide where it will live. This topic surveys the four primary platforms used in this course — Android, iOS, Windows, and Web — and then widens the view to additional platforms you may encounter in practice, such as macOS, Linux, wearables, smart TVs, automotive displays, and embedded or kiosk systems. Each platform brings its own screen sizes, input methods, interaction conventions, distribution channels, and user expectations, and those differences drive real design decisions.
It also helps to think in categories rather than product names. Mobile platforms assume touch, small screens, interruptions, and on-the-go use. Desktop platforms assume keyboard and mouse, larger screens, and longer focused sessions. Web platforms assume a browser, variable screen sizes, and near-universal reach at the cost of some device integration. Recognizing which category your project falls into is the first step toward justifying a platform choice in your scope document.
The videos below are practical tours of widely used platform ecosystems. As you watch, pay less attention to the specific button clicks and more to the platform-level questions: What device and input method is this software designed for? Does it run in a browser, as an installed desktop application, as a mobile app, or as all three? How does the interface change across those versions, and what does that suggest about the constraints a designer must respect on each platform?
Kevin Stratvert walks through the applications included in Microsoft 365, covering what each one is for and how they relate to each other, from Teams and Outlook to collaboration tools like Yammer. Based on the title and description, the video is an orientation to a large ecosystem rather than a deep tutorial on any single app. Expect to see tools that exist simultaneously as desktop programs, web apps, and mobile apps.
It is a clear, well-produced tour of a major vendor ecosystem that spans desktop, web, and mobile, which makes it a useful concrete example when comparing platform categories and the Windows platform in particular.
This beginner tutorial introduces Microsoft Power Apps, a low-code environment for building business applications. It is likely to show how an app is assembled, configured, and then made available to users across devices without writing traditional platform-specific code. Watch for how the same app is intended to be consumed on a phone and in a browser.
Stratvert is a widely followed, accurate tutorial producer, and the video illustrates the cross-platform build-once/run-anywhere idea that is central to discussing platform selection trade-offs.
A step-by-step beginner tutorial on Google Drive, covering file storage and backup, accessing files from different devices, and sharing and collaborating with others. The focus is on a service delivered primarily through the browser with companion apps on other devices. It demonstrates how web-first products handle access, sync, and sharing.
It gives you a concrete, familiar example of the Web platform category and shows why browser-based delivery is often chosen for reach and collaboration, directly supporting the mobile/desktop/web comparison.
Together these videos give you observable examples of software delivered on desktop, web, and mobile, which is the raw material for comparing platforms against HCI constraints and user needs (MO1). Seeing the same vendor ship a browser-based service, an installed suite, and a low-code cross-platform builder makes the trade-offs of each delivery model concrete, so you can argue for a platform choice against your own project requirements rather than by habit (MO2). As you watch, note the constraints and capabilities each platform imposes — those notes feed directly into the objectives, constraints, and success criteria sections of your project scope document (MO3).
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Android is the most widely deployed mobile platform in the world, and that reach comes with a particular set of design realities. Unlike a single tightly controlled device family, Android spans thousands of hardware models, screen sizes and densities, OS versions, and manufacturer skins, and it reaches users across a very broad range of regions, budgets and network conditions. Designing for Android therefore means designing for variability rather than for one idealized device.
This topic looks at three things: what the Android platform offers (its component model, system UI patterns, and the Material Design language that sets user expectations), the conventions Android users have learned to rely on (navigation structures, standard components, back behavior, theming and typography), and the constraints you must plan around (fragmentation, performance and memory limits, permissions and privacy, accessibility, and store quality expectations). These constraints are not technical trivia — they shape what your interface can reasonably promise.
The videos below come from the official Android Developers channel. As you watch, listen for the distinction between what the platform gives you for free and what you must decide deliberately. Note how often the answer to a design question on Android is "use the standard component unless you have a strong reason not to," and ask yourself what that implies for the scope and effort estimates in your own project.
A short episode from the MAD Skills series explaining why Google recommends building Android apps with the Material Design Components library rather than hand-rolling UI elements. It is likely to cover what the library provides — themed, consistent, accessible components that follow platform conventions — and the practical benefits of adopting it over custom widgets. Expect discussion of theming, consistency with user expectations, and reduced implementation effort.
This maps directly to the Android Design Conventions subtopic: Material Design is the convention Android users expect, and this video explains it from the platform owner's own developer channel.
An overview of what Google means by Android app quality as user expectations on the platform have risen, spanning areas such as privacy, user experience, performance and compatibility. It likely introduces the quality framework that apps are measured against on the Play Store and why meeting it matters for adoption and ratings. Treat it as a checklist of the non-negotiables a designer should account for early.
It frames the Android Constraints and Considerations subtopic well, showing that constraints come not only from hardware but from platform-level quality and privacy expectations that must be scoped from the start.
A focused look at the visual side of Android app quality — how layout, visual polish and adherence to platform visual norms shape users' first impression of an app. Expect attention to issues like rendering across different screen sizes and densities, respecting system UI such as status and navigation bars, and avoiding visual defects. It is a brief, concrete companion to the broader quality overview.
It connects the Android Platform Overview and design conventions subtopics by showing how device variability translates into specific visual design obligations, in a concise and authoritative format.
Together these videos give you the Android half of the platform comparison required by MO1: they make explicit the design constraints — device fragmentation, visual and quality expectations, privacy requirements, and a prescribed design language — that distinguish Android from web and desktop targets. For MO2, the quality overview and Material Design rationale supply concrete, citable reasons you can use to justify choosing or rejecting Android against your project requirements. For MO3, the quality and visual-experience videos function as a source of realistic constraints and success criteria to write into your scope document, rather than discovering them late in development.
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.
Choosing iOS as a target platform means accepting a particular design philosophy along with a particular set of rules. Apple publishes the Human Interface Guidelines (HIG), maintains a consistent system of controls, typography, materials, and navigation patterns, and reviews every app before it reaches the App Store. For an HCI designer, that combination is both a gift and a constraint: much of the interaction vocabulary is already decided for you, users arrive with strong expectations about how things should behave, and deviating from convention tends to cost you more than it gains.
In this topic we look at three things: what the iOS platform actually is (devices, system design language, and the audience that uses it), the design conventions that make an app feel "native" on iOS, and the constraints that come with Apple's more controlled ecosystem — review policies, hardware and device-size assumptions, accessibility expectations, and limited freedom to invent your own UI patterns. These factors feed directly into whether iOS is the right platform for your team's project.
The videos below come from Apple Developer's WWDC sessions, which is as close to a primary source as you can get for iOS design. While watching, note the recurring vocabulary — hierarchy, consistency, materials, controls, navigation — and ask yourself two questions: what does this guidance require of a designer, and what would it prevent you from doing? Those answers become constraints you can cite in your scoping document.
An Apple WWDC25 session that walks through how an app idea becomes an actual interface, covering the design foundations Apple expects developers to apply. Based on its description, it focuses on how thoughtful design elevates functionality and makes apps feel clear, intuitive, and effortless. Expect discussion of structuring content, establishing hierarchy, and choosing appropriate system components.
It is an official Apple source and maps directly to the iOS Design Conventions subtopic, showing the reasoning behind the conventions rather than just listing them — useful when you need to justify design decisions.
A WWDC26 session on the principles of great design, linked directly to Apple's Human Interface Guidelines design principles documentation. It is likely to present the high-level values Apple wants apps on its platforms to embody, such as clarity, consistency, and deference to content. The session serves as an entry point into the HIG itself.
It gives you the conceptual frame behind the HIG, which is the single most important reference for anyone designing for iOS, and supports both the platform overview and design conventions subtopics.
A WWDC25 session introducing Apple's updated design system, with references to the Human Interface Guidelines sections on materials and related documentation. It is likely to cover the system's visual language — layers, materials, controls, and how they behave across Apple devices. This is the kind of material that shows how much of your interface iOS already defines for you.
Seeing the breadth of a prescribed system makes the ecosystem's constraints concrete, which is exactly the point of the iOS Constraints and Considerations subtopic; it also comes straight from the platform owner, so the details are accurate and current.
These sessions give you an authoritative picture of what designing for iOS actually demands, which is the raw material for MO1: you cannot meaningfully compare mobile, web, and desktop constraints until you know how tightly a platform like iOS specifies its interaction and visual conventions. The emphasis on system components, materials, and design principles gives you concrete, citable reasons for or against choosing iOS for your project, supporting the platform justification in MO2. Finally, the constraints surfaced here — prescribed patterns, device and ecosystem assumptions, and expectations your users bring with them — translate directly into the constraints and success criteria sections of the project scope document required by MO3.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
The Windows desktop remains one of the most widely deployed application platforms in business, education, and engineering settings. Unlike a phone, a Windows machine typically assumes a large screen, a mouse or trackpad, a full keyboard, multiple overlapping windows, and long working sessions. Those assumptions shape everything from how much information you can place on a screen at once, to how you expose commands (menus, ribbons, toolbars, right-click context menus, keyboard shortcuts), to how users expect to move data between applications.
In this module you are deciding which platform fits your project. Windows is a strong choice when users need dense data views, precise pointer input, file system access, long-form content creation, or integration with an organization's existing productivity and identity systems. It is a weaker choice when your users are mobile, occasional, or touch-first. The constraints matter as much as the capabilities: varying screen sizes and DPI settings, accessibility and keyboard navigation expectations, installation and update paths, and the strong conventions users already carry from Office and other Windows software.
The videos below approach Windows from three angles: the Microsoft 365 ecosystem that many Windows users live inside, the current developer tooling story on Windows, and a low-code route to building Windows-friendly business apps. While watching, note the interaction patterns you see repeatedly (ribbons, panes, command bars, keyboard shortcuts), and ask yourself what each one assumes about the user's hardware, attention, and environment. Those observations are the raw material for the platform justification and scope document you will write.
A beginner-oriented walkthrough of what Microsoft 365 is as a subscription and ecosystem, covering the applications it bundles and how desktop apps relate to their cloud and web counterparts. Expect demonstrations inside familiar Windows productivity applications rather than a formal design lecture.
It gives you a concrete tour of the software environment most Windows users already know, which is where the platform's design conventions - ribbons, panes, consistent command placement - come from; Kevin Stratvert is a former Microsoft product manager and explains the ecosystem clearly for newcomers.
A short conference segment from Microsoft Build 2026 in which Kayla Cinnamon demonstrates recent additions aimed at developers working on Windows. It is likely to touch on tooling, terminal and workflow improvements, and how developers set up and work within the Windows environment.
It is a first-party Microsoft source and gives a current snapshot of what building on Windows actually looks like today, which helps you weigh tooling and platform support when justifying a desktop choice.
A step-by-step beginner tutorial on Microsoft Power Apps, showing how to assemble a business application with low-code tools rather than traditional programming. It walks through the app-building interface, data connections, and producing something usable by an organization.
It illustrates a realistic path many Windows-oriented organizations take for internal tools, letting you compare build effort, constraints, and control against writing a full native desktop application when you select a platform for your project.
Together these videos let you characterize the Windows side of the mobile/web/desktop comparison called for in MO1: you see the input assumptions, screen density, and interaction conventions of desktop productivity software, plus the cloud and web counterparts that blur the line. The developer experience and Power Apps videos surface practical build-and-deploy considerations - tooling, low-code versus custom development, organizational integration - that you will need to cite when you select and justify a platform under MO2. Finally, the constraints you identify while watching (hardware assumptions, licensing and ecosystem dependencies, development effort) translate directly into the objectives, constraints, and success criteria sections of the scope document required by MO3.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
The web is the most broadly reachable application platform available to you. A web app runs inside a browser, which means a single codebase can be opened on a laptop, a tablet, a phone, or a shared kiosk without anyone installing anything. That reach comes with trade-offs: you inherit the browser's capabilities and limits, you depend on a network connection, and you must design for screen sizes and input methods you cannot predict in advance.
In this module you are deciding which platform fits your project. To make that call for the web, you need a working picture of three things: how web applications are typically structured (a client in the browser talking to a server over HTTP APIs), the design conventions users already expect from web pages, and the constraints that shape what a browser-based interface can realistically do. Those three threads map directly onto the subtopics for this topic.
The videos below approach the web platform from three angles: the communication layer that connects a web front end to its back end, the difference between responsive and adaptive approaches to varying screens and capabilities, and practical visual conventions for web layout. As you watch, keep asking what each idea implies for your own project proposal: what would it cost you in effort, what would it give your users, and where would the browser get in your way.
A short crash-course explanation of REST APIs: what they are, how clients and servers exchange data over HTTP, and how requests and responses are typically structured, with examples. The video is part of ByteByteGo's system design series, so it frames REST in the context of how real applications are built.
Web applications almost always separate a browser front end from a server back end, and REST is the most common way those two talk; understanding this gives you concrete grounding for the Web Platform Overview subtopic and for the network-dependence constraint of web apps.
The Flutter team explains the distinction between responsive design (adjusting layout to the amount of available screen space) and adaptive design (adjusting behavior to what the platform itself can do). Expect definitions, the reasoning behind each, and examples of when you would apply one, the other, or both.
Responsive versus adaptive is the central vocabulary for discussing how a single web experience serves many devices, which speaks directly to cross-device reach and to Web Platform Constraints and Considerations; it comes from a platform team that deals with multi-device UI daily.
A fast, practical walkthrough of web design fundamentals from a working designer, covering common improvements to layout, spacing, typography and visual hierarchy that make pages feel polished. The framing is concrete tips you can apply immediately rather than abstract theory.
It gives you the conventional patterns users already expect from web pages, supporting the Web Design Conventions subtopic with practitioner-level, applicable guidance you can carry into your own prototype.
Together these videos build the platform-specific knowledge MO1 requires: the REST video clarifies the client-server, network-dependent nature of web applications; the adaptive-versus-responsive video shows how web interfaces must stretch across screen sizes and device capabilities; and the web design video grounds the conventions users expect in a browser. That understanding of web strengths and limits is what lets you argue in MO2 why the web is or is not the right choice for your project, and it supplies concrete constraints and considerations, such as connectivity, browser capability, and multi-device layout, that you can name explicitly in the scope document required by MO3.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Choosing a platform is one of the first real design decisions you make in an HCI project, and it constrains almost everything that follows: screen size and input method, interaction patterns, offline behavior, accessibility options, distribution, and even how users discover your app. In this topic we treat platform selection as a structured decision rather than a preference. You weigh who your users are and where they will realistically use the product, what capabilities the interface actually requires (camera, sensors, notifications, large-screen multitasking, keyboard-heavy entry), what your team can actually build with the tools and time available, and then you write the decision down with the reasoning behind it.
That last step matters more than students expect. A platform choice that is documented with criteria, alternatives considered, and trade-offs accepted can be defended to a client or instructor, revisited when requirements change, and reused as input to your scope document. An undocumented choice usually turns into an argument later in the term.
The videos below come from software architecture and system design rather than from HCI directly. Watch them for the decision-making method, not for the specific technologies: notice how each one starts from requirements and constraints, lays out options, names the trade-offs, and arrives at a justified choice. Then practice translating that same discipline to your own question — mobile, web, or desktop — where the constraints are users, context of use, and interface capability instead of servers and databases.
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.
Once you have a rough idea of what your project should do and who it is for, the next practical question is: what will you actually build it with? Every platform — Android, iOS, Windows, and the web — comes with its own expected toolchain, from design and prototyping software through to IDEs, UI frameworks, and testing tools. Choosing well early saves rework later; choosing poorly can lock your team into a workflow that fights your design goals or your available skills.
This topic surveys those options in two layers. The first is design and prototyping: tools like Figma that let you sketch, wire up, and test an interface before any code exists, so usability problems surface cheaply. The second is implementation: the native tool sets for each platform (Android Studio and Kotlin, Xcode and Swift, Visual Studio and .NET, plus the browser-based web stack) and the cross-platform frameworks such as Flutter, React Native, .NET MAUI, and Compose Multiplatform that promise one codebase across several targets.
As you watch, keep your own project in mind. Note what each tool assumes about your team's skills, what it makes easy versus awkward, and how much control it gives you over platform-specific interaction conventions. Pay attention to the trade-offs discussed around cross-platform work — code reuse, performance, access to native UI patterns — because those trade-offs are exactly the kind of justification you will need to write into your scope document.
A short beginner tutorial on building an interactive prototype in Figma, covering how to link frames, set up interactions and transitions, and play back the result. It is aimed at people new to the tool and focuses on the prototyping mode rather than advanced design systems. Expect a quick, hands-on walkthrough rather than a deep reference.
Figma is the de facto standard for interface design and prototyping across platforms, and this video gives a compact entry point into the prototyping subtopic from a UX-focused channel, so you can mock up and test screens before committing to a development toolchain.
The creator builds the same application six times using Flutter, React Native, .NET MAUI, SwiftUI, Capacitor, and Compose Multiplatform, then compares the experience and results. Expect discussion of setup, developer experience, UI capability, and the practical differences between native and cross-platform approaches. It is a comparison piece rather than a tutorial on any single framework.
This directly serves the cross-platform tools subtopic and also touches the native iOS and Windows stacks, giving you a side-by-side basis for arguing why one toolchain suits your project better than another.
An official Flutter video that introduces Flutter by mapping its concepts onto what an iOS developer already knows, covering ideas such as widgets, layout, and navigation in comparison to native iOS development. It is framed as an orientation rather than a full course. Viewers unfamiliar with iOS can still use it as a contrast between a native and a cross-platform mental model.
Coming from the Flutter team itself, it is an authoritative look at how a cross-platform framework relates to a native platform's tooling and conventions — useful context when weighing iOS development tools against a shared-codebase approach.
Together these videos move from design tooling to implementation tooling, which is the bridge between deciding on a platform and planning the work. The Figma tutorial supports MO3 by showing how prototypes can make objectives and success criteria concrete before development starts. The six-framework comparison and the Flutter-for-iOS orientation support MO1 and MO2 by exposing the real constraints of each platform's toolchain — native UI fidelity, code reuse, and developer effort — so your platform choice can be justified against stated project requirements rather than preference alone.
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.