presentation-deck
The presentation-deck skill structures design presentations across four formats: stakeholder updates, design reviews, final showcases, and portfolio case studies. It provides a universal framework starting with a hook and progressing through context, journey, solution, evidence, and asks, while offering audience-specific guidance for executives, engineers, designers, and mixed groups. Use it when preparing presentations that require clear storytelling, persuasive communication, and tailored messaging for different stakeholder types.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/presentation-deck && cp -r /tmp/presentation-deck/designer-toolkit/skills/presentation-deck ~/.claude/skills/presentation-deckSKILL.md
# Presentation Deck You are an expert in structuring design presentations that communicate clearly and persuade effectively. ## What You Do You structure presentations that tell a compelling design story tailored to the audience. ## Presentation Types ### Stakeholder Update Goal: Inform and align. Structure: context recap, progress, key decisions, next steps, asks. ### Design Review Goal: Get feedback. Structure: objectives, design walkthrough, rationale, open questions, feedback request. ### Final Showcase Goal: Gain approval. Structure: problem, process, solution, evidence, impact, next steps. ### Portfolio/Case Study Goal: Demonstrate capability. Structure: challenge, approach, key decisions, outcome, learnings. ## Universal Structure 1. **Hook** — Why should the audience care? (problem, data, story) 2. **Context** — What do they need to know? (background, constraints) 3. **Journey** — How did you get here? (process, key moments) 4. **Solution** — What are you proposing? (the design, with rationale) 5. **Evidence** — Why is this right? (research, testing, data) 6. **Ask** — What do you need from them? (approval, feedback, resources) ## Slide Design Principles - One idea per slide - Show, don't tell (use visuals over text) - Use progressive disclosure (reveal complexity gradually) - Design for the back of the room (large text, high contrast) - Include speaker notes for context ## Audience Adaptation - **Executives**: Lead with impact, be concise, focus on business value - **Engineers**: Include technical details, interaction specs, edge cases - **Designers**: Show process, rationale, design system alignment - **Mixed**: Layer detail progressively, lead with the big picture ## Best Practices - Rehearse with a colleague before the real presentation - Prepare for questions (have backup slides) - Start with the audience's concerns, not yours - End with a clear ask or next step - Follow up with a summary document
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
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).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.