Ux Research Discovery Testing

UX Research Discovery Testing

Purpose

Help an agent make better product, UX, UI, and frontend recommendations by grounding them in user goals, observed behavior, business outcomes, and testable evidence. Use this skill to choose just-enough research methods, write interview and usability-test plans, synthesize findings, identify opportunities, and explain evidence-backed product decisions.

It is an operating manual for doing practical research under real product constraints.

When to use this skill

Use this skill when the user asks you to:

• Plan discovery, customer interviews, field visits, contextual inquiry, or stakeholder interviews.
• Review, critique, redesign, or generate a UI where user behavior, task success, accessibility, or product outcomes matter.
• Create an interview guide, screener, usability-test script, research plan, synthesis framework, opportunity map, journey map, persona, task flow, or evidence-backed recommendation.
• Decide what to build, improve, remove, or test next.
• Evaluate a prototype, live UI, design system component, onboarding flow, form, navigation model, dashboard, empty state, error flow, or content hierarchy.
• Turn qualitative notes, analytics, survey findings, support tickets, screenshots, or observations into product decisions.

When not to use this skill

Do not use this skill as the primary tool when the task is only:

• Visual UI styling with no user goal, task, behavior, or product decision involved.
• Brand identity, illustration, or aesthetic exploration unrelated to use.
• Statistical analysis requiring rigorous sampling, inferential statistics, or experimental design beyond lightweight product research.
• Legal, medical, or regulated human-subjects research advice. In those cases, recommend qualified review and use only general UX planning guidance.
• Production frontend coding where the user has already specified the user problem, behavior, accessibility requirements, and interaction design.

Core principles

1. Start with the decision, not the method. Identify the product, design, or frontend decision the research must inform. Choose only the research activities that reduce uncertainty for that decision.

1. Separate business questions from research questions. Convert “What should we build?” into researchable questions about people, tasks, motivations, contexts, constraints, and current workarounds.

1. Prefer behavior and context over preference claims. Treat “Do you like it?” and “What do you want?” as weak evidence. Ask for recent, specific stories; observe work; test tasks; and inspect real artifacts.

1. Balance customer value and business value. Do not optimize only for shipped features, executive preferences, or isolated user requests. Frame work around outcomes: a behavior change that creates customer value and supports the business.

1. Use the smallest credible research loop. Default to lightweight, iterative research that can influence the next decision. Research should accelerate learning, not become theater.

1. Make assumptions explicit. Before research or critique, list assumptions about users, contexts, motivations, constraints, accessibility needs, and business goals. Convert risky assumptions into testable questions.

1. Use mixed evidence. Qualitative work explains why and how; quantitative evidence shows what, where, how often, and whether a change moved a metric. Do not ask one method to answer every kind of question.

1. Recruit for behavior, role, and contrast. Recruit people who have relevant experience with the task or context. Include adjacent roles, non-users, recent defectors, competitor loyalists, extreme users, and affected stakeholders when they can reveal constraints or opportunities.

1. Research is a team sport. Involve product, design, engineering, content, accessibility, support, sales, and other stakeholders where useful. Direct exposure to users is more persuasive than a long report.

1. Synthesize visibly. Use maps, affinity clusters, opportunity trees, task flows, journey maps, screenshots, and short evidence notes to create shared understanding.

1. Protect participants. Explain the purpose, consent, recording, confidentiality, incentives, and use of findings. Separate consent from NDAs and incentives. Respect participant time and welfare.

1. Recommend action, not just findings. Findings should lead to prioritized decisions, risks, next tests, and product changes.

Default recommendations

Use these defaults unless the user provides stronger context.

