whiteport-design-studio 0.2.2 → 0.3.0

package/docs/{learn-wds → learn}/module-04-product-brief/module-04-overview.md

@@ -72,7 +72,7 @@ The unique features that ensure excellence:
 - AI-guided discovery (no blank page paralysis)
 - Conversational approach (talk it out, Saga writes it down)
 - Structured output (proper formatting automatically)
-- Built-in best practices (SMART goals, constraint checklists)
+- Built-in best practices (the SMART model, constraint checklists)
 - Two levels: Simplified vs Complete (based on project needs)
 
 ### [Lesson 5: Using Your Product Brief](lesson-05-using-brief.md)
@@ -135,13 +135,13 @@ Step-by-step hands-on guide to creating your Product Brief with Saga.
 - **Speed:** 30-45 min vs days of meetings
 - **AI-Guided:** Saga asks the right questions, no blank page
 - **Conversational:** Natural dialogue, not form-filling
-- **Professional:** Built-in best practices (SMART goals, checklists)
+- **Professional:** Built-in best practices (the SMART model, checklists)
 - **Flexible:** Two levels (simplified vs complete)
 - **Living:** Easy to update as you learn
 
 **Additional Documents:**
 - Optional strategic documents created as needed
-- All live in Project Brief folder
+- All live in Product Brief folder
 - Same conversational approach with Saga
 - Expand foundation based on project complexity
 
@@ -189,6 +189,6 @@ By the end of this module, you will:
 
 ---
 
-[← Back to Course Overview](../00-course-overview.md) | [Next: Module 05: Trigger Mapping →](../module-05-trigger-mapping/module-05-overview.md)
+[← Back to Course Overview](../00-course-overview/00-course-overview.md) | [Next: Module 05: Platform Requirements →](../module-05-platform-requirements/module-05-platform-requirements-overview.md)
 
 *Part of the WDS Course: From Designer to Linchpin*

package/docs/{learn-wds → learn}/module-04-product-brief/tutorial-04.md

@@ -1,4 +1,4 @@
-# Tutorial 04: Create Your Project Brief
+# Tutorial 04: Create Your Product Brief
 
 **Hands-on guide to defining your project vision, goals, and constraints**
 
@@ -9,7 +9,7 @@
 This tutorial walks you through creating a complete project brief that serves as the foundation for all design decisions.
 
 **Time:** 30-45 minutes  
-**Prerequisites:** Module 01 completed  
+**Prerequisites:** Module 02 completed (WDS installed)  
 **What you'll create:** A complete project brief document
 
 ---
@@ -90,7 +90,7 @@ Specific, measurable objectives that define project success from a business pers
 
 ### How to do it:
 
-**Framework: SMART Goals**
+**Framework: The SMART Model**
 
 - **S**pecific - Clear and unambiguous
 - **M**easurable - Can track progress
