ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity
BMAD-METHOD/docs/learn/module-16-design-delivery/module-16-design-delivery-o...

5.6 KiB
Raw Blame History

Module 16: Design Delivery

Time: 45 min | Agent: Freya | Phase: UX Design [H] Handover | Focus: Delivery

Where Design Meets Development

You've designed complete flows — scenarios, specifications, prototypes, visual design. Now you package them for development.

In the BMad method, design deliveries are the bridge between your design work and the development team (or development agents). Each delivery is a complete, testable flow — not a single widget or half-finished page, but a full user journey from entry to exit.

What Is a Design Delivery?

A Design Delivery (DD) is a YAML file that acts as a contract between design and development. It packages everything needed to build one complete flow:

  • What you're delivering and why it matters
  • Which scenarios, pages, and components are included
  • What technical requirements exist
  • How to validate the implementation
  • How complex the work is

The DD file doesn't contain the actual design work — it references your scenarios, specifications, and design system. One source of truth, no duplication.

Where Deliveries Live

Design deliveries sit alongside the PRD in the E-PRD folder:

E-PRD/
├── 10-PRD.md                              ← Master PRD document
├── design-deliveries/
│   ├── DD-001-user-registration.yaml      ← Complete flow: signup → welcome
│   ├── DD-001-handoff-log.md              ← Notes from handoff dialog
│   ├── DD-002-dashboard.yaml              ← Complete flow: login → dashboard
│   └── DD-002-handoff-log.md
└── test-scenarios/
    ├── TS-001-user-registration.yaml      ← Tests for DD-001
    └── TS-002-dashboard.yaml              ← Tests for DD-002

How this connects to the PRD

The master PRD (10-PRD.md) has a Section 4: Functional Requirements that grows as you complete deliveries. Each DD adds its functional requirements to this section, building up the complete product specification over time.

The PRD provides the technical foundation (architecture, APIs, data models). The DD files provide the design specification. Together they give development everything needed to build.

The Rule: Complete and Testable

A design delivery must be a complete, testable flow. This means:

  • Complete: Entry point to exit point, every screen specified
  • Testable: A tester can verify it works without asking you questions
  • Valuable: It delivers real user and business value on its own

Good delivery scope:

  • User registration flow (landing → signup → email verification → welcome)
  • Dashboard experience (login → dashboard → key actions)
  • Checkout flow (cart → payment → confirmation)

Bad delivery scope:

  • Just the signup form (not a complete flow)
  • A button component (not a flow at all)
  • Half the dashboard with placeholder pages

If a flow isn't complete, go back to the design activities in Phase 4 and finish it.

The Delivery Process

In the WDS workflow, design delivery is the [H] Handover activity within Phase 4 (UX Design). When Freya detects that a flow is complete, she initiates the handover:

Step 1: Detect completion — Is the flow complete and testable?
    ↓
Step 2: Create Design Delivery (DD-XXX.yaml)
    ↓
Step 3: Create Test Scenario (TS-XXX.yaml)
    ↓
Step 4: Handoff Dialog (20-30 min with development team)
    ↓
Step 5: Hand off (mark as in_development)
    ↓
Step 6: Continue with next flow (return to design activity)

This is iterative. You don't deliver everything at once. As soon as one flow is complete, package it and hand it off. Then start the next flow while development builds the first one.

Parallel Work

The delivery model enables parallel work:

Week 1: Design Flow 1
Week 2: Hand off Flow 1 → Dev builds Flow 1
        Design Flow 2
Week 3: Hand off Flow 2 → Dev builds Flow 2
        Test Flow 1 (Module 17)
        Design Flow 3

You design the next flow while development builds the current one. Testing validates what was built last. Everyone stays productive.

What You'll Learn

Lesson 1: Validation and Packaging

The validation checklist, the Freya audit, creating the DD file and test scenario, the handoff dialog, and what makes a delivery ready.

Common Mistakes

Mistake Fix
Delivering incomplete flows Check: entry to exit, every screen specified
Missing acceptance criteria Write them before delivery — testable, specific
Vague specifications Run Freya's audit: no "appropriate" or "suitable"
Duplicating content in DD Reference artifacts, don't copy them
Delivering too late Hand off as soon as a flow is complete
Skipping the handoff dialog 20-30 minutes prevents weeks of misunderstanding

The Test

Can a developer who has never seen this project build this flow correctly from your DD file and the artifacts it references?

If no, it's not ready.

Practice

For one completed flow:

  1. Run through the validation checklist
  2. Fill any gaps
  3. Create the DD-XXX.yaml file
  4. Write acceptance criteria
  5. Create the test scenario

Lessons

Lesson 1: Validation and Packaging

Ensuring everything is complete and packaging for handoff

Tutorial

Tutorial 16: Create Your Delivery

Hands-on guide to validating specifications and packaging for handoff

Next Module

Module 17: Usability Testing →

Test your design with real users.

Part of the WDS Course: From Designer to Linchpin