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

In the first conversation, I would turn the vague request into a specific problem.

I would ask:

• Who is the new app for?
• What does success in onboarding mean for the business?
• Where do users currently struggle, if anywhere?
• What does onboarding include today?
• Are there legal, technical, or brand constraints?

Then I would try to define the user problem in plain language. For example, instead of "make onboarding better," I might uncover that first-time users do not understand the value of the app before they are asked to create an account.

I would also ask how success will be measured, such as completion rate, time to finish, or early retention. That gives us a shared target and keeps the work from becoming opinion-driven.

Before leaving the meeting, I would summarize my understanding back to the PM, confirm any assumptions, and propose the next step, like reviewing analytics or doing a few user interviews. That way, the request becomes an actionable design brief instead of a vague direction.

Direct answer

With sparse analytics, the first move isn't more research, it's a fast audit of what's actually being measured today, followed by triangulating cheap qualitative signal with whatever quantitative signal can be stood up quickly, so the highest-impact opportunity gets found through convergence of evidence rather than waiting for a perfect dataset that may never arrive.

Structured elaboration

Finding the opportunity

• Start with an instrumentation audit, not new research: what events are already logged, even informally in support tickets or ops spreadsheets, and where are the biggest blind spots in the core funnel from browse to contact to transaction. This usually takes days and shows where the team is flying blind.
• Talk to people who already have informal signal: support, sales, ops. They're sitting on qualitative evidence about where users get stuck that hasn't been formalized, and it's the fastest way to generate hypotheses before running new research.
• Run a small number of targeted interviews or session observations, aimed at the specific funnel step the instrumentation audit and internal stakeholders both point to, so the qualitative work confirms or kills a hypothesis instead of fishing for one from scratch.
• Prioritize by triangulation, not any single source. An opportunity that shows up independently in the instrumentation gaps, in support tickets, and in interviews is far more trustworthy on sparse data than one that shows up in only one source.

Escalating what's found

• Lead with the decision being asked for, not the process. Leadership needs the opportunity, the evidence, and the specific ask, not a narrated research journey.
• Show convergent evidence explicitly, the same friction point named in the funnel gap, in support tickets, and in interviews, rather than presenting sources separately, since convergence is what compensates for the lack of a large quantitative dataset.
• Name the confidence level honestly given sparse data. This is a well-triangulated hypothesis, not a proven, sized result, so the ask should be the smallest experiment that would size it, not a large investment on unproven evidence.

Worked example

On a plateaued marketplace, the instrumentation audit shows there's no event tracking between viewing a listing and sending a message, a real blind spot in the middle of the funnel. Support tickets independently show a recurring theme: users say they don't know what information to include in a first message and give up. A handful of quick user interviews confirm it: several participants say they closed the listing because composing a message felt like it required information they didn't have yet. All three sources point at the same gap, which is enough convergence to bring to leadership as the top opportunity, along with a proposal to instrument that specific step and run a lightweight prototype test of a structured, prompted first-message flow before committing to a larger redesign.

Trade-offs and pitfalls

• Triangulating instead of waiting for clean data is the right call at this scope, but it's easy to let one vivid support ticket or a strongly worded interview quote stand in for volume. Keep checking whether a signal shows up in more than one independent source before treating it as the top opportunity.
• Escalating with too much narrative and not enough of a concrete ask reads as interesting but not actionable to leadership; the ask, budget, engineering time, or a specific experiment, needs to be explicit.
• New instrumentation takes time to accumulate volume. Don't promise leadership a sized business case before the data exists to size it; promise a specific, time-boxed path to get there instead.

Direct answer

Scope the discovery effort as a time-boxed funnel: spend the first stretch aligning on what "the problem" even means and what evidence would settle it, the middle stretch gathering just enough qualitative and quantitative signal to form real hypotheses, and the last stretch validating the strongest hypothesis cheaply before anyone touches a solution. The deliverable is not a research report, it is a specific, falsifiable problem statement plus a recommendation on whether to proceed, and to what.

Structured elaboration

What makes this different from just "doing user research"

• The hypotheses are written down before the interviews, so the team can tell afterward whether the data changed anyone's mind or just confirmed what they already believed.
• The output is a decision (proceed, reframe, or stop), not a synthesis deck. If discovery cannot produce a real go or no-go call, the scope was too vague going in.
• Solutioning is explicitly deferred. The moment someone sketches a UI, the team has silently converted a discovery exercise into a design sprint, and the original ambiguity about motivation never actually got resolved.

Worked example

