writing-design-plans

name	writing-design-plans
description	Use when you have a design brief or strategy and need to break implementation into reviewable chunks — creates step-by-step plans with verification criteria for each task

Writing Design Plans

A design plan breaks an approved design direction into discrete, reviewable tasks. Each task is small enough to evaluate clearly and specific enough that the result is predictable.

When to Use

• After design-discovery and/or design-strategy have produced an approved direction
• Before any implementation work begins
• When a design task is too large to complete and review in one step

Process

Step 1: Review Inputs

Gather:

• Design brief (from design-discovery)
• Strategy document (from design-strategy, if applicable)
• Personas (from inclusive-personas)
• Existing design system inventory

Step 2: Identify Design Tasks

Break the work into categories:

1. Structure tasks — information architecture, page hierarchy, navigation
2. Component tasks — individual UI components that need designing
3. Layout tasks — how components compose into screens
4. Interaction tasks — states, transitions, feedback patterns
5. Content tasks — copy, labels, error messages, help text
6. Accessibility tasks — specific inclusive design requirements per component

Step 3: Order the Work

Design work has natural dependencies:

Structure → Layout → Components → Interactions → Content → Review
     ↑ accessibility woven through each step, not a final phase ↑

Order tasks so that:

• Foundation work (structure, layout) comes before detail work (interactions, content)
• Each task can be reviewed independently
• Accessibility is addressed within each task, not deferred

Step 4: Write the Plan

# Design Plan: [Feature/Project Name]

> **For agentic workers:** REQUIRED: Use designpowers:designpowers-critique to review completed work against this plan.

**Goal:** [One sentence — what this plan delivers]

**Design Direction:** [Reference to the design brief or strategy]

**Personas:** [Reference to personas this plan serves]

---

## Task 1: [Task Name]

**Files:** [Which files will be created or modified]

- [ ] Step 1: [Specific action]
- [ ] Step 2: [Specific action]
- [ ] Step 3: [Specific action]

**Accessibility check:** [What inclusive design criteria this task must meet]

**Verification:** [How to confirm this task is complete and correct]

---

## Task 2: [Task Name]
...

Step 5: Task Sizing

Each task should be:

• 2-5 minutes of focused work — small enough to hold in your head
• Independently reviewable — someone can evaluate it without seeing everything else
• Specifically described — exact files, exact components, exact acceptance criteria
• Accessibility-inclusive — each task addresses its own inclusive design requirements

If a task takes longer than 5 minutes, break it down further.

Step 6: Save and Review

Save to: docs/designpowers/plans/YYYY-MM-DD-<feature>-plan.md

Present the plan to the user. Walk through:

• Does the task order make sense?
• Are any tasks missing?
• Are the accessibility checks appropriate for each task?
• Is the scope right, or should anything be deferred?

User must approve the plan before execution begins.

Integration

• Called by: design-discovery, design-strategy
• Calls: Implementation begins via the relevant design skills (ui-composition, interaction-design, etc.)
• Pairs with: designpowers-critique (reviews work against the plan)

Anti-Patterns

Pattern	Problem
Tasks without accessibility checks	Every task affects the user experience. Every task has accessibility implications
Tasks that say "make it look good"	Vague tasks produce vague results. Be specific about what "good" means
Accessibility as the final task	By then it is too late. Accessibility is in every task
Plan without persona references	If you do not know who you are designing for, you cannot verify the design works