Make a decision~30 min

Make a Decision: Frame the Real Problem

Early preview draft — not yet practitioner or accessibility reviewed.
Goal
Practice turning a solution-shaped request into a problem statement sharp enough to design against — the framing step that decides whether everything after it is aimed right.
Scenario
A stakeholder tells you: "We need an onboarding checklist — new users aren't activating." You suspect the checklist is a solution, not the problem. Before any design happens, you have to establish what is actually going wrong and for whom.
Audience
A product manager who genuinely believes the checklist is the answer and needs to see your framing to be talked out of (or into) it.
Constraints
You may not propose any interface. The deliverable is entirely pre-solution: the problem, the people, the evidence you have, and the evidence you'd need.
Deliverable
A one-page problem framing: (1) the problem statement — who, what they're trying to do, what's in the way; (2) what you actually know vs. assume, each labeled; (3) the two riskiest assumptions and how you'd check each cheaply; (4) a one-sentence answer to "why not just ship the checklist?"
Counts on your evidence profile as
A completed Skill Lab with its rubric and your deliverable
Accessibility requirement
Write the problem statement in plain language a newcomer could follow — jargon-free framing is itself part of the craft this lab practices.
AI policy
AI use is allowed in a limited way for this lab — see details below. AI can pressure-test your framing ("what am I assuming?") after you've written it yourself — starting from a generated framing defeats the exercise, because the judgment being practiced is yours.
Rubric
  • No solutioning: The framing contains zero interface or feature proposals — the checklist question is answered in terms of the problem, not a counter-design.
  • Know vs. assume is honest: At least two items sit in the assume column, and neither is trivially checkable — the split shows real epistemic honesty, not a formality.
  • Checks are cheap and specific: Each riskiest assumption has a check that could genuinely run this week (specific data to pull, specific people to ask) rather than "do more research."

Skills: Problem Framing, Stakeholder Communication

Relevant to: Product Designer, UX Designer

Your work

Sign in to start this lab.