Problem Definition and Framing Questions

Direct answer

Budget, timeline, technical dependencies, legal or privacy requirements, and data quality or accessibility are the five categories worth checking on nearly every problem; each one, left unstated, tends to surface late and expensively rather than early and cheaply.

Structured elaboration

Budget: a fixed engineering or research budget changes the ambition level of the acceptable solution; a problem framed without it invites a proposal that's infeasible before anyone realizes it.

Timeline: whether there's a hard external deadline (a contractual commitment, a regulatory date) versus a soft internal target changes how much discovery is worth doing before committing to a direction.

Technical dependencies: constraints like "can't change the backend data model" or "must work within the existing authentication system" bound the solution space before design work starts; discovering them mid-build is expensive.

Legal or privacy: requirements like data-residency rules or consent requirements can eliminate entire categories of otherwise-reasonable solutions, and they're the category most likely to be assumed away by a team without direct legal expertise.

Data quality or accessibility: whether the data needed to measure success or diagnose the problem actually exists, and at what quality, determines whether an experiment-based approach is even possible, or whether you're starting from a smaller, more manual signal.

Worked example

Framing a project to "reduce fraud losses on the platform": surfacing budget (a fixed quarter of engineering capacity) changes the solution from a from-scratch machine-learning model to an incremental rules-based improvement to the existing system; surfacing legal (regulatory reporting requirements for declined transactions in certain jurisdictions) means any new decisioning logic needs an audit trail, which is easy to omit from a design that didn't ask this question up front; surfacing data quality (the labels for "confirmed fraud" are only reliable going back 6 months due to a past data-pipeline change) bounds how much historical data a model-based approach could actually train on, changing the realistic scope of what's achievable in the given timeline.

Two design-audience versions of this same checklist ask for an identical answer with different framing language ("what constraints should you record when framing a UX problem" and "list common constraints surfaced during problem framing for UI work"), confirming the checklist itself, not its phrasing, is the tested content.

Trade-offs and pitfalls

Surfacing every constraint category on every problem, exhaustively, before any work starts adds real overhead, and for a small, well-understood problem it's disproportionate; the categories are a checklist to consult, not a mandatory five-section document for every request. The bigger risk is the opposite: skipping legal or data-quality checks specifically, because they require pulling in someone outside the immediate team, is the most common way a project discovers a blocking constraint late, after design or even engineering work has started.

Direct answer

A request is ambiguous when it lacks at least one of: a defined target user, a measurable success criterion, or a stated constraint, such that two reasonable people could act on it in genuinely different, mutually exclusive ways. The tell isn't that the request is short or informal, it's that filling in the missing piece changes what "success" would even mean.

Structured elaboration

Three concrete symptoms that mark a request as ambiguous:

1. No named user or segment. "Improve engagement" doesn't say whose engagement; power users, first-time users, and lapsed users would each call for a different intervention, and picking the wrong one wastes the work.
2. No measurable success criterion. "Make it better" has no metric attached, so there's no way to know when to stop or whether an attempted fix worked.
3. Unstated constraints. A request that doesn't mention timeline, budget, or technical boundaries invites a scope that later turns out to be infeasible, after work has already started.

Two lightweight moves to reduce ambiguity immediately, before engaging engineering or design: (1) restate the request back with your best-guess assumptions filled in explicitly ("when you say improve engagement, do you mean daily active users, or session length, for which segment, by when?") so the requester can confirm or correct in thirty seconds rather than a full discovery meeting; (2) check whether the request maps to an existing, already-scoped problem statement or metric definition the team has used before, which often resolves the ambiguity without needing to ask anyone anything.

Worked example

"Improve dashboard performance," handed over with nothing else, is ambiguous on all three counts: no named user (all dashboard users? enterprise accounts specifically?), no metric (load time? query latency? perceived responsiveness?), no constraint (by when, with what engineering budget). Restating it with assumptions filled in: "I'm assuming you mean p95 page-load time for the main analytics dashboard, currently at 4.2 seconds, targeting under 2 seconds within the quarter, is that right?" turns a request that could be interpreted five different ways into one the requester can confirm or correct in one sentence.

Trade-offs and pitfalls

