252 lines
6.9 KiB
Markdown
252 lines
6.9 KiB
Markdown
# Module 07: The Design Phase
|
|
|
|
## Lesson 1: Entering Design Mode
|
|
|
|
**The transition from strategy to creation**
|
|
|
|
---
|
|
|
|
## You've Built the Foundation
|
|
|
|
Take a moment to appreciate what you've accomplished:
|
|
|
|
**Module 04: Product Brief** — Your North Star
|
|
- Vision and positioning
|
|
- Target users and stakeholders
|
|
- Success criteria and constraints
|
|
|
|
**Module 05: Platform Requirements** — Your Boundaries
|
|
- Platforms you're targeting
|
|
- Integrations required
|
|
- Constraints and knowledge gaps
|
|
|
|
**Module 06: Trigger Map** — User Psychology Mapped
|
|
- Personas with driving forces
|
|
- Business goals connected to features
|
|
- The "why" behind every decision
|
|
|
|
This is your strategic foundation. Every design decision you make from here forward references these documents.
|
|
|
|
---
|
|
|
|
## The Mindset Shift
|
|
|
|
Strategy is about **discovering and documenting**.
|
|
Design is about **visualizing and specifying**.
|
|
|
|
You're moving from:
|
|
|
|
| Strategy Mode | Design Mode |
|
|
|---------------|-------------|
|
|
| What should we build? | How should it work? |
|
|
| Why does this matter? | What does the user see? |
|
|
| Who is this for? | How do they accomplish their goal? |
|
|
| What's possible? | What exactly happens? |
|
|
|
|
Both matter. But they require different thinking.
|
|
|
|
---
|
|
|
|
## Before We Begin: Why Specifications Matter
|
|
|
|
Before diving into the design workflow, you need to understand a critical question:
|
|
|
|
**"Why can't we just skip to code?"**
|
|
|
|
**Short answer:** Because code is 10-20% of the value. Specifications are 80-90%.
|
|
|
|
**Your app exists in specifications.** The code is just one possible projection—like compiled output.
|
|
|
|
This isn't about "doing things the hard way." This is about **doing things the professional way** with AI-assisted development.
|
|
|
|
**→ [Read Lesson 2: Why Specifications Matter](lesson-02-why-specifications-matter.md)** for the complete philosophy behind WDS.
|
|
|
|
Key insights you'll learn:
|
|
- Code is a lossy projection from specifications
|
|
- Specifications align humans on shared goals
|
|
- Specs are meta-prompts that enable autonomous AI work
|
|
- Professional approach: Prompt → Spec → Code (not Prompt → Code → Debug hell)
|
|
- Why this represents "the spirit of BMad v6 through the lens of a designer"
|
|
|
|
**This foundation is critical.** Read Lesson 2 before continuing.
|
|
|
|
---
|
|
|
|
## Meet Freya
|
|
|
|
Freya is your design partner for this phase.
|
|
|
|
**What Freya does:**
|
|
|
|
- Thinks WITH you, not FOR you
|
|
- Asks "WHY?" before "WHAT?"
|
|
- Connects every decision to your Trigger Map
|
|
- Won't let you skip the hard thinking
|
|
|
|
**What Freya doesn't do:**
|
|
|
|
- Create pretty pictures without substance
|
|
- Make decisions for you
|
|
- Let you design in isolation from strategy
|
|
- Accept "I don't know" as a final answer
|
|
|
|
She's not a pixel pusher. She's a thinking partner who happens to work with visuals.
|
|
|
|
---
|
|
|
|
## The Freya Approach
|
|
|
|
Freya's first question is always strategic:
|
|
|
|
> "Looking at your Trigger Map, which persona's journey should we design first?"
|
|
|
|
Not: "What color should the button be?"
|
|
|
|
Every design decision connects back to your strategic foundation. If it doesn't connect, it gets questioned.
|
|
|
|
---
|
|
|
|
## The Design Workflow
|
|
|
|
Nine modules. Eight steps. One coherent journey.
|
|
|
|
```
|
|
Outline → Sketch → Storyboard → Specify → Components → Visual → System → Deliver
|
|
```
|
|
|
|
| Step | What You Do | What You Create |
|
|
|------|-------------|-----------------|
|
|
| **Outline Scenarios** | Define user journeys | Scenario outlines |
|
|
| **Conceptual Sketching** | Visualize default states | Rough sketches |
|
|
| **Storyboarding** | Show transformations | Keyframe sequences |
|
|
| **Specifications** | Document every detail | Complete specs |
|
|
| **Components** | Define reusable patterns | Component definitions |
|
|
| **Visual Design** | Apply visual language | Polished designs |
|
|
| **Design System** | Organize for reuse | System documentation |
|
|
| **Delivery** | Package for implementation | Delivery package |
|
|
|
|
---
|
|
|
|
## Not Strictly Linear
|
|
|
|
You'll loop back. That's expected.
|
|
|
|
- Sketching reveals gaps in your scenario outline
|
|
- Storyboarding exposes missing states
|
|
- Specifications surface component needs
|
|
- Visual design raises consistency questions
|
|
|
|
**The loop is the process.** Don't fight it.
|
|
|
|
---
|
|
|
|
## Multiple Entry Points
|
|
|
|
Every step offers choices for how you start:
|
|
|
|
| Entry Point | How It Works |
|
|
|-------------|--------------|
|
|
| **I have a sketch** | You provide, AI refines |
|
|
| **I have inspiration** | You share, AI extracts patterns |
|
|
| **Dream it up** | AI creates options, you pick |
|
|
| **Let's discuss** | Conversation shapes the concept |
|
|
|
|
Same step. Same output. Different starting points.
|
|
|
|
You're not forced into one way of working. Use what feels natural for each situation.
|
|
|
|
---
|
|
|
|
## Creative Discipline
|
|
|
|
> "Creative discipline enables creativity, not constrains it."
|
|
|
|
This phrase captures the WDS approach to design.
|
|
|
|
**Without discipline:**
|
|
- Endless exploration with no conclusion
|
|
- Beautiful mockups that solve wrong problems
|
|
- Scattered work that can't be implemented
|
|
- Decisions without rationale
|
|
|
|
**With discipline:**
|
|
- Focused exploration with clear outcomes
|
|
- Beautiful mockups grounded in strategy
|
|
- Coherent work ready for implementation
|
|
- Every decision documented with WHY
|
|
|
|
Structure doesn't limit creativity. It channels it.
|
|
|
|
---
|
|
|
|
## What You'll Create
|
|
|
|
By the end of this phase:
|
|
|
|
| Artifact | Purpose |
|
|
|----------|---------|
|
|
| **Scenario outlines** | The journeys you're designing |
|
|
| **Conceptual sketches** | Visual explorations of each view |
|
|
| **Storyboards** | How elements transform |
|
|
| **Detailed specifications** | Every decision documented |
|
|
| **Component definitions** | Reusable patterns identified |
|
|
| **Visual designs** | Final look and feel |
|
|
| **Design system** | Your component library |
|
|
| **Delivery package** | Ready for implementation |
|
|
|
|
---
|
|
|
|
## Design System
|
|
|
|
Remember the choice from setup:
|
|
|
|
| Mode | What Happens |
|
|
|------|--------------|
|
|
| **1. None** | Ad-hoc styling, no extraction |
|
|
| **2. Building** | System grows from your work |
|
|
| **3. Library** | Use external + your branding |
|
|
| **4. Existing** | Import from previous projects |
|
|
|
|
This affects how Freya works with you throughout the phase.
|
|
|
|
**Mode 1-2:** You're creating the design language as you go
|
|
**Mode 3-4:** You're working within established patterns
|
|
|
|
Neither is better. Just different workflows.
|
|
|
|
---
|
|
|
|
## The Core Principle
|
|
|
|
Every pixel has a reason.
|
|
Every interaction traces back to user psychology.
|
|
Every component connects to a business goal.
|
|
|
|
**Nothing is decoration. Everything is decision.**
|
|
|
|
When you can explain WHY something exists, you've designed well.
|
|
|
|
When you can't explain it, something's missing.
|
|
|
|
---
|
|
|
|
## Ready to Design
|
|
|
|
You have:
|
|
- Strategic foundation (Product Brief, Trigger Map, Platform Requirements)
|
|
- A thinking partner (Freya)
|
|
- A clear workflow (8 steps)
|
|
- Flexible entry points (multiple ways to start each step)
|
|
|
|
Let's begin.
|
|
|
|
---
|
|
|
|
**[Continue to Module 08: Outline Scenarios →](../module-08-outline-scenarios/module-08-outline-scenarios-overview.md)**
|
|
|
|
---
|
|
|
|
[← Back to Module Overview](module-07-design-phase-overview.md)
|
|
|
|
*Part of Module 07: Design Phase*
|