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

A problem is ready to move into prototyping once you have a validated assumption or two (not just an untested belief), at least one prioritized, testable hypothesis about the cause or the opportunity, and rough alignment among the key stakeholders on what success looks like; missing any of these, more discovery is worth the time before design work starts.

Structured elaboration

Validated assumptions: at least the riskiest assumption underlying the effort has been checked against some real evidence, even lightweight evidence (a quick data pull, a handful of interviews), rather than resting entirely on belief. Moving to prototyping on an unvalidated assumption risks building against a premise that turns out to be false.

Prioritized hypotheses: a ranked, not just listed, set of candidate causes or directions, with the top one identified as the leading candidate to prototype against; a flat list with no prioritization signals discovery hasn't actually converged on a direction yet.

Stakeholder alignment: the people who'll evaluate the prototype (engineering, for feasibility; whoever approves the eventual launch) roughly agree on what the problem is and what success would look like, even if they don't yet agree on the solution; misalignment here, discovered only after a prototype exists, is expensive to unwind.

Worked example, login-flow redesign: (1) Validated assumption: session-replay review of 30 failed login attempts confirmed users are abandoning specifically at the password-reset step, not elsewhere in the flow, checked against actual data rather than assumed from a single complaint. (2) Prioritized hypothesis: the leading candidate is that the reset-confirmation email takes over 5 minutes to arrive for a meaningful share of users, checked against email-delivery logs, ranked above a secondary hypothesis (confusing reset-form copy) because the data more strongly supports it. (3) Stakeholder alignment: both the engineering lead (who'll assess email-delivery-speed feasibility), and the product manager, have confirmed "reduce password-reset abandonment" as the target outcome, even though the specific fix isn't decided yet.

Trade-offs and pitfalls

Waiting for full certainty on all three criteria before ever prototyping can itself become a stalling pattern, particularly on a low-stakes, easily-reversible change where a quick prototype would actually resolve remaining uncertainty faster than more upfront discovery; the criteria are meant to catch problems that are clearly underspecified, not to demand perfect confidence before any building starts. The opposite pitfall, moving to prototyping with none of the three in place because of schedule pressure, tends to produce a prototype that tests the wrong thing, wasting the time it was meant to save.

Direct answer

Rather than building the dashboard as specified, lead with a short discovery conversation aimed at one question: what decision are you trying to make, and how would you make it differently depending on what the data shows? A request "for visibility" almost always has a real decision hiding behind it, and surfacing that decision usually reveals a narrower, faster deliverable than a full dashboard.

Structured elaboration

The questions to ask, in order: (1) "What decision would you make differently if you had this data, versus if you didn't?" This is the single most important question, because if there's no clear answer, the request may genuinely be for situational awareness rather than a decision, which changes what "done" looks like. (2) "How often would you check this, and what would trigger you to act on what you see?" This distinguishes a need for a live dashboard from a need for a periodic report or even a one-time analysis. (3) "What's the smallest version of this that would already tell you something useful?" This surfaces whether a full dashboard is actually needed or whether a single number, refreshed weekly, would answer the underlying question.

If the VP's (vice president's) answers reveal a genuine, recurring decision (say, "I need to know weekly whether to reallocate budget between two initiatives based on their relative performance"), the request reframes into a much narrower, well-scoped deliverable, two specific metrics compared side by side, rather than an open-ended dashboard. If the answers reveal no specific decision, the honest reframe is proposing a lighter-weight alternative, such as a monthly summary email, and explaining why: building a full interactive dashboard for situational awareness alone is a larger and more expensive commitment (both to build and to maintain) than the underlying need justifies.

Worked example

Discovery timeline: a 30-minute conversation using the three questions above, followed by a one-page problem statement circulated back to the VP for confirmation before any build work starts ("I understand the need is: decide weekly whether to reallocate budget between initiative A and B, based on their relative cost-per-acquisition; is that right?"), rather than starting a multi-week dashboard build on the original vague request.

The identical three-step move, surface the actual intent, propose evidence to test the assumption, offer a non-dismissive path forward, applies just as well to a peer stakeholder as to a VP: when a stakeholder insists "users want a carousel on the homepage because competitors use it," the same sequence surfaces what problem the carousel is meant to solve, proposes a cheap way to test whether that problem is real, and avoids either building the carousel uncritically or dismissing the idea outright.

Trade-offs and pitfalls

Pushing back on a VP-level request "for visibility" carries real political risk if handled poorly: framing it as "I don't think you need this" reads as dismissive, while framing it as "help me understand the decision this supports, so I build the right thing the first time" reads as diligence. The pitfall to avoid is building the originally-requested dashboard anyway to avoid the conversation; that path optimizes for avoiding short-term friction at the cost of shipping something that may not get used, which is a worse outcome for both the requester and the team that built it.

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

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.