Asking too many clarifying questions can read as stalling rather than diagnosing, especially with a requester who expects a fast turnaround; the restate-with-assumptions move is usually faster than a list of open questions because it lets the requester correct a specific guess rather than generate the specification from scratch. The opposite failure, proceeding on an ambiguous request without resolving any of it, risks building the wrong thing entirely and discovering the mismatch only at review.

Direct answer

Each complaint becomes a hypothesis with a metric and a cheap test attached: "search is too slow" becomes "search latency above [X] seconds causes users to abandon the search results page," measured by search-abandonment rate segmented by response time, tested by adding latency instrumentation and checking whether abandonment correlates with slow responses. The other two complaints follow the same pattern: state what you believe is causing the friction, name the metric that would confirm it, and propose the smallest test that would tell you if you're right.

Structured elaboration

The general move for each complaint: (1) name the specific, falsifiable claim behind the vague complaint, (2) attach a metric that would move if the hypothesis is true, (3) propose the cheapest experiment or data pull that would confirm or reject it before committing to a fix.

"Search is too slow": hypothesis, search response times above some threshold cause users to abandon before results load; metric, search-abandonment rate, segmented by measured response time; test, instrument response-time logging if not already present, then check whether abandonment correlates with slower responses (this is an observational check, not an experiment, and it's the cheapest first step).

"Onboarding is confusing": hypothesis, a specific step in the flow (not the whole flow) is where users get stuck or drop off; metric, step-by-step completion rate through onboarding; test, look at the funnel breakdown to find the specific step with the steepest drop, then run a small number of moderated usability sessions on just that step.

"We need saved filters": hypothesis, users are repeating the same filter combinations across sessions, indicating a real recurring need rather than a one-off preference; metric, rate of users applying the same filter set in 3 or more separate sessions; test, check existing session logs for repeated filter patterns before building anything, which validates or invalidates the request with data that already exists.

Worked example

For the saved-filters complaint, checking existing logs (no new instrumentation required) for users who apply the same 2 or more filter criteria across 3+ distinct sessions gives a concrete answer before any engineering time is spent: if that rate is high, the feature request reflects a real recurring pattern; if it's low, the request may reflect one vocal user rather than a broad need, and a cheaper interim fix (remembering the last-used filter for that session only) might suffice instead.

Trade-offs and pitfalls

The trap is treating the complaint's stated cause as already confirmed ("onboarding is confusing" becomes "we need to redesign onboarding") rather than testing it first; a complaint is a hypothesis about the user's experience, not a verified diagnosis. A second trap is picking a metric too broad to isolate the effect (overall conversion rate, rather than the step-specific completion rate for onboarding), which makes it impossible to tell whether a later fix actually addressed the reported friction.

Direct answer

For a designer, problem definition and framing means establishing, before any screens get sketched, exactly who is affected, what is currently happening, what "better" would look like, and how you'll know when you've gotten there. The goal is to make the team's shared understanding of the problem explicit and checkable, rather than letting each person carry a different unstated assumption into the design review.

Structured elaboration

The discipline produces a small set of concrete artifacts, not just a mental model: a written problem statement (who, current state, desired state, timeframe, metric), a short list of prioritized hypotheses about what's driving the gap, the success metrics that will confirm a fix worked, and acceptance criteria, meaning the specific pass or fail checks a proposed change must clear before it ships. These are lightweight, often a paragraph and a bulleted list, but writing them down (rather than keeping them as shared assumptions) is what lets a team catch disagreement before it costs a sprint of design work.

Postponing solutions until after this framing matters because the first plausible-looking fix is rarely the best one, and it is much cheaper to be wrong about a sentence on a page than about a shipped redesign. A designer who frames first is also better positioned to push back when a stakeholder arrives with a solution already attached ("just add a carousel"): the framing step gives you the vocabulary to ask what problem that carousel is meant to solve, rather than either building it uncritically or rejecting it without a reason the stakeholder will accept.

Worked example

A well-formed problem statement in this discipline: "New users who complete account setup in under 2 minutes retain at 3x the rate of users who take longer than 5 minutes; setup currently takes a median of 6 minutes. We want median setup time under 3 minutes within one quarter, measured as time from account-creation-start to setup-complete event." This names the user, the current and desired states, a timeframe, and a metric, without saying anything yet about what the setup flow should look like.

A concrete instance of this same discipline: "Checkout abandons at 38%, well above the 22% baseline for comparable flows; the evidence is a session-replay review, the impact is estimated by multiplying the affected monthly session volume by the abandonment-rate gap and the average order value (a concrete formula, not a bare figure), and the constraint is a two-sprint budget" names the situation, evidence, impact, and constraints in one breath, the same components this broader framing discipline exists to produce.

Trade-offs and pitfalls

The risk of over-investing in this step is real: an experienced designer can spend so long framing that discovery itself becomes the bottleneck, especially on a low-stakes change where a quick prototype would answer the question faster than more analysis. The right calibration is proportional to reversibility and cost: frame carefully before a redesign that will take a quarter to build and is hard to undo; frame lightly, in a sentence, before a change you could ship and revert in a day.

Direct answer

"Existing business-to-business (B2B) customers on the mid-market tier, with a 6-month sales cycle, are churning at a rate that jeopardizes the annual-contract renewal base; we want to identify the dominant driver and reduce churn within two quarters." From there: stakeholders are sales (for renewal and expansion context), customer success (for account-health signal), and finance (for the retention-versus-acquisition trade-off); likely root causes to test are onboarding time-to-value, a competitor feature gap, and support responsiveness; experiments and constraints follow from which of those the data actually points to.

Structured elaboration

Stakeholders: customer success owns the account-health and usage data and the closest relationship with churning accounts; sales owns the renewal-cycle timeline and competitive intelligence from lost deals; finance owns the retention-versus-acquisition cost trade-off, since a B2B (business-to-business) product with a 6-month sales cycle makes new-customer acquisition expensive relative to retaining an existing account.

Hypothesized root causes, in the order cheapest to check: (1) slow time-to-value, meaning accounts that take longer to reach a defined "activated" milestone churn more, checkable against existing account data without new instrumentation; (2) a specific competitor feature gap, checkable against sales' loss-reason notes from recent renewal conversations; (3) support responsiveness, checkable against existing ticket-resolution-time data correlated with churned versus retained accounts.

Experiments, one per surviving hypothesis after the cheap checks above narrow the field: if time-to-value is implicated, a guided-onboarding pilot for new accounts, measuring whether faster time-to-value correlates with lower churn in the next renewal cohort; if the feature gap is implicated, that becomes a roadmap input rather than an experiment, since building a feature isn't something you A/B test before committing resources; if support responsiveness is implicated, a pilot with a dedicated response-time service-level agreement (SLA) for accounts flagged at churn risk, measuring whether faster response correlates with retention.

Constraints: a 6-month sales cycle means any fix aimed at NEW accounts won't show up in the churn numbers for two quarters at the earliest, so this problem needs both a near-term mitigation for at-risk existing accounts and a longer-term structural fix.

Trade-off: acquiring a new mid-market account costs meaningfully more, in sales cycle length alone, than retaining an existing one, which is the argument for weighting investigation and mitigation toward the churn side even if a parallel acquisition push looks more immediately visible to leadership.

Worked example

If the loss-reason review (cheap check 2) shows 60% of lost-deal notes from the past two quarters cite a specific missing integration a competitor offers, that's a stronger, more specific signal than a vague "we're losing to competition," and it turns the roadmap conversation into a concrete build-or-don't decision rather than an open-ended investigation.

A structurally similar problem, framed cross-functionally rather than as a churn diagnosis, is leading discovery for international expansion: the same discipline applies, identify the likely user segments in the new market, name the local constraints (payment methods, localization, legal and regulatory requirements), specify what data would confirm product-market fit there, and propose a phased, single-region pilot with its own measurement plan before a full-market commitment.

Trade-offs and pitfalls

The main risk in a churn problem like this is treating it as a single root cause when B2B churn is frequently multi-causal: a real fix might require addressing time-to-value AND a competitive gap simultaneously, and stopping investigation after confirming the first plausible cause risks leaving a second, equally real cause unaddressed. The six-month sales cycle constraint is easy to overlook when a fix "feels" urgent; without accounting for it, leadership may expect churn numbers to move faster than the sales-cycle math allows.