Design Thinking and the End-to-End Design Process Questions

Direct answer

Five Whys is a chain of "why" questions that walks from an observed symptom to a plausible underlying cause. Used well on a metric like this, it turns "people cancel at two weeks" into a specific, testable hypothesis about what's missing in that window, rather than stopping at the first plausible-sounding answer.

Structured elaboration

• Each "why" should answer the previous statement directly, in one causal step, not jump levels or restate the symptom in different words.
• Five Whys produces a single causal chain, but real product problems usually have more than one cause. Treat the output as a hypothesis to confirm with data, not a verdict.
• Stop when you hit something the team can actually act on: a process, a design choice, a missing signal. Stopping at "users are impatient" isn't actionable; stopping at "onboarding doesn't get them to a specific moment of value" is.
• Anchor each "why" to an existing signal where possible (funnel data, support tickets, cancellation survey text) instead of pure speculation.

Worked example: subscription cancels around two weeks

1. Why do users cancel around two weeks in? Because that's roughly when the free-trial-to-paid charge posts, so it's the first moment they consciously re-evaluate the subscription.
2. Why does re-evaluating at that moment lead to canceling rather than continuing? Because by then they haven't yet done the thing the product is actually for, so there's nothing concrete to weigh against the charge.
3. Why haven't they done the core thing yet? Because the path from signup to that first meaningful use isn't sequenced. It's discoverable, but nothing in the product actively walks them there.
4. Why isn't it sequenced? Because onboarding was built to explain features, not to get one specific outcome achieved in the first session.
5. Why does onboarding optimize for feature explanation instead of a first outcome? Because it predates the current pricing model and was never revisited once the trial-to-paid moment became the point where users decide.

Plausible root cause: the two-week cancel spike lines up with the trial-to-paid charge, and users hit that decision point without having reached the product's core value yet, because onboarding teaches features rather than driving one outcome.

What to test to confirm it: this is a hypothesis until it's checked against data that already exists. Pull the cohort of users who canceled in the trial-to-paid window and check, from existing product analytics, whether they disproportionately had not completed the core activation event before canceling, compared against the completion rate for users who converted. If cancelers completed that event at a meaningfully lower rate, the hypothesis holds and the fix is an onboarding and activation problem. If completion rates look similar between the two groups, the chain above is wrong and the real driver is something else (price sensitivity, a specific broken feature, a competitor offer), which needs its own Five Whys starting from that data.

Trade-offs and pitfalls

• The biggest failure mode is stopping at the first answer that sounds right and happens to confirm what the team already believed. Force at least one alternate chain before committing to a root cause.
• Five Whys assumes one dominant cause. If the data check above shows activation completion isn't actually different between cancelers and converters, don't force the chain to still be true; that's a signal to start over from a different why.
• It's a synthesis tool for framing a hypothesis fast, not a substitute for confirming it. Shipping a fix based on the chain alone, without the data check, risks solving a plausible-sounding problem instead of the real one.

I would start by separating business symptoms from user needs.

First, I would gather:

• Funnel data. Where exactly do people abandon, for example shipping, payment, or review.
• Segment data. New vs returning users, mobile vs desktop, guest vs logged-in, payment method, geography.
• Support signals. Complaint themes, chat transcripts, refund reasons, and common screenshots.
• Qualitative evidence. Session replays, usability tests, and a few post-abandonment interviews.
• Constraint data. Shipping cost, taxes, inventory rules, latency, and any account or payment errors.

Then I would decide priority by asking: which issue affects the most users, which issue blocks completion, and which issue creates the most trust damage. A user need matters most when it is both frequent and severe. For example, if many users abandon because shipping costs appear late, that is a stronger first fix than a rare edge case in an advanced payment option. I would also check whether one problem masks another, like slow page load making an otherwise clear checkout look broken.

Situation: I was redesigning a sign-up flow for a consumer app, and my first concept put the main CTA front and center because I assumed speed was the biggest need.

Task: Usability testing showed the opposite. People were not hesitating because the button was hard to find. They were hesitating because they did not understand the options well enough to trust the choice.

Action: I reviewed the test notes, watched the sessions again, and pulled out three repeated moments of confusion. Then I changed the design to add short plain-language comparisons, clearer helper text, and a save-and-return path. A few teammates still preferred my original version, so I did not argue from opinion. I showed clips from the tests, explained the user goal in simple terms, and framed the change as reducing risk rather than just changing visuals.

Result: We launched the revised flow, and support feedback dropped around the confusing choice point. The biggest lesson for me was that research is valuable when it changes my mind, not when it confirms it.

Direct answer

A design brief comes first: written at kickoff, it captures the vague ask as business goals, audience, constraints, and success metrics, and directs the research and framing that follow. A problem statement comes next, once that research is in: it names precisely what is wrong and for whom, without proposing a solution. A How Might We question comes last, reframing that problem statement as an open, generative invitation for ideation. Each artifact narrows or reframes the one before it: the brief scopes the work, the problem statement precisely names the issue that work uncovered, and the HMW opens that issue back up for solution generation.

Structured elaboration

