Spotify Senior Product Designer Interview Preparation Guide

Direct answer
Attack the problem at three levels at once: make the build actually able to tree-shake, meaning the bundler automatically detects and drops code a page never actually imports instead of shipping the whole library (per-component exports, no forced side effects), restructure heavy or rarely-used components so they can be loaded on demand instead of bundled by default, and change the design-level defaults (fewer global overrides, smaller default surface) so pages stop pulling in more than they use in the first place. A barrel-import library with runtime CSS-in-JS is close to a worst case for bundle size; each lever addresses a different part of why that happens.

Structured elaboration

Build-level levers

• Ship ESM builds with named, per-component entry points instead of a single default export that re-exports the whole library, so a bundler's static analysis can actually see which components are unused and drop them.
• Mark the package side-effect-free so dead-code elimination is allowed to run at all:

{
  "module": "dist/index.esm.js",
  "main": "dist/index.cjs.js",
  "sideEffects": ["./reset.css"]
}

Leaving sideEffects unset (or true) tells the bundler every import might have side effects, which disables tree-shaking for the whole package regardless of how clean the code itself is; this single field is often the highest-leverage fix available.

• Provide both ESM (for tree-shaking bundlers) and CJS (for older tooling and Node SSR) builds, generated from the same source, rather than shipping only one and forcing every consumer onto it.

Component-level levers

• Split large composite components into smaller primitives that compose together, so a page that only needs a button doesn't transitively pull in an entire form-and-validation module graph.
• Dynamically import genuinely heavy, rarely-used components (a rich text editor, a chart, a large icon set) rather than bundling them into the default import path:

const Editor = React.lazy(() => import("my-lib/Editor"));

• Prefer a zero-runtime or compile-time styling approach for the component library itself over a runtime CSS-in-JS engine, since runtime style injection adds both a JS runtime cost and an unavoidable initial-render cost that scales with how many components a page uses.

Design-level levers

• Work with design to define a small, explicit "critical" set of atoms and molecules meant for above-the-fold, first-paint use, and treat anything outside that set as a candidate for lazy-loading by default rather than an exception that needs justification.
• Limit global style overrides and encourage theme tokens plus scoped component styles instead, since global overrides tend to force the bundler to include the whole theme surface on every page regardless of what that page actually uses.

