| name | design-reporting |
| description | 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. |
If you need to check connected tools (placeholders) or role/company context, see 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.
