Problem Definition and Framing Questions

Direct answer

Ordered by risk reduction per unit of effort: (1) whatever data you already have access to, since it costs nothing new to check; (2) the single most consequential unknown, the one that would most change your recommendation if it came back differently; (3) whether anyone else has already solved or investigated something similar; (4) a quick, low-cost check on your leading hypothesis; (5) a broader validation pass only if the first four still leave real uncertainty.

Structured elaboration

1. Existing data first: before requesting anything new, check what's already available, dashboards, logs, past analyses, since this is the cheapest possible information and often resolves more uncertainty than expected before you've spent any new effort.

2. The single most consequential unknown: identify which specific unknown, if resolved, would most change your recommendation; investigating a fact that wouldn't actually change your decision either way is low-value regardless of how easy it is to check, so this step comes before anything else that isn't free.

3. Prior work: check whether the organization has already investigated something adjacent, an old analysis, a past experiment, a team that hit a similar question; this can save the entire remaining investigation if a close-enough answer already exists somewhere.

4. A quick check on the leading hypothesis: once you have a working theory from steps 1 to 3, a cheap, fast test (not a full experiment) that would meaningfully update your confidence, before committing more time.

5. Broader validation, only if still needed: a fuller investigation, additional data collection, a proper experiment, reserved for genuine remaining uncertainty after the first four steps, rather than the default starting point.

The ordering logic is strictly about return on a scarce resource, time: each step is ordered from lowest-cost, highest-value first, so that if you run out of time at any point, you've captured the highest-value information available at that cost level rather than partway through a more expensive step that hadn't yet paid off.

Worked example

Given limited time to recommend whether a reported "users can't find the export button" complaint is worth fixing: step 1, existing analytics already show the export feature's click rate over the past month, no new pull required; step 2, the most consequential unknown is whether this is a genuinely common complaint or one vocal user, so that's the priority to resolve, not (for instance) exactly how many pixels the button should move; step 3, a quick search finds a similar complaint was investigated eight months ago and traced to a specific onboarding cohort, which narrows where to look now; step 4, a fast query segmenting current click rate by that same cohort; step 5, a broader usability study only if the segmented data still leaves the picture unclear.

Trade-offs and pitfalls

This ordering assumes you can correctly judge, at step 2, which unknown is genuinely the most consequential; misjudging that (chasing an easy-to-check but low-impact question first) undermines the whole point of the ordering, so it's worth deliberately pausing on step 2 rather than rushing past it to the checks that feel more concrete. The other pitfall is skipping step 3 (checking for prior work) because searching for it feels like it takes effort, when it's often the fastest way to shortcut the rest of the list entirely.

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

State it as: "Among users who signed up by email in the past 14 days, onboarding completion fell from 80% to 60% after the new onboarding flow shipped; we want completion back above 80% within [N] weeks, measured as sessions that reach the 'setup complete' event." That single sentence names the target user, the current state, the desired state, a timeframe, and the metric that will tell you when the problem is solved.

Structured elaboration

A well-formed problem statement carries five load-bearing parts, and a statement missing any one of them invites the wrong kind of solution:

1. Target user - not "users" in general, but the specific segment the data is about (email sign-ups in the last 14 days, not all users). Naming the wrong segment sends the team investigating a population that was never affected.
2. Current state - the measured baseline, with enough specificity to be re-derived by someone else (80% completion, this cohort, this date range).
3. Desired state - what "fixed" looks like, ideally the prior baseline unless there is a reason to target something else.
4. Timeframe - both the window the drop was observed over and the window you're giving yourself to fix it. Without a fix-by timeframe, "reduce this" never gets prioritized against other work.
5. Metric - the exact signal you'll watch, defined precisely enough that two people computing it independently get the same number.

Two things a problem statement should NOT do: it should not name a cause ("completion fell because the new flow is confusing") and it should not name a solution ("we need to simplify onboarding"). Both foreclose investigation before it starts. The statement's job is to make the gap undeniable and measurable, not to explain it.

Worked example

Given the scenario: baseline is 80%, current is 60%, a 20 percentage-point drop, among the email-signup cohort, in the 14 days since the new flow shipped. The statement: "Onboarding completion among email-signup users has fallen from 80% to 60% in the 14 days since the new onboarding flow launched; we want to recover to at least 80% within 3 weeks, measured as the share of that cohort reaching the account-setup-complete event within 24 hours of signup." Note what's absent: no claim about WHY it dropped (a new step added friction, a bug, a segment mix shift) and no proposed fix. Those come after this statement, once investigation starts.

