Every interface is built for someone, and almost every interface is also paid for, approved, maintained, or regulated by someone else. Before you can write a believable use case scenario, you have to know who those people are. This topic introduces stakeholder analysis: the practice of systematically listing everyone who has an interest in a system, classifying them, and deciding whose input shapes which design decisions.
A key distinction in this module is between users and stakeholders. Users are the people who directly operate the interface to accomplish a task; stakeholders are the broader set of parties affected by or invested in the system, including managers, clients, support staff, compliance officers, and sometimes people who never touch the software at all. Users are a subset of stakeholders, but their goals are not identical to stakeholder needs — a manager may need audit trails and cost control while the frontline user needs speed and fewer clicks. You will also look at how user roles and permissions subdivide the user population, since an administrator and a guest may use the same system in very different ways.
As you watch the videos below, keep a running list of two things: the techniques each speaker uses to surface stakeholders who might otherwise be forgotten, and the kinds of questions used to pull needs and goals out of those people. Notice that the videos come from different traditions — UX research, project management, and software engineering — and that each tradition frames stakeholders slightly differently. That contrast is useful: it shows you that stakeholder identification is a transferable skill with vocabulary that shifts depending on who is doing it.
Revisit this video a second time with a different lens: listen specifically for how stakeholder statements are turned into usable inputs for design rather than treated as instructions to follow.
A second pass helps you separate stakeholder needs from user goals, which is the distinction most often confused when students begin writing scenarios.
A project-management-oriented walkthrough of how to identify the stakeholders on a project. The video is aimed at practitioners who need a practical, repeatable method for listing and sorting the people with an interest in a project's outcome.
It gives you a concrete, step-by-step identification technique from the project management perspective, which complements the UX view and supports the "Techniques for Stakeholder Identification" subtopic.
A lecture-style software engineering video that defines stakeholders, presents the common types or categories of stakeholders, and discusses why they matter to a software project. It also addresses how to go about identifying them during the requirements phase.
The explicit focus on stakeholder types maps closely to the subtopics on defining stakeholders and distinguishing users from other interested parties, and it frames the material in the software engineering vocabulary used in this course.
Together these videos prepare you for the module outcomes by establishing who the scenarios are about before you write them. Identifying and classifying stakeholders and user roles gives you the cast of actors and the goals needed to compose accurate use case scenarios (MO1). The NN/g interview video and the identification techniques in the project management and software engineering videos introduce the interview-based side of requirements gathering that you will extend with surveys and observation (MO2). Finally, recognizing that different stakeholders care about different things — speed and ease of use for end users, security, compliance, and cost for others — sets up the later work of sorting collected requirements into functional and non-functional interface specifications (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.