Problem Framing in Design

Definition

Designers actively reframe design briefs from personal and distinctive perspectives, transforming the "problem as given" into a problem frame that stimulates and pre-structures solution emergence. This is not a search for the optimal solution to a pre-defined problem, but an exploratory process where the designer's frame of reference shapes what solutions become possible.

In the Book

Cross documents this through case studies of expert designers. Kenneth Grange, designing a sewing machine, approached the brief from his personal distaste for "contradictions" in design—where products are poorly adapted to use. Rather than accepting the client's brief for a simple restyling, he reframed the problem around usability and user pleasure: "My attitude is to want it to be a pleasure to operate." This frame led to an entirely different conceptual approach with asymmetrical layout and rounded edges, emerging from his experience of actually operating the machine.

Similarly, Gordon Murray, designing the Formula One suspension system, framed the problem not as "improve the suspension" but as "How the hell can we get ground effect back?" while satisfying regulations. This distinctive problem frame led him directly to the concept of a hydro-pneumatic suspension system. In the city car design, Murray's frame centered on creating an efficient, lightweight vehicle through radical manufacturing innovation, which cascaded into solutions at every level of detail—from the three-part suspension to the single opening canopy. Cross notes that "their problem framing arises from the requirements of the particular design situation, but is strongly influenced by their personal motivations."

Why It Matters

Problem framing is where designer agency enters most clearly. Rather than being problem-solvers executing a specification, designers are problem-definers. Understanding this reframe mechanism reveals why two designers given the same brief can arrive at fundamentally different solutions—not from different technical competence, but from different problem frames. This transfers to any domain where you inherit a "problem as stated" but the real leverage lies in redefining what problem you're actually solving.