/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 |