Moving from a vague ask to each of these is a narrowing and reframing exercise, not three unrelated documents. The path is: turn the vague ask into a design brief that scopes the work and sets constraints and success criteria, let that brief direct research until you can state the problem precisely, then open the problem back up briefly with an HMW to avoid jumping straight to one solution.

flowchart LR
    A[Vague ask] --> B[Design brief: scope, constraints, goals]
    B --> C[Research directed by brief]
    C --> D[Problem statement: precise, no solution]
    D --> E[How Might We: open, generative]

Worked example

Vague ask: "users are dropping out at the confirm step of a money transfer flow."

Design brief (first): For the money-transfer confirm step, where drop-off is visibly higher than at earlier steps: improve completion rate at that step without adding friction to the steps before it, within existing security and compliance constraints, and validate the leading concept with a moderated usability round before build. This scopes the investigation and sets what "done" looks like before research starts.

Problem statement (after research directed by the brief): Users attempting a money transfer abandon at the final confirmation screen at a noticeably higher rate than at earlier steps in the flow, and the confirmation screen is the last point before the transfer is irreversible.

How Might We (last): How might we give users enough confidence at the confirm step that they complete transfers they already intended to make?

Note what stayed constant across all three: none of them names a specific solution (a redesigned button, a new fee display). The brief sets direction and constraints up front, but it directs where to look, it does not prescribe the fix; the actual solution only emerges from ideation and testing after the HMW opens the space.

Trade-offs and pitfalls

A common mistake is treating the design brief as if it already contains the solution, which collapses the whole process before research even starts. A second is writing a "problem statement" that has already smuggled in a solution ("users need a clearer confirm button"), which quietly narrows the team's thinking before ideation even begins. A close third is an HMW so broad it fails to focus anything ("how might we improve money transfers") or so narrow it is really just a solution in disguise ("how might we add a progress bar"). Skipping the problem statement and jumping from a design brief straight to How Might We, or straight to a solution, is how teams end up building against assumptions instead of what the research actually found.

A vague brief means the real deliverable in the first couple weeks is not a design, it is a scoped problem statement and a measurable definition of success. I would spend the first days on quick stakeholder interviews and a pass through existing analytics to find where the actual pain is, then convert that into a one-page problem statement with a baseline metric and a target, signed off by the stakeholder before design work starts.

Scoping the effort

Ask before you assume

A short stakeholder-interview kit, five questions I would actually bring into the kickoff:

1. What made you decide this needs attention now? (surfaces the real trigger: a support escalation, a board metric, a competitor move)
2. What have you already tried, and what happened?
3. Who is affected: all users, or one segment?
4. What would "better" look like as a number, even a rough one?
5. What's the deadline, and is it fixed or negotiable?

Check the data before you accept the framing

Pull whatever telemetry already exists in parallel with the interviews, do not take the stakeholder's framing at face value. "Increase engagement in checkout" often turns out to mean something specific and measurable, like drop-off between shipping and payment, and instrumentation (the analytics/event-tracking code that records what users actually do in the product) can surface that in an afternoon instead of a week of interviews.

Diagnose root cause before you scope a fix

For a brief like "make checkout faster," resist jumping straight to UX changes. Faster could mean perceived latency (no loading state, no optimistic UI) or actual backend latency (a slow payment API call). Check timing data and a quick session replay (a recorded playback of a real user's on-screen actions) before committing to a scope, because the fix and the owning team differ in each case.

Turn answers into a problem statement

Template: "[Segment] struggle to [task] because [evidence-backed cause], costing [business metric]. Success is [target metric] within [timeframe]."

Communicate risk under time pressure

By the end of week one or early week two, bring stakeholders a short one-pager: the proposed problem statement, the baseline metric, and what is explicitly out of scope. Flag risk early: "the two-week estimate assumes X; if research surfaces Y, that pushes the target." That protects both the timeline and the credibility of whatever ships.

Worked example

Take the onboarding brief. A compressed plan: days 1 to 2, stakeholder interviews plus a kickoff to lock the five questions above; days 3 to 4, analytics review of the completion funnel; day 5, synthesis; end of week one, a draft problem statement circulated for pushback; week two, a handful of quick validation conversations, then the success criteria get finalized and signed off.

Say the funnel shows 1,000 users starting onboarding, 640 reaching step 2, and 410 completing step 3.

Both steps lose roughly a third of users, close enough that the problem statement should name both rather than picking one on instinct, and the success criteria should target the earlier step first since fixing it changes the denominator for everything after it.

Trade-offs and pitfalls

• Designing before a baseline exists means nobody can tell afterward whether the fix worked.
• Treating the stakeholder's word ("engagement") as the actual problem instead of re-deriving it from data is the single most common shortcut, and it is how teams solve the wrong thing well.
• Two weeks is not enough for full generative research; the goal is a defensible, falsifiable scope, not certainty. A senior candidate names what is still unknown and how the next phase will de-risk it, rather than pretending the scope is final.
• Staying quiet about emerging risk to protect the deadline is worse than surfacing it early; a stakeholder who hears about a bigger problem in week one can re-plan, one who hears about it at the deadline cannot.