Worked example
Consider a page that imports a single Button from a library whose public entry point is one barrel file re-exporting all 180 components, with sideEffects unset. Even though the page's code only references Button, the bundler cannot prove the other 179 components' module-level code has no side effects, so it's forced to include the entire module graph reachable from that one import statement, roughly the whole library, not just the one component the page uses. Restructure the same library to (a) mark sideEffects: false, explicitly listing only the CSS reset file as an exception, and (b) expose my-lib/Button as its own entry point rather than only a named export from the barrel: now a bundler doing static analysis can prove that importing Button alone touches only Button's own module and its direct dependencies, and everything else in the 180-component graph is provably unreachable and gets dropped. This is a structural, complexity-level argument (the bundler's reachability analysis, not a measured byte count), which is the right level of reasoning here since the actual bytes saved depend on the specific build tool, minifier, and library contents in a given repo and can't be honestly stated without running that exact build.

Trade-offs & pitfalls
Splitting a monolithic barrel export into per-component entry points is a breaking change for every existing consumer's import statements, so it needs a migration path (codemod plus a deprecation window on the old barrel import) rather than a silent cutover. Moving off a runtime CSS-in-JS engine is a larger migration than it sounds, because dynamic, prop-driven styles (a color computed from a variant prop at render time) don't translate directly to build-time CSS extraction without redesigning how those dynamic styles are expressed. Dynamic imports introduce their own pitfall on the server: a component lazy-loaded on the client can cause a hydration mismatch (server-side rendering, or SSR, produces HTML up front, and if the client's first render doesn't produce the exact same output because the lazy component wasn't there yet, React flags the mismatch) or an extra network waterfall if it isn't also handled correctly in the SSR path, so "make it lazy" isn't free of new problems, it trades one class of problem (bundle size) for a different one (loading-state and hydration complexity) that needs its own design (skeleton states, suspense boundaries).

Direct answer

A promise made in a sales conversation isn't automatically a commitment the roadmap has to honor, but it also isn't something to dismiss by pointing at process. The job is to find out quickly how big the ask actually is, then either fold it into already-planned work, offer something narrower that satisfies the intent, or explain clearly why it can't happen and what happens instead, rather than letting 'the process says no' be the whole answer.

Structured elaboration

1. Get the real scope fast

Find out exactly what was promised and how technically involved it is. A quick conversation with sales and a fast technical read often turns 'they promised a change' into either 'this is a config toggle' or 'this touches several systems,' and those two cases should be handled completely differently.

2. Route by size, honestly

Small, low-risk asks can go through a lightweight fast-track with the right owner's sign-off. Larger asks go through normal prioritization, with the customer commitment logged as one input among others, not an automatic override of everything else on the roadmap.

3. The urgent-and-risky variant: when the fix means a breaking contract change

Sometimes the promise is a customer-facing bug fix, and fixing it correctly requires a breaking API contract change that frontend and mobile integrations depend on. Other systems, like the mobile app, expect the API to hand back data in an exact, agreed shape (that agreed shape is the contract); changing that shape without warning breaks them, because their code is written to read the old shape and has no way to interpret the new one. Here the stakes shift: this isn't a process-bypass question anymore, it's a technical breakage risk question. The right move is to check who else depends on the contract, see whether the fix can ship as an additive, non-breaking change instead (meaning something new is added without touching what already works, so nothing that currently depends on the contract is disturbed), and if a break is genuinely unavoidable, version it and coordinate a migration window with every dependent integration before flipping it, rather than shipping it hot for one customer's benefit while breaking others silently.

4. The reverse-direction variant: when the roadmap deprioritizes something already promised

Sometimes there's no new promise to accommodate at all; instead, a roadmap shift deprioritizes a feature that was already promised to enterprise customers. Here the job isn't to accommodate a new ad hoc promise, it's to build a walk-back communication plan: get ahead of it with the account team before the customer notices the date has slipped, be specific about the new timeline or an alternative that addresses the underlying need, and give the customer-facing team language they can actually use, rather than leaving them to explain a surprise on their own.

5. Close the loop both ways

Tell the customer-facing team what was decided and why. Tell the team that owns the process whether the promise revealed a real gap worth fixing, such as a fast-track path that didn't exist yet, or a case where sales needs earlier visibility into technical constraints before a call.

Worked example

A rep promises a customer a small label change during a renewal call. A quick check shows it's a low-risk config change, so it ships that week through the lightweight path with the account owner's sign-off, and the exception gets logged. Contrast that with a case where a rep promises a fix to a data-export bug, and fixing it correctly means changing the shape of a public API response that a mobile app and two partner integrations depend on. Instead of pushing a fast fix, the team ships an additive new field alongside the old one, migrates the highest-risk integration first behind a feature flag (a toggle that turns the new behavior on for one group at a time, so it can be tested on a small slice before everyone gets it), and only removes the old field once every consumer has moved over, later than the customer originally hoped, but without breaking anyone else in the meantime. Separately, when a previously promised enterprise feature gets bumped by a roadmap shift, the team gives the account manager a specific revised date and a smaller interim capability to offer, so the customer hears a plan instead of discovering the slip on their own.

Trade-offs and pitfalls

• Using process purely as a shield, with no real attempt to find a legitimate fast path, damages trust with both sales and the customer for no real safety gain.
• Letting one ad hoc exception become the unwritten template invites every future promise to bypass prioritization; log exceptions and periodically check whether the process itself needs a documented fast lane instead.
• Treating a breaking-change fix as a normal prioritization question, rather than a dependency-risk question, is how a favor to one customer quietly breaks several others.
• Not looping back to ask why sales made a promise outside the guardrails in the first place means the same collision happens again on the next renewal call.

In the first week, I would focus on protecting the launch while testing whether the plan is still realistic.

Day 1 and 2: I would get the facts. What is late, what is truly on the critical path, and which milestones depend on the partner. I would also ask for a written status update so there is one shared view of the problem.

Day 3 and 4: I would reset alignment with the partner and internal leaders. I would make the risk visible, propose a recovery plan, and define what needs to happen by when. If needed, I would narrow scope, add internal backup work, or create a phased launch so the entire roadmap is not blocked by one dependency.

Day 5: I would decide whether the original date is still credible. If the partner has recovered, I keep the plan. If not, I recommend a revised timeline with clear trade-offs, rather than hoping the delay disappears.

The key is to avoid passive waiting. Even without direct authority, I can protect the launch by clarifying ownership, escalating early with options, and keeping leadership informed with facts instead of optimism.

For example, in a case like this, the launch depended on a third-party payments provider delivering a new API endpoint that a checkout redesign needed to go live. On Day 1, the written status update from the vendor's account manager revealed the endpoint was not late by a day or two, it was still in the vendor's own internal QA with no committed date, three weeks past their original commitment. By Day 3, resetting alignment meant a joint call with the vendor and internal engineering leadership where the risk was made explicit: without the endpoint, the full checkout redesign could not ship on the original date. The recovery plan split the work: internal engineering built a fallback that used the vendor's existing, older endpoint for most transaction volume, while the new endpoint's remaining edge cases, a smaller set of international payment methods, were scoped out of the initial launch and phased in once the vendor delivered. On Day 5, the vendor still had no firm delivery date for the new endpoint, so the recommendation was to launch on the original date with the phased fallback rather than slip the whole roadmap, with a follow-up launch for the remaining payment methods once the vendor's endpoint actually shipped.

Layout (wireframe zones)

• Header: logo + global nav + skip-to-results link (visible on focus)
• Search bar: text input, clear button, search submit; live autosuggest below
• Filter sidebar (left, collapsible): group headings, checkboxes, range sliders
• Results area (main): result count + sort control, results list, pagination / infinite-scroll sentinel
• Right-hand preview panel (optional): detailed preview shown on focus/selection

Keyboard tab-order

1. Skip-to-results (1)
2. Search input (2) -> Clear (3) -> Submit (4)
3. Autosuggest items (arrow keys navigable; Enter to accept)
4. Filter toggle (5) -> Filter controls sequentially (6…n)
5. Sort control (after filters)
6. Results list: first result link (tab) then keyboard arrow navigation within list (Left/Right/Up/Down) to move focus between results; Enter opens, Space toggles selection
7. Preview panel controls
8. Pagination / Load more

ARIA & semantic notes
Before the attribute list: these ARIA (Accessible Rich Internet Applications) attributes collectively tell a screen reader which element controls which, and what role each piece plays, so a non-visual user gets the same structure a sighted user sees.

• Use semantic elements: <header>, <main role="main">, <aside aria-labelledby="filters-heading">, <ul role="list">, <li role="listitem">
• Search input: aria-label or aria-labelledby; aria-controls="autosuggest" and aria-autocomplete="list"
• Autosuggest: role="listbox" + options role="option"; manage aria-selected
• Collapsible filters: buttons with aria-expanded & aria-controls; each group has aria-labelledby
• Filter inputs: native <input type="checkbox"> for built-in accessibility; for custom controls include role and accessible name
• Results list: role="list" and each card role="article" with tabindex="-1" for programmatic focus; primary action is a focusable link
• Live regions: aria-live="polite" on results count and "X results" updates
• Preview panel: aria-labelledby and aria-hidden toggled when not visible
• Keyboard focus ring visible; focus trap avoided except in modal

Example annotations for developers (to include on wireframes)

• "Search input: set aria-controls='autosuggest'; arrow keys move through #autosuggest options; Enter selects and populates input."
• "Filter group: toggle button (aria-expanded) collapses panel, preserve checkbox tabindex order; keyboard users can tab into group and use Space to toggle each."
• "Results navigation: Tab lands on first result link. Arrow keys move focus among result cards; implement roving tabindex, a pattern where only one item in the group is reachable by Tab at a time (that item has tabindex=0) and arrow keys move focus between the other items in the group, instead of every item taking its own stop in the normal Tab order. When a card gains roving focus, update preview panel via aria-live or set focusable preview and manage aria-hidden."
• "Infinite scroll: include sentinel element with role='status' and aria-live='polite' announcing 'Loading more results' and 'N more results loaded'."
• "Screen-reader labels: every icon button (clear, sort, close preview) must have aria-label. Provide concise accessible names for result metadata (e.g., '3.5 out of 5 stars, 120 reviews')."

Design rationale & testing

• Use native controls where possible for predictability.
• Prefers roving tabindex + arrow navigation for grid/list browsing.
• Test with VoiceOver, NVDA, and keyboard-only scenarios; include edge case: zero results announcement and keyboard focus after filtering.

Direct answer

An empathy map is a lightweight visual tool teams use to synthesize what a user says, thinks, does, and feels, in order to build shared understanding and surface design or product opportunities together, rather than relying on any one person's interpretation of the research.

Pre-work (sent 48 hours before)

Share a short persona or a recent customer vignette along with 2 to 3 real user quotes or metrics. Ask each participant to review it and bring one customer anecdote or data point of their own. Prepare a shared whiteboard with a 2x2 empathy-map template and a written agenda.

60-minute workshop plan

• 0 to 5 min, kickoff: state the purpose, the expected outputs (top 3 insights, 3 possible experiments), roles, and the timebox.
• 5 to 20 min, individual silent brainstorm: each person adds 3 to 5 sticky notes per quadrant using the shared persona or a real customer quote.
• 20 to 40 min, share and cluster: each participant reads 1 to 2 highlights per quadrant while the facilitator groups similar notes into clusters and a scribe labels each cluster with its supporting evidence.
• 40 to 50 min, insight generation: small mixed groups (designer, engineer, customer success) each pick one cluster and answer what problem it indicates, how it affects the business or user outcome, and what hypothesis or experiment follows. For example, if the customer-success representative brings in three separate tickets about a payment failing with no explanation, that cluster becomes the group's pick, and the hypothesis becomes that a vague failure message, not the underlying fraud rule, is driving repeat checkout abandonment.
• 50 to 60 min, decide next steps: each group presents one insight and one next action (prototype, analytics check, or user interview), and the product manager captures priorities, owners, and a timeline.

Roles during the session

• Facilitator (product manager): keeps time, keeps scope, synthesizes.
• Designer: surfaces empathy patterns, proposes UX experiments.
• Engineer: calls out technical constraints and feasibility.
• Customer success: brings the customer's voice, flags severity and urgency.
• Scribe: documents clusters, evidence, and action items.

For a two-sided or marketplace product, add a merchant-facing product manager or a growth representative so the map captures both sides of the transaction, not only the buyer's experience.

Sample prompts for each quadrant

• Says: "What exact phrases or quotes have customers used?" For example, "It takes too long to set up."
• Thinks: "What might they be worried about or assuming but not saying?" For example, "Is this secure? Will this break my workflow?"
• Does: "What observable actions do they take?" For example, retries setup, contacts support, abandons the flow.
• Feels: "What emotions underlie the behavior?" For example, frustrated, anxious, relieved.

Converting results into product insights

Synthesize the clusters into 3 prioritized problems, each backed by evidence (quotes, frequency, and severity as flagged by customer success). For each, write a clear hypothesis: "If we do X, then metric Y will improve by roughly Z." Map each hypothesis to a concrete next step, a quick prototype test, an analytics event change, or a targeted interview. Log outcomes against the roadmap or backlog, tag tickets with the empathy cluster they came from, assign an owner, and set a measurable target. Share a one-page summary with stakeholders and run at least one validation step within two weeks.

Trade-offs and pitfalls

A 60-minute session generates directional hypotheses, not proof; treat every "insight" from the workshop as a candidate for validation, not a finished decision.

Direct answer

Fix the issues in the order they compound: illegible base typography first, then the missing hierarchy between labels and values, then inconsistent card elevation, then inconsistent call-to-action (CTA) placement. Each later fix only pays off once the one before it is solved, so that is also the priority order for shipping.

Structured elaboration

1. Typography legibility is the floor. If labels are too small or too low-contrast to read comfortably, no amount of grouping or spacing fixes scannability, since the user cannot parse the content in the first place. This is two separate corrections, and both have to actually happen: raise the label to a genuinely readable size rather than nudging it a pixel, and darken it so it separates from the card behind it instead of sitting in the same mid gray that caused the complaint.

2. Visual hierarchy within each metric is next. A dashboard card usually shows a label ("Revenue") and a value ("$482K"). These need to look different in weight and size, not just in position, so the eye lands on the number first and the label second, the way a person actually scans a dashboard.

3. Card and shadow consistency comes after content is legible. Standardize on one or two elevation treatments (for example a resting card style and a single hover or active style) instead of letting shadows vary ad hoc from card to card, since inconsistent shadows read as visual noise even once the text inside is fixed.

4. CTA placement consistency is the polish layer. Put the primary action for a card (for example "View details") in the same visual position across every card and every screen, so users learn the pattern once instead of re-scanning each screen to relocate it.

Worked example

Say three of the dashboard's twelve cards, Revenue, Active Users, and Errors, currently use an 11px label and a 13px value, both the same medium gray at fairly low contrast against a light gray card background.

Rework, in the same priority order:

• Labels: 11px medium gray becomes 14px in a dark gray only a step or two off the value's near-black, at medium weight, in sentence case. Three things there are deliberate. The size moves by 3px, not 1px, because a 1px bump does not answer a complaint that the text is too small to read. The color actually moves off "medium gray," which was the diagnosis, rather than being restated as the cure. And the label stays sentence case rather than going uppercase: uppercase strips the ascender and descender cues that give a short word its recognizable shape, which is exactly the cue a reader is using when they glance at a dense grid of labels, so uppercase at label sizes trades legibility for a styling effect on the one element the priority order says must be legible first.
• Values: 13px becomes 28px, near-black, bold. Against the 14px label that is exactly a 2x size jump (14 to 28), stacked with a weight shift and a color shift, and it is the combination rather than any one of the three that separates "what is this metric" from "what is the number" at a glance.
• Elevation: the four different shadow styles observed across the twelve cards collapse into one, a 1px border plus a subtle 2px blur shadow, applied everywhere.
• CTA: each card's "View details" action moves to the same bottom-right position across all twelve cards, replacing a mix of top-right, inline, and bottom-left placements.

Trade-offs and pitfalls

Fixing typography and contrast alone, without also building weight and size hierarchy between label and value, makes everything uniformly readable but still visually flat, a common wrong turn that looks like progress without improving scannability. The mirror-image mistake is subtler and more common: writing down "make labels legible" as priority one and then shipping a change that only touches the value, leaving the label a pixel larger and the same gray it always was. If the priority-one fix cannot be described as a change someone would notice, it did not happen. Overcorrecting shadows down to nothing can make cards blend into the background entirely; some elevation cue usually still needs to survive. Doing the CTA placement fix first, before the underlying legibility and hierarchy issues, wastes effort. It is cosmetic polish on top of a dashboard users still cannot read at a glance.

Scope & Objective
Establish Design Operations for a 50-person product org to remove execution friction, raise design quality, speed delivery, and scale a consistent design culture and system.

Key Roles (initial)

• Design Ops Lead (0.5 FTE) — owns roadmap, vendor contracts, metrics, cross-functional alignment
• Design System Engineer (0.5 FTE) — component library, tokens, code handoff patterns
• Program Coordinator (part-time) — meeting rhythms, onboarding logistics, resource tracking
  (Designers remain embedded in product teams; ops is a service center.)

Core Responsibilities

• Tooling: audit current stack (Figma, FigJam, Proto, Zeplin, Miro, Jira), consolidate licenses, set shared libraries, CI for tokens
• Onboarding: 1-week kit + 30/60/90 checklist, mentor pairing, design playbook with team-specific workflows
• Process: standardized discovery templates, design review cadence, handoff checklist, research repository, weekly office hours

Initial KPIs (first 6 months)

• Time-to-first-deliverable for new hires (target -30%)
• Design handoff rework rate (bugs/clarifications from engineering) reduced by 40%
• Reuse rate of design system components > 50% of new screens
• Satisfaction score from PM/Eng/Design (quarterly pulse > 8/10)

6-Month Pilot Plan
Month 0–1: Discovery — tool audit, stakeholder interviews, baseline KPIs
Month 2: Quick wins — consolidate libraries, launch onboarding kit, run 2 design reviews/week
Month 3–4: Build — implement tokens, component library, handoff checklist, research repo
Month 5: Measure — collect KPIs, run pulse surveys, document time savings and rework reduction
Month 6: Iterate & Expand — present ROI to leadership, propose scaling (full-time hires, automation)

Example success metric: after month 4, expect 25% fewer engineering clarifications and 20% faster new-hire ramp. This plan demonstrates measurable operational value while keeping designers focused on product outcomes.

Direct answer

I'd give the PM (product manager) an end-to-end plan, not just a metric name: one primary hypothesis with a pre-registered minimum detectable effect (MDE, the smallest change worth caring about), a stratified randomization so the pricing/layout/messaging bundle is tested fairly across customer segments, explicit guardrails against harm, and stopping rules decided before the test starts, not while watching the dashboard.

Structured elaboration

Primary hypothesis: "Bundling the redesigned pricing display, layout, and messaging on the checkout page increases checkout completion rate relative to the current design, without reducing average order value." Note it's framed as one bundled hypothesis, since the three changes ship together as a single redesign, not three separate levers; that has a real trade-off covered below.

Segmentation / stratification: randomize at the user level, but stratify the randomization by the two dimensions most likely to interact with the redesign: device (mobile vs. desktop, since layout changes often land very differently on each) and customer type (new vs. returning, since pricing-display familiarity differs). Stratifying means you guarantee balanced representation of each stratum in both arms rather than hoping random assignment gets there by chance, which matters when a stratum is a minority of traffic.

Power calculation assumptions: baseline checkout conversion rate 3.0%, and the team wants to detect an absolute lift of 0.3 percentage points (to 3.3%, a 10% relative lift), at a 5% two-sided significance level and 80% power. Using the standard two-proportion sample size formula:

$z_{\alpha/2}$ and $z_{\beta}$ are just the standard-normal critical values for your chosen significance level and power (1.96 and 0.84 at the conventional two-sided 5% / 80% settings used here). Plain-English intuition for the formula itself: the numerator grows with how noisy the two conversion rates are, the denominator shrinks with how big a gap you're trying to detect, so a tiny gap in a noisy metric needs a much bigger sample. With $p_1=0.03$, $p_2=0.033$, this comes out to roughly 53,200 checkout sessions per arm (about 106,400 total). This is the concrete number that turns into a duration commitment once you know daily checkout traffic (e.g. at 5,000 sessions/day total, roughly 21 days minimum).

Monitoring and stopping rules: pre-register the sample size above and do not call the test before it's reached, even if the p-value dips below 0.05 earlier (early peeking inflates the real false-positive rate well past the nominal 5%). If the team wants interim looks, use a sequential testing correction (e.g. an alpha-spending boundary, a pre-set schedule for how much of the total 5% false-positive budget each interim look is allowed to spend, so repeated peeking can't quietly push the real error rate above the stated level) decided in advance, not ad hoc peeking. Stop early only for a guardrail breach, never for an early "win" on the primary metric.

Guardrails: (1) average order value, so a completion-rate win isn't secretly a discount-driven race to the bottom; (2) checkout error rate / page load time, so a layout change isn't winning by masking a performance regression that would show up elsewhere; (3) refund/chargeback rate over the following weeks, since pricing/messaging changes can shift what customers expect and drive returns.

Rollout strategy if it succeeds: ramp gradually (e.g. 50% to 75% to 100%) rather than flipping immediately, keep a small (2-5%) long-term holdback for a few weeks post-ramp to confirm the effect persists and isn't a novelty spike, and only fully retire the old checkout design after that holdback confirms stability.

Worked example

At 5,000 checkout sessions/day evenly stratified across mobile/desktop and new/returning, the test needs about 106,400 total sessions, or roughly 21-22 days at that volume. If the true lift really is 0.3pp and it holds, that's worth (at, say, a $60 average order value) an estimated $0.18 in incremental revenue per session exposed, or about $27,000/month at 150,000 monthly sessions once fully rolled out, before accounting for the guardrail checks passing.

Trade-offs & pitfalls

Bundling pricing, layout, and messaging into one variant means a win tells you the bundle works, not which piece does the work; if the team wants to attribute impact to a specific element for future iteration, a factorial design (testing the three changes both separately and combined) is more informative but needs substantially more traffic to reach the same power in every cell, often not practical at this baseline conversion rate. A second pitfall: don't let "returning customer" stratification hide a real segment-level harm, such as the redesign clearly helping new customers while quietly hurting returning customers who were used to the old pricing layout; always report segment cuts, not just the pooled result, before recommending a full rollout.

Direct answer

Early convergence and dominant voices are both structural problems, not personality problems, so fix them with structure: separate individual, silent generation from group discussion, use written and voted synthesis instead of open debate to reach the shortlist, and make sure the shortlist reflects different underlying assumptions rather than just the most popular ideas in the room.

Structured elaboration

Preventing early convergence

• Timebox the divergent phase and require a minimum quantity of ideas before anyone is allowed to discuss or critique them.
• Set an explicit "yes and, not yes but" norm going in, and give the facilitator a parking lot (a running list where off-topic or premature points get noted for later, not discussed now) to redirect premature critique without shutting the person down.
• Do not let the room see a shortlist forming until the divergence timebox is actually over.

Preventing dominant voices from steering the room

• Start with silent, written generation (one idea per note) before any spoken sharing, so quieter participants and people without positional authority contribute before the loudest voice sets the frame.
• Share round robin, one idea at a time with no rebuttal in between, rather than open floor.
• Get explicit agreement up front from any senior stakeholder in the room that their role during divergence is to contribute ideas, not to signal a preferred answer; a facilitator who is not the decision-maker should run the room.
• Use anonymous or simultaneous dot voting, not a show of hands, so votes are not anchored to who voted first or loudest.

From divergence to a synthesized shortlist

flowchart TD
    A[Frame the problem, align on the goal] --> B[Review research inputs / empathy map]
    B --> C[Silent solo generation, one idea per note]
    C --> D[Round robin share, no debate yet]
    D --> E[Affinity cluster into themes]
    E --> F[Spread dot vote across clusters]
    F --> G[Facilitator drafts shortlist across distinct assumptions]
    G --> H[Group stress tests shortlist against constraints]
    H --> I[Commit to directions to prototype]

Affinity clustering groups similar sketches or notes into themes. Dot voting (each participant gets a fixed number of votes, spread across clusters rather than stacked on one) surfaces which themes have real group interest. The facilitator then drafts a shortlist that is explicitly mapped to different underlying assumptions about the brief, not just the highest vote counts, since dot voting alone tends to favor familiar-sounding ideas over riskier, more novel ones. The group gets one more pass to stress-test that shortlist against real constraints (feasibility, timeline, scope) before committing to what gets prototyped.

Adapting when the room cannot be live together
When true synchronous overlap does not exist across time zones, replace the live workshop with a staggered structure: a shared async board (Miro or FigJam) with a silent-generation deadline everyone hits independently, an async voting window once generation closes, and then one shorter synchronous call reserved only for the clustering-to-shortlist synthesis step, which benefits most from real-time discussion. Running the entire thing asynchronously tends to lose the momentum a live room creates, so keep the synthesis step live if any overlap at all is possible.

Running it as a multi-day sprint for a genuinely fuzzy brief
When the brief itself is too vague for a single session to resolve (a "checkout abandonment is a problem" level brief with no clear opportunity area yet), extend this same divergence-to-shortlist logic across a short discovery or design-sprint format (a structured multi-day process for going from a problem to a tested prototype): an early block to align on the problem and goal and produce several distinct low-fidelity directions from different underlying assumptions about why abandonment is happening, followed by the same clustering, voting, and stress-testing sequence described above before selecting what gets prototyped.

Worked example

A team facing a fuzzy "reduce checkout abandonment" brief runs a workshop with a PM, two engineers, a researcher, and two designers. Session opens with a short review of the research inputs already available (funnel drop-off data, a handful of support tickets) framed loosely as an empathy map of where and why people seem to be dropping off. Each participant then silently writes as many "why might someone abandon here" and "how might we address that" pairs as they can in a fixed window, one per sticky. Round robin sharing follows, no debate. The group clusters the notes and finds three distinct underlying assumptions: people are confused about total cost, people distrust entering payment details, and people are interrupted mid-flow and cannot resume easily. Dot voting spreads across all three clusters rather than piling onto one. The facilitator drafts a three-item shortlist, one direction per assumption, and the group stress-tests each against a rough two-week build constraint before agreeing on which two to actually prototype.

Trade-offs and pitfalls

• Senior stakeholder presence changes room dynamics no matter how good the structure is; get explicit buy-in beforehand that they contribute ideas, not verdicts, during divergence.
• Dot voting still tends to reward safe, familiar-sounding ideas over bold or risky ones; consider a reserved "wildcard" vote category if you want to protect against that.
• Over-structuring an async process removes the energy and quick back-and-forth a live room provides; only push the whole session async when overlap genuinely does not exist, and keep synthesis live whenever any overlap is possible.
• A shortlist built purely from top vote counts, without checking it spans different assumptions, quietly re-introduces the early-convergence problem you were trying to avoid in the first place.

Direct answer

I would tell one specific story: a vague brief ("make the dashboard easier to use") that I turned into a falsifiable claim (one that some possible observation could prove wrong), tested cheaply, and let the result change what we built. The strong shape is: what made the problem ambiguous, how I narrowed it, what exactly the test could prove or disprove, and which decision moved because of it. (The details below are an illustrative story skeleton. Replace them with your own real project.)

Structured elaboration

• Situation. As the product designer on an analytics tool, I was handed "new admins find the dashboard confusing." That is a feeling, not something I could test.
• How I got to a testable problem. I (1) listed what "confusing" could mean: cannot find the first report, do not understand the chart labels, or do not trust the numbers; (2) read 20 support tickets and watched session recordings (screen captures of real users) to see which of the three showed up in behaviour; (3) wrote one claim: "New admins who cannot reach their first report in the first session are the ones who leave, and the cause is the navigation label, not the chart design."
• The test. A prototype test with two navigation variants: the existing label ("Insights") and a task-based label ("See your first report", named for what the user wants to do). Eight participants saw each variant. Prediction written beforehand: if the label is the cause, participants on the new label reach the report unaided noticeably more often; if both variants fail the same way, my claim is wrong. Task success was measured by who reached the report without help.
• What the test changed. Most participants on both variants still stalled, at the step after navigation (choosing a data source): 2 of 8 reached the report unaided with the old label and 3 of 8 with the new one, far short of the 6 of 8 bar in the worked example below. The label was not the main cause. We dropped the planned navigation rework and put the effort into a guided first-run flow for data source selection.
• Result, kept honest. A moderated test (a researcher present, giving tasks and observing) with eight participants per variant shows direction, not proof. I reported it as "strong enough to redirect a two-week design effort, not strong enough to forecast a metric", and the later activation measurement (the share of new admins reaching their first report in live use) was the real confirmation.

Worked example

Before: "dashboard is confusing" (cannot be wrong, so cannot be tested). After: "In a first session, at least 6 of 8 new admins will reach their first report unaided if the label is the cause." The after-version names who, what behaviour, and what result would count as failing. When the test showed most stalling in both variants, the claim failed cleanly, which is exactly why it was useful.

Trade-offs and pitfalls

• Common wrong turn: reframing the problem into a question that confirms the solution you already like. Writing the prediction and the failing result first prevents that.
• Over-claiming: do not quote a percentage lift from a small prototype test.
• What I would do differently: check the funnel data (counts of users reaching each step of the flow) before building the prototype. A single query would have shown the drop was after navigation and saved a variant.