Design backlog writer

Why this exists, and what I'd change

Why it exists. Engineering tickets written before design is locked in get rewritten. Design output (copy, states, conditionals, pre-fill rules) defines engineering scope. This skill exists to force design-before-tickets in the workflow.

Design tradeoffs.

• Design epics and tasks live in their own folder, parallel to engineering. Same epic conceptually, two artifacts. Cost: looks like duplicate work. The discipline is doing design first, then engineering refs the design output.
• Defines WHAT, not HOW. Data, components, copy, states. Never layout, position, or screen mockups. Cost: junior designers want direction on layout. This skill explicitly won't give it to them.
• Per-field copy tables instead of screen titles. Field labels, helpers, validation, conditions. Cost: very granular. For a tiny feature, this can feel heavyweight.

What I'd change. Auto-generate a dependency checklist that maps each engineering ticket to the design tasks that must be done first. Right now the dependency is implicit. Making it explicit prevents the rewrites.

---

Design Backlog Writer

Create Design Epics (DE) and Design Tasks (DT) that give designers creative licence while providing clear constraints: user jobs, business priorities, data requirements, and component-level copy.

Core Principle

Define WHAT, never HOW. The design backlog specifies what data must be collected, what states exist, what copy each component needs, and what constraints apply. It never prescribes screen layouts, navigation patterns, or interaction models — those are design decisions.

• Epic = JTBD brief (user goals, business priorities, data constraints, success criteria)
• Task = journey-phase scope with field/component-level copy tables
• Copy = per-field labels, helpers, validation messages, conditions — not screen titles or section headings

Naming & Tagging

Artifact	ID format	Filename	Tag (Notion)
Design Epic	DE-[N]	DE-[N]_[descriptive_name].md	Design
Design Task	DT-[N].[T]	DT-[N].[T]_[descriptive_name].md	Design Task

• [N] = sequential epic number
• [T] = sequential task within the epic
• Effort uses T-shirt sizing: S, M, L, XL

Directory Structure

All design backlog output lives in outputs/backlog/design/ organised by feature:

outputs/backlog/design/
└── [feature-name]/
    ├── DE-[N]_[descriptive_name].md   ← Design Epic
    ├── DT-[N].1_[descriptive_name].md ← Design Task 1
    └── DT-[N].2_[descriptive_name].md ← Design Task 2

Use templates/design-epic-template.md and templates/design-task-template.md as the base for each file.

Design Epic Structure

Use templates/design-epic-template.md as the base. See outputs/backlog/design/ for completed examples.

Frontmatter

---
epic_id: DE-[N]
issue_type: Epic
tags: Design
product_group: [Your product area]
priority: [P0|P1|P2]
status: Draft
design_effort: [S|M|L|XL]
notion_ticket:
---

Content Sections

1. User Jobs to Be Done — Primary and secondary jobs in the user's voice. Frame as quotes. Focus on what the user wants to accomplish and how they want to feel, not what screens they'll see.

2. Business Priorities — Numbered, opinionated priorities explaining what the business cares about and why. Written as product thinking, not requirements. Each should explain the "so what" — why this priority matters for design decisions.

3. What Must Be Collected — Summary table of data categories, what's collected, and key constraints. Link to the source plan/PRD as the constraint document. Emphasise: "the design must satisfy it, but how it's structured into screens and flows is a design decision."

4. Pre-fill Rules — Non-negotiable data behaviours (read-only fields, editable pre-fills, backend-only fields, fields that must NOT be pre-filled).

5. Success Criteria — Measurable outcomes (completion rates, time targets, error rates).

6. Design Tasks — Table of child tasks with ID, name, journey phase, and effort.

7. Existing Design Assets — Figma links, what's already designed, what's out of scope.

8. Reference — Links to PRDs, plans, engineering epics, LOV data.

Design Task Structure

Use templates/design-task-template.md as the base. See outputs/backlog/design/ for completed examples.

Frontmatter

---
design_epic: DE-[N]
parent_epic:
issue_type: Story
tags: Design Task
product_group: [Your product area]
design_effort: [S|M|L|XL]
priority: [P0|P1|P2]
status: Draft
figma_file:
notion_ticket:
---

Content Sections

1. Design Task — 1-2 sentence scope statement. What journey phase this covers.

