User Research and User Centered Design Questions

Covers the full practice of grounding design decisions in evidence about users. Topics include research methodologies such as user interviews, surveys, contextual inquiry, usability testing, analytics review, split testing, competitive analysis, and observational studies; creating and using personas, user journeys, and mental models; synthesizing qualitative and quantitative findings into actionable insights; validating designs and hypotheses through testing and measurement; ideation and iterative design cycles that respond to research findings; and practical considerations across levels from junior basics through mid level independent planning and senior strategy for integrating research into product workflows.

MediumTechnical

48 practiced

Define the most appropriate success metrics for a redesign intended to reduce feature discovery time in a complex analytics product. Propose primary and secondary metrics, instrumentation events required, and guardrails to identify regressions in other areas (e.g., power users' workflows).

Sample Answer

Start with a clear goal: reduce time-to-discover key features for typical users without harming advanced workflows. Define success metrics in tiers, list instrumentation events, and set guardrails to catch regressions.

Primary metrics (directly tied to goal)- Median Feature Discovery Time: time from session start (or task intent signal) to first use of a targeted feature.- Discovery Rate: % of users who use the targeted feature at least once within N sessions/days.- Time-to-Activation for new users: same as above restricted to cohorts <30 days.

Secondary metrics (behavioral and business impact)- Task Completion Rate: % completing common tasks that rely on discovered features.- Feature Retention: % who continue using the feature after 7/30 days.- NPS/task satisfaction for discovery flow (survey trigger after first discovery).

Instrumentation events (required)- session_start, page_view, navigation_click (with context: page, component_id)- feature_hint_shown / tooltip_shown (id, user_cohort)- feature_discovered (feature_id, discovery_path, timestamp)- feature_used (feature_id, action_type, duration)- task_completed (task_id, success, time_taken)- user_profile (role, power_user_flag, tenure)- survey_shown / survey_response

Key properties to capture: user_id (anonymous id), timestamp, session_id, cohort tags, device, A/B variant.

Guardrails to detect regressions- Monitor power-user funnels: power_user_feature_latency (time-to-action for advanced workflows) and task completion rates for top 10 advanced flows; set alert if drop >5% or time increases >10%.- Performance & error metrics: page_load_time, API_latency, error_rate — alert if degraded.- Business KPIs: retention, engagement, conversion — flag significant negative deltas vs. baseline.- Run A/B with segment-specific analysis (new vs power users). Use statistical significance and minimum detectable effect; if overall metric improves but power-user metrics regress beyond threshold, roll back or iterate.

Operationalize- Baseline metrics before launch, define targets (e.g., reduce median discovery time by 30%, increase discovery rate by 20%), and set automated dashboards and alerts. Combine quantitative metrics with qualitative feedback (session replays, interviews) for root-cause.

HardTechnical

41 practiced

You're designing an A/B test to compare two onboarding flows and expect a small effect size (~2% improvement in conversion). Describe how you'd design the experiment: hypothesis, sample size estimation, primary metric, experiment duration, and how you'd handle multiple comparisons across segments.

Sample Answer

Hypothesis- H0: New onboarding conversion = Control conversion. H1: New onboarding conversion > Control conversion. Define whether the 2% is absolute (e.g., 20% → 22%) or relative (2% relative = 20% → 20.4%) — design assumes absolute 2pp unless stated.

Primary metric- Primary: First-week conversion to key outcome (e.g., completed onboarding or first paid conversion). Use a binary conversion measured per user. Secondary metrics: time-to-first-success, retention at 7/30 days, and NPS (for guardrails).

Sample size estimation- Choose α = 0.05 (two-sided) and power = 0.8–0.9. Use standard two-proportion formula: n_per_arm = [ (Z_{1-α/2}*√(2p(1−p)) + Z_{power}*√(p1(1−p1)+p2(1−p2)) )^2 ] / (p2−p1)^2- Example: baseline p1 = 0.20, p2 = 0.22 (Δ=0.02), α=0.05, power=0.8 → roughly n ≈ 24,000 per arm. If power=0.9, n increases ~1.5x.- Account for expected loss (bots, duplicate users) and clustering: inflate sample by 10–20% if needed.

Experiment duration- Run until both: (a) required sample per arm is reached, and (b) you observe at least one full user cycle relevant to metric (e.g., 7–14 days for retention). Avoid peeking — use pre-registered stopping rules or sequential methods (alpha spending) if you need interim looks.

Multiple comparisons / segments- Pre-specify primary analysis and a small number of planned subgroup analyses (e.g., new vs returning, mobile vs web). For multiple exploratory segments, control false discovery: - Use hierarchical testing: test global effect first; only if significant, test subgroups. - Or apply Benjamini–Hochberg to control FDR for multiple hypotheses. - If segments are few and critical, Bonferroni is conservative but acceptable.- Consider stratified randomization to ensure balance across segments and use interaction tests rather than separate tests per segment.

Practical considerations- Pre-register metric definitions, analysis plan, and sample-size assumptions. Monitor implementation fidelity, instrumentation, and traffic leakage. Report effect size, confidence intervals, and business impact (projected revenue lift) not only p-values.

EasyTechnical

40 practiced

Explain mental models and describe an exercise you would run with cross-functional teams (design, engineering, marketing) to surface users' mental models for the product’s search feature. Include delivery artifacts and how this would influence design decisions.

HardTechnical

54 practiced

As PM, explain how you would set up and maintain cross-functional collaboration between research, design, and engineering to ensure research artifacts (recordings, insights, recommendations) are discoverable and linked to roadmap tickets. Include tooling, naming conventions, and handoff rituals.

Sample Answer

Situation / goal: Ensure research artifacts are consistently discoverable and explicitly tied to roadmap work so teams make decisions using evidence, reduce duplicate research, and speed implementation.

Setup (tools + structure):- Research repository: Dovetail or Notion for transcripts, tags, and highlights. Store recordings in a linked cloud folder (Drive/S3) with player support (Lookback/Hotjar for session playback).- Roadmap & tickets: Jira (or ClickUp) for backlog; integrate with the research repo via links and automation (Dovetail-Jira or a Zapier/GitHub Action).- Design files: Figma + comments; link frames to research insights.- Search & index: Weekly export to Confluence/Notion index page with a living table of insights.

Naming & metadata conventions (enforceable):- File/Artifact name pattern: YYYYMMDD_Project_Feature_Method_Presenter_v1 e.g., 20251201_Payments_CheckoutUsability_Interview_Sam_v1- Required metadata fields in research repo: project, feature, personas, method, date, tags (insight, pain-point, hypothesis), confidence (low/med/high), recommended action.- Jira ticket fields: Research Link (single link), Research Summary (1–2 bullets), Insight IDs (comma-separated), Confidence, Acceptance Criteria referencing insights.

Handoff rituals & cadence:- Research kickoff: PM/Design/Eng attend research plan; PM creates ticket placeholder with hypotheses and required success metrics.- Weekly research sync (30 min): readouts of top 3 insights; PM tags which backlog items to update.- Readout ritual before refinement: For any story entering grooming, PM ensures Research Link and a 1-slide summary attached; devs must review before sizing.- Design → Eng handoff: Designer links Figma frames & research insights in the ticket; 15‑minute walkthrough in refinement.- Post-ship retrospective: 30-day follow-up to add outcomes to original research artifact.

Ownership & enforcement:- ResearchOps owns repository hygiene; PM owns linkage to roadmap; engineering/design teammates required to confirm in ticket checklist.- Automation: Use Jira automation to block transitions if Research Link/summary missing for tickets tagged “requires-research”.- KPIs: % of roadmap tickets with research links, time from insight to ticket linkage, reuse count of insights.

Example ticket checklist:- [ ] Research Link present- [ ] 1‑line insight summary- [ ] Confidence level set- [ ] Designer & Engineer acknowledged

Why this works:- Single source of truth + enforced metadata makes artifacts searchable.- Rituals create predictable handoffs and shared accountability.- Automation + KPIs sustain behavior rather than relying on memory.

This approach reduces ambiguity, speeds decisions, and creates a clear audit trail from evidence → decision → shipped outcome.

MediumSystem Design

50 practiced

Your design team proposes a change to the design system button component that affects spacing and focus styles. Describe how you'd validate this change with users and engineering, what rollout strategy you'd recommend, and how you'd measure success post-rollout.

Sample Answer

Requirements & constraints:- Confirm scope: spacing and focus styles across variants/platforms (mobile, desktop, high-DPI), accessibility (WCAG), and components that inherit button styles.- Success criteria: maintain or improve task completion, accessibility pass, no regressions in layout or performance.

Validation with users:- Prototype & usability tests: create interactive prototypes (Figma + HTML/CSS) showing old vs new spacing/focus in real tasks (form submit, modal actions). Run 5–8 moderated tests and 20–50 unmoderated sessions to capture task completion, perceived clarity, and confusion around focus state.- Accessibility testing with screen-reader users and keyboard-only flows; run Axe/Pa11y automated checks and at least 3 manual keyboard+NVDA/VoiceOver sessions.- Qualitative feedback: heatmaps and short surveys on clarity/comfort.

Validation with engineering:- Impact analysis: engineering assesses CSS surface area, component API changes, potential visual regressions, bundle size, and cross-browser issues.- Implementation plan: build component behind a feature flag, provide clear tokens (spacing, focus token) and migration guide.- Automated visual regression tests (Percy/Chromatic) and unit/interaction tests verifying focus outlines and spacing at breakpoints.- Accessibility sign-off from an engineer or accessibility specialist.

Rollout strategy:- Feature-flagged gradual rollout: start with internal + 1% of users, monitor, then 10%, 50%, 100% over days/weeks depending on risk.- Canary on low-risk pages first (marketing/landing pages) then critical flows (checkout, account actions).- Provide a quick rollback path by toggling flag and versioning tokens.

Measurement & KPIs:- Quantitative: click-through rate on CTA, conversion rate on critical flows, task completion/time in usability tasks, keyboard navigation success rate, focus-visible detection (analytics event when element receives keyboard focus), layout shift / CLS, and CSS/JS bundle size.- Qualitative: NPS snippets, support tickets mentioning UI confusion, session recordings for unexpected interactions.- Accessibility: automated pass rate and manual audit results.

Success criteria & post-rollout:- No statistically significant negative change in primary conversion metrics; improved keyboard accessibility metrics; zero high-severity accessibility failures.- If regression detected, pause rollout, hotfix spacing/focus tokens, run another validation batch.- After stable rollout, update design system docs, publish migration guide, and schedule a retrospective to capture lessons learned.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.