User Research and Discovery Questions

Interviewers will evaluate your research toolkit and synthesis skills. Describe methods you use to discover and validate user needs such as user interviews, contextual inquiry, usability testing, surveys, analytics review, and controlled experiments. Show how you define the core problem, recruit and run studies, synthesize qualitative and quantitative insights into personas and journey maps, form hypotheses, and translate findings into prioritized design and product recommendations.

MediumTechnical

35 practiced

Role-play: a product manager insists on shipping a feature immediately because of customer anecdotes, but you only have anecdotal evidence. Draft a short response and an expedited 2–3 step research plan that balances speed and risk while providing enough evidence to inform the decision within a few days.

MediumTechnical

68 practiced

Analytics show a 40% drop in the checkout funnel. Propose a hypothesis-driven prioritization and design a single A/B test aimed at reducing drop-off. Include the hypothesis, the variant(s) you'll test, primary and secondary metrics, guardrail metrics, traffic allocation, and sample size considerations for statistical power.

Sample Answer

**Situation & prioritization**- Drop is at checkout — high impact on revenue and user experience. Prioritize friction points that are quick to test: progress clarity, form friction, unexpected costs, and trust signals. I pick form friction (too many fields + unclear errors) because UX research and session replays often show users abandoning there.

**Hypothesis**- If we reduce perceived effort and increase clarity in the checkout form, then checkout completion will increase versus current flow.

**Variant (single A/B)**- Control: current checkout.- Variant: simplified checkout — consolidate fields (guest checkout, address autocomplete, inline validation, progress indicator, “why we need this” helper text), mobile-optimized keyboard types.

**Metrics**- Primary metric: checkout completion rate (users who reach order-confirmation / users who enter checkout).- Secondary metrics: time-to-complete checkout, form field error rate, average order value.

**Guardrails**- Cart abandonment rate upstream, payment success rate, refund/chargeback rate, session duration (ensure no negative downstream effects).

**Traffic allocation**- 50/50 random assignment across eligible users (new and returning shoppers who start checkout) for clean power and simplest analysis.

**Sample size & power**- Assume baseline completion = 20%. Target detectable uplift = absolute +3 percentage points (to 23%). With alpha = 0.05, power = 0.8, two-sided test, required N per variant ≈ 14,000 (use standard proportions sample-size calculator). If traffic limited, consider longer test or raising detectable effect to 4–5 pp.- Run for at least one business cycle (min 2 weeks) and monitor sequentially with pre-registered analysis plan; stop only on reaching pre-defined statistical thresholds.

**Why this approach**- Focuses on highest-impact UX friction with low engineering cost; metrics cover success and safety; sample-size is realistic for typical ecommerce volumes and balances sensitivity with runtime.

MediumTechnical

67 practiced

Compare recruiting participants from internal support logs versus external recruitment platforms for discovery interviews. Discuss the kinds of biases each introduces, relative costs and turnaround times, representativeness, and when you would choose one approach over the other.

HardTechnical

37 practiced

Propose a plan to scale rapid discovery research for a startup growing from 30 to 200 people across 8 product teams. Define roles (researchers, research-ops, citizen researchers), lightweight templates and playbooks, tooling recommendations, request SLAs, a triage process for research requests, and QA measures to maintain rigor while increasing volume.

Sample Answer

**Overview / Goal**I’d scale discovery by creating a lightweight, repeatable system that increases throughput without sacrificing rigor—centralizing ops, empowering citizen researchers, and standardizing templates, tooling, SLAs, triage, and QA.

**Roles**- Researchers (2–4): lead high‑risk studies, mentor, handle complex synthesis and frameworks.- Research-Ops (1–2): recruitment, panel management, tools, metrics, study scheduling.- Embedded Research Advocates (one per product area): 0.5 FTE designers/PMs trained to run low-risk studies.- Citizen Researchers: engineers/PMs trained on scripts and ethical basics; run quick validation tests and guerrilla usability checks.

**Lightweight Templates & Playbooks**- Research brief (goal, success metrics, stakeholders, timeline, sample size) — 1 page.- Screener + consent boilerplate.- 30‑minute interview guide + prompts (modular).- Usability test checklist (tasks, success criteria).- Synthesis deck template: key insights, verbatims, decisions, recommended experiments.- Playbooks: “5‑day discovery sprint”, “remote unmoderated test”, “concept validation” (stepwise checklists).

**Tooling Recommendations**- Recruiting & notes: Airtable for panel + Calendly.- Study platforms: Lookback/PlaybookUX for moderated; Maze/Optimal Workshop for unmoderated.- Repository & synthesis: Dovetail for tagging and insights; Notion for playbooks and intake.- Collaboration: Figma + FigJam for journeys; Slack for notifications; Miro for workshops.

**Request SLAs & Intake**- Public intake form (Notion/Airtable): purpose, desired outcomes, impact, timeline, audience, effort estimate.- Triage SLA: auto-acknowledge 24h; initial scoping response 3 business days.- Commitment window: low‑effort requests (<1 week) scheduled within 2 weeks; strategic/complex within 4–6 weeks.

**Triage Process**- Weekly 30‑min research council (researchers + leads): score requests via RICE (reach, impact, confidence, effort) and alignment to quarter goals.- Route: green = citizen or embedded researcher; amber = researcher-led with ops support; red = strategic deep dive.- Fast lane (urgent customer-blocking issues): expedited within 48–72 hours.