2. User Job — Single quote from user perspective for this specific task.

3. Business Context — Why this is hard, what the design tensions are, what matters most. Include a "What makes this hard" subsection if there's conditional logic, pre-fill asymmetry, or multi-state complexity.

4. Data to Collect (if applicable) — Summary of field groups with key constraints. Link to source plan for full field specs. Include a pre-fill behaviour table when relevant.

5. Copy — Field & Component Level — The core deliverable. Table format, one row per field/component:

   For data collection tasks:

   Field	Label	Helper / Placeholder	Validation	Condition
   fieldName	User-facing label	Helper text or placeholder	Validation message	When shown / pre-fill state

   For state-based tasks:

   State	Heading	Body	Primary CTA	Secondary CTA
   State name	Heading copy	Body copy	Button text	Button text

   For component-heavy tasks:

   Component	Text	Condition
   Component name	Label or text	When shown

   Add a Pre-fill component copy sub-table when the task includes pre-filled fields.

6. Acceptance Criteria — Checklist format. Focus on what must be true in the design, not how to achieve it. Always include "Arabic / RTL variant included."

7. Reference — Links to specific sections of plans, PRDs, Figma branches, LOV files.

Context Routing (Internal - for Claude)

When this skill is invoked, automatically check:

Source	Location	What to Extract
Active PRDs	outputs/prds/*.md	User goals, data requirements, field specs, conditional logic
Kickoff docs	outputs/prds/*-team-kickoff.md	Scope, constraints, open design questions
User research	outputs/research/synthesis/*.md	User quotes → Epic JTBD framing
Stakeholder profiles	context-library/stakeholder-template.md	Design team contacts, Figma owners
JTBD framework	context-library/strategy/jtbd-canvas.md	JTBD language and framing patterns

Cross-skill links:

• PRD was just written → /prd-draft output is the natural source document
• This skill runs BEFORE /create-tickets — design output (copy, states, conditionals, pre-fill rules) defines engineering scope. Always do design first, then engineering tickets.
• After this skill → push DE and DT files to your project management tool (e.g., Notion, Linear, Jira) using your sync skill
• After this skill → run /create-tickets using both the PRD AND the design output as source; engineering ACs should reference the DT copy tables
• Prototype exists → check outputs/prototypes/ for Figma links to pre-populate figma_file: frontmatter
• Research needed → /user-research-synthesis for JTBD language before writing the Epic

Correct feature workflow:

1. /prd-draft → PRD
2. /design-backlog-writer ← you are here
3. Push design backlog to your PM tool (Notion / Linear / Jira)
4. /create-tickets → engineering tickets (reference design output)
5. Push engineering backlog to your PM tool

Output location: outputs/backlog/design/[feature-name]/

---

Writing Process

1. Read the source document

Read the PRD or plan thoroughly. Identify:

• User goals and pain points → Epic JTBD
• Data requirements and field specs → Task copy tables
• Conditional logic and branching → Task "What makes this hard"
• Pre-fill rules → Epic pre-fill section + task pre-fill tables
• States and scenarios → Task scenario tables

2. Define the Epic as a JTBD brief

Write from the user's perspective. The Epic should read like a design brief, not a requirements doc. Business priorities should be opinionated — explain why something matters for design, not just that it matters.

3. Break tasks by journey phase, not by screen

Group by user intent phase (e.g., "data collection", "consent & submission", "post-submission") rather than by individual screens. The designer decides screen boundaries.

4. Write copy at field/component level

Every user-facing field or component gets a row in the copy table: label, helper/placeholder, validation message, and condition for when it appears. Never write screen titles, section headers, or layout descriptions — those are design decisions.

5. Document conditional logic as data conditions

Express conditions as field-value relationships (incomeType = Employed, maritalStatus = Married), not as screen flows ("on the next screen...").

Watch Out For

• Prescribing screens or layouts. If your task mentions "Screen 1", "top of the page", "bottom sheet" — you're dictating HOW. Remove it.
• Screen-level copy. If your copy section has "Screen title: ..." — refactor to field/component level.
• Missing conditions. Every conditional field must specify when it appears.
• Missing pre-fill states. If a field can arrive pre-filled, specify whether it's read-only or editable.
• Vague acceptance criteria. "Design should be good" → "Pre-filled read-only fields are visually distinct from editable fields."