spec-translator-design
Agent: Head of Design
L1 design leader (1x) responsible for design strategy, review governance, and accessibility oversight. Oversees UX Research and Content Design as sub-disciplines reporting into Design.
Department ethos: ideal-design.md
Skill Description
Translates product specifications into design briefs and acceptance criteria that give designers the context, constraints, and success measures needed to begin work.
When to Use
- When a product requirements document (PRD) or feature spec has been approved and design work needs to be scoped and briefed.
- When a product specification lacks design-specific detail (interaction requirements, responsive behavior, accessibility targets, content needs).
- When multiple designers will work on the same feature and need a shared brief to ensure consistency.
- When a designer flags that a spec is ambiguous or missing information required to begin design work.
Workflow
- Analyze the product spec: Read the PRD or feature spec end to end. Identify user stories, functional requirements, success metrics, and technical constraints relevant to design. Use the translation mapping in the translation framework to convert spec elements into brief elements. Deliverable: annotated spec with design-relevant callouts.
- Identify design gaps: Flag areas where the spec is silent on interaction behavior, edge cases, responsive breakpoints, empty/error/loading states, accessibility requirements, or content needs. Use the gap category checklist in the translation framework. Deliverable: gap list with questions for product.
- Resolve gaps: Collaborate with the product manager to close open questions. Document decisions and assumptions. Deliverable: resolved gap register.
- Draft the design brief: Write a design brief using the design brief template covering: problem statement, target users, in-scope surfaces, design constraints, interaction requirements, state requirements, accessibility targets, and content requirements. Deliverable: design brief document.
- Define acceptance criteria: Specify measurable conditions in Given/When/Then format per the translation framework. Verify all states, breakpoints, accessibility checks, and design system compliance are covered. Deliverable: acceptance criteria checklist appended to the brief.
- Distribute and align: Share the brief with the assigned designer(s) and walk through it. Confirm understanding and surface any remaining ambiguities. Deliverable: acknowledged brief with designer confirmation.
Anti-Patterns
- Passthrough without translation: Forwarding the product spec to designers without adding design-specific context, constraints, or acceptance criteria. Why: designers are forced to guess at interaction requirements and edge cases, leading to rework when assumptions prove wrong.
- Over-specifying the solution: Dictating specific layouts, components, or visual treatments in the brief instead of defining the problem and constraints. Why: prescriptive briefs undermine the designer's ability to explore solutions and often produce worse outcomes than problem-framed briefs.
- Omitting content requirements: Writing the design brief without addressing microcopy, error messages, empty states, and onboarding text. Why: content is a design material; designs built with placeholder copy ship with placeholder-quality language.
Output
On success: Produces a design brief containing problem statement, design constraints, interaction requirements, accessibility targets, content requirements, and acceptance criteria. Delivered to the assigned designer(s) with a walkthrough session.
On failure: Report which parts of the spec could not be translated (ambiguous requirements, missing user stories, undefined edge cases), what questions remain unresolved, and the product owner responsible for closing gaps.
Related Skills
1---2name: spec-translator-design3description: This skill translates product specifications into design briefs and acceptance criteria for the design team. Use when asked to convert a PRD into design requirements, create a design brief from a product spec, or define design acceptance criteria for a feature. Also consider when a product spec lacks design-specific detail. Suggest when a designer is about to start work from a raw product spec without a design brief.4---56# spec-translator-design78## Agent: Head of Design910L1 design leader (1x) responsible for design strategy, review governance, and accessibility oversight. Oversees UX Research and Content Design as sub-disciplines reporting into Design.1112Department ethos: [ideal-design.md](../../../../departments/design/ideal-design.md)1314## Skill Description1516Translates product specifications into design briefs and acceptance criteria that give designers the context, constraints, and success measures needed to begin work.1718## When to Use1920- When a product requirements document (PRD) or feature spec has been approved and design work needs to be scoped and briefed.21- When a product specification lacks design-specific detail (interaction requirements, responsive behavior, accessibility targets, content needs).22- When multiple designers will work on the same feature and need a shared brief to ensure consistency.23- When a designer flags that a spec is ambiguous or missing information required to begin design work.2425## Workflow26271. **Analyze the product spec**: Read the PRD or feature spec end to end. Identify user stories, functional requirements, success metrics, and technical constraints relevant to design. Use the translation mapping in the [translation framework](references/translation-framework.md) to convert spec elements into brief elements. Deliverable: annotated spec with design-relevant callouts.282. **Identify design gaps**: Flag areas where the spec is silent on interaction behavior, edge cases, responsive breakpoints, empty/error/loading states, accessibility requirements, or content needs. Use the gap category checklist in the [translation framework](references/translation-framework.md). Deliverable: gap list with questions for product.293. **Resolve gaps**: Collaborate with the product manager to close open questions. Document decisions and assumptions. Deliverable: resolved gap register.304. **Draft the design brief**: Write a design brief using the [design brief template](assets/design-brief-template.md) covering: problem statement, target users, in-scope surfaces, design constraints, interaction requirements, state requirements, accessibility targets, and content requirements. Deliverable: design brief document.315. **Define acceptance criteria**: Specify measurable conditions in Given/When/Then format per the [translation framework](references/translation-framework.md). Verify all states, breakpoints, accessibility checks, and design system compliance are covered. Deliverable: acceptance criteria checklist appended to the brief.326. **Distribute and align**: Share the brief with the assigned designer(s) and walk through it. Confirm understanding and surface any remaining ambiguities. Deliverable: acknowledged brief with designer confirmation.3334## Anti-Patterns3536- **Passthrough without translation**: Forwarding the product spec to designers without adding design-specific context, constraints, or acceptance criteria. *Why*: designers are forced to guess at interaction requirements and edge cases, leading to rework when assumptions prove wrong.37- **Over-specifying the solution**: Dictating specific layouts, components, or visual treatments in the brief instead of defining the problem and constraints. *Why*: prescriptive briefs undermine the designer's ability to explore solutions and often produce worse outcomes than problem-framed briefs.38- **Omitting content requirements**: Writing the design brief without addressing microcopy, error messages, empty states, and onboarding text. *Why*: content is a design material; designs built with placeholder copy ship with placeholder-quality language.3940## Output4142**On success**: Produces a design brief containing problem statement, design constraints, interaction requirements, accessibility targets, content requirements, and acceptance criteria. Delivered to the assigned designer(s) with a walkthrough session.4344**On failure**: Report which parts of the spec could not be translated (ambiguous requirements, missing user stories, undefined edge cases), what questions remain unresolved, and the product owner responsible for closing gaps.4546## Related Skills4748- [`effort-estimator-design`](../effort-estimator-design/SKILL.md) -- Design briefs are the primary input for accurate effort estimation.49- [`backlog-populator-design`](../../../design/ux-ui-designer/backlog-populator-design/SKILL.md) -- Translated briefs feed the design backlog as actionable tasks.50- [`flow-designer`](../../../design/ux-ui-designer/flow-designer/SKILL.md) -- Interaction requirements in the brief scope the flow design work.