---

name: research-recommendation
description: "Convert qualitative research findings into a single actionable design recommendation — so findings ship instead of sitting in a Confluence page nobody reads."

/research-recommendation

Ten findings with equal weight is a way to say nothing. Research teams produce reports; design teams need a single prioritized recommendation backed by evidence and tied to a business metric. The gap between the two is why most UX research collects dust. The problem isn't research quality — it's that the synthesis step gets skipped. Researchers list what they heard; nobody takes the step of saying "this one, not the others, because of this evidence, and here's how we know it worked." This skill forces that step.

The Pattern — Separate Signal from Outlier

• What problem came up across the majority of sessions — unprompted, in similar language, with similar consequences?
• How many participants mentioned it? (3 out of 5 is a pattern; 1 out of 5 is a note)
• What was the exact language they used? (Verbatim — their words will be more precise than your paraphrase)
• What behavior did they exhibit that corroborates what they said? (Clicks, hesitations, workarounds, abandonment)
• What did you observe that participants didn't mention but is clearly a problem? (Silent behavior is often more honest than stated feedback)

The Business Impact of Fixing It

• Which product metric does this problem affect? Be specific: trial-to-paid conversion, 7-day retention, feature adoption rate, support ticket volume for a specific issue, NPS for a specific user segment
• What's the current metric level? What would a 10-15% improvement look like in revenue or cost terms?
• Is there an existing benchmark — A/B test, competitive data, industry average — that gives you a range for what improvement is plausible?
• What's the cost of not fixing it? (Users churning to a competitor? Support team absorbing friction? Enterprise deals stalling on a specific flow?)

The Specific Design Change

• Describe the change in one sentence. Not "improve the onboarding flow" — "add a progress indicator to the 4-step setup wizard so users understand they're 75% done at Step 3 where 60% currently abandon"
• What specifically changes for the user? Before state, after state.
• What is explicitly NOT changing in this recommendation? (Scope boundary prevents the change from expanding into a 3-month redesign)
• Is this change implementable in one sprint, or does it require a longer arc? If longer, what's the Phase 1?

Why This One and Not the Others

• What were the other findings from this round of research?
• Why is this recommendation the priority? (Frequency? Severity of consequence? Ease of fix relative to impact? Strategic alignment?)
• What's the second-priority finding, and what would need to be true for it to move up?

How to Measure It Worked

• What metric will you track, and at what time horizon? (Some usability changes show up in 2 weeks; some retention changes take 60 days)
• What's the minimum improvement that justifies the engineering cost?
• What does failure look like — and what would you do if the metric doesn't move?

Rules

1. One recommendation, not a list — if you have multiple, this skill produces one output and queues the rest
2. The design change must be specific enough for an engineer to estimate — "improve clarity" is not a design change
3. Business metric must be named — a recommendation without a success metric cannot be prioritized against other work
4. The "why this one" section is mandatory — skipping it means leadership will reorder based on opinion
5. Verbatim participant language must appear in the output — it's the most persuasive evidence in a design review

This output is a one-page recommendation you can take to a design critique, a sprint planning session, or a leadership review — with evidence, a specific change, and a measurement plan attached.