Problem Definition and Framing Questions

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

Ship the web version on the six-week timeline as planned, and for mobile, ship the smallest set of changes that avoids leaving the two platforms visibly and confusingly inconsistent, deferring the full redesign to a follow-up phase. The problem statement makes the trade-off explicit rather than silent: "we are prioritizing a complete redesign on web within the six-week window, and a scoped-down update on mobile to avoid inconsistency, with the full mobile redesign following in phase two, because engineering capacity does not support both platforms simultaneously in this window."

Structured elaboration

Scope boundaries: define explicitly what mobile gets in this phase (the same underlying search logic and results ranking as web, but not the new visual layout) and what it doesn't (the redesigned card layout, the new filtering interface), so engineering, design, and stakeholders share the same understanding of what's actually shipping on each platform.

Phased delivery approach: web ships the full redesign on schedule; mobile ships a minimal-viable-change version, updated results data and ranking behind the existing mobile layout, in the same window, with the mobile visual redesign following as an explicitly scheduled phase two rather than an open-ended "later."

Risks: users switching between web and mobile may notice the visual inconsistency during the gap between phases, which is a real but bounded cost, worth naming explicitly rather than discovering through user complaints; and phase two needs a committed timeline and owner, or "we'll get to it" phases have a well-documented tendency to slip indefinitely once the pressure of the original deadline is gone.

Worked example

The problem statement communicated to stakeholders: "Web search results redesign ships on the original six-week date. Mobile ships the same underlying search improvements (data and ranking) within the same window, on the existing visual layout, with the mobile visual redesign following in phase two, targeted for [specific date] and owned by [specific person]. This avoids either delaying the entire launch to accommodate mobile engineering capacity, or shipping a visually inconsistent experience with no plan to resolve it." Naming a phase-two date and owner up front is what prevents "phase two" from becoming a phase that never happens.

The same scope-boundary discipline applies to a "quick" UI update that can't touch the backend data model (a checklist of what must be clarified up front: which fields are display-only versus backend-dependent, what trade-offs a display-only fix accepts) and to a legacy design-system migration spanning 200-plus component variants (a phased migration with a rollback strategy and acceptance criteria defined per phase, not just at the end).

Trade-offs and pitfalls

The main risk in this kind of phased approach is that phase two loses priority once the phase-one pressure is gone and a new deadline arrives for something else; committing to a specific date and owner for phase two at the same time you commit to phase one is what protects against that, though it isn't a guarantee. The other pitfall is defining the phase-one mobile scope too narrowly to be worth shipping at all, in which case the better call might be a short, explicit delay on mobile alone rather than a phase-one release so minimal it doesn't move any of the metrics the redesign was meant to improve.

Direct answer

Problem statement: "Users abandon the checkout flow at a rate we believe is avoidable, driven by unclear pricing or an overly long form; we want to identify the dominant cause and reduce abandonment within one quarter." Then three research questions, ranked by how much uncertainty each removes, and two experiments that test the two most likely causes cheaply before committing to a redesign.

Structured elaboration

Turning "make checkout less confusing" into something actionable means resisting the urge to start sketching a new flow and instead doing three things in order:

1. State the problem without naming the fix. "Confusing" is a symptom description from whoever gave you the brief, not a diagnosis. The statement should capture the business impact (checkout abandonment, cart-to-purchase drop-off) without assuming the cause is visual clutter, form length, or anything else specific.
2. Rank the highest-uncertainty questions. Three that reduce the most uncertainty for the least effort: (a) where in the funnel do users actually drop, step by step, not just "checkout" as a whole; (b) do session recordings or support tickets show a specific point of friction (an unexpected shipping cost, a validation error, a confusing field); (c) has anything changed recently (a redesign, a new payment provider, a pricing change) that correlates with the drop, which would point to a regression rather than a long-standing usability gap.
3. Design experiments that isolate one variable each. Confirming the top hypothesis before building the full redesign avoids spending a sprint on the wrong fix.

Worked example

If step-by-step funnel data (question 1) shows the drop concentrates at the shipping-cost step, and session recordings (question 2) show users repeatedly navigating back to the cart after seeing that price, the two experiments become: (1) show an estimated shipping cost earlier in the flow, on the cart page, and measure the change in step-to-step conversion at the shipping step specifically; (2) offer a lower-friction guest checkout for users who abandon at account creation, and measure whether abandonment at that specific step drops. Both experiments have one clearly measurable outcome each (conversion rate at a named step) rather than "conversion is better," which would leave you unable to tell which change caused any improvement.

The same three-part output, statement, research questions, experiments, holds regardless of who the ambiguous brief comes from: an engineering-reported inconsistency (three teams shipping visibly different versions of the same navigation component), a chief executive officer (CEO)-level ambiguous goal ("increase monetization from casual users," with no design specifics attached), and a product manager's (PM's) "improve discoverability" ask with no defined success metric all reduce to the identical framing move, only the domain changes.

Trade-offs and pitfalls

The trap in this kind of prompt is treating "less confusing" as license to redesign everything at once: a full redesign conflates multiple hypotheses, so even if overall conversion improves you cannot attribute the gain to any one change, and if it does not improve you have no idea which piece to revert. The second trap is skipping the funnel-breakdown question entirely and going straight to user interviews, which surface real but not necessarily representative friction points; pairing quantitative funnel data with qualitative signal is what keeps the research questions honest about what's actually costing conversion versus what's merely annoying.

Direct answer

Problem discovery is the work of understanding and confirming what's actually wrong and for whom, before anyone commits to how to fix it; solution delivery is building and shipping that fix. Jumping from a reported symptom straight into solution delivery skips the step where you'd have caught that the symptom had a different cause than assumed, and the cost of that mistake is a shipped feature that doesn't move the metric.

Structured elaboration

The two phases answer different questions and use different tools. Discovery asks: is this real, who does it affect, and what's actually causing it, using tools like funnel analysis, session recordings, interviews, and support-ticket review. Delivery asks: given a confirmed cause, what's the best way to address it, using tools like prototyping, engineering estimation, and design iteration. A team that conflates the two ends up debating solution details ("should the button be blue or green") for a problem whose existence hasn't even been confirmed with data.

Worked example

A stakeholder reports "our search feature isn't good enough, we should invest in better relevance ranking." Jumping straight to solution delivery means starting a multi-quarter ranking-model project on the stakeholder's assumption alone. Reframing to discovery first: pull search-abandonment and zero-result-rate data (is search actually underperforming, and by how much, compared to what baseline), segment by query type (is the issue concentrated in a specific category, like long-tail queries, rather than search broadly), and review a sample of failed searches to see whether the pattern is a relevance-ranking issue at all, or something narrower, like a specific product category having thin catalog coverage. If the data shows the "bad search" complaints concentrate on one under-stocked category, the actual fix is a catalog gap, not a ranking-model investment, an outcome the discovery step surfaces and the jump-to-solution path would have missed entirely, at the cost of a much larger, misdirected engineering investment.

Trade-offs and pitfalls

Discovery isn't free: it takes time, and on a genuinely well-understood, previously-validated problem, re-running discovery from scratch every time is wasteful. The judgment call is proportional to how confident you already are that you understand the cause, and how expensive and reversible the proposed solution is: a multi-quarter model investment warrants discovery; a one-day copy change that's trivial to revert may not. The opposite failure, treating every request as needing full discovery regardless of stakes, reads as obstruction rather than rigor and burns trust with stakeholders who have a genuinely well-scoped, low-risk request.

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.