Background Goals Questions

Background, Goals, and Questions

Note

Source alignment: reflects the “start building a research plan: project background, research goals, and research questions” reading and the example research plan sections.

This section turns a vague idea of “testing the prototype” into a clear plan. It captures context, intent, and the specific questions the study must answer before you recruit participants.

Project Background

• Product and context
  • What the product/prototype is, who it serves, and the problem space.
  • Stage and fidelity: paper, low‑fi, clickable, high‑fi; what is in/out of scope for testing.
• Prior research and constraints
  • Summarize insights from earlier courses (empathize/define/ideate) that inform this study.
  • Known risks, assumptions, and technical or policy constraints that might affect scenarios.
• Target scenarios and tasks
  • Core jobs‑to‑be‑done that the study will exercise (e.g., onboarding, search, checkout).
  • Dependencies and data/setup needs for realistic tasks (seed accounts, content, test data).
• Data and privacy guardrails
  • Identify any data you must avoid collecting (e.g., SPII) and how participant privacy will be protected.

Note

Purpose: get the whole team on the same page before the study starts. Keep it concise, include prior attempts/insights, and state how new insights will be used and what decisions they will drive.

Research Goals

• Outcome‑oriented, not method‑oriented
  • State what you intend to learn or validate (not “run 8 interviews”).
  • Link each goal to a product decision (e.g., “decide between A/B navigation patterns”).
• Typical goal themes
  • Validate that users can complete core tasks without assistance.
  • Identify major usability issues and their severity/impact.
  • Assess comprehension of labels, information architecture, and feedback messages.
  • Evaluate accessibility blockers and accommodation needs.
  • Gauge perceived ease, confidence, and satisfaction for key flows.
• Success alignment
  • Define what “good enough” looks like for this iteration (benchmarks, thresholds, guardrails).
  • Capture risks to validity (e.g., prototype gaps, learning effects) and how you will mitigate them.

Tip

Match goal type to timing: foundational (why/if to build), design (how to build), and post‑launch (whether it worked as expected).

Research Questions (RQs)

• Characteristics
  • Specific, actionable, and answerable; directly tied to goals and tasks.
  • Neutral phrasing; avoid implying the expected path or solution.
• Coverage
  • Discovery of where users expect to start and how they navigate.
  • Comprehension of terminology and visual hierarchy.
  • Error recovery and guidance clarity when users get stuck.
  • Accessibility: keyboard, screen reader, color contrast, target sizes, captions.
• From RQs to tasks
  • The script should operationalize each RQ into prompts and observations, plus KPIs where relevant.
  • Keep the wording neutral and user‑centric to avoid leading participants toward a specific path.
• Not literal interview questions
• RQs are not the verbatim questions you’ll read to participants; those live in the script. RQs are the handful of study‑level questions your research must answer and will structure your readout.

Examples: Background

• Product: Mobile app to find and book community classes.
• Audience: Adults new to the city; varying tech literacy; some screen‑reader users.
• Prototype: Clickable Figma; flows: search, filter, booking, cancel.
• Constraints: No real payments; fake data; booking confirmation mocked.

Examples: Goals

• Validate if first‑time users can discover and book a class.
• Identify top 5 usability issues in search/filter.
• Assess whether “Enroll” vs. “Book” label affects comprehension.
• Ensure screen‑reader users can navigate results and select a class.

Example Research Questions

• Onboarding and orientation
  • Where do users expect to start finding classes? Why?
  • Do users recognize the primary action on the home screen?
• Search and filter
  • Can users narrow results effectively using filters and sort?
  • Which filter names or placements cause confusion?
• Details and decision making
  • Do users find enough information to choose confidently (location, time, price)?
  • What information is missing or distracting at decision time?
• Booking flow
  • Can users complete booking without assistance? Where do they hesitate or backtrack?
  • Are error messages and form validation clear and helpful?
• Accessibility
  • Can keyboard and screen‑reader users perceive, operate, and understand all steps?
  • Are touch targets large enough and focus order logical?
  • Do error announcements surface to assistive technologies with the right timing and context?

Tip

Draft goals first, then derive RQs. Keep RQs concise and map each to a task and measure so analysis rolls up cleanly to decisions.

Traceability Tips

• Create a simple matrix that maps goals → RQs → tasks/KPIs → findings/recommendations.
• Use consistent identifiers (G1, RQ1.2, T3, KPI‑A) in notes and your readout for easy cross‑reference.
• In your readout, group findings under goals; link each to specific evidence (clip/quote/KPI) and a recommendation.

Summary: Set a concise background that explains why the study is needed and how insights will be used; define research goals that fit where you are in the lifecycle; and write research questions that are neutral, specific, and actionable so they can be translated into tasks and measures.

Summary: Background anchors the why; goals state intended learning; research questions specify what to observe. Clear alignment ensures your script, KPIs, and analysis produce decision‑ready insights.