Say product wants to add a "save for later" feature to a shopping app, but nobody can articulate whether users actually abandon items due to price hesitation, comparison shopping, or simple forgetfulness. Framing stretch: the team agrees the deciding question is "what is the dominant reason items get abandoned in-cart," and writes three hypotheses (price sensitivity, comparison across sites, distraction/forgetting). Generative stretch: eight contextual interviews with recent cart-abandoners plus a review of existing session recordings around the cart step surface that comparison shopping dominates for higher-priced items, while forgetting dominates for low-priced, low-consideration items. Validation stretch: a simple concept test, showing two mocked "save for later" treatments (one framed around price tracking, one around a quick-access list) to a small group, checks which framing resonates with which segment. The discovery output is not a persona deck, it is a recommendation: build a lightweight quick-access list first (serves the larger, easier-to-solve forgetting segment), and treat price-tracking as a separate, later bet that needs its own validation.

Trade-offs and pitfalls

• The most common failure is discovery theater: running interviews and surveys but never writing down what evidence would change the recommendation, so the team ends up doing generative research and then designing anyway, regardless of what was found.
• A few weeks is not enough for a representative sample. Be explicit that the output is a directional, evidence-informed hypothesis, not a statistically validated conclusion, and pair it with a cheap in-market check once a solution ships.
• Skipping the framing stretch to get to interviews faster usually backfires, because without written hypotheses the team cannot tell confirmation bias from a genuine finding.
• Letting solutioning creep in during generative research narrows what people say. Once you show a mockup, you stop learning about the underlying problem and start getting feedback on your idea instead.

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.

Direct answer

"Too dense" is a symptom, not a problem statement: it describes a feeling, not what specifically is failing for whom. Turning it into a design challenge means finding out what "dense" is standing in for (too much irrelevant information, too little visual hierarchy, too many steps to get an answer) before sketching anything, and then testing the reframed challenge at low fidelity before committing to a direction.

Structured elaboration

1. Treat "too dense" as a symptom with several possible causes. It could mean information overload (too much shown at once), poor hierarchy (the right things aren't emphasized), navigation friction (the right information exists but is hard to find), or simply that different users need different subsets of the same dashboard. Each cause implies a different fix, so jumping to a redesign before narrowing this is a common wrong turn.

2. Ask a small number of targeted clarifying questions to separate the causes. What decisions do people make with this dashboard most often? Which panels do they actually use versus ignore? What were they trying to do the last time the density got in their way? The goal is to locate the complaint in a specific task, not just gather general sentiment.

3. Surface constraints, including accessibility, while still framing the problem, not after a direction is picked. If some of the density comes from information required for compliance or from users with different visual or cognitive needs, that has to shape the reframed challenge itself, not get bolted on to a chosen solution afterward, where it is far more expensive to accommodate.

4. Sketch multiple low-fidelity concepts that test different hypotheses about the cause, not one polished direction. Because the root cause is still uncertain at this point, the sketches should be different enough from each other to actually discriminate between hypotheses (one testing task-first flows, one testing progressive disclosure, one testing role-based views), rather than three visual variations on the same idea.

Worked example

Reframed design challenge: "How might we surface the information each user actually needs for their most common decisions, without hiding the detail power users still rely on?"

Clarifying questions to ask before sketching: which two or three decisions does this dashboard get used for most often; who besides the primary user sees this same view and do their needs differ; which panels get checked daily versus rarely, if analytics can show that; and can you walk me through the last time the dashboard slowed you down on a real task.

Three low-fidelity concepts to test against different hypotheses: (1) a role-based landing view showing three or four prioritized metrics with a path to the full dashboard, testing whether the complaint is really about irrelevant information; (2) a progressive-disclosure layout with collapsed detail that expands on demand, testing whether the complaint is about visual clutter rather than missing information; (3) a task-first flow that surfaces only what's relevant to a stated goal like "investigate a metric drop," testing whether the complaint is really about navigation, not density at all. The same reframing move applies to a low-traffic settings page that still needs to be fast: the symptom would be different ("too slow" rather than "too dense"), but the discipline is the same, find out what "slow" is standing in for (too many steps, unclear defaults, page weight) before sketching a fix.

Trade-offs and pitfalls

The biggest pitfall is skipping straight to a cleaner-looking redesign, since a visually simpler dashboard that still shows the wrong things, or hides things a power user relies on, will draw the same complaint back within a release or two. A second pitfall is treating every user's density complaint as the same complaint; a dashboard built for one persona's idea of "less dense" can make things worse for another persona who relied on the density. Surfacing accessibility and compliance constraints late, after a direction is chosen, is expensive to unwind; doing it during framing costs almost nothing.