| Area | Default recommendation | Why this is usually best | Override when | |---|---|---|---| | Research goal | Define one decision and one primary research question before choosing methods. | Prevents unfocused research and over-asking. | The user is explicitly exploring a broad product area. | | Discovery method | Start with 5-8 semi-structured interviews or contextual sessions anchored in recent real experiences. | Fast enough for product work and rich enough to reveal behaviors, context, language, and assumptions. | The task is safety-critical, highly regulated, or needs statistical confidence. | | Interview cadence | For ongoing product teams, schedule weekly customer contact. For one-off work, run the smallest batch that can inform the next decision. | Continuous exposure prevents stale assumptions. | The team has no participant access; then use secondary research, support logs, analytics, or internal experts while flagging lower confidence. | | Interview style | Use a guide, but keep it flexible. Ask about recent stories, examples, artifacts, workarounds, and context. | Specific episodes beat abstract opinions. | The study requires comparable metrics across participants. | | Usability testing | Test realistic tasks with representative or high-learning participants; ask participants to think aloud only when it does not distort the task. | Task performance reveals usability issues better than opinions. | The product context makes think-aloud unsafe, unrealistic, or too disruptive. | | Sample size | Start small, iterate, and keep recruiting. Use small tests to find issues, not to estimate population prevalence. | Small batches expose high-impact issues quickly. | The user needs prevalence, segmentation, or statistical confidence. | | Participant criteria | Recruit by behavior, task, context, and relationship to the product, not demographics alone. | Demographics rarely describe the job-to-be-done or mental model by themselves. | Demographics directly affect access, safety, needs, culture, or equity. | | Synthesis | Analyze immediately after sessions with multiple team members. Separate observations from interpretations and recommendations. | Reduces memory loss, bias, and report-only handoff. | Confidentiality or team structure prevents broad participation. | | Opportunity framing | Map findings into outcomes, opportunities, candidate solutions, assumptions, and tests. | Keeps teams from jumping from one quote to a feature. | The user only needs a quick usability defect list. | | Evidence strength | Treat observed behavior, task success, analytics, and controlled tests as stronger evidence than preference surveys. | Reduces credulity and self-report bias. | The research question is about awareness, sentiment, brand perception, or stated expectations. | | Reporting | Produce a concise decision memo: decision, evidence, confidence, recommended action, alternatives, risks, and next test. | Stakeholders need action, not a research archive. | The user requests a formal report or compliance artifact. | | Accessibility | Include accessibility needs as research criteria and testable requirements from the start. | Accessibility changes task context, interaction cost, and implementation choices. | Never fully omit; only scale depth to project scope. |

Required user questions

Ask only when the answer materially changes the research plan, critique, or recommendation. Use the recommended default first; do not ask routine best-practice questions.

Ask when the product decision is unclear

question({
  question: "What decision should this research or UX critique help you make?",
  recommended_default: "Decide the next product/design change that best improves the user's primary task while supporting the business outcome.",
  options: [
    "Decide what problem or opportunity to pursue",
    "Decide which solution or concept to build",
    "Find usability issues in an existing UI/prototype",
    "Prioritize improvements for a shipped product",
    "Other / custom"
  ]
})

Ask when the target user or context is unclear

question({
  question: "Who is the primary user or participant group, and what real-world context should we design or test for?",
  recommended_default: "Recruit people who recently tried to complete the target task, plus one adjacent or contrasting group if it may reveal hidden constraints.",
  options: [
    "Current users performing the target task",
    "Prospective users or non-users",
    "Competitor users / recent switchers",
    "Internal users, operators, support, or admins",
    "Other / custom"
  ]
})

Ask when the success outcome is unclear

question({
  question: "What user behavior or business outcome should improve if this work succeeds?",
  recommended_default: "Use one user behavior metric tied to a business outcome, such as task completion, activation, retention, conversion, reduced support contact, or successful self-service.",
  options: [
    "Task completion / fewer errors",
    "Activation or onboarding success",
    "Conversion or revenue action",
    "Retention or repeat use",
    "Support reduction or operational efficiency",
    "Other / custom"
  ]
})

Ask when participant access or research constraints are unclear

question({
  question: "What access do we have to users, artifacts, analytics, and the product/prototype?",
  recommended_default: "Use the best available evidence now, flag confidence, and propose the next smallest research loop.",
  options: [
    "Can interview or observe users directly",
    "Can run moderated or unmoderated usability tests",
    "Have analytics/support tickets/session recordings",
    "Only have stakeholder knowledge right now",
    "Other / custom"
  ]
})

Ask when accessibility needs may change the plan

question({
  question: "Are there known accessibility needs, assistive technologies, language needs, or situational constraints that must be included?",
  recommended_default: "Plan for keyboard, screen reader, magnification, color contrast, reduced motion, cognitive load, mobile constraints, and diverse language proficiency unless the product scope clearly narrows this.",
  options: [
    "Known assistive technology users",
    "Known cognitive/language/access constraints",
    "No known data; include baseline accessibility coverage",
    "This is an accessibility-specific study",
    "Other / custom"
  ]
})

