Research / Structure / Validation / 01
Frame the outcome
Separate the user’s job, the business constraint, and the behavior that would prove the design works.
Before you begin
By the end, you can…
- Separate outcomes from requested features
- Write a falsifiable problem frame
- Choose evidence that could change the plan
01 / Understand
Requests are clues, not requirements
“Add a dashboard” describes a solution. Ask what decision the dashboard should improve, who makes it, what they do today, and what cost or risk exists. The answer may still be a dashboard, but now the team can judge whether it works.
A useful problem frame names the person, situation, desired progress, constraints, and evidence of success. It also names what would disprove the opportunity. Without a disconfirming signal, research becomes a search for agreement.
02 / Apply
Turn ambiguity into a learning plan
List assumptions about value, usability, feasibility, and viability. Rank them by uncertainty and consequence. The riskiest assumption determines what to learn first.
Match evidence to the decision: interviews for motives and language, observation for actual behavior, analytics for patterns at scale, and prototypes for comprehension and usability.
03 / Make
Your studio task
Make — Write a one-page opportunity brief for a problem you can observe this week.
- Rewrite a feature request as an outcome.
- List five assumptions and rank them by uncertainty and consequence.
- Choose one method that could disprove the riskiest assumption.
- Define the behavior or evidence that would change your decision.
It names a user, situation, desired progress, constraint, and disconfirming signal.
04 / Check