Research Planning and Fieldwork Questions

Intro (context)
I’d frame each interview as 30–45 minutes focused on outcomes, users, and measurable success. Questions probe goals, metrics, data needs, and constraints.

Product Manager (2–3)

• What top user problems should the dashboard solve and for which personas? (ask for examples)
• What business KPIs must this dashboard move, and what success thresholds look like in 3 and 6 months?
• Which decisions should stakeholders be able to make from the dashboard vs. what’s informational only?

Engineering Lead (2–3)

• What data sources, latency, and update cadence are feasible given current pipelines?
• What performance, security, and access-control constraints should I design for?
• Which implementation risks (ETL, scale, permissions) would most affect UX delivery?

Sales Director (2)

• What sales workflows must the dashboard support and what actions do reps take after seeing insights?
• What metrics or visualizations would increase adoption and how would your team measure ROI?

Technique to surface assumptions/constraints
I use an Assumption Mapping workshop: list assumptions (user, data, technical, business), rate impact/uncertainty, and document each with owner and validation plan. Capture as a living board (Miro/Figma) linked to interview notes and prioritized for validation in prototypes or data checks.

Overview / Goal
I will validate whether the mid-fidelity prototype supports clear onboarding and a smooth first-time purchase for new users, uncover friction points, and gather improvements.

Research questions

• Can new users complete account setup and make a first purchase without assistance?
• Where do users hesitate or make errors during onboarding and checkout?
• Is critical information (shipping, pricing, payment) discoverable and understandable?

Tasks & success criteria

1. Create an account and complete onboarding.
   • Success: finishes onboarding screens and lands on home/dashboard without help; no more than 1 critical error.
2. Find a product in category X and view details.
   • Success: reaches product detail page within 3 minutes and views specs/pricing.
3. Add product to cart and proceed to checkout.
   • Success: adds item and reaches payment screen with correct cart contents.
4. Complete purchase using provided test card.
   • Success: sees order confirmation and order number; no payment errors.

Quantitative metrics

• Task success rate (per task)
• Time on task (seconds)
• Error rate / critical failures
• System Usability Scale (post-test)

Qualitative probes

• Ask: “What did you expect to happen?” “What’s confusing?” “How would you describe this flow to a friend?” Observe hesitation, comments, and navigation rationale.

Stop criteria

• Stop early if 3 consecutive participants encounter the same critical failure blocking completion, or after 8–10 participants if diminishing returns observed and findings stabilize.

What problem framing means (in my words)
Problem framing is defining the real user problem we aim to solve before designing a solution. It aligns stakeholders on who the user is, the context they’re in, the user’s goal, and what success looks like. Good framing prevents building feature-first solutions that miss root causes and ensures research and design questions are measurable and testable.

Why it’s critical

• Focuses research and testing on the right assumptions
• Reduces wasted effort and scope creep
• Enables clear success metrics for iteration and product decisions

Poorly framed problem (what it sounds like)
“We need to add a faster checkout because users are dropping off.”

Well-framed problem statement
“Busy weekend shoppers (user) abandoning purchase during checkout on mobile (context) need a simpler, trustworthy payment flow (goal) so that mobile checkout completion rate increases from 48% to 65% within three months (measurable outcome).”

Framework & goal
Understand daily workflows, pain points, and decision moments when people use a personal‑finance app over seven days to inform feature priorities and UX flows (onboarding, budgeting, transaction categorization, alerts).

Recruitment

• 20–25 participants stratified by experience: 8 power users, 8 casual users, 8 new users; balanced by income bracket and age.
• Recruit via in‑app opt‑in, social ads, and user panels; screen with a 5‑min survey (devices, primary finance tasks, permission to share anonymized data).

Prompt cadence & format

• Day 0: onboarding video + consent + quick baseline survey (financial goals, pain points).
• Daily: morning micro‑prompt (text push/email) asking planned finance tasks for the day; evening prompt with 3 structured items: what you did (select + short text), a 1–5 frustration/usefulness rating, and optional voice note/photo of receipts/screens.
• Midweek check‑in (Day 4): 5‑min contextual interview via chat/video.
• Exit (Day 7): final survey + 20‑min interview.

Data capture

• Self‑reports: structured responses, free text, voice notes, photos.
• Passive telemetry (with consent): screen flows, time on task, feature usage, event logs.
• Optional screen recordings for task instances.

Incentives & engagement

• Tiered incentive: $20 base + $5/day completed + $10 bonus for completing interviews and >80% prompts.
• Daily micro‑gamification: progress bar + personalized thank‑you messages; reminders only twice/day.

Analysis plan

• Quantitative: frequency of feature use, time‑on-task, completion rates; cluster by user segment.
• Qualitative: thematic coding of evening entries and interviews to extract needs, pain points, decision contexts; create journey maps showing emotional valence across seven days.
• Synthesis: identify top opportunity areas, personas, and 3 prioritized design recommendations with supporting evidence (quotes, session snippets, telemetry). Validate with a small follow‑up usability test.

Immediate safety first

• Pause the session and check participant well‑being; ask direct questions about imminent risk (e.g., “Is anyone in danger right now?”). If there’s immediate danger, follow emergency procedures and call authorities/medical help.
• Separate other participants if group setting to avoid escalation.

Legal reporting obligations

• Know and follow institutional policies and local law: notify my manager and the institution’s legal/compliance or IRB immediately. Provide only factual notes of the observation — date/time/context — avoiding speculation.
• If law requires reporting (e.g., imminent harm, mandatory reporting), coordinate with legal/IRB before contacting external authorities.

Consent and confidentiality

• Revisit consent: explain to the participant what I observed and how it may affect confidentiality limits (what must be reported by law).
• Preserve confidential data: redact identifiable information in notes; store recorded materials securely. Only share with authorized stakeholders (legal, IRB) on a need‑to‑know basis.

Adapting the study and recommendations

• Pause or modify protocols to mitigate harm (remove prompts that encourage illegal misuse; avoid demonstrations).
• Add safety screening and explicit non‑encouragement language to consent and moderator scripts.
• In analysis and recommendations, frame findings as risk signals: prioritize design changes that reduce misuse (e.g., safer defaults, clearer warnings, fail‑safe engineering), and recommend cross‑functional follow‑up with product safety, legal, and engineering for remediation and compliance.
• Document all decisions and communications for auditability.

This approach balances participant safety, legal duties, and ethical research while preserving trust and actionable product guidance.