@@ -120,7 +120,7 @@ List 3-5 business goals:
 **AI Support:**
 
 ```
-Agent: "Let's make these goals SMART. For each goal, I'll help you:
+Agent: "Let's express these goals using the SMART model. For each goal, I'll help you:
 - Make it specific and measurable
 - Set realistic targets
 - Define timeframes"
@@ -294,7 +294,7 @@ Define your success criteria:
 **Completeness:**
 
 - ✓ Vision is clear and compelling
-- ✓ Goals are SMART
+- ✓ Goals are expressed using the SMART model
 - ✓ All stakeholder groups identified
 - ✓ Constraints documented
 - ✓ Success criteria defined
@@ -318,7 +318,7 @@ Agent: "Let me review your project brief:
 
 ---
 
-## Step 7: Save Your Project Brief
+## Step 7: Save Your Product Brief
 
 **Create file:** `A-Project-Brief/project-brief.md`
 
@@ -354,7 +354,7 @@ Agent: "Let me review your project brief:
 
 **Next Module:**
 
-- [Module 03: Identify Target Groups](../module-03-identify-target-groups/module-03-overview.md)
+- [Module 03: Identify Target Groups](../module-03-alignment-signoff/module-03-overview.md)
 - Start mapping WHO your users are
 
 ---
@@ -397,4 +397,6 @@ A: Use the brief to facilitate alignment discussions. Document disagreements and
 
 **Your project brief is the foundation for everything that follows. Take the time to get it right!**
 
-[← Back to Module 02](module-02-overview.md) | [Next: Module 03 →](../module-03-identify-target-groups/module-03-overview.md)
+[← Back to Module Overview](module-04-overview.md) | [Next: Module 05 - Platform Requirements →](../module-05-platform-requirements/module-05-platform-requirements-overview.md)
+
+*Part of Module 04: Product Brief*

package/docs/learn/module-05-platform-requirements/lesson-01-why-boundaries-matter.md

@@ -0,0 +1,232 @@
+# Module 05: Platform Requirements
+
+## Lesson 1: Why Boundaries Matter
+
+**Designing in reality, not fantasy**
+
+---
+
+## The Beautiful Disaster
+
+Picture this: You've spent three weeks designing a stunning real-time collaboration feature. Users can see each other's cursors moving across the screen. Changes sync instantly. It's beautiful.
+
+You present it to the development team.
+
+Silence.
+
+Then: "Our backend doesn't support WebSockets. That would take months to implement."
+
+Three weeks of design work. Gone. Not because the design was bad, but because you designed in ignorance of what was possible.
+
+---
+
+## The Invisible Fence
+
+Every project has boundaries. Technical boundaries. Budget boundaries. Timeline boundaries. Expertise boundaries.
+
+**Most designers never see these fences until they crash into them.**
+
+And by then, they've invested significant time designing solutions that can't be built. Or can only be built at enormous cost. Or will take so long that the project loses momentum.
+
+**This isn't just frustrating — it's preventable.**
+
+---
+
+## What Boundaries Really Are
+
+Boundaries aren't limitations on your creativity. They're the shape of reality that your design must fit into.
+
+**Think of it like architecture:**
+
+An architect doesn't complain about gravity. They design *with* it. They use it. They understand that buildings must stand up, water runs downhill, and structural loads must be distributed.
+
+**As a designer, your gravity is:**
+
+- The platforms you're targeting (web, mobile, desktop)
+- The systems you must integrate with (authentication, payments, APIs)
+- The constraints you must work within (budget, timeline, team skills)
+- The complexity that exists in integrations
+- The gaps in what the team knows
+
+These aren't restrictions. They're the physics of your design universe.
+
+---
+
+## The Real Cost of Ignorance
+
+Let's be blunt about what happens when designers don't understand platform requirements:
+
+**Scenario 1: The Offline Fantasy**
+
+Designer creates mobile app with offline-first experience. Beautiful sync conflict resolution. Elegant local storage patterns.
+
+Reality: Client only has budget for a web app. No native development resources. The entire offline architecture? Irrelevant.
+
+**Scenario 2: The Integration Assumption**
+
+Designer assumes single sign-on with existing company tools. Designs seamless flow between systems.
+
+Reality: Legacy system has no API. Integration would require custom middleware costing $50K. Feature gets cut.
+
+**Scenario 3: The Performance Ignore**
+
+Designer creates image-heavy, animation-rich experience.
+
+Reality: Target users are in regions with slow internet. Page takes 30 seconds to load. Bounce rate is 90%.
+
+**Each of these represents weeks or months of wasted work.**
+
+---
+
+## This Isn't About Being a Developer
+
+Here's what many designers get wrong: they think understanding platform requirements means becoming technical. Learning to code. Understanding databases.
+
+**No.**
+
+You don't need to know *how* WebSockets work. You need to know *whether they're available*.
+
+You don't need to understand OAuth implementation details. You need to know *which authentication the client already uses*.
+
+You don't need to design the database schema. You need to know *what data already exists*.
+
+**You're discovering boundaries, not building infrastructure.**
+
+---
+
+## The Strategic Advantage
+
+When you understand platform requirements, something shifts:
+
+**Your designs become immediately buildable.**
+
+Developers don't push back. They don't say "that's not possible." They say "yes, we can do that."
+
+**Your estimates become accurate.**
+
+Because you're designing within real constraints, timeline predictions hold. Projects finish on time.
+
+**Your stakeholders gain confidence.**
+
+When every design is grounded in reality, stakeholders trust your judgment. They stop micromanaging technical feasibility.
+
+**You become the designer who "gets it."**
+
+The one who doesn't waste time. The one who delivers. The one who makes implementation smooth instead of painful.
+
+---
+
+## When to Discover Boundaries
+
+This is Phase 1 work — before you design anything.
+
+**Before sketches.** Before wireframes. Before mockups. Before prototypes.
+
+If you wait until you're deep in design to discover boundaries, you'll have to throw work away. If you discover them upfront, every minute of design time is spent on solutions that can actually be built.
+
+**The time investment is tiny:**
+
+- 30 minutes with Saga
+- A conversation with the development team
+- A quick review of existing systems
+
+**The payoff is massive:**
+
+- Zero wasted design time
+- Immediate developer buy-in
+- Stakeholder confidence
+- Faster project completion
+
+---
+
+## The Saga Approach
+
+This is why Saga handles platform requirements, not Freya.
+
+**Platform requirements are strategic, not creative.**
+
+You're not designing — you're discovering. You're mapping the terrain before you start building.
+
+Saga asks the strategic questions:
+
+- "What platforms are we targeting?"
+- "What systems need to integrate?"
+- "What constraints should I know about?"
+- "What feels risky or unknown?"
+
+These questions surface boundaries before they become blockers.
+
+---
+
+## What You're Creating
+
+At the end of this module, you'll have:
+
+`A-Product-Brief/platform-requirements.md`
+
+A simple document that captures:
+
+1. **Platforms** — Where the product will live
+2. **Integrations** — What systems connect
+3. **Constraints** — What's impossible or expensive
+4. **Complexity** — Where challenges exist
+5. **Knowledge Gaps** — What we don't know yet
+
+This document travels with your Product Brief because it's strategic context — the shape of reality that all design decisions must respect.
+
+---
+
+## The Handoff Advantage
+
+Here's a powerful pattern:
+
+Once you document platform requirements, you can **hand them off to development immediately**.
+
+While you move into UX design, Freya can also handle development tasks in parallel:
+
+- Research knowledge gaps
+- Spike complex integrations
+- Set up development environment
+- Validate technical assumptions
+
+**Design and platform prep happen in parallel.**
+
+You're not waiting. You're not blocked. The project moves forward on multiple fronts simultaneously.
+
+---
+
+## The Emotional Shift
+
+Without understanding boundaries:
+
+- Constant anxiety about whether designs are buildable
+- Fear of presenting to developers
+- Frustration when ideas get rejected
+- Feeling like you're working in the dark
+
+With understanding boundaries:
+
+- Confidence that every design is grounded
+- Developer meetings become collaborative, not confrontational
+- Ideas get refined, not rejected
+- Clarity about what's possible and what's not
+
+**This one shift transforms how it feels to work on projects.**
+
+---
+
+## What's Next
+
+In the next lesson, you'll learn exactly how to document platform requirements. We'll walk through each section: platforms, integrations, constraints, complexity, and knowledge gaps.
+
+Then you'll practice with a tutorial that guides you through creating your own platform-requirements.md.
+
+---
+
+**[Continue to Lesson 2: Defining Platform Requirements →](lesson-02-defining-platform-requirements.md)**
+
+---
+
+[← Back to Module Overview](module-05-platform-requirements-overview.md)
+
+*Part of Module 05: Platform Requirements*