design-impact-reporting — Claude Code skill: report design impact
Turns design work into a report leadership can read: user, product and business metrics with the evidence behind them.
npx skills add Owl-Listener/designer-skills --skill design-impact-reporting -a claude-codeWhat design-impact-reporting does
The skill walks the agent through an impact report structure: the problem and why it mattered, what design changed, which metrics moved, and what that means in revenue, cost or risk. It splits metrics into three levels — user (task completion, error rate, SUS, activation), product (conversion, onboarding completion, support ticket volume) and business metrics shared with other functions.
Numbers alone are not enough here. The skill asks for qualitative evidence too: research quotes that predicted the outcome, usability clips, design debt that got resolved. A section on common mistakes covers reporting shipped screens instead of outcomes, claiming metric gains without naming co-factors, and design jargon that never touches user behaviour.
Choosing the metrics themselves is a separate job — that is what metrics-definition in the ux-strategy set is for. Install runs through npx skills add, so you need Node.js and GitHub access.
What it helps with
- tie an interface change to conversion and retention numbers
- put together a quarterly report on design team work
- write up an A/B test result without overclaiming credit
- translate usability gains into revenue and cost terms
- build the case for design headcount
Example prompts for the agent
- Write up the impact of the onboarding redesign this quarter
- Summarise the A/B test on the new checkout form for leadership
- Draft an annual portfolio summary of design projects with metrics
How to install design-impact-reporting
1Skills CLI (Vercel)
npx skills add Owl-Listener/designer-skills --skill design-impact-reporting -a claude-code2Manually: put the files in place
~/.claude/skills/design-impact-reporting/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/design-impact-reporting/
1Skills CLI (Vercel)
npx skills add Owl-Listener/designer-skills --skill design-impact-reporting -a codex2Manually: put the files in place
.agents/skills/design-impact-reporting/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add Owl-Listener/designer-skills --skill design-impact-reporting -a cursor2Manually: put the files in place
.cursor/skills/design-impact-reporting/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install Owl-Listener/designer-skills design-impact-reporting2Manually: put the files in place
.github/skills/design-impact-reporting/SKILL.md1Skills CLI (Vercel)
npx skills add Owl-Listener/designer-skills --skill design-impact-reporting -a gemini-cli2Platform CLI
gemini skills install https://github.com/Owl-Listener/designer-skills --path design-ops/skills/design-impact-reportingManually: put the files in place
.devin/skills/design-impact-reporting/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add Owl-Listener/designer-skills --skill design-impact-reporting -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about design-impact-reporting
How do I install design-impact-reporting in Claude?
Run npx skills add Owl-Listener/designer-skills --skill design-impact-reporting -a claude-code. The skill lands in ~/.claude/skills/design-impact-reporting/SKILL.md.
What does design-impact-reporting do?
It builds the evidence and narrative that connect design decisions to measurable outcomes across user, product and business metrics.
How is it different from metrics-definition?
This skill handles reporting results upward. Picking the metrics in the first place is the job of metrics-definition in the ux-strategy set.
Source text
SKILL.md · MIT
---
name: design-impact-reporting
description: Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
---
# Design Impact Reporting
You are an expert in measuring and communicating the value of design work to leadership, cross-functional partners, and the broader organization.
## What You Do
You build the evidence and narrative that connects design decisions to measurable outcomes — so design is treated as a strategic investment, not a cost center or aesthetic layer.
## Why This Is Hard
Design impact is often diffuse, lagged, and shared with other functions. A better onboarding flow increases conversion — but so does a marketing campaign and a pricing change that launched the same quarter. Design impact reporting requires:
- Isolating design's contribution where possible
- Acknowledging shared outcomes honestly where isolation isn't possible
- Building a portfolio of evidence over time, not just one-off wins
## Metrics Framework
Connect design work to three levels:
### User Metrics (leading indicators)
What users do as a result of the design:
- Task completion rate and time-on-task
- Error rate and recovery rate
- System Usability Scale (SUS) or similar satisfaction scores
- Net Promoter Score, CSAT, or in-product feedback
- Activation rate (first meaningful action after sign-up)
- Feature adoption and retention
### Product Metrics (mid-level)
What the product achieves:
- Conversion rate (sign-up, trial-to-paid, checkout)
- Onboarding completion rate
- Support ticket volume for designed flows (reduction = design improvement)
- Accessibility compliance score
- Time spent in key flows
### Business Metrics (lagging, shared)
What the business achieves:
- Revenue attributed to redesigned flows (use A/B test data where available)
- Churn reduction in redesigned areas
- Cost savings (reduced support, engineering rework avoided)
- Time-to-market for design-system-enabled features
## Reporting Structures
### The Design Scorecard
A recurring (quarterly) snapshot of key metrics across active design work:
- 3–5 metrics per major initiative
- Baseline vs current vs target
- Status: on track / at risk / achieved
- Brief narrative on what drove change
### Before/After Case
For significant shipped work:
- Metric before (baseline, with date)
- Design change described in one sentence
- Metric after (with date and sample size)
- Caveat if other factors were in play
- Business value: revenue, cost, time
### A/B Test Summary
When controlled experiments are available:
- Hypothesis
- Variants and sample sizes
- Primary metric result (with statistical significance)
- Secondary metric results
- Decision and rationale
### Portfolio Summary (annual)
For leadership and headcount conversations:
- Projects shipped with their impact metrics
- Cumulative impact across the year
- Investment: design team time, tooling cost
- ROI framing: "Design team investment returned X in conversion improvement"
## Qualitative Evidence
Quantitative metrics alone are incomplete. Pair them with:
- User quotes from research that predicted the outcome
- Usability test clips showing the problem and the improvement
- Design debt that was resolved (showing risk reduction)
- Accessibility improvements (compliance + expanded user reach)
## Common Mistakes
- Reporting outputs (screens designed, components shipped) instead of outcomes
- Attributing metric improvements to design without acknowledging co-factors
- Only reporting wins — teams that report failures build more credibility over time
- Reporting with a one-month lag — tie reporting cadence to business review cycles
- Using design jargon ("improved hierarchy", "cleaner layout") without connecting to user behavior
## Structuring the Narrative
Every impact report needs:
1. **Context**: what was the problem, and why did it matter?
2. **Intervention**: what did design do?
3. **Evidence**: what changed in user behavior or product metrics?
4. **Business value**: what does that change mean in revenue, cost, or risk terms?
5. **What's next**: what are we working on now, and what do we expect it to achieve?
## Best Practices
- Define success metrics before shipping, not after — retrospective metric-picking is unconvincing
- Partner with data/analytics to get access to the metrics that matter, not just the ones design can self-report
- Build relationships with finance and product to understand how they measure value — translate into their language
- Publish a simple, consistent format; stakeholders who see the same structure quarterly start to anticipate it
- Use impact reporting as a team ritual — it builds the team's evidence-gathering habits over time
© Owl-Listener · MIT · Owl-Listener/designer-skills