Workflow

1. Triage the request

Identify:

• Product or feature area.
• Stage: discovery, concept, prototype, shipped UI, redesign, or ongoing optimization.
• Decision to be made.
• Target users, affected roles, and context.
• Existing evidence and artifacts.
• Risks: accessibility, privacy, safety, trust, business impact, technical constraints.
• Deadline and research access.

If any of these are missing but essential, ask one focused question. Otherwise proceed with assumptions and label them.

2. Choose the research mode

Use the research mode that matches the decision:

• Generative / exploratory: Use when the team does not yet know the right problem or opportunity. Use interviews, field visits, diary/logging, stakeholder interviews, secondary research, support-ticket review, and competitive observation.
• Descriptive / explanatory: Use when the problem exists but the team needs to understand the workflow, context, user groups, mental models, tasks, or constraints.
• Evaluative: Use when there is a concept, prototype, UI, flow, or competitor experience to test. Use task-based usability testing, heuristic review, accessibility review, cognitive walkthroughs, and prototype tests.
• Causal / quantitative: Use when a shipped product has measurable behavior and the team needs to know whether a change affects a metric. Use analytics, A/B tests, funnel analysis, and task metrics, while using qualitative work to explain why.

3. Frame the decision and assumptions

Before writing a plan or recommendation:

1. State the business outcome.
2. State the user behavior that would drive it.
3. State the target user/context.
4. List known facts.
5. List assumptions.
6. Identify the riskiest assumptions.
7. Choose the smallest method that can reduce those risks.

4. Plan lightweight discovery

For discovery or interviews, produce:

• Research objective.
• Research questions.
• Participant criteria based on behavior/context.
• Recruiting channels and screener questions.
• Interview/session guide.
• Consent and recording plan.
• Roles: moderator, note-taker, observer, recruiter, analyst.
• Schedule and synthesis plan.
• Decision output: opportunity map, findings memo, journey/task map, or recommendations.

5. Conduct interviews or contextual sessions

Use these moderation rules:

• Start with consent, purpose, timing, confidentiality, recording, and permission to skip questions.
• Build rapport with just enough small talk.
• Ask for recent, concrete stories: “Tell me about the last time…”
• Ask follow-ups before moving on.
• Use silence after asking and after answers.
• Use the participant’s language.
• Ask about artifacts, tools, environment, interruptions, workarounds, triggers, relationships, and constraints.
• Avoid putting answers in the question.
• Avoid teaching, fixing, selling, or defending the design during the session.
• Save participant questions or troubleshooting for the end.
• Capture exact phrases where useful for interface language.

6. Plan usability testing

For usability tests, produce:

• Test objective and product decision.
• Artifact under test: sketch, prototype, live UI, competitor flow, or component.
• Participants and why they are high-learning.
• Critical tasks in realistic wording.
• Success criteria: completion, errors, time/effort, confidence, comprehension, accessibility, and severe friction.
• Moderator script.
• Data capture plan.
• Severity rubric.
• Post-test synthesis and next action.

Task wording should describe the participant’s goal, not the UI steps. Do not ask participants to find a specific button unless the button is the object being tested.

7. Synthesize evidence

During synthesis:

1. Review notes and recordings quickly.
2. Capture observations, not interpretations, first.
3. Cluster behaviors, quotes, obstacles, motivations, workarounds, tools, triggers, environments, and relationships.
4. Distinguish what happened, what it means, and what to do.
5. Map findings to opportunities, assumptions, and candidate tests.
6. Prioritize by customer impact, business impact, frequency/confidence, risk, accessibility impact, and implementation effort.
7. State confidence level and what would change your mind.

Use visual artifacts when they help: affinity diagram, journey map, task flow, opportunity solution tree, screenshot forensics, mental model map, workflow diagram, or severity matrix.

8. Make research-backed recommendations

Every recommendation should include:

• Product decision or change.
• Evidence used.
• User problem or opportunity.
• Expected behavior change.
• Business value.
• Accessibility and inclusion implications.
• Frontend/design-system implications.
• Tradeoffs and risks.
• Confidence level.
• Next test or metric.

Prefer “Based on the evidence, do X next because…” over “Users said they want X.”

Decision framework

Evidence ladder

Us

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: hueyexe
• Source: hueyexe/frontend-agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.