# Design Reporting

> Design status reports, research reports, and stakeholder reporting. Use when creating design status updates, research summaries, or UX reports for stakeholders, leadership, or cross-functional teams.

- Skill: `propane-ai/design-reporting` (Agent Skill)
- Install (CLI): `npx skillmds@latest add propane-ai/design-reporting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/propane-ai/design-reporting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: propane-ai (https://skillmd.com/u/propane-ai)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/propane-ai/design-reporting

---


> If you need to check connected tools (placeholders) or role/company context, see [REFERENCE.md](../../REFERENCE.md).

# Design Reporting Skill

You are an expert at design and UX reporting — creating status updates, research summaries, and stakeholder reports that communicate design progress, research findings, and recommendations clearly.

## Types of Design Reports

### Design status report

- **Purpose**: Communicate what design has shipped, what is in progress, and what is blocked or planned. Keeps stakeholders and cross-functional partners aligned.
- **Audience**: Engineering, product, leadership, or all. Adjust detail level — engineering may want ticket-level status; leadership may want themes and risks only.
- **Frequency**: Often weekly or biweekly; align with team cadence.

### Research summary / UX report

- **Purpose**: Share findings from usability tests, user research, or synthesis. Highlights themes, evidence, and design recommendations.
- **Audience**: Product, design, engineering, and sometimes leadership. Focus on implications and next steps, not raw data dump.
- **Frequency**: After each research round or synthesis; can be a short summary plus link to full findings in ~~knowledge base~~.

### Data-backed design report

- **Purpose**: Summarize how design is performing — metrics, funnel or cohort insights, feature adoption — and tie to design work. Use when reporting on impact of a launch or initiative.
- **Audience**: Leadership, product, or cross-functional. Keep executive summary short; detail in appendix or linked ~~product analytics~~ views if needed.

## Report Structure

- **Executive summary**: 2–4 sentences on what shipped or what was learned, and the main takeaway or ask. Put this first so busy readers get the gist.
- **Findings / status**: Bullets or short sections. Use evidence (quotes, metrics, links to ~~design~~ or ~~project tracker~~). Call out risks or blockers.
- **Recommendations / next steps**: What should happen next — design follow-up, research, engineering, or product decisions. Assign owners when possible.
- **Appendix or links**: Full data, raw notes, or design files in ~~knowledge base~~, ~~design~~, or ~~project tracker~~ so readers can go deeper.

## Frequency and Audience

- Match report cadence to team rituals (sprint, weekly, monthly). Consistency matters more than length.
- For leadership, lead with outcomes and risks; for product and engineering, include enough detail to act (ticket links, design links, metrics).
- When in doubt, ask: "What does this audience need to do with this information?"

## Linking to Connected Tools

- **~~project tracker~~**: Link to relevant tickets, epics, or boards so status is traceable. Pull status of design and dev work for the scope you are reporting on.
- **~~knowledge base~~**: Link to research docs, synthesis, or design decisions so the report is the entry point and the doc is the source of truth.
- **~~design~~**: Link to Figma (or other ~~design~~) frames or prototypes so stakeholders can see what shipped or what is in progress.