The work across the layershow the three phases meet the three layers of the framework
An Associate asks why a particular form field is required. On the same product, a Lead asks whether the onboarding flow is the right answer to the activation problem. A VP asks whether the product line will still matter to the company in two years. All three are doing Problem Framing.
This section sets the phases (2.1-2.3) against the framework’s three layers. A practitioner at any level can then locate the work they are doing, see what the same phase looks like at the layers above, and read what it requires of someone in a different position.
Scope, time-horizon, and mechanism change from one cell to the next. Scope, the size of what the phase is acting on, expands from a screen to a feature to a product area to a portfolio to an organisational year. Time-horizon, the span over which consequences play out, lengthens from a sprint to a release to a quarter to multiple years. Mechanism (how the phase actually happens) shifts from the practitioner’s own hands, to other designers’ hands, to the systems and standards under which any designer works, to the conditions in which decisions even get made.
The phases are properties of the work itself (2.1), so every cell applies at every level, whoever does it. A VP choosing which problems the team will work on is doing Problem Framing, the same phase as the Associate reading a brief, at the scope, time-horizon, and mechanism the role allows. A few labels in the cells below are defined in later chapters: the three forces of User need, Viability, and Feasibility (Chapter 1), the Precision intersection (6.3), and the management domains (Chapter 12). Read them here as pointers to what those chapters develop.
2.4 — The work across the layers how the three phases meet the three layers of the framework · H3