backlog-populator-design
Agent: UX/UI Designer
L2 UX/UI designer (Nx) responsible for user flow design, wireframing, prototyping, and component mapping.
Department ethos: ideal-design.md
Tool policy: allowed-tools.yaml
Skill Description
Populates the design backlog with well-defined, estimable design tasks derived from design briefs and product roadmap items.
When to Use
- When a design brief has been finalized and needs to be decomposed into actionable backlog items for sprint planning.
- When the product roadmap updates and new design work needs to be captured in the backlog.
- When the design backlog is stale or empty despite active product initiatives requiring design input.
Workflow
- Review source material: Read the design brief, product spec, or roadmap item. Identify all design deliverables required -- flows, wireframes, visual designs, prototypes, component specs, handoff documentation. Use the deliverable-to-ticket mapping in the backlog framework. Deliverable: deliverable inventory.
- Decompose into tasks: Break each deliverable into discrete, estimable backlog items using the ticket template in the backlog framework. Each item must have a clear definition of done, the target Figma file or page, and any dependencies. Deliverable: draft backlog items.
- Tag and categorize: Apply phase labels (
phase:wireframe, phase:visual, etc.) and design system impact labels (ds:none, ds:new-component, etc.) per the backlog framework. Deliverable: tagged backlog items.
- Sequence and link: Order items using the sequencing rules in the backlog framework. Apply dependency flags (BLOCKED:research, BLOCKED:content) where upstream work is outstanding. Deliverable: sequenced backlog ready for sprint planning.
Anti-Patterns
- Vague tickets: Creating backlog items like "design the feature" without specifying deliverable type, scope, or definition of done. Why: vague items cannot be estimated, assigned, or verified as complete, and they create ambiguity during sprint planning.
- Skipping dependency mapping: Adding items without identifying upstream blockers (pending research, missing content, unresolved spec questions). Why: designers pick up blocked tasks, stall, and switch context -- wasting capacity and disrupting flow.
- One-shot population: Populating the backlog once and never updating it as the brief evolves or scope changes. Why: stale backlogs misrepresent the true design workload and lead to missed deliverables.
Output
On success: Produces a set of tagged, sequenced design backlog items with definitions of done, dependencies, and phase labels. Delivered in the team's backlog tool, ready for sprint planning.
On failure: Report which parts of the brief could not be decomposed (ambiguous requirements, missing content direction, undefined user flows), what partial items were created, and the questions that must be resolved.
Related Skills
1---2name: backlog-populator-design3description: This skill populates the design backlog with well-defined design tasks aligned to the product roadmap. Use when asked to break down a design brief into backlog items, create design tickets from a spec, or prepare the design backlog for sprint planning. Also consider when the design backlog is empty despite active product initiatives. Suggest when a new design brief arrives without corresponding backlog entries.4---56# backlog-populator-design78## Agent: UX/UI Designer910L2 UX/UI designer (Nx) responsible for user flow design, wireframing, prototyping, and component mapping.1112Department ethos: [ideal-design.md](../../../../departments/design/ideal-design.md)13Tool policy: [allowed-tools.yaml](../../../../allowed-tools.yaml)1415## Skill Description1617Populates the design backlog with well-defined, estimable design tasks derived from design briefs and product roadmap items.1819## When to Use2021- When a design brief has been finalized and needs to be decomposed into actionable backlog items for sprint planning.22- When the product roadmap updates and new design work needs to be captured in the backlog.23- When the design backlog is stale or empty despite active product initiatives requiring design input.2425## Workflow26271. **Review source material**: Read the design brief, product spec, or roadmap item. Identify all design deliverables required -- flows, wireframes, visual designs, prototypes, component specs, handoff documentation. Use the deliverable-to-ticket mapping in the [backlog framework](references/backlog-framework.md). Deliverable: deliverable inventory.282. **Decompose into tasks**: Break each deliverable into discrete, estimable backlog items using the ticket template in the [backlog framework](references/backlog-framework.md). Each item must have a clear definition of done, the target Figma file or page, and any dependencies. Deliverable: draft backlog items.293. **Tag and categorize**: Apply phase labels (`phase:wireframe`, `phase:visual`, etc.) and design system impact labels (`ds:none`, `ds:new-component`, etc.) per the [backlog framework](references/backlog-framework.md). Deliverable: tagged backlog items.304. **Sequence and link**: Order items using the sequencing rules in the [backlog framework](references/backlog-framework.md). Apply dependency flags (BLOCKED:research, BLOCKED:content) where upstream work is outstanding. Deliverable: sequenced backlog ready for sprint planning.3132## Anti-Patterns3334- **Vague tickets**: Creating backlog items like "design the feature" without specifying deliverable type, scope, or definition of done. *Why*: vague items cannot be estimated, assigned, or verified as complete, and they create ambiguity during sprint planning.35- **Skipping dependency mapping**: Adding items without identifying upstream blockers (pending research, missing content, unresolved spec questions). *Why*: designers pick up blocked tasks, stall, and switch context -- wasting capacity and disrupting flow.36- **One-shot population**: Populating the backlog once and never updating it as the brief evolves or scope changes. *Why*: stale backlogs misrepresent the true design workload and lead to missed deliverables.3738## Output3940**On success**: Produces a set of tagged, sequenced design backlog items with definitions of done, dependencies, and phase labels. Delivered in the team's backlog tool, ready for sprint planning.4142**On failure**: Report which parts of the brief could not be decomposed (ambiguous requirements, missing content direction, undefined user flows), what partial items were created, and the questions that must be resolved.4344## Related Skills4546- [`spec-translator-design`](../../../design/head-of-design/spec-translator-design/SKILL.md) -- Design briefs from spec translation are the primary input for backlog population.47- [`effort-estimator-design`](../../../design/head-of-design/effort-estimator-design/SKILL.md) -- Backlog items are the unit of work that effort estimation operates on.48- [`wireframe-builder`](../wireframe-builder/SKILL.md) -- Wireframe tasks are a common output of backlog population.