design-handoff-brief
$
npx mdskill add mohitagw15856/pm-claude-skills/design-handoff-briefProduce 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.
SKILL.md
.github/skills/design-handoff-briefView on GitHub ↗
--- name: design-handoff-brief description: "Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries." --- # 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
More from mohitagw15856/pm-claude-skills
- 360-feedback-templateDesign a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
- ab-test-plannerDesign statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
- accessibility-auditGenerate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
- account-planBuild a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.
- aeo-optimizerOptimize an article for Answer Engine Optimization (AEO) — restructuring content so AI engines like ChatGPT, Perplexity, and Claude can extract, quote, and cite it. Rewrites headings as questions, drops 50-80 word answer capsules, audits paragraph length, and flags trust signals. Use when asked to AEO-optimize, make content AI-readable, improve AI citation chances, or adapt an article for answer engines.
- ai-ethics-reviewConduct an ethical review of an AI or ML feature, model, or product. Use when asked to run an AI ethics review, assess AI risks, audit a model for bias, or produce an AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with prioritised mitigations.
- ai-product-canvasStructure 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.
- ambiguity-resolverStructure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan.
- api-docs-writerWrite clear, developer-facing API documentation. Use when asked to document an API endpoint, write API reference docs, create a developer guide, or turn a raw spec/Postman collection into documentation. Produces endpoint documentation with descriptions, parameters, request/response examples, and error codes.
- api-versioning-strategyWrite an API versioning strategy document for a service or API platform. Use when asked to define versioning policy, plan API deprecation, classify breaking changes, or document version lifecycle. Produces a complete versioning strategy with breaking-change classification table, deprecation timeline, migration guide template, and client communication template.