design-handoff-brief
This skill transforms product requirements and feature briefs into structured design handoffs that equip designers with user context, constraints, and success criteria before design work begins. Use it when translating PRDs into actionable design briefs, preparing design kickoffs, or ensuring designers understand user goals and edge cases rather than just feature specifications.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/design-handoff-brief && cp -r /tmp/design-handoff-brief/plugins/pm-advanced/skills/design-handoff-brief ~/.claude/skills/design-handoff-briefSKILL.md
# Design Handoff Brief Skill
Produce a design brief that sets designers up for success — grounding them in user context and constraints before they open Figma, not after they've gone in the wrong direction.
## Required Inputs
Ask the user for these if not provided:
- **Feature brief or PRD** (even rough notes work)
- **Designer's name or team** (for personalisation)
- **Technical constraints** (any engineering limitations already known)
- **Timeline** (when does design need to be done?)
## What Designers Actually Need (and PMs Often Skip)
- The user's goal, not the feature name
- The emotional state of the user at this moment in the journey
- What success looks like — how will we know the design worked?
- Constraints: technical, legal, brand, accessibility
- Edge cases that must be handled
- What we're explicitly NOT solving for
## Process
1. Read the feature brief or PRD provided
2. Extract user goal (reframe from feature language to user outcome language)
3. Identify constraints — technical limitations, brand guidelines, accessibility requirements
4. List edge cases the design must handle
5. Define success criteria the design should be evaluated against
6. Write a "not in scope" section to prevent scope creep in design
7. **Validate** — Confirm every edge case listed is specific enough to design for, and every out-of-scope item is concrete enough to say "no" to
## Output Structure
### Design Brief: [Feature Name]
**User Goal:** (in the user's words, not ours)
"When I [situation], I want to [motivation] so that I can [outcome]."
**Context & Emotional State:**
[Where is the user in their journey? What are they feeling? What just happened?]
**Design Success Criteria:**
- [Criterion 1 — measurable where possible]
- [Criterion 2]
- [Criterion 3]
**Constraints:**
- Technical: [limitations engineering has flagged]
- Brand: [relevant brand guidelines]
- Accessibility: [WCAG level required, any specific requirements]
- Legal/Compliance: [if applicable]
**Edge Cases to Design For:**
- [Edge case 1]
- [Edge case 2]
- [Edge case 3]
**Explicitly Out of Scope:**
- [What we are NOT solving in this design iteration]
**Reference Material:**
- User research: [link]
- Existing patterns: [Figma component library link]
- Competitor examples: [links if relevant]
## Quality Checks
- [ ] User goal is written in user language (not feature/product language)
- [ ] At least one edge case covers an error or failure state
- [ ] Success criteria are measurable or observable (not "looks good")
- [ ] Out-of-scope section names at least one thing that might seem in scope but isn't
- [ ] Technical constraints are specific enough for an engineer to confirm
## Anti-Patterns
- [ ] Do not write the user goal in feature language ("design the checkout flow") — it must be written from the user's perspective with a motivation and outcome
- [ ] Do not skip the "Explicitly Out of Scope" section — without it, designers will inadvertently solve problems not intended for this iteration
- [ ] Do not list edge cases that are so generic they apply to any feature (e.g. "handle errors") — each edge case must be specific to this feature's failure modes
- [ ] Do not hand off the brief without confirming engineering constraints are accurate — a constraint that is wrong is worse than no constraint
- [ ] Do not omit the emotional context of the user — designs without emotional grounding produce technically correct but experientially flat resultsConduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.
Build the storyline and slide structure for a board presentation. Use when asked to create a board deck, board presentation narrative, board meeting slides, or quarterly board update. Produces a complete slide-by-slide structure with narrative beats, talking points, and slide content guidance.