
Learn how UX requirements align user needs with business goals, using empathy and situation mapping, context of use, and contextual use scenarios to drive valuable outcomes.
Examine why traditional requirements produce mediocre products and learn how ux focused requirements, driven by user research and outcome goals, guide better, testable design decisions.
Explore poor requirements generation and its costs in accreditation systems: late submissions, penalties, and customer churn. Requirements must be generated and negotiated through UX-focused, iterative methods.
This lecture critiques use cases and user stories, and shows how to craft contextual, value-driven requirements using empathy, situational mapping, and contextual use scenarios.
Clarifies why assumptions and misunderstandings derail requirements and why not all data points matter. Emphasizes that requirements are not features and highlights the user experience value loop for guiding trade-offs.
Explore why what people say they need often differs from what they actually need, and why surveys mislead, urging user observation over focus groups.
Identify what people actually need by separating root problems from symptoms, define measurable success with stakeholder goals, and design for users' mental models to ensure meaningful requirements.
Observe how people actually use products to uncover unarticulated needs, focus on outcomes and satisfaction, and translate context of use into accurate requirements.
Explore empathy mapping to uncover user needs by detailing thoughts and emotions, environment, social influences, behavior, pain, and gain using the six-area empathy mapping template.
Create an empathy map for Jane Holden, a 51-year-old emergency operator, to explore motivations, emotions, social and environmental influences shaping her use of the call scripting app and defining success.
Explore sample empathy map insights for an emergency call operator, detailing thoughts, emotions, environment, pains, and gains to guide ux requirements that support emotional drivers.
Master situational mapping to build contextual personas with two-area mapping template, then develop a hypothetical situation noting what the user thinks, feels, sees, and does, plus best and worst outcomes.
Create a situational map using the guidebook form to help an emergency operator gather caller situation and location, sequence steps, and capture on-screen cues and thoughts.
Explore how to apply the situational map to design fast, calm, and simple ux that captures caller location and situation, employs relevant scripts, and supports rapid dispatch to first responders.
Ask targeted questions after empathy and situational mapping to uncover stress factors, data flows, and handoffs that shape requirements. Identify unknowns and data needs to enable speed and accuracy.
Learn to design for context by using contextual use scenarios that reveal context of use, addressing flow, culture, sequence, and artifacts through concise, user-centered narratives.
Learn how to translate conversations into visual workflow scenarios using boxes and arrows, questions, and color-coded notes to reveal sticking points and refine the user journey.
Extract functional needs and elements from use scenarios to form requirements, illustrated by Kia and Mr. Wilson. Model search, overview views, follow‑ups, appointment parameters, and resource‑aware scheduling.
Generate contextual requirements for a retiree investment portal using Bob Davison's persona, including empathy maps, situational maps, and a first-use scenario to define functional needs and elements.
Generate, don't gather, requirements; use prototypes and evidence to validate needs, rooted in personas and use scenarios, and ensure every feature links to user motivations and business goals.
What UX struggles would you love to end?
Do you want to stop the endless cycle of rework to satisfy stakeholders’ moving targets?
Would you like to play a role in creating requirements instead of having them handed to you like written law?
Are you tired of delivering products with UX defects you know could have been avoided?
Do you wish there was a way to get managers to agree to UX work at the start of the project, instead of tacking it on at the end, when it’s too late?
If you answered YES to any of those questions, you’re in the right place. I created this course specifically to end the vicious cycle too many developers and product teams are trapped in: vague requirements they had no hand in creating, constant rework and a never-ending stream of new (and changing) requirements.
See, I’ve been there myself. In nearly 30 years of working with organizations of all sizes in nearly every industry, I know that cycle all too well. I know what it’s like to try and roll the “UX rock” up that hill only to have your stakeholders or managers or clients roll it back down.
No more debate about when UX work should happen.
I know the pain of fighting to get UX included at the start of a project all too well. And I also know that it’s entirely possible to put an end to it.
UX Requirements Made Simple will show you how to get a seat at the requirements table, open the minds and ears of your managers or clients, and see a massive change in both the quality of requirements and the success of the delivered product.
You’ll see how easy it is to quickly integrate strategic UX validation into an existing requirements process — without the need for additional time, money or resources. Here’s just some of what you’ll learn:
Poor methods for requirements that rely on a broken engineering process — and a better, simpler set of methods that get to clarity and value quickly.
Why what users say they need isn’t what they actually need (and how to tell the difference).
Poor requirements tools that address task completion instead of success — and a smarter set of tools that focus your work squarely on desired outcomes.
How to get managers or clients (or your team) to ask the right questions, instead of solution jumping.
How to create contextual use scenarios that tell the real story of the user’s journey from start to finish — and extract relevant functional needs and elements that make up valuable requirements.
It’s simple, it’s straightforward, and it works.
Not because I say it does — but because the Enterprise teams I’ve taught to use these methods have gotten the results I’m talking about. It works because more than 140,000 students (yes, that’s a real number) tell me that my courses have changed the work they do for the better.
Why? Because I deal in software development reality instead of UX fantasy. Perfect situations where we can do these well-funded deep dives into UX research don’t exist for a vast majority of development teams, and I’m really tired of hearing everyone pretend otherwise. So everything I deliver is based in reality, in the less-than perfect world most of us live in.