The same five components (target user, current state, desired state, timeframe, metric) transfer directly whether the trigger is a product metric, a data-science churn model, or a machine-learning (ML) launch: an ML repeat-purchase-drop variant of this exact scenario needs the identical five parts, just with an ML-specific metric (a model's tracked outcome) standing in for the product metric.

Trade-offs and pitfalls

The most common failure is writing a statement that is really a solution in disguise ("we need to add a progress bar to onboarding"), which locks the team onto one hypothesis before anyone has checked whether it's the right one. The second most common failure is omitting the timeframe: a problem statement without a "by when" for the desired state reads as aspirational rather than actionable, and competes poorly against work that does have a deadline. A statement that is too broad ("improve onboarding") fails the same test as no statement at all: it can't be disproven, so nobody can ever confirm it's solved.

Direct answer

The original statement, "our homepage isn't converting enough, we need to make it better and align it with brand standards," is missing a baseline, a target, a specific user segment, a timeframe, and it smuggles in a solution ("align with brand standards") without establishing that brand misalignment is actually the cause. Rewritten: "Homepage-to-signup conversion for new visitors is currently 2.1%, below the 3.5% benchmark from comparable landing pages on this site; we want to close that gap within one quarter, measured as signup conversion rate for new (non-returning) visitors to the homepage."

Structured elaboration

What's missing from the original, specifically: No baseline ("isn't converting enough" compared to what?). No target ("make it better" by how much?). No named segment (all homepage visitors, or a specific subset?). No timeframe (by when?). An embedded, unverified solution ("align it with brand standards" assumes the cause is a branding mismatch, which hasn't been established by any evidence in the original statement).

The rewrite fixes each gap: it states a real baseline (2.1%) against a real comparison point (3.5% benchmark from comparable pages, which grounds "not converting enough" in an actual number instead of a feeling), a target and timeframe (close the gap within one quarter), a specific segment (new visitors, since returning visitors' conversion behavior is a different problem), and it removes the embedded solution entirely, leaving the cause open for investigation.

Worked example

Acceptance criteria that follow from the rewritten statement: (1) new-visitor signup conversion reaches at least 3.0% within the quarter, (2) the change does not reduce conversion for returning visitors by more than 0.5 points (a guardrail, since a homepage change optimized for new visitors could inadvertently hurt the experience for returning ones), (3) the fix ships with before-and-after data attributing the change specifically to the homepage modification, not a concurrent marketing campaign or seasonal effect. These are concrete pass-or-fail checks the original vague statement could never have produced.

Trade-offs and pitfalls

Rewriting a stakeholder's statement risks reading as a rebuke of their original framing, particularly when it came from someone senior; it helps to frame the rewrite as "here's how I'd operationalize what you're describing so we can measure whether we've fixed it," which credits the underlying concern while fixing what's missing. The pitfall in the rewrite itself is inventing a specific baseline number without actually pulling it from data; if the real baseline isn't known yet, the honest version of the rewrite states that measuring the baseline is the first concrete step, rather than presenting an invented number as though it were established fact.

Direct answer

A high-quality problem statement names the specific target user, states the current measured condition, states the desired condition, gives a timeframe, and specifies the metric that will confirm the gap is closed. Leaving any one of these out is what turns "we should fix onboarding" into an unactionable slogan instead of a scoped, testable problem.

Structured elaboration

Walking through why each part earns its place:

• Target user: without a named segment, "users are dropping off" could mean everyone or one small cohort, and those two situations call for completely different investigations.
• Current vs desired state: this is the gap the rest of the process exists to close. Stated as two numbers (or two qualitative states with a clear boundary between them), it gives the team a shared definition of "done" before anyone proposes how to get there.
• Timeframe: both the window the current state was observed over, and the window given to close the gap. A statement with no fix-by date competes poorly for prioritization against work that has one.
• Metric: precise enough that two people computing it independently land on the same number. A metric like "engagement" without a computation rule invites disagreement later about whether the fix worked.

A statement that includes all four but is still too broad ("increase engagement, ever, by some amount") fails a different test: it can't be disproven, so nobody can ever say with confidence that it's been solved.

Worked example

For the scenario given: "Among users who received the design update, monthly active users (MAU, the count of distinct users active at least once in a 30-day window) dropped 12% in the 30 days after the update shipped. We want MAU for this cohort back to its pre-update baseline within 6 weeks, measured as the 30-day rolling MAU count for users on the updated design." That single sentence is specific enough that a different analyst, handed only the sentence, could pull the same number from the event logs.

The same components apply to a one-paragraph ML problem statement written for a product requirements document (PRD): target user, current versus desired state, and constraints carry over unchanged, with one addition, an ML problem statement should also name the evaluation metric and baseline the model will be judged against, since "success" for a model is otherwise undefined.

Trade-offs and pitfalls

The most common failure mode is a statement that smuggles in a cause or a solution ("MAU dropped because the new layout hides the main action, so we should revert it"), which shuts down investigation before it starts by presenting an unverified theory as settled fact. The second is treating this as a one-time exercise: the components matter because they are testable, not because they're a checklist to fill in once and never revisit if new evidence emerges during discovery.