Welcome to Last Minute Lecture.
This free chapter overview is designed to help students review and understand key concepts.
These summaries supplement, not replace, the original textbook and may not be redistributed or resold.
For complete coverage, always consult the official text.
Welcome to The Deep Dive, the show where we take the densest topics and distill them into genuinely useful knowledge, giving you a serious shortcut to being well informed.
Today we're tackling what is probably the foundational phase of interaction design.
That's right, discovering requirements.
You tasked us with mastering a core chapter called discovering requirements and our mission today is pretty simple.
It's all about stopping the focus on the solution space and really locking in on the what?
The problem space.
We need to understand the users, their constraints, their daily routines and their goals before we even think about designing the first screen.
Exactly.
That deep understanding is the bedrock.
And while design requirements and evaluation are all inevitably linked in this big iterative loop.
Like the double diamond design process.
Precisely.
This initial stage has to have distinct goals.
If you don't define the problem clearly, every design effort that follows is just going to be fundamentally flawed.
It sounds like requirements discovery is the ultimate exploratory process.
So where does this crucial activity sit within that broader iterative design cycle?
It spans the first two phases of the double diamond.
So the exploration phase and the definition phase.
Exactly.
You're gaining insights and then you're establishing a really clear description of what needs to be developed.
But crucially, the discovery process itself is iterative.
Meaning you don't just ask users once and walk away?
Oh, not at all.
Requirements evolve, they change organically as stakeholders start interacting with initial designs and prototypes.
So if things are constantly shifting, how do we stop the whole project from becoming a moving target?
Once we find a key user need, how is it actually captured, formalized?
Well the level of rigor really depends on the domain and frankly the stakes.
For a low stakes product, let's say a new feature on a simple exercise app, you might just capture the requirements implicitly.
The prototype is the requirement in a way.
But for something more critical?
In high stakes environments, I'm talking process control software in a factory or even more critically air traffic control systems.
You need structured, explicit and rigorous notation.
You cannot afford to lose a single requirement.
Why bother with all that documentation though?
I get safety, but for a non -critical business app, why not just jump into development after a few meetings?
Because the main goal of that formality is risk mitigation.
Specifically.
Specifically, mitigating miscommunication.
Misunderstanding requirements is just the fast lane to developing a product that's unusable or inappropriate or just completely fails to meet the business need.
So clear articulation serves two main functions.
It gives technical clarity for developers and it allows users to contribute effectively and agree on the scope.
It's a bulwark against scope creep and honestly, team memory loss.
That really puts the importance of documentation into perspective.
Okay, so if that's the activity, let's define the key element.
What exactly is a requirement?
At its core,
a requirement is a statement about the intended product.
It specifies what it is expected to do or how it will perform.
And that could be a huge range of things, right?
Absolutely.
It can be super specific and technical like the time to load a map must be less than half a second or it can be much broader, more qualitative.
Like the product has to be appealing to teenagers.
So when we capture these, how do we make sure we don't just get the statement but all the crucial context that goes with it?
We need structure.
This is why requirements frameworks exist.
A really powerful example is the atomic requirements shell.
And that comes from a framework called Volair.
That's the one.
If you picture a really detailed form for every single requirement, this structure makes sure that every piece of context, its source, its priority, even a customer satisfaction rating is captured.
What's the most important part of that shell?
The truly crucial field is the fit criterion.
This is your secret weapon.
The fit criterion.
It's the measure you use to assess if the requirement has been fulfilled.
It forces testability and success metrics right at the start.
So if you state a requirement is the map must load quickly,
the fit criterion forces you to define what quickly actually means.
Like 95 % of map loads must complete in under 500 milliseconds on a 4G connection.
Exactly.
It makes it measurable and actionable.
Okay, but that formal shell sounds intensive.
I know a lot of interaction design happens in really fast -paced, agile environments.
How does this translate?
That's where user stories take center stage.
They move away from that heavy documentation and are designed to communicate requirements concisely between team members.
And a user story is just a small deliverable chunk of functionality, right?
Something a customer can see.
Yep.
And it serves as a starting point for a conversation.
Is there a standard framework people use for reading them?
There is.
The classic structure is used all over the world because it forces you to state the purpose and the value.
As a role, I want behavior so that benefit.
Let's hear those travel organizer examples again.
I think they really highlight the value part.
Sure.
As a traveler, I want to save my favorite airline for all my flights so that I will be able to collect air miles.
The value is clear.
Collecting air miles.
Then the other one.
As a travel agent, I want my special discount rates to be prominently displayed so that I can offer my clients competitive prices.
The value there is competitive advantage.
But we all know the real world doesn't always fit neatly into a two -week sprint.
What happens when we hit one of those massive requirements?
That's when we use epics.
An epic is just a huge user story.
It's a high -level goal that might take weeks, maybe months to implement.
So you have to break it down.
You must.
Epics get broken down into smaller, actionable user stories, or tasks, before they can be pulled into a sprint.
Like the travel app example.
Right.
An epic might be.
As a group traveler, I want to choose from a range of potential vacations that suit the collective group's preferences so that the whole group can have a satisfactory time.
That clearly covers dozens of smaller stories about filtering, voting, comparing options.
Understanding the scale is vital.
Okay, let's switch gears to classification.
Requirements come from users, business, tech.
We often hear the simple split.
Functional versus non -functional.
But our sources introduce a much broader view.
They do.
While functional, what the product will do, and non -functional, the characteristics and constraints, is the traditional split, we really need a wider lens.
Frameworks like the seven product dimensions.
Exactly.
That helps you cover the interface, action, data, control, environment, quality attribute, and user aspects.
But let's focus on the six most common types in interaction design.
They cover the necessary breadth.
Let's run through those six, starting with the obvious one.
First, functional requirements.
This is the core purpose.
What is the system going to do?
For a factory automation system, a functional requirement is that the robot must be able to place and weld metal pieces accurately.
Simple.
Okay, number two.
Second are data requirements.
This gets into the nitty -gritty of the information.
It's volatility, size, persistence, accuracy, and value.
So for a bank, the data has to be accurate and persist for years.
Precisely.
Third is the incredibly important category of environmental requirements,
or the context of use.
This breaks down into four critical aspects.
The physical environment is one.
Right.
That deals with lighting, noise, whether the user is wearing protective gear.
So for example, if you're designing a communication system for workers in a loud factory,
a speech interface is just a terrible idea.
Because of the noise interference.
Makes sense.
What are the others?
The social environment addresses collaboration.
Is the work shared, coordinated?
Are people using it at the same time or asynchronously?
Then you have the organizational environment, that's user support, training, company infrastructure, and finally the technical environment, which is all about compatibility and limitations.
Got it.
So moving beyond the context, the fourth type is all about the people using it.
That's user characteristics.
You have to capture the abilities, skills, backgrounds, preferences, and disabilities of your audience.
You need to distinguish clearly between a novice, who needs a lot of guidance, and an expert, who wants efficiency and flexibility.
And this leads to creating a user profile.
Yes.
Which aggregates those characteristics for a typical user.
Okay, two to go.
The final two deal with quality.
Fifth, we have usability goals.
This is where you get into usability engineering and set specific, measurable metrics early on.
Things like efficiency,
effectiveness, memorability.
Got it.
And sixth, user experience goals.
These are often harder to quantify, but they are absolutely vital for adoption.
Is the product comfortable?
Is it aesthetically pleasing,
trustworthy,
delightful even?
Within that category of non -functional constraints, the sources really emphasize usable security.
But isn't there a fundamental tension there?
If security is truly robust, it has to get in the user's way sometimes.
That tension is the central design challenge of our time.
The requirement isn't just for security, it's for usable security.
Because users will just find a way around it if it's too frustrating.
That's what Adams and Sass found way back in 1999.
When security mechanisms become overwhelming, too many complex password rules, confusing alerts users develop coping strategies.
And in essence, the overly complex security design undermines the security itself.
The designer's job is to make those security steps feel manageable and integrated, not like some annoying hurdle.
That requires deep insight into user behavior.
So let's pivot from theory to practice.
How do we actually discover all these layered requirements?
We still use the standard techniques of course, interviews, observation, questionnaires.
But interaction design relies on some more specialized methods.
Like?
Like studying documentation.
Existing manuals, logs, corporate standards.
That gives you crucial background on the prescribed steps, even if that's not what users actually do.
And I imagine looking at what's already out there is important.
Definitely.
Researching other products.
If you're designing a new non -visual drawing tool, you have to analyze the existing tools for blind users to find their limitations or any unmet needs.
The core insight then is triangulation.
You combine techniques to see the problem from different angles.
Exactly.
Observation shows you the context, interviews reveal the specifics, documentation confirms the official process.
It's about building a holistic picture.
We talked about observation, but how do we uncover behavior and attitudes that the user isn't even consciously aware of?
This is where the idea of probes comes in, right?
These feel like a genuine innovation.
They really are.
They're an imaginative approach designed to prompt participants into action or deep reflection on the really mundane parts of their daily lives.
They rely on participants logging data over time.
And the original version was the cultural probe.
How did that work?
Cultural probes weren't about asking direct questions.
They were meant to provoke insight.
They often involved a wallet or a packet with evocative objects inside postcards, a disposable camera, maps, diaries, asking people to engage with them.
So you're not just asking them what's important, you're getting them to show you.
Exactly.
If you'll subtle attitudes and values, a questionnaire would just completely miss.
And there are variations on this.
Many.
We see design probes, which are objects relating to a specific question, like the top Trump's probe where people rated the powers of an object.
We also use technology probes.
Like an app deployed in the field.
Right.
Like the Kalinda movement monitoring device used in rural Kenya to gather location and motion data in a real world setting.
And then there are the provocative probes.
These are designed to challenge existing norms and provoke discussion.
Take the box, for example.
It was a physical device designed to challenge domestic laundry practices by, well, provoking users about the assumption of continuous electricity.
It forces them to articulate assumptions they never realized they had.
That's the goal.
Okay, let's move to another core field research process.
Contextual Inquiry, or CI.
This sounds much more structured than probes.
It is.
Contextual Inquiry is a crucial methodology.
It uses one -on -one field interviews and relies on a master -apprentice model.
So the interviewer becomes the apprentice.
Exactly.
You're immersed in the user's world, the master's world learning, by observing and participating.
The key is to focus on why they do something, not just what they're doing.
And this CI process has four guiding principles.
It does.
First, context.
You have to go to user, see what they do as they do it.
Second is partnership.
You and the user are on equal footing, exploring their life together.
And third?
Third is interpretation.
Observations are turned into design hypotheses collaboratively with the user.
You don't guess why they do something.
You stop and ask them, I noticed you just did that.
What does that mean to you?
Their input validates the interpretation.
And the last principle is focus.
While the user leads, the focus keeps the discussion guided toward the project's scope, making sure the data you collect is relevant.
I see that Contextual Inquiry often surfaces something called cool concepts.
What are those?
Cool concepts are insights from what users find genuinely desirable or compelling about technology.
They're split into two groups.
Okay.
Joy of Life concepts like accomplish, connection, identity, sensation,
capture how products enrich a user's broader life.
You have Joy of Use concepts like direct inaction, hassle factor, learning delta, which focus on the friction and pleasure of using the product itself.
So once we have all this rich qualitative data, we often need to switch from discovery to generation, creating new ideas and requirements.
And that's where brainstorming comes in.
Brainstorming is essential for generating innovative ideas from the requirements we've uncovered.
To do it well, the rules are strict, include a wide range of disciplines, never criticize or debate ideas, and you have to welcome silly stuff.
Because wild ideas can lead to useful requirements.
Very often they do.
And practically, you use catalysts, sticky notes, and start with a well -honed problem to keep the energy high and the output relevant.
Okay, we've defined the requirements.
Now we need to communicate the vision.
A list of requirements isn't very compelling.
This brings us to two essential communication tools, personas and scenarios.
Right.
Personas, which were popularized by Alan Cooper, are synthesized, rich, realistic descriptions of typical users.
And crucially, they are not idealized users or just job descriptions.
They're characterized by goals related to the product.
Exactly.
You include a name, a photo, behavior patterns, attitude, environment, like Ben the beginner cook.
Their power is phenomenal because they help designers make focused decisions and remind the team that real people are using the product.
You ask, what would Ben do?
That's it.
They lend emotional weight and realism to abstract requirements.
And the persona then comes to life inside a scenario.
Yes.
A scenario is just an informal narrative description of human activities or tasks.
They let us explore context, needs, and requirements in a story format that anyone can relate to.
And it can describe existing behavior or behavior with a new technology.
Both.
And I appreciate that the sources also extend this to design fiction.
It's a way to take a scenario situated in a fictional world and explore ethics or context without worrying about implementation today.
It's a tool for provocative exploration.
So visually, a scenario is a single experience of using the product from one persona's perspective, linking their goal to the narrative.
They're inextricably linked.
They are.
But while personas and scenarios communicate the vision, sometimes we need to formalize the step -by -step interaction details.
That's where use cases fit in.
And use cases are all about functional requirements, capturing the interaction through a sequence of actions.
Right.
Which is different from a user story's focus on the outcome.
We use two main styles.
First are essential use cases.
They're abstract.
They focus on the division of tasks between the user's intention and the product system responsibility.
Avoiding interface specifics.
Correct.
The second style is detailed use cases.
These are much more specific.
They detail the normal course, the most common path, and then any alternative courses, specifying what happens if a step fails.
So if a user enters an invalid country name, for example.
Exactly.
That distinction is key.
Use cases formalize the interaction logic, while scenarios provide the human context and motivation.
If we pull this all back to the big picture, we've really covered the entire requirements landscape.
We have.
We define the requirements types.
Functional, data, environmental, user, usability, and UX.
We explore the techniques for discovery, contextual inquiry, probes, brainstorming, and finally, the essential artifacts that bring requirements to life.
Personas, scenarios, and use cases.
It becomes incredibly clear that, as Frederick Brooks once said, the hardest single part of building a software system is deciding precisely what to build.
And that decision hinges entirely on this foundational requirements discovery process.
The goal isn't just to list features, but to engage in a true partnership with users through interviews, probes, observation to transform complex, often unarticulated human needs into a clearly defined valuable product.
It's the collaboration that drives the value.
A huge thank you for guiding us through this essential deep dive into requirements discovery.
Now you are fully equipped to understand the crucial what before you ever have to worry about the how.
We'll see you next time.