Problem FramingHead-dominant: what is the real problem?

The problem governs the order of design work. We, as designers, move through all these phases: Problem Framing, Value Shaping, Experience Realisation. The problem also dictates which one each moment needs.

Most of the time, a problem that lands on my desk arrives already packaged. Someone has decided what it is, set its scope, and started solving it, all inside the brief. “Users are dropping off at checkout.” “Onboarding is confusing.” “We need to revamp the remittance screen.” Early on, I took briefs like these at face value and got straight to work, and shipped more than one solution to the wrong problem. They read like problem definitions, but more often than not, they’re closer to symptom reports: observations of what has gone wrong, made by someone with assumptions about the cause.

Problem Framing is Head-dominant work, but Heart is also present in Problem Framing. You cannot frame a problem without some orientation toward who it affects. Hand is present too, because you cannot frame a problem responsibly without some idea of what is possible to build. What makes Problem Framing Head-dominant is that the primary activity is cognitive: stepping back from the problem, questioning its framing, resisting the urge to begin making before you know what you are making for.

Problem Framing is oriented by one overriding question: is this even the right problem? Many briefs describe the symptom of the actual problem rather than the problem itself. Here are the probing questions to check.

• Symptom, What is the observable evidence something is wrong?
  Drop-off rates, support tickets, failed usability tests, conversion gaps. The presenting complaint: real, but the least useful place to design a solution. A symptom can be generated by many different underlying conditions. Treating it without the condition is work you’ll do again.
• Premise, What assumption about user behaviour, business model, or product structure is generating the symptom?
  Where the real problem sits. A checkout drop-off may sit on top of a false premise, that users trust the brand enough to enter payment details without reassurance. The intervention is trust infrastructure elsewhere in the product.
• Constraints, Which of the constraints the brief appears to carry are real, and which are inherited?
  Structural limits the team genuinely cannot move, or inherited assumptions that entered the brief and have never been tested? An assumed constraint and a real one demand different responses.
• Outcome, What would the situation look like if the premise were corrected?
  The state of the world the design is trying to produce, described before any feature or screen is chosen. Articulating the outcome before the solution makes the subsequent work falsifiable: you can ask, at the end, whether it happened.