Design Question

Origin & evolution

The dominant framing, "How Might We", traces to Min Basadur, who carried it into design from creative-problem-solving research. As a manager at Procter & Gamble in the early 1970s, Basadur watched a team stuck on "how can we make a better green-stripe soap?" to rival Colgate's Irish Spring, and reframed the question as "how might we create a more refreshing soap of our own?" Moving from a fixed solution to an open one broke the deadlock. Basadur built on Alex Osborn and Sidney Parnes, whose creative-problem-solving process had long used questioning to widen a search before narrowing it.

The framing spread through a clear chain of people. It passed from Basadur to Charles Warren, who took it to IDEO and its leader Tim Brown; IDEO made starting every project with How Might We questions a house habit, and Warren later carried it to Google. Tim Brown described the technique in Change by Design (2009) as the way to turn a problem into a design challenge.

How Might We is the most famous framing, and it is not the only one. Practitioners also work in "What if" questions to provoke speculative answers, "Why do" questions to interrogate a behaviour's cause, and "What prevents" questions to surface blockers. Treating the design question as the general category, with these as its templates, keeps the technique honest about what it is doing: opening a search. The Nielsen Norman Group reads the value as sitting entirely in the scoping. A question pitched at the right altitude reframes a constraint🔒ConstraintStrategyA constraint entityView reference → into an opening; pitched wrong it either dictates the answer or hovers uselessly above any situation a team can act on.

How it works in practice

A research study🧑‍🔬Research StudyUser ResearchA planned research activityView reference → surfaces an insight🔦InsightUser ResearchA synthesised finding from researchView reference →: experienced users abandon guided onboarding because they read it as condescending. Stated as a complaint, "users hate our tutorial🧑‍🏫TutorialCustomer EducationA step-by-step tutorialView reference →", it invites defensiveness. Reframed too narrowly, "how might we let users skip the tutorial?", it has already chosen the answer. The team pitches it in the middle: "how might we let confident users prove themselves without slowing down the ones who need🫀NeedUserA user need, pain, desire, or constraintView reference → help?" That question is open enough to admit several answers, an adaptive flow, a skip-to-workspace escape, a difficulty self-select, and tight enough that each answer is testable. A session against it produces six concepts; two become prototypes📱PrototypeExperience DesignAn interactive mockup for testingView reference →. The reframe did the work the brainstorm gets credit for.

Design question vs. its neighbours

• Need is what the user requires, stated from their side and closed. A design question reopens that need as a generative prompt for the team. "Confident users need to skip ahead" is a need; "how might we let confident users prove themselves without abandoning the ones who need help?" is the question that turns it into a brief a team can answer. The edge need_reframed_as_design_questionNeedreframed asDesign Questioncausal records that move.
• Design concept🌱Design ConceptExperience DesignA possible design direction or approachView reference → is a candidate answer; a design question is the prompt that invites several. The question precedes the concept, and one good question should produce more than one concept worth prototyping. The graph captures this as design_question_answered_by_design_conceptDesign Questionanswered byDesign Conceptcausal.
• Hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → opens nothing; it commits to one answer and predicts an outcome🏆OutcomeStrategyA desired business or user outcomeView reference →. A design question can carry a working hunch, and its job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → is to keep the search wide before any bet is placed.

In the graph

In the Unified Product Graph, design_question💭Design QuestionExperience DesignAn open design problem to explore is the canonical type, with how_might_we💭Design QuestionExperience DesignAn open design problem to explore as an alias, in the Experience, Design & Brand region's design domain. Its framing property enumerates the templates (how_might_we💭Design QuestionExperience DesignAn open design problem to explore, what_if, why_do, what_prevents), so the specific phrasing is first-class data rather than buried in prose. It surfaces from upstream evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → through insight_inspires_design_questionInsightinspiresDesign Questioncross-domain and need_reframed_as_design_questionNeedreframed asDesign Questioncausal, the structural claim that good questions come from findings, not whiteboard inspiration. It resolves forward through design_question_answered_by_design_conceptDesign Questionanswered byDesign Conceptcausal and design_question_resolved_by_decisionDesign Questionresolved byDecisioncausal, and its lifecycle, open to exploring to resolved or parked, enforces the field's own rule that a question left permanently open is a project that stalled.