ux-research
Use this skill when planning user research, conducting usability tests, creating journey maps, or designing A/B experiments. Triggers on user interviews, usability testing, user journey maps, A/B test design, survey design, persona creation, card sorting, tree testing, and any task requiring user experience research methodology or analysis.
design ux-researchusabilityuser-interviewsjourney-mapstestingWhat is ux-research?
Use this skill when planning user research, conducting usability tests, creating journey maps, or designing A/B experiments. Triggers on user interviews, usability testing, user journey maps, A/B test design, survey design, persona creation, card sorting, tree testing, and any task requiring user experience research methodology or analysis.
Quick Start
- Open your terminal or command prompt
- Run:
npx skills add AbsolutelySkilled/AbsolutelySkilled --skill ux-research - Start your AI coding agent (Claude Code, Cursor, Gemini CLI, or any supported agent)
- The ux-research skill is now active and ready to use
ux-research
ux-research is a production-ready AI agent skill for claude-code, gemini-cli, openai-codex. Planning user research, conducting usability tests, creating journey maps, or designing A/B experiments.
Quick Facts
| Field | Value |
|---|---|
| Category | design |
| Version | 0.1.0 |
| Platforms | claude-code, gemini-cli, openai-codex |
| License | MIT |
How to Install
- Make sure you have Node.js installed on your machine.
- Run the following command in your terminal:
npx skills add AbsolutelySkilled/AbsolutelySkilled --skill ux-research- The ux-research skill is now available in your AI coding agent (Claude Code, Gemini CLI, OpenAI Codex, etc.).
Overview
UX research is the systematic study of target users to inform product design and business decisions. It bridges the gap between assumptions and evidence - replacing "we think users want X" with "users told us X because of Y." This skill covers the full research lifecycle: scoping a study, selecting methods, recruiting participants, collecting data, synthesizing findings, and communicating insights that drive action.
Good research is not about proving you are right. It is about reducing the cost of being wrong before you build. Five users in a moderated session will surface 80% of your usability problems for a fraction of what a failed launch costs.
Tags
ux-research usability user-interviews journey-maps testing
Platforms
- claude-code
- gemini-cli
- openai-codex
Related Skills
Pair ux-research with these complementary skills:
Frequently Asked Questions
What is ux-research?
Use this skill when planning user research, conducting usability tests, creating journey maps, or designing A/B experiments. Triggers on user interviews, usability testing, user journey maps, A/B test design, survey design, persona creation, card sorting, tree testing, and any task requiring user experience research methodology or analysis.
How do I install ux-research?
Run npx skills add AbsolutelySkilled/AbsolutelySkilled --skill ux-research in your terminal. The skill will be immediately available in your AI coding agent.
What AI agents support ux-research?
This skill works with claude-code, gemini-cli, openai-codex. Install it once and use it across any supported AI coding agent.
Maintainers
Generated from AbsolutelySkilled
SKILL.md
UX Research
UX research is the systematic study of target users to inform product design and business decisions. It bridges the gap between assumptions and evidence - replacing "we think users want X" with "users told us X because of Y." This skill covers the full research lifecycle: scoping a study, selecting methods, recruiting participants, collecting data, synthesizing findings, and communicating insights that drive action.
Good research is not about proving you are right. It is about reducing the cost of being wrong before you build. Five users in a moderated session will surface 80% of your usability problems for a fraction of what a failed launch costs.
When to use this skill
Trigger this skill when the user:
- Needs to plan a user research study or define research questions
- Wants to design or conduct user interviews or contextual inquiry
- Needs to run or script a moderated usability test
- Asks about creating user journey maps or experience maps
- Wants to design an A/B test, including hypothesis and sample size
- Needs to build a user survey or screener questionnaire
- Asks about creating personas from research data
- Wants to run card sorting or tree testing exercises
- Needs to synthesize qualitative data using affinity mapping
- Wants to write a research findings report or share-out
Do NOT trigger this skill for:
- Pure analytics or quantitative data analysis without a user behavior lens (use a data-analysis skill instead)
- UI/visual design decisions that are not grounded in a research question (use absolute-ui instead)
Key principles
Research questions before methods - Define what decisions your research must inform before choosing a method. "We will run interviews" is not a research plan. "We need to understand why users abandon the checkout flow" is.
5 users find 80% of issues - Jakob Nielsen's landmark finding still holds for formative usability testing. Recruit 5 representative participants per distinct user segment. More sessions do not linearly increase insight - they surface the same issues repeatedly.
Triangulate across methods - No single method answers everything. Pair interviews (why) with analytics (how many) with usability tests (can they do it). Convergent findings across methods are high-confidence findings.
Recruit representative users - Recruiting convenience samples (colleagues, power users, friends) produces data that does not generalize. Screeners must filter for the behaviors and contexts that match your target segment, not just demographics.
Synthesis is where value lives - Raw notes and recordings are not insights. Value is created in the synthesis step: clustering observations into patterns, naming themes, and connecting evidence to design implications. Budget as much time for synthesis as for fieldwork.
Core concepts
Generative vs. evaluative research
| Type | Goal | When to use | Example methods |
|---|---|---|---|
| Generative | Discover problems, needs, and opportunities | Early in a project, before solutions exist | User interviews, diary studies, contextual inquiry |
| Evaluative | Test whether a solution works for users | After a design exists, before or after launch | Usability tests, A/B tests, first-click tests |
Running evaluative research too early (testing mockups of unvalidated concepts) wastes cycles. Running generative research too late (interviewing users after building) surfaces insights you cannot act on.
Qualitative vs. quantitative
| Dimension | Qualitative | Quantitative |
|---|---|---|
| Question type | Why? How? What is the experience? | How many? How often? What percentage? |
| Sample size | 5-20 participants | Hundreds to thousands |
| Output | Themes, quotes, behavioral patterns | Statistics, rates, significance |
| Risk | Hard to generalize; researcher bias | Misses "why" behind numbers |
Neither is superior. Qualitative research generates hypotheses; quantitative research tests them at scale.
Research ops
Research operations (ResearchOps) is the infrastructure that makes research repeatable: participant panels, consent templates, recording tools, repositories, and synthesis workflows. Without it, research knowledge lives in individual researchers' heads and dissipates when they leave.
Bias types to mitigate
| Bias | Description | Mitigation |
|---|---|---|
| Confirmation bias | Seeking evidence that supports existing beliefs | Define hypotheses before fieldwork; use a co-researcher to challenge interpretations |
| Leading bias | Questions that suggest the desired answer | Use open-ended, neutral phrasing; pilot-test your guide |
| Sampling bias | Participants who do not represent target users | Write behavioral screeners; recruit outside your network |
| Social desirability bias | Participants saying what they think you want to hear | Ask about past behavior, not hypothetical preferences; observe over asking |
| Recency bias | Over-weighting the last sessions in synthesis | Synthesize incrementally; weight all sessions equally |
Common tasks
Plan a research study
Use this template before any study begins:
RESEARCH PLAN
=============
Project: [Name]
Date: [Start - End]
Researcher: [Name]
RESEARCH QUESTIONS
1. [Primary question the research must answer]
2. [Secondary questions]
DECISIONS THIS RESEARCH INFORMS
- [Specific product/design/business decision]
METHOD
[Selected method and why it fits the research questions]
PARTICIPANTS
- Target segment: [Description]
- Number: [N per segment]
- Screener criteria: [Behavioral criteria, not just demographics]
TIMELINE
- Recruiting: [Dates]
- Fieldwork: [Dates]
- Synthesis: [Dates]
- Share-out: [Date]
MATERIALS NEEDED
- [Discussion guide / task scenarios / prototype / survey link]
SUCCESS CRITERIA
[How will we know the research answered the questions?]Conduct user interviews
Discussion guide structure:
- Warm-up (5 min) - Rapport-building; ask about their role and context. Never start with your main topic.
- Topic exploration (30-40 min) - Open-ended questions about behavior, not opinion.
- Specific scenarios (10-15 min) - "Tell me about a time when..." to get concrete stories.
- Wrap-up (5 min) - "Is there anything important I didn't ask about?"
Probing techniques:
| Probe | When to use | Example |
|---|---|---|
| The silent probe | After a short answer; pause 3-5 seconds | (silence) |
| Echo probe | Repeat the last few words as a question | "You said it was confusing?" |
| Elaboration probe | When an answer needs depth | "Can you tell me more about that?" |
| Example probe | When an answer is abstract | "Can you give me a specific example?" |
| Clarification probe | When a term is ambiguous | "When you say 'complicated,' what do you mean?" |
| Impact probe | To understand consequences | "What happened as a result of that?" |
Rules for interviewers:
- Ask one question at a time. Never stack questions.
- Never suggest an answer in the question.
- Prioritize "what did you do?" over "what would you do?"
- Take sparse notes during the session; full notes immediately after.
Run moderated usability tests
Task design rules:
- Tasks must be scenario-based, not feature-based. "You want to send $50 to a friend" not "Use the transfer feature."
- Tasks must have a clear, observable completion state.
- Order tasks from low to high complexity.
- Include one task you expect to fail - it will reveal the most.
Key metrics per task:
| Metric | What it measures | How to collect |
|---|---|---|
| Task completion rate | Can users do it at all? | Binary success/failure per task |
| Time on task | Efficiency | Timer from task start to success |
| Error count | Where the design breaks down | Count distinct wrong paths taken |
| Satisfaction (SEQ) | Perceived ease | Single Ease Question (1-7 scale) after each task |
Think-aloud protocol: Ask participants to narrate their thoughts while working. Do not help them when they struggle - that is your signal. Only intervene if they are completely stuck for more than 3 minutes.
Debrief questions:
- "What was the most confusing part?"
- "If you could change one thing, what would it be?"
- "What did you expect to happen when you clicked X?"
Create user journey maps
Use this template for each journey:
JOURNEY MAP: [User goal / scenario]
=====================================
Persona: [Name and segment]
Scenario: [Context and starting point]
STAGES: [Awareness] → [Consideration] → [Decision] → [Use] → [Advocacy]
For each stage:
ACTIONS: What is the user doing?
THOUGHTS: What are they thinking?
EMOTIONS: [Frustrated / Neutral / Delighted] + why
TOUCHPOINTS: [Channel: website / app / email / support / etc.]
PAIN POINTS: What is going wrong or creating friction?
OPPORTUNITIES: Design interventions to improve this stageTips:
- Base journeys on real research data, not assumptions. Every cell should be traceable to a quote or observation.
- Map the current-state journey before designing a future-state journey.
- Emotion is the most actionable row - peaks and valleys show where to invest.
Design an A/B test
Hypothesis template:
We believe that [change to control]
will result in [expected outcome]
for [target user segment]
because [rationale from research or data].
Null hypothesis: There is no difference between control and variant.Metrics:
| Metric type | Examples | Notes |
|---|---|---|
| Primary | Conversion rate, task completion, sign-up | One metric only - the one the decision rests on |
| Guardrail | Revenue per user, support ticket rate | Must not degrade; test stops if they do |
| Secondary | Click-through rate, scroll depth | Directional signal; not decision criteria |
Sample size calculation:
Before running any test, calculate the required sample size using:
- Baseline conversion rate (from analytics)
- Minimum detectable effect (MDE) - the smallest change worth acting on
- Statistical power: 80% (standard)
- Significance level: 95% (p < 0.05)
Use a sample size calculator (e.g., Evan Miller's). A common mistake is ending a test as soon as significance is reached - this inflates false positives (peeking problem). Set the duration before the test starts and do not stop early.
Duration rule: Run for at least one full business cycle (usually 2 weeks) to capture weekly behavior variation, regardless of when significance is reached.
Synthesize findings with affinity mapping
- Data dump - Write one observation per sticky note (physical or digital). Include a participant ID on each note.
- Silent sort - Each team member groups notes without discussion.
- Cluster and name - Groups become themes. Name themes as insights ("Users do not trust the price until they see a breakdown") not categories ("Pricing").
- Count and rank - Note how many participants contributed to each theme. Themes supported by 4 of 5 participants are high-confidence.
- Extract implications - For each theme, write: "This means we should consider [design implication]."
Write a research report
Template:
RESEARCH REPORT: [Study name]
==============================
Date: [Date]
Researcher: [Name]
Method: [Methods used]
Participants: [N, segment description]
EXECUTIVE SUMMARY (3-5 sentences)
[Most important finding and recommended action]
RESEARCH QUESTIONS
[Restate from the plan]
KEY FINDINGS
Finding 1: [Insight statement]
Evidence: [Quotes and observations]
Implication: [What this means for the product]
Finding 2: ...
RECOMMENDATIONS
Priority 1 (do now): [Specific action]
Priority 2 (consider): [Specific action]
Priority 3 (monitor): [Watch metric or re-research]
LIMITATIONS
[Sample size constraints, recruitment bias, prototype fidelity issues]
APPENDIX
- Discussion guide
- Participant screener
- Raw notes / recording linksAnti-patterns
| Anti-pattern | Why it is wrong | What to do instead |
|---|---|---|
| Validating rather than learning | Designing research to confirm a decision already made; ignoring contradictory findings | Define what would change your mind before starting; share raw data with stakeholders |
| One-method thinking | Using only surveys or only interviews for everything | Match method to the research question; triangulate across methods |
| Recruiting power users | Power users have different mental models and error tolerance than average users | Write screeners that target typical usage frequency and context |
| Skipping synthesis | Sharing raw quotes and session recordings as "insights" | Cluster, theme, and interpret data; insights require analysis |
| Testing too late | Running usability tests after engineering is complete, when changes are expensive | Integrate research at every stage; paper prototypes are testable |
| Asking hypothetical questions | "Would you use a feature that..." elicits aspirational, inaccurate answers | Ask about past behavior: "Tell me about the last time you did X" |
Gotchas
Stopping an A/B test when significance is first reached inflates false positive rate - This is the "peeking problem." With continuous monitoring, you will reach p<0.05 by chance on roughly 1 in 20 tests even when there is no real effect. Set the test duration before launch based on sample size calculation and do not stop early regardless of when significance is reached.
Usability test participants who are too polite produce misleading data - Many participants will complete tasks while struggling rather than say they are confused, to avoid seeming incompetent. Watch behavior (hesitation, wrong clicks, backtracking) more than verbal reports. Silence or slow movement is a signal; "yeah, that was fine" may not be.
Journey maps built from assumptions rather than data entrench existing beliefs - A journey map created in a workshop without participant quotes attached to each cell is a hypothesis map, not a research artifact. Every pain point and emotion in a journey map must be traceable to a specific observation or quote.
Survey questions with "usually" or "typically" elicit aspirational, not actual behavior - "How do you typically research products before buying?" invites respondents to describe their ideal selves. Ask about the last specific instance: "Think about the last time you bought something over $50 online. Walk me through what you did before purchasing." Specific past behavior is more accurate than general habits.
Recruiting from your own user base misses non-users and churned users - If you only recruit current active users, you systematically exclude people who tried and left, people who never signed up, and people in adjacent segments. For generative research, recruit from the broader target population, not just existing customers.
References
For detailed content on specific topics, read the relevant file from references/:
references/research-methods.md- Catalog of 15+ UX research methods with when-to-use, sample size, and effort level
Only load a references file if the current task requires deep detail on that topic.
References
research-methods.md
UX Research Methods Catalog
A catalog of 18 UX research methods with when to use each, appropriate sample sizes, and effort level. Use this to match a research question to the right method rather than defaulting to whatever method feels familiar.
How to read this catalog
- When to use - The research question or project stage this method fits best
- Sample size - Typical number of participants for valid results
- Effort - Relative cost in time and resources (Low / Medium / High)
- Output - What the method produces
Generative Methods
1. In-depth User Interviews
One-on-one conversations exploring a user's behaviors, mental models, and motivations in depth. The gold standard for qualitative discovery.
- When to use: Early discovery; understanding why users behave a certain way; building empathy before design begins
- Sample size: 5-8 per user segment
- Effort: Medium (30-90 min per session + synthesis)
- Output: Themes, quotes, behavioral patterns, opportunity areas
Tips: Always ask about past behavior, not hypothetical preferences. Record with consent. Use probing techniques (silence, echo, elaboration) to go deeper than surface answers.
2. Contextual Inquiry
Observation in the user's natural environment while they work, with the researcher asking questions as behaviors occur. Surfaces tacit knowledge that users cannot articulate in interviews.
- When to use: Understanding a complex or unfamiliar workflow; enterprise software; physical environments
- Sample size: 5-8 participants
- Effort: High (travel + long sessions + analysis)
- Output: Workflow diagrams, observed pain points, workarounds, environmental constraints
Tips: Use the master-apprentice model - the user teaches you their work, you observe and ask "why" when something unexpected happens.
3. Diary Studies
Participants self-report experiences, behaviors, or emotions at regular intervals over days or weeks using a structured log. Captures longitudinal behavior that a single session cannot.
- When to use: Behaviors that unfold over time; infrequent events; tracking emotional arc of an experience
- Sample size: 10-20 participants
- Effort: High (long duration; participant compliance management)
- Output: Time-series behavioral data, longitudinal patterns, moment-of-experience quotes
Tips: Keep the logging task under 5 minutes per entry. Use in-app prompts or SMS reminders to improve compliance. Compensate participants well - they are doing ongoing work.
4. Focus Groups
Moderated group discussion (6-8 participants) exploring attitudes, perceptions, and reactions to concepts. Better for social opinions than individual behavior.
- When to use: Concept reactions; brand perception; understanding shared social norms
- Sample size: 6-8 per group; run 2-3 groups
- Effort: Medium
- Output: Range of opinions, shared language, social dynamics around a topic
Tips: Focus groups reveal what people say in social contexts, not what they do alone. Never use them as a substitute for individual interviews or usability testing. Dominant personalities can skew group opinion.
5. Card Sorting
Participants group and label content items, revealing their mental models of how information should be organized.
- When to use: Information architecture design; navigation structure; labeling decisions
- Sample size: 15-30 for open sort; 20-30 for closed sort
- Effort: Low to Medium
- Output: Dendrogram, similarity matrix, category names participants generate
| Variant | Description |
|---|---|
| Open sort | Participants create their own groups and labels. Use for new IA design. |
| Closed sort | Participants sort into predefined categories. Use to validate existing IA. |
| Hybrid | Participants sort then suggest alternate category names. |
Tools: Optimal Workshop Optimal Sort, Maze, Miro.
6. Surveys
Structured questionnaires delivered at scale to measure attitudes, behaviors, and satisfaction. Quantifies what qualitative research surfaces.
- When to use: Measuring baseline satisfaction; validating qualitative themes at scale; tracking metrics over time
- Sample size: 100+ for basic segmentation; 400+ for statistical significance across subgroups
- Effort: Low to Medium (design is hard; fielding is cheap)
- Output: Frequencies, cross-tabs, satisfaction scores, NPS, net sentiment
Tips: Limit surveys to 5-10 questions. Each question must map to a specific decision. Include one open-ended question at the end. Pilot-test with 3-5 people before distributing. Avoid Likert scales without a clear neutral midpoint.
7. Stakeholder Interviews
Internal interviews with product managers, engineers, sales, and support to surface existing knowledge, constraints, and organizational assumptions.
- When to use: Project kick-off; understanding internal constraints; auditing existing research before doing new work
- Sample size: 3-8 stakeholders
- Effort: Low
- Output: Existing knowledge inventory, business goals, known assumptions, research gaps
Tips: Ask what decisions they need research to inform, not just what they already believe. Surface gaps between what stakeholders assume and what users actually do.
Evaluative Methods
8. Moderated Usability Testing
A researcher watches participants attempt realistic tasks on a product, identifying usability issues through observation and think-aloud narration.
- When to use: Before launch; after major redesign; when you suspect specific task flows have issues
- Sample size: 5 per distinct user segment
- Effort: Medium (recruiting + 60-90 min sessions + synthesis)
- Output: Task completion rates, error patterns, pain point quotes, prioritized issue list
Tips: Write task scenarios, not task instructions. "Find a flight from NYC to LA for next Friday" not "Click the search field and enter a departure city." Debrief with open questions after all tasks are complete.
9. Unmoderated Remote Usability Testing
Participants complete tasks independently using an automated platform. Faster and cheaper than moderated testing; loses the ability to probe unexpected behavior.
- When to use: Quick validation; high-volume testing; when budget for moderated sessions is limited
- Sample size: 20-50 (more participants compensate for lost depth)
- Effort: Low to Medium
- Output: Task completion rates, time-on-task, screen recordings, click paths
Tools: UserTesting, Maze, Lookback, Userbrain.
Tips: Write very clear task scenarios - you cannot clarify in real time. Include attention-check questions to filter low-quality responses.
10. A/B Testing
Randomized experiment serving two or more variants to traffic simultaneously and measuring outcome differences using statistical inference.
- When to use: Optimizing a specific conversion or engagement metric when you have sufficient traffic
- Sample size: Calculated from baseline rate, MDE, power (80%), and significance (95%). Typically thousands per variant.
- Effort: Medium to High (requires engineering instrumentation)
- Output: Statistically significant lift or null result on primary metric
Tips: Test one variable at a time. Define primary metric, guardrail metrics, and test duration before starting. Never stop a test early because it reached significance (peeking problem). Always validate that instrumentation works before starting.
11. First-Click Testing
Participants are shown a screen and asked where they would click to complete a goal. Reveals whether navigation and calls-to-action are findable.
- When to use: Evaluating navigation labels; testing landing page hierarchy; quick IA validation
- Sample size: 20-40 participants
- Effort: Low
- Output: Click heatmap, first-click accuracy rate, time-to-first-click
Tips: First-click accuracy of 80%+ indicates strong findability. Below 60% signals a labeling or layout problem worth redesigning before full usability testing.
12. Tree Testing
Participants navigate a text-only site hierarchy to find items, isolating IA problems from visual design noise.
- When to use: Validating navigation structure before implementing visual design; testing redesigned IA
- Sample size: 30-50 participants
- Effort: Low to Medium
- Output: Directness score, success rate, time per task, where users go wrong
Tools: Optimal Workshop Treejack, Maze.
Tips: Run tree testing before card sorting if you want to audit existing navigation. Pair results with card sorting data to see both how users organize content and whether they can find it in your proposed structure.
13. Concept Testing
Showing early-stage concepts (sketches, storyboards, low-fi mockups) to users and collecting reactions before significant design investment.
- When to use: Validating multiple directions early; testing messaging and positioning; checking comprehension of a new idea
- Sample size: 5-8 per concept
- Effort: Low to Medium
- Output: Preference data, comprehension rates, emotional reactions, deal-breaker concerns
Tips: Present concepts as options, not finished products. Ask "what do you think this does?" before asking "would you use this?" Never ask "do you like it?" - preference without task context is not actionable.
14. Desirability Testing
Participants select from a set of adjectives to describe their reaction to a design. Surfaces emotional and brand alignment data.
- When to use: Brand redesigns; evaluating visual design tone; comparing multiple design directions
- Sample size: 20-30 per design direction
- Effort: Low
- Output: Word frequency distribution; comparison across variants
Method: Use Microsoft's Product Reaction Cards (118 adjectives, ~60% positive). Present the design, then ask users to pick 5 words that describe it. Compare distributions across variants or against brand target.
15. Heuristic Evaluation
Expert reviewers evaluate an interface against established usability heuristics (typically Nielsen's 10) and rate the severity of violations.
- When to use: Quick audit before user research; identifying obvious issues without recruiting participants; small teams with limited research budget
- Sample size: 3-5 expert evaluators (not a substitute for testing with real users)
- Effort: Low
- Output: Prioritized issue list with severity ratings (0-4 scale)
Severity scale: 0 = not a usability problem; 1 = cosmetic; 2 = minor; 3 = major; 4 = catastrophic.
Tips: Heuristic evaluation finds different issues than usability testing - experts miss problems that confuse novices and vice versa. Use both for comprehensive coverage.
16. Eye Tracking
Technology measures where users look on a screen, producing fixation maps and scan paths. Shows attention patterns that click data alone cannot reveal.
- When to use: Optimizing visual hierarchy; evaluating advertising placement; studying reading patterns on dense content
- Sample size: 30-40 for reliable heatmaps
- Effort: High (equipment cost, lab setup, analysis complexity)
- Output: Fixation heatmaps, gaze plots, areas of interest dwell time, scan path analysis
Tips: Eye tracking reveals where attention goes, not whether comprehension occurred. Always pair with verbal probing or comprehension questions to interpret fixation data.
17. Session Recording Analysis
Watching recordings of real user sessions in production to identify rage clicks, error loops, and abandonment patterns at scale.
- When to use: Post-launch investigation; identifying where users struggle in the live product; complementing quantitative analytics
- Sample size: 50-200 sessions per flow being analyzed
- Effort: Low to Medium
- Output: Friction points, error patterns, rage-click hotspots, abandonment moments
Tools: FullStory, Hotjar, LogRocket, PostHog.
Tips: Filter for sessions with specific behaviors (rage clicks, error states, task abandonment) rather than watching random sessions. Pair findings with funnel analytics to understand scale.
18. Accessibility Audit
Systematic evaluation of an interface against WCAG guidelines, using automated scanning tools plus manual testing with assistive technologies.
- When to use: Before launch; after major UI changes; compliance requirements; inclusive design review
- Sample size: Automated tools + 2-3 assistive technology users
- Effort: Medium
- Output: WCAG violation list by severity, screen reader compatibility report, keyboard navigation assessment
Tips: Automated tools catch ~30% of accessibility issues. Manual testing with screen readers (NVDA, VoiceOver, JAWS) and keyboard-only navigation is required for full coverage. Include users with disabilities in usability testing whenever possible.
Method Selection Guide
| Research question | Recommended method |
|---|---|
| Why do users abandon this flow? | Moderated usability test + session recording |
| What are users' core needs we haven't addressed? | In-depth interviews + contextual inquiry |
| Where should we put this feature in the navigation? | Card sorting + tree testing |
| Which variant converts better? | A/B test |
| How satisfied are users overall? | Survey (NPS, CSAT, or SUS) |
| Does our new design feel like our brand? | Desirability testing |
| Is this early concept worth building? | Concept testing |
| What usability issues exist before we recruit users? | Heuristic evaluation |
| How does this feature perform over weeks of use? | Diary study |
| Where are users actually looking on this page? | Eye tracking or first-click test |
Frequently Asked Questions
What is ux-research?
Use this skill when planning user research, conducting usability tests, creating journey maps, or designing A/B experiments. Triggers on user interviews, usability testing, user journey maps, A/B test design, survey design, persona creation, card sorting, tree testing, and any task requiring user experience research methodology or analysis.
How do I install ux-research?
Run npx skills add AbsolutelySkilled/AbsolutelySkilled --skill ux-research in your terminal. The skill will be immediately available in your AI coding agent.
What AI agents support ux-research?
ux-research works with claude-code, gemini-cli, openai-codex. Install it once and use it across any supported AI coding agent.
Is ux-research free?
Yes, ux-research is completely free and open source under the MIT license. Install it with a single command and start using it immediately.
What is the difference between ux-research and similar tools?
ux-research is an AI agent skill that teaches your coding agent specialized ui/ux & design knowledge. Unlike standalone tools, it integrates directly into claude-code, gemini-cli, openai-codex and other AI agents.
Can I use ux-research with Cursor or Windsurf?
ux-research works with any AI coding agent that supports the skills protocol, including Claude Code, Cursor, Windsurf, GitHub Copilot, Gemini CLI, and 40+ more.