By the end of the lesson, you can formulate a user problem instead of a solution idea, break the problem down into assumptions built on evidence, and write a success criterion that can actually be checked on a prototype or in a test.
Why is a good idea not enough?
Almost every design job starts with an idea: "We need a mobile app," "let's add a chatbot," "let's have a more modern dashboard." These sentences are natural, but they contain a trap: they name a solution before the problem is known. If we cling to a solution too early, the research will only look for why the already chosen idea is good. This is called confirmation bias, and most teams fall into it. The defense: instead of the solution, we formulate the problem, and in a way that can be checked.
A solution is not a problem
A useful framework, which you will use throughout the semester project:
[User], in [situation], wants to achieve [goal], but because of [obstacle], [consequence] happens.
For example: "A first-year student, when enrolling in courses, wants to compare conflicting courses, but the times appear in several separate views, so they make an uncertain decision." This is not yet a solution. But it defines the investigation: whether this really causes the trouble, for whom, how often, and what information would help.
The elements of the problem
Problem framing is the clear formulation of the user, situation, goal, obstacle, and consequence. Let us look at why all five are needed, element by element.
User: not "everyone", but someone whose situation you can observe. For example "first-year student", not "students".
Situation: the same person needs something different when they first orient themselves and something different right before a deadline. The situation provides the context of the task (time, device, emotional state).
Goal: the desired outcome, not the interface action (as in the previous lesson).
Obstacle: what makes the goal harder. This is the subject of design; content, structural, and visual solutions come here.
Consequence: this shows the weight. A misleading label may be annoying, while a bad cancellation condition can cause loss of money or a lost appointment. The consequence helps with prioritization.
The size of the problem matters too. "University administration is complicated" may be true, but it is unmanageable for a semester project. "The student cannot tell whether they still need to upload a document before submitting the application" is already an investigable and designable task. If your problem is too big, narrow it until you can describe one task of one user.
Assumptions and evidence
Every initial problem frame contains assumptions. This is not a mistake, since at the start we cannot know everything. The mistake is treating an assumption as fact. So make an assumption map: list the claims of the problem frame, and next to each write where it comes from.
Claim
Source
If wrong, what changes?
Students search for events on their phones
assumption
Medium: optimizing for mobile is important anyway, but it is not the main question
People do not understand organizers' jargon
assumption
Large: the whole navigation and content is affected
The price of the event is the most important decision criterion
observation
Medium
The third column (risk) marks what needs to be checked first. An assumption whose being wrong would change the whole plan is a research priority.
Later, assumptions become design hypotheses (checkable statements about the effect of a change); we learn about this in chapter 9. For now it is enough to distinguish: an assumption is a not-yet-verified claim about the situation.
Success criterion: how do we know it got better?
A success criterion is an observable sign from which it can be decided whether the user reached the goal. Why must it be thought out in advance? Because if we decide what counts as success after the test, we inadvertently fit it to the result we got. The success criterion is the "measuring stick" of the research.
Characteristics of a good success criterion:
it relates to behavior or understanding, not taste ("make it clean," "make them love it");
it clearly describes the task and the sign of success,
where possible, it also includes the error or the effort, for example without outside help, within two minutes.
Examples:
The participant, without outside help, selects an appointment that suits them, and can state the cancellation condition.
The participant fills in the mandatory fields correctly on the first attempt, or can fix the data from the error message.
After the booking, the participant can say for sure whether the booking was created, when, where, and what the next step is.
In a small study, you do not need to promise a statistically generalizable metric. It is also a valuable result if three relevant participants get stuck at the same point, and in the modified prototype this obstacle disappears. What matters is that you fit the claim to the limits of the sample: "of the three participants examined, all three…", not "users…".
Worked example: the problem of Mai program
Starting idea: "we need a map-based event app." This is a solution. A research question could be: how does a student find a suitable program for tonight? Suppose the first conversations show that the main trouble is not a lack of locations, but that event pages do not quickly reveal the price, start time, language, or advance registration.
The new frame of the problem: "A student looking for a spontaneous program wants to compare tonight's events in a short time, but the basic data needed for the decision appears scattered or incomplete, so they give up the search or choose the wrong program." Here we have the user (the student looking for a spontaneous program), the situation (little time, tonight), the goal (to compare), the obstacle (scattered, incomplete data), and the consequence (they give up or choose badly).
It does not yet follow that a map is needed. A first prototype could be a well-filterable list in which the data important for comparison is visible up front. The success criterion of the test: the participant finds an event that meets their own conditions within two minutes, and can explain why it suits them. This criterion is tied to behavior, checkable, and the measured value (two minutes) also signals that speed truly matters in this situation.
Common misconceptions
Claim
Clarification
"The more detailed the problem statement, the better."
Detail is useful if it can be researched or affects a decision. An invented backstory is not evidence.
"The success criterion is the same as our project goal."
The project goal can be broad; the success criterion is the way of checking the specific planned task.
"If the participant solved it, there is no problem."
Watch for workarounds, uncertainty, errors, and also whether they understood the consequence.
"The problem frame is final."
The first version is a working hypothesis. After the research it will probably change, and that is normal.
In brief
Instead of a solution, we formulate a problem: user, situation, goal, obstacle, consequence.
The assumption map shows what is proven and what is not, and which error would be the most expensive.
The success criterion is an observable sign, fixed in advance, of behavior or understanding, not of taste.
Even with a small sample you can learn, if the wording fits the limits of the sample.
Review questions
Why is "let's make a clean interface" not a problem statement?
Which success criterion would be observable in your own project?
Which of your assumptions would be the riskiest if it proved wrong?
How would you narrow a problem that is too big to a single testable task?
Problem framing and success criteria
Objectives
By the end of the lesson, you can formulate a user problem instead of a solution idea, break the problem down into assumptions built on evidence, and write a success criterion that can actually be checked on a prototype or in a test.
Why is a good idea not enough?
Almost every design job starts with an idea: "We need a mobile app," "let's add a chatbot," "let's have a more modern dashboard." These sentences are natural, but they contain a trap: they name a solution before the problem is known. If we cling to a solution too early, the research will only look for why the already chosen idea is good. This is called confirmation bias, and most teams fall into it. The defense: instead of the solution, we formulate the problem, and in a way that can be checked.
A solution is not a problem
A useful framework, which you will use throughout the semester project:
For example: "A first-year student, when enrolling in courses, wants to compare conflicting courses, but the times appear in several separate views, so they make an uncertain decision." This is not yet a solution. But it defines the investigation: whether this really causes the trouble, for whom, how often, and what information would help.
The elements of the problem
Problem framing is the clear formulation of the user, situation, goal, obstacle, and consequence. Let us look at why all five are needed, element by element.
The size of the problem matters too. "University administration is complicated" may be true, but it is unmanageable for a semester project. "The student cannot tell whether they still need to upload a document before submitting the application" is already an investigable and designable task. If your problem is too big, narrow it until you can describe one task of one user.
Assumptions and evidence
Every initial problem frame contains assumptions. This is not a mistake, since at the start we cannot know everything. The mistake is treating an assumption as fact. So make an assumption map: list the claims of the problem frame, and next to each write where it comes from.
The third column (risk) marks what needs to be checked first. An assumption whose being wrong would change the whole plan is a research priority.
Later, assumptions become design hypotheses (checkable statements about the effect of a change); we learn about this in chapter 9. For now it is enough to distinguish: an assumption is a not-yet-verified claim about the situation.
Success criterion: how do we know it got better?
A success criterion is an observable sign from which it can be decided whether the user reached the goal. Why must it be thought out in advance? Because if we decide what counts as success after the test, we inadvertently fit it to the result we got. The success criterion is the "measuring stick" of the research.
Characteristics of a good success criterion:
Examples:
In a small study, you do not need to promise a statistically generalizable metric. It is also a valuable result if three relevant participants get stuck at the same point, and in the modified prototype this obstacle disappears. What matters is that you fit the claim to the limits of the sample: "of the three participants examined, all three…", not "users…".
Worked example: the problem of Mai program
Starting idea: "we need a map-based event app." This is a solution. A research question could be: how does a student find a suitable program for tonight? Suppose the first conversations show that the main trouble is not a lack of locations, but that event pages do not quickly reveal the price, start time, language, or advance registration.
The new frame of the problem: "A student looking for a spontaneous program wants to compare tonight's events in a short time, but the basic data needed for the decision appears scattered or incomplete, so they give up the search or choose the wrong program." Here we have the user (the student looking for a spontaneous program), the situation (little time, tonight), the goal (to compare), the obstacle (scattered, incomplete data), and the consequence (they give up or choose badly).
It does not yet follow that a map is needed. A first prototype could be a well-filterable list in which the data important for comparison is visible up front. The success criterion of the test: the participant finds an event that meets their own conditions within two minutes, and can explain why it suits them. This criterion is tied to behavior, checkable, and the measured value (two minutes) also signals that speed truly matters in this situation.
Common misconceptions
In brief
Review questions