**QA & Maintaining Rigor**- Standard codebook and tagging taxonomy in Dovetail; mandatory fields in brief.- Peer review: every study readout reviewed by another researcher before distribution.- Inter-rater reliability checks quarterly on tagging.- Monthly randomized audit of 10% of studies for consent, recruitment quality, and bias checks.- Continuous training: monthly brown-bags, hands-on workshops for citizen researchers; templates updated via feedback loop.

**Metrics**- Throughput (# studies/month), time-to-insight, stakeholder satisfaction, action rate (recommendations implemented).- Quarterly review to re-balance staffing between researchers and ops.

Example: I’d pilot this for two quarters: hire one research-op, create the intake + brief template, run trainings, and measure throughput and quality — iterate based on audit and stakeholder feedback. This balances speed, scale, and rigor while embedding research across 8 teams.

HardTechnical

39 practiced

Design an accessibility evaluation protocol for a complex interactive timeline component with drag-and-drop and keyboard navigation. Specify participant selection criteria (including assistive tech users), tasks to validate keyboard and screen-reader flows, a mix of automated and manual checks, success criteria, and how you would produce developer-facing tickets with reproducible steps and artifacts.

Sample Answer

**Overview & goals**Validate that the interactive timeline (drag/drop, reordering, range selection, zoom) is fully operable via keyboard, correctly exposed to screen readers, and free of common accessibility violations. Produce actionable developer tickets with reproducible steps and artifacts.

**Participant selection**- 6–8 participants total: - 2–3 keyboard-only users (no assistive tech) - 2 users who regularly use screen readers (NVDA or JAWS on Windows; VoiceOver on macOS/iOS) - 1 user with motor impairments who uses alternative input (switch/voice) - 1–2 neurodiverse participants (attention/processing differences)- Recruit based on experience with complex interactive widgets and product-relevant tasks.

**Test tasks (manual, moderated)**- Keyboard navigation: - Focus entry: Tab into timeline → verify visible focus, landmark annunciation. - Item selection: Arrow/right-left to move between events; Space/Enter to open details. - Drag-and-drop with keyboard: Select event → activate “grab” key (Space) → use arrow keys to move → confirm drop (Space/Enter). Observe focus management and announcements. - Range resize: Focus range handle → Arrow keys adjust start/end; verify live value announcement. - Zoom & pan: Keyboard shortcuts to zoom in/out and pan; verify focus remains and content is reachable.- Screen-reader flows: - Read item list: Ensure role (list/listitem), labels, and date ranges are announced. - Drag/drop announcement: When grabbing/moving, screen reader should announce “grabbed”, current position, and “dropped” on release. - Live region updates: When timeline updates (filter/zoom), proper aria-live polite/assertive used.- Error/edge tasks: - Attempt invalid drop (overlap) and confirm accessible error message and focus routing. - Mobile touch and VoiceOver gestures (if applicable).

**Automated + semi-automated checks**- Run axe-core and Lighthouse for baseline WCAG 2.1 AA violations (color contrast, ARIA misuse).- Use Pa11y or jest-axe in CI for regressions.- Accessibility tree snapshots (axe or Chrome DevTools) for critical states (grabbed, dragging, dropped).- Keyboard-only automated smoke tests using Puppeteer/Playwright to simulate tab/arrow sequences and assert focus order and element states.- Use screen-reader automation (NVDA+IA2 APIs, VoiceOver scripts) for regression assertions where feasible.

**Success criteria / metrics**- Functional: All core tasks completed by 90% of participants without assistance; errors <=1 per task on average.- Screen-reader: Announcements present and meaningful for 95% of critical actions (grab, move, drop, resize).- Automated: Zero new critical/serious WCAG violations; contrast >= 4.5:1 for text.- Usability metrics: Task time comparable to baseline (±20%); SUS/accessibility satisfaction scores improved or within acceptable range.- No blocking focus traps; focus order logical and predictable.

**Ticketing & developer handoff**For each issue create a ticket with:- Title + severity (WCAG reference) and priority.- Repro steps (numbered), e.g.: 1. Open /timeline. 2. Tab into timeline until event “Q2 release” receives focus. 3. Press Space to grab; press Arrow Right twice; press Space to drop. 4. Actual: Screen reader says “dropped” but announces wrong date. 5. Expected: Announce new date/time and position.- Attach artifacts: - Short screen recording (screen + microphone) of the failing flow. - Accessibility tree snapshot and DOM excerpt (copy/paste). - Axe/Lighthouse report snippet with JSON. - Keyboard trace from automation (Playwright script or recorded keystrokes). - Suggested fix notes: ARIA role/attribute changes, focus management code snippet, WCAG success criteria references.- Repro label: browser/OS/AT combination used (e.g., Chrome 117 + NVDA 2023.3).- Test case id linking to canonical test matrix so dev can regression-test fix.

**Follow-up**- Pairing session with dev to reproduce and verify fix.- Add automated regression test and include test in CI.- Update component documentation and pattern library with keyboard interaction spec, aria usage, and examples.

Unlock Full Question Bank

Get access to hundreds of User Research and Discovery interview questions and detailed answers.

Join thousands of developers preparing for their dream job.