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

Prioritization approach
I would first identify anything that blocks a user from completing the core task. Keyboard-only means someone navigates entirely with Tab, Enter, and arrow keys instead of a mouse. Low-vision users may need stronger contrast, larger text, or zoom support. If a control only works on hover, or if color is the only way to show status, that is a high-priority accessibility gap because it can prevent basic use.

What I fix first

1. Keyboard access to all essential actions.
2. Visible focus states so users can see where they are.
3. Replace color-only signals with text, icons, or patterns.
4. Then review hover content, tooltips, and visual polish.

Worked example
If a table filters sales data and the filter menu opens only on hover, I would make it open with keyboard first, then ensure the active filter is announced clearly and not just shown in blue. A user should be able to tab to the filter, press Enter, choose "Last 30 days," and apply it without touching a mouse.

Balancing with other priorities
I would treat critical accessibility fixes as part of product quality, not as optional extras. I would bundle them with the next planned dashboard release, reserve time in the sprint for them, and defer cosmetic improvements if needed. If effort is large, I would split it: ship the blockers now, then schedule follow-up improvements. I would also use impact and usage to decide, because fixing the most common workflows first gives the biggest benefit to the most users.

I know the problem is framed well when the team can explain it without jumping to a solution.

A strong problem frame includes three things:

• The user problem. What is the user trying to do, and where are they getting stuck?
• The business goal. Why does solving this matter now?
• The constraints. What limits exist, such as time, technology, legal, or brand?

Success criteria are the measurable signals that tell us whether the work helped. I try to define one primary metric and a few guardrails. A guardrail is a metric that should not get worse while the main metric improves, such as support contacts, error rate, or time to complete.

Concrete example: if onboarding completion is 50 percent today, I might set the goal to raise it to 60 percent, while keeping support tickets and drop-off after day one flat or better. That is better than saying, "make onboarding nicer," because the team can test against something real.

If I cannot write the problem and success criteria in plain language, I keep researching before I design.

The arc has roughly six moving phases: framing, research and synthesis, ideation and prototyping, testing, handoff and launch, and iteration. What makes it "end to end" is that each phase hands off a specific artifact the next phase depends on, not a vague sense of progress. Here is the flow, since the handoffs are usually where a process actually breaks.

The flow

flowchart LR
    A[Frame: brief plus success metric] --> B[Discover: research plus current data]
    B --> C[Define: problem statement]
    C --> D[Ideate: concept options]
    D --> E[Prototype: low to high fidelity]
    E --> F[Test: usability evidence]
    F --> G{Meets bar?}
    G -- no --> D
    G -- yes --> H[Handoff: specs plus edge cases]
    H --> I[Launch: ship plus monitor]
    I --> J[Iterate: read data, feed back]
    J --> C

Phase and handoff detail

Deliverables specific to early discovery

In the discovery window specifically: a stakeholder-aligned brief (week one), raw research notes and an early synthesis (end of week one into week two), and a small number of persona or journey artifacts only if the problem is genuinely underexplored, not by default on every project. These exist to ground the define phase, not to be deliverables in their own right.

Worked example

For a checkout redesign: frame hands "reduce shipping-step drop-off, find out why" to discovery. Discovery hands "cost surprise is the top verbatim complaint, correlated with the shipping-to-payment funnel step" to define. Define hands "users abandon due to late-surfaced shipping cost; success is reduced shipping-to-payment drop-off" to ideation. The same pattern continues through the diagram above, with test able to route back to ideate if the prototype does not clear the bar, and iteration after launch feeding new evidence back into a revised define.

Trade-offs and pitfalls

• The biggest failure mode is a phase producing an artifact the next phase cannot actually use, research notes with no synthesis, a "problem statement" that is really a solution in disguise. Check each handoff specifically for that.
• Real projects do not run these phases once in strict sequence; the loop from test back to ideate, and from iterate back to define, is normal and expected, not a sign the process failed.
• A senior candidate can also name when they would compress or skip a phase (a well-understood, low-risk change might skip formal testing) and say why that is a deliberate trade-off, not corner-cutting.

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.

The hard part is not the math, it is putting UX pain, technical debt, and a sales ask onto one comparable scale when they do not share a natural unit. I translate each into reach, impact, effort, and confidence using the best proxy available for that category, score them, then defend the ranking with the two or three underlying assumptions rather than the score itself.

Translating incommensurate inputs onto one scale

For the "hundreds of smaller UI issues" case: score that long tail as one aggregate line item (a rough combined reach and a fixed effort budget) rather than running individual RICE calculations on 200 bugs. Itemizing the tail at RICE-level precision is illusory rigor, not real rigor.

Worked example

Four competing backlog items, scored with reach times impact times confidence, divided by effort:

Showing the method on the first row:

The other three rows follow the same formula with their own inputs from the table. Ranking by score: UX pain fix, UI polish backlog, tech debt, sales ask.

Defending it in a short briefing

Structure: state the recommendation first in one sentence, show the ranking table, name the one or two assumptions most likely to get challenged (here: is the tech debt incident count representative, and is the sales deal actually firm), and give the fallback if a challenged assumption changes the picture. That is a three or four minute structure, not a walk-through of the whole spreadsheet.

Trade-offs and pitfalls

• Sales asks and tech debt rarely have a clean reach number; forcing one and presenting it with false precision is worse than being transparent that it is an estimate.
• If a low-scoring sales ask is tied to a must-close deal, that is not a scoring failure, it is a different kind of constraint (a contractual gate) that the framework does not capture. Say so explicitly rather than inflating the impact number to make the ranking match the political reality.
• Watch for score creep: stakeholders learn which inputs move the score and inflate them next cycle. Ground each score in a checkable source (a ticket count, an analytics query, a deal record).