Design handoff brief

--- name: design-handoff-brief description: "Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use this 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 that includes the user’s 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 are fine) - Designer’s name or team (for personalization) - Technical constraints (any known engineering limitations) - Timeline (when does the design need to be completed?) ## What Designers Actually Need (and PMs Often Skip) - The user’s goal, not the feature name - The user’s emotional state at this point 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 are explicitly NOT trying to solve ## Process 1. Read the feature brief or PRD provided 2. Extract the user’s goal (reframe from feature-based language to user-outcome-based language) 3. Identify constraints:technical limitations, brand guidelines, accessibility requirements 4. List edge cases the design must handle 5. Define success criteria against which the design should be evaluated 6. Write a “not in scope” section to prevent scope creep in the design 7. Validate : Confirm that every listed edge case is specific enough to design for, and that 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 identified by engineering] - Brand: [relevant brand guidelines] - Accessibility: [required WCAG level, 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 - [ ] The 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”) - [ ] The “Out-of-scope” section lists at least one item that might appear to be in scope but is not - [ ] Technical constraints are specific enough for an engineer to verify ## Anti-Patterns - [ ] Do not write the user goal in feature language (“design the checkout flow”):it must be written from the user’s perspective, including 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 that engineering constraints are accurate:a wrong constraint is worse than no constraint at all - [ ] Do not omit the user’s emotional context:designs without an emotional foundation produce results that are technically correct but lack emotional depth