feat(wds): Add comprehensive deliverables for design workflow
Introduced new documentation files for key deliverables in the WDS design workflow, including the Product Brief, Trigger Map, Platform PRD, Page Specifications, Design System, and Design Delivery PRD. Each document outlines essential components, processes, and strategic insights to guide users through the design and development phases. This update enhances clarity, provides structured guidance, and ensures alignment between design intent and technical execution, facilitating a smoother handoff to development teams.
This commit is contained in:
Mårten Angner
parent
8f3af396dd
commit
c523e3c6bf
|
|
@ -0,0 +1,98 @@
|
|||
# Deliverable 07: Design Delivery PRD
|
||||
|
||||
**Package everything developers need - turn specs into buildable epics and stories**
|
||||
|
||||
---
|
||||
|
||||
## What Is This Deliverable?
|
||||
|
||||
The Design Delivery PRD organizes your page specifications and design system into developer-ready documentation:
|
||||
- Epic breakdown (major features)
|
||||
- User stories (specific tasks)
|
||||
- Acceptance criteria
|
||||
- Technical dependencies
|
||||
- Implementation sequence
|
||||
- Links back to page specifications
|
||||
|
||||
**Created by:** Idunn the WDS Technical Architect Agent
|
||||
**When:** Phase 7 - After page specs and design system are complete
|
||||
**Format:** PRD document with epics, stories, and implementation guide
|
||||
|
||||
---
|
||||
|
||||
## What's Included
|
||||
|
||||
### 1. Implementation Strategy
|
||||
- Development phases
|
||||
- Priority order
|
||||
- Technical dependencies
|
||||
- Resource requirements
|
||||
- Timeline estimates
|
||||
|
||||
### 2. Epics
|
||||
For each major feature:
|
||||
- Epic name and description
|
||||
- Business value
|
||||
- User stories included
|
||||
- Technical dependencies
|
||||
- Acceptance criteria at epic level
|
||||
|
||||
### 3. User Stories
|
||||
For each story:
|
||||
- Story format: "As a [persona], I want to [action] so that [benefit]"
|
||||
- Acceptance criteria (specific, testable)
|
||||
- Linked page specifications
|
||||
- Design system components used
|
||||
- Technical notes
|
||||
- Estimation (story points or time)
|
||||
|
||||
### 4. Component Mapping
|
||||
- Which design system components are needed
|
||||
- Where components are used
|
||||
- Reusability opportunities
|
||||
- Implementation order (dependencies)
|
||||
|
||||
### 5. Handoff Documentation
|
||||
- How to read page specifications
|
||||
- Object ID system explanation
|
||||
- Content strategy references
|
||||
- Testing requirements
|
||||
- Quality criteria
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
*(Example coming soon)*
|
||||
|
||||
---
|
||||
|
||||
## How to Create This
|
||||
|
||||
**Hands-on Tutorial:** [Module 10: Design Delivery](../module-10-design-delivery/tutorial-10.md)
|
||||
|
||||
**Workflow Reference:** [Design Delivery Workflow](../../workflows/6-design-deliveries/)
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Without a Design Delivery PRD:
|
||||
- Developers start coding without full context
|
||||
- Implementation order is inefficient
|
||||
- Design intent gets lost in translation
|
||||
- "What did you mean?" meetings daily
|
||||
- Specifications sit unused
|
||||
|
||||
With a Design Delivery PRD:
|
||||
- Clear implementation roadmap
|
||||
- Developers understand the full picture
|
||||
- Efficient build sequence
|
||||
- Specifications become actionable tasks
|
||||
- Reduced rework and confusion
|
||||
|
||||
---
|
||||
|
||||
**Previous Deliverable:** [Component Library & Design Tokens](design-system.md)
|
||||
**Next Steps:** Hand off to development! (Testing handled by BMM workflows)
|
||||
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
# Deliverable 06: Component Library & Design Tokens
|
||||
|
||||
**Extract reusable patterns - scale your design efficiently across the entire product**
|
||||
|
||||
---
|
||||
|
||||
## What Is This Deliverable?
|
||||
|
||||
The Design System documents all reusable components, patterns, and design tokens:
|
||||
- Component specifications (buttons, cards, forms, etc.)
|
||||
- Design tokens (colors, typography, spacing)
|
||||
- Interaction patterns
|
||||
- Accessibility guidelines
|
||||
- Component usage rules
|
||||
|
||||
**Created by:** Freyja the WDS UX Designer Agent (extraction from page specs)
|
||||
**When:** Phase 6 - After initial page specifications are complete
|
||||
**Format:** Structured component library documentation
|
||||
|
||||
---
|
||||
|
||||
## What's Included
|
||||
|
||||
### 1. Design Tokens
|
||||
- **Colors:** Brand palette, semantic colors, state colors
|
||||
- **Typography:** Font families, sizes, weights, line heights
|
||||
- **Spacing:** Consistent spacing scale
|
||||
- **Shadows:** Elevation system
|
||||
- **Border Radius:** Rounding scale
|
||||
- **Breakpoints:** Responsive design breakpoints
|
||||
|
||||
### 2. Component Library
|
||||
For each component:
|
||||
- Component name and Object ID pattern
|
||||
- Visual examples and variants
|
||||
- States (default, hover, active, disabled, error, loading)
|
||||
- Content structure
|
||||
- Usage guidelines
|
||||
- Accessibility requirements
|
||||
- Code examples (if applicable)
|
||||
|
||||
### 3. Patterns
|
||||
- Navigation patterns
|
||||
- Form patterns
|
||||
- Layout patterns
|
||||
- Interaction patterns
|
||||
- Empty states
|
||||
- Error states
|
||||
- Loading states
|
||||
|
||||
### 4. Guidelines
|
||||
- When to use each component
|
||||
- Accessibility standards (WCAG compliance)
|
||||
- Mobile vs desktop considerations
|
||||
- Brand guidelines integration
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
*(Example coming soon)*
|
||||
|
||||
---
|
||||
|
||||
## How to Create This
|
||||
|
||||
**Hands-on Tutorial:** [Module 09: Design System](../module-09-design-system/tutorial-09.md)
|
||||
|
||||
**Workflow Reference:** [Design System Workflow](../../workflows/5-design-system/)
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Without a Design System:
|
||||
- Every page/screen designed from scratch
|
||||
- Inconsistent UI across product
|
||||
- Developers reinvent components repeatedly
|
||||
- No single source of truth
|
||||
- Design debt accumulates fast
|
||||
|
||||
With a Design System:
|
||||
- Rapid design and development
|
||||
- Consistent user experience
|
||||
- Easier maintenance and updates
|
||||
- Onboarding new designers/developers faster
|
||||
- Scalable design operations
|
||||
|
||||
---
|
||||
|
||||
**Previous Deliverable:** [Page Specifications & Prototypes](page-specifications.md)
|
||||
**Next Deliverable:** [Design Delivery PRD](design-delivery-prd.md)
|
||||
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
# Deliverable 05: Page Specifications & Prototypes
|
||||
|
||||
**Turn sketches into complete specs - capture WHAT it looks like AND WHY you designed it that way**
|
||||
|
||||
---
|
||||
|
||||
## What Is This Deliverable?
|
||||
|
||||
Page Specifications are detailed documentation for each page/screen in your product:
|
||||
- Complete content with language tags
|
||||
- Component descriptions with Object IDs
|
||||
- Navigation and user flows
|
||||
- Strategic rationale for design decisions
|
||||
- Interactive prototypes (optional)
|
||||
|
||||
**Created by:** Freyja the WDS UX Designer Agent
|
||||
**When:** Phase 5 - After Platform PRD (or in parallel)
|
||||
**Format:** Markdown specifications + sketches/prototypes
|
||||
|
||||
---
|
||||
|
||||
## What's Included
|
||||
|
||||
### For Each Page:
|
||||
1. **Navigation Structure**
|
||||
- Page name and placement
|
||||
- Entry and exit points
|
||||
- Embedded sketch/wireframe
|
||||
|
||||
2. **Page Overview**
|
||||
- User situation and context
|
||||
- Page purpose and goals
|
||||
- Success criteria
|
||||
|
||||
3. **Page Sections**
|
||||
- Organized by section objects
|
||||
- Component hierarchy with Object IDs
|
||||
- Content with language tags (EN, etc.)
|
||||
- Links and interactions
|
||||
|
||||
4. **Object Registry**
|
||||
- Complete list of all Object IDs
|
||||
- Component types and parent sections
|
||||
- Status tracking
|
||||
|
||||
5. **Strategic Links**
|
||||
- References to Content Strategy
|
||||
- Connections to Trigger Map
|
||||
- Links to personas and driving forces
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
See the [WDS Presentation Project - Page Specification](../../examples/WDS-Presentation/docs/4-scenarios/1.1-wds-presentation/1.1-wds-presentation.md)
|
||||
|
||||
---
|
||||
|
||||
## How to Create This
|
||||
|
||||
**Hands-on Tutorial:** [Module 08: Initialize Scenario](../module-08-initialize-scenario/tutorial-08.md)
|
||||
|
||||
**Additional Tutorial:** [Module 12: Conceptual Specs](../module-12-conceptual-specs/tutorial-12.md)
|
||||
|
||||
**Workflow Reference:** [UX Design Workflow](../../workflows/4-ux-design/)
|
||||
|
||||
**Quality Workflow:** [Page Specification Quality](../../workflows/4-ux-design/page-specification-quality/)
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Without Detailed Specifications:
|
||||
- Developers guess at your intent
|
||||
- Content gets "lorem ipsum" treatment
|
||||
- Design decisions lost in handoff
|
||||
- Endless "what did you mean?" meetings
|
||||
|
||||
With Page Specifications:
|
||||
- Preserves design intent from concept to code
|
||||
- Developers understand the WHY, not just the WHAT
|
||||
- Content is strategic, not placeholder
|
||||
- Specifications become AI-ready super-prompts
|
||||
- Reduces implementation errors and rework
|
||||
|
||||
---
|
||||
|
||||
**Previous Deliverable:** [Platform PRD & Architecture](platform-prd.md)
|
||||
**Next Deliverable:** [Component Library & Design Tokens](design-system.md)
|
||||
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
# Deliverable 04: Platform PRD & Architecture
|
||||
|
||||
**Define the technical foundation - bridge design vision with technical reality**
|
||||
|
||||
---
|
||||
|
||||
## What Is This Deliverable?
|
||||
|
||||
The Platform PRD (Product Requirements Document) defines the technical architecture and infrastructure decisions:
|
||||
- Data models and database structure
|
||||
- System architecture and tech stack
|
||||
- APIs and integrations
|
||||
- Security and performance requirements
|
||||
- Technical constraints and decisions
|
||||
|
||||
**Created by:** Idunn the WDS Technical Architect Agent
|
||||
**When:** Phase 4 - After Trigger Map, before UX design (or in parallel)
|
||||
**Format:** Structured PRD document + architecture diagrams
|
||||
|
||||
---
|
||||
|
||||
## What's Included
|
||||
|
||||
### 1. System Architecture
|
||||
- High-level architecture diagram
|
||||
- Technology stack decisions (and rationale)
|
||||
- Infrastructure requirements
|
||||
- Deployment strategy
|
||||
|
||||
### 2. Data Models
|
||||
- Entity relationships
|
||||
- Database schema
|
||||
- Data flow diagrams
|
||||
- Storage requirements
|
||||
|
||||
### 3. API Specifications
|
||||
- Endpoint definitions
|
||||
- Request/response formats
|
||||
- Authentication & authorization
|
||||
- Rate limiting and caching
|
||||
|
||||
### 4. Technical Requirements
|
||||
- Performance benchmarks
|
||||
- Security requirements
|
||||
- Scalability considerations
|
||||
- Browser/device support
|
||||
|
||||
### 5. Integration Points
|
||||
- Third-party services
|
||||
- External APIs
|
||||
- Authentication providers
|
||||
- Analytics and monitoring
|
||||
|
||||
### 6. Technical Risks
|
||||
- Known challenges
|
||||
- Mitigation strategies
|
||||
- Technical debt considerations
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
*(Example coming soon)*
|
||||
|
||||
---
|
||||
|
||||
## How to Create This
|
||||
|
||||
**Hands-on Tutorial:** [Module 06: Platform Architecture](../module-06-platform-architecture/tutorial-06.md)
|
||||
|
||||
**Workflow Reference:** [Platform PRD Workflow](../../workflows/3-prd-platform/)
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Without Platform Architecture:
|
||||
- Designers create UX that's technically impossible
|
||||
- Developers make inconsistent tech decisions
|
||||
- Costly rework when design meets reality
|
||||
- Security and performance as afterthoughts
|
||||
|
||||
With Platform Architecture:
|
||||
- Realistic design constraints from day one
|
||||
- Technical decisions documented and justified
|
||||
- Developers aligned on approach
|
||||
- Foundation for sustainable growth
|
||||
|
||||
---
|
||||
|
||||
**Previous Deliverable:** [Trigger Map & Personas](trigger-map.md)
|
||||
**Next Deliverable:** [Page Specifications & Prototypes](page-specifications.md)
|
||||
|
||||
|
|
@ -0,0 +1,146 @@
|
|||
# Deliverable: Product Brief
|
||||
|
||||
**Crystal-clear strategic foundation that guides every design decision**
|
||||
|
||||
---
|
||||
|
||||
## About WDS & the Product brief
|
||||
|
||||
**WDS (Whiteport Design Studio)** is an AI agent framework module within the BMAD Method that transforms how designers work. Instead of creating documentation that gets lost in translation, your design work becomes **powerful prompts** that guide AI agents and development teams with precision and intent.
|
||||
|
||||
**The Product Brief** is your first strategic deliverable in the WDS workflow. After you've secured stakeholder commitment (Pitch & Service Agreement), this document defines **what you're building and why it matters**. Everything that follows - from trigger mapping to final specifications - builds on this foundation.
|
||||
|
||||
Think of it as your project's constitution: the strategic reference point that keeps everyone aligned as the project evolves.
|
||||
|
||||
---
|
||||
|
||||
## What Is This Deliverable?
|
||||
|
||||
The Product Brief is your project's north star - a comprehensive document that defines:
|
||||
- What you're building and why it matters
|
||||
- Who it's for and what problems it solves
|
||||
- How success will be measured
|
||||
- Strategic positioning and competitive landscape
|
||||
- Technical and business constraints
|
||||
|
||||
**Created by:** Saga the WDS Analyst Agent
|
||||
**When:** Phase 2 (Module 04) - After alignment, before design work begins
|
||||
**Format:** Structured markdown document
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
**Without a solid Product Brief:**
|
||||
- ❌ Teams build features nobody asked for
|
||||
- ❌ Scope creep becomes unmanageable
|
||||
- ❌ Design decisions based on personal preference, not strategy
|
||||
- ❌ You can't evaluate trade-offs ("Should we add this feature?")
|
||||
|
||||
**With a Product Brief:**
|
||||
- ✅ Every design decision has clear rationale
|
||||
- ✅ Team alignment on priorities
|
||||
- ✅ Ability to say "no" to scope creep
|
||||
- ✅ Confidence that you're building the right thing
|
||||
|
||||
---
|
||||
|
||||
## The Dialog with Your Thinking Partner: Saga the Analyst
|
||||
|
||||
**The Process (30-45 minutes):**
|
||||
|
||||
Saga the Analyst guides you through defining your product with strategic questions:
|
||||
|
||||
```
|
||||
Saga the Analyst: "Let's start with the vision. In one sentence,
|
||||
what transformation are you creating for users?"
|
||||
|
||||
You: "We're helping small teams manage their projects without
|
||||
the complexity of enterprise tools."
|
||||
|
||||
Saga the Analyst: "Perfect! That's clear. Now, who specifically is this for?"
|
||||
|
||||
You: "Remote teams of 3-10 people - freelancers, startups, small agencies."
|
||||
|
||||
Saga the Analyst: "Got it. Who is this NOT for?"
|
||||
|
||||
You: "Large enterprises with complex approval workflows -
|
||||
they need something different."
|
||||
|
||||
Saga the Analyst: "Great clarity! Let's talk about core features..."
|
||||
```
|
||||
|
||||
As you talk, Saga the Analyst creates:
|
||||
- ✅ Vision statement
|
||||
- ✅ Target users (who it's for, who it's NOT for)
|
||||
- ✅ Core features (prioritized)
|
||||
- ✅ Success criteria (SMART objectives)
|
||||
- ✅ Competitive landscape
|
||||
- ✅ Constraints
|
||||
|
||||
Then you review together:
|
||||
|
||||
```
|
||||
Saga the Analyst: "Here's your Product Brief. Does this capture your vision?"
|
||||
|
||||
You: "Yes! But add 'time tracking' to must-haves."
|
||||
|
||||
Saga the Analyst: "Updated! ✅ Brief is ready."
|
||||
```
|
||||
|
||||
**Result:** Product Brief saved to `/docs/1-project-brief/01-product-brief.md`
|
||||
|
||||
---
|
||||
|
||||
## What's Included
|
||||
|
||||
### Core Sections
|
||||
1. **Project Vision:** The big picture - what transformation you're creating
|
||||
2. **Product Positioning:** How you're different from competitors
|
||||
3. **Target Users:** Detailed description of who this is for (and who it's NOT for)
|
||||
4. **Core Features:** Essential functionality (prioritized)
|
||||
5. **Success Criteria:** SMART objectives and measurable KPIs
|
||||
6. **Competitive Landscape:** Where you fit in the market
|
||||
7. **Constraints:** Budget, timeline, technical, regulatory limitations
|
||||
8. **Business Model:** How this makes/saves money
|
||||
9. **Risks & Assumptions:** What could go wrong and what we're betting on
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
See the [WDS Presentation Project - Product Brief](../../examples/WDS-Presentation/docs/1-project-brief/01-product-brief.md)
|
||||
|
||||
---
|
||||
|
||||
## Agent Activation
|
||||
|
||||
To start creating your Product Brief:
|
||||
|
||||
```
|
||||
@saga I need to create a Product Brief for [Your Project Name].
|
||||
```
|
||||
|
||||
Saga the Analyst will begin the conversation and guide you through the process.
|
||||
|
||||
---
|
||||
|
||||
## How to Create This
|
||||
|
||||
**Hands-on Tutorial:** [Module 04: Project Brief](../module-04-project-brief/tutorial-04.md)
|
||||
|
||||
**Workflow Reference:** [Project Brief Workflow](../../workflows/1-project-brief/)
|
||||
|
||||
---
|
||||
|
||||
## Getting Started with WDS
|
||||
|
||||
New to WDS? Install the complete AI agent framework to unlock all capabilities:
|
||||
|
||||
👉 **[Install WDS & Get Started](../../getting-started/getting-started-overview.md)**
|
||||
|
||||
---
|
||||
|
||||
**Previous Deliverable:** [Service Agreement](service-agreement.md)
|
||||
**Next Deliverable:** [Trigger Map & Personas](trigger-map.md)
|
||||
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
# Deliverable: Project Pitch
|
||||
|
||||
**Persuade stakeholders your project is worth the investment**
|
||||
|
||||
---
|
||||
|
||||
## What Is This Deliverable?
|
||||
|
||||
The Project Pitch is your persuasive document that:
|
||||
- Articulates your project vision in business language stakeholders understand
|
||||
- Demonstrates clear ROI and strategic value
|
||||
- Shows you've thought through the approach
|
||||
- Convinces decision-makers to say "yes"
|
||||
|
||||
**Created by:** Saga the WDS Analyst Agent
|
||||
**When:** Phase 1 (Module 03) - Before you have formal commitment
|
||||
**Format:** Markdown document, often converted to PDF/presentation
|
||||
|
||||
---
|
||||
|
||||
## What's Included
|
||||
|
||||
- **Project Overview:** Clear statement of what you're building and why
|
||||
- **Business Value:** ROI, cost savings, or strategic benefits
|
||||
- **Problem Statement:** What pain points does this solve?
|
||||
- **Approach:** High-level methodology and timeline
|
||||
- **Investment Required:** Budget, resources, time commitment
|
||||
- **Success Criteria:** How we'll know if it worked
|
||||
- **Next Steps:** What happens if they say yes
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
See the [WDS Presentation Project - Pitch](#) *(Coming soon)*
|
||||
|
||||
---
|
||||
|
||||
## How to Create This
|
||||
|
||||
**Hands-on Tutorial:** [Module 03: Alignment & Signoff](../module-03-alignment-signoff/tutorial-03.md)
|
||||
|
||||
**Workflow Reference:** [Alignment & Signoff Workflow](../../workflows/1-project-brief/alignment-signoff/)
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Without a compelling pitch:
|
||||
- Decision-makers don't understand the value
|
||||
- Projects get stuck in "let me think about it" limbo
|
||||
- You can't articulate ROI clearly
|
||||
- Stakeholders dismiss it as "nice to have"
|
||||
|
||||
With a strong pitch:
|
||||
- Clear business case for investment
|
||||
- Stakeholders excited about the vision
|
||||
- Decision happens quickly (yes or no)
|
||||
- Foundation for alignment on goals
|
||||
|
||||
---
|
||||
|
||||
**Next Deliverable:** [Service Agreement](service-agreement.md) - Formalize the commitment (after pitch is accepted)
|
||||
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
# Deliverable: Service Agreement
|
||||
|
||||
**Formalize stakeholder commitment with a clear contract**
|
||||
|
||||
---
|
||||
|
||||
## What Is This Deliverable?
|
||||
|
||||
The Service Agreement is your formal contract that:
|
||||
- Defines scope of work (what's included, what's not)
|
||||
- Establishes clear deliverables and timeline
|
||||
- Protects both parties with terms and conditions
|
||||
- Provides legal foundation for the project
|
||||
|
||||
**Created by:** Saga the WDS Analyst Agent
|
||||
**When:** Phase 1 (Module 03) - After pitch is accepted, before work begins
|
||||
**Format:** Markdown document converted to contract/PDF format
|
||||
|
||||
---
|
||||
|
||||
## What's Included
|
||||
|
||||
- **Scope of Work:** What's included (and what's explicitly not)
|
||||
- **Deliverables:** Tangible outputs you'll produce (with links to examples)
|
||||
- **Timeline:** Key milestones and completion dates
|
||||
- **Payment Terms:** Cost structure, payment schedule, late fees
|
||||
- **Change Management:** How scope changes are handled (change order process)
|
||||
- **Acceptance Criteria:** When work is considered complete
|
||||
- **Intellectual Property:** Who owns what (code, designs, content)
|
||||
- **Termination Clause:** How either party can exit the agreement
|
||||
- **Warranties & Limitations:** What you guarantee (and don't)
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
See the [WDS Presentation Project - Service Agreement](#) *(Coming soon)*
|
||||
|
||||
---
|
||||
|
||||
## How to Create This
|
||||
|
||||
**Hands-on Tutorial:** [Module 03: Alignment & Signoff](../module-03-alignment-signoff/tutorial-03.md)
|
||||
|
||||
**Workflow Reference:** [Alignment & Signoff Workflow](../../workflows/1-project-brief/alignment-signoff/)
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Without a formal agreement:
|
||||
- Scope creep becomes unmanageable
|
||||
- Payment becomes contentious ("that's not what I meant")
|
||||
- No protection if client stops paying
|
||||
- Unclear who owns the final work
|
||||
|
||||
With a service agreement:
|
||||
- Protected scope and budget
|
||||
- Clear payment terms
|
||||
- Legal recourse if needed
|
||||
- Professional credibility
|
||||
- Foundation for healthy client relationships
|
||||
|
||||
---
|
||||
|
||||
**Previous Deliverable:** [Project Pitch](project-pitch.md) - Get stakeholder buy-in first
|
||||
**Next Deliverable:** [Product Brief](product-brief.md) - Define what you're actually building
|
||||
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
# Deliverable 03: Trigger Map & Personas
|
||||
|
||||
**Connect business goals to user psychology - design with insight, not guesswork**
|
||||
|
||||
---
|
||||
|
||||
## What Is This Deliverable?
|
||||
|
||||
The Trigger Map is a strategic framework that connects:
|
||||
- **Business Goals:** What the company wants to achieve
|
||||
- **User Psychology:** What motivates and frustrates your users
|
||||
- **Personas:** Detailed profiles of key user groups
|
||||
- **Feature Priorities:** Which features move the needle on both
|
||||
|
||||
**Created by:** Cascade the WDS Strategist Agent
|
||||
**When:** Phase 3 - After Product Brief, before design begins
|
||||
**Format:** Visual map + detailed persona documents
|
||||
|
||||
---
|
||||
|
||||
## What's Included
|
||||
|
||||
### 1. Business Goals
|
||||
- SMART objectives with measurable targets
|
||||
- Priority ranking (what matters most?)
|
||||
- Connection to product strategy
|
||||
|
||||
### 2. Driving Forces
|
||||
- **Positive Forces:** What motivates users (aspirations, gains, desires)
|
||||
- **Negative Forces:** What frustrates users (pain points, fears, obstacles)
|
||||
- Emotional and practical triggers for each persona
|
||||
|
||||
### 3. Personas
|
||||
Detailed profiles for each key user group:
|
||||
- Background & context
|
||||
- Current situation & pain points
|
||||
- Goals & aspirations
|
||||
- Fears & frustrations
|
||||
- Motivations & values
|
||||
- Tech savviness & preferences
|
||||
|
||||
### 4. Feature Impact Analysis
|
||||
- How each feature affects persona driving forces
|
||||
- Impact on business goals
|
||||
- Priority matrix (High/Medium/Low impact)
|
||||
|
||||
### 5. Key Insights
|
||||
- Strategic recommendations
|
||||
- Design principles derived from psychology
|
||||
- "Aha!" moments from the mapping process
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
See the [WDS Presentation Project - Trigger Map](../../examples/WDS-Presentation/docs/2-trigger-map/)
|
||||
|
||||
---
|
||||
|
||||
## How to Create This
|
||||
|
||||
**Hands-on Tutorial:** [Module 04: Trigger Mapping](../module-04-map-triggers-outcomes/tutorial-04.md)
|
||||
|
||||
**Workflow Reference:** [Trigger Mapping Workflow](../../workflows/2-trigger-mapping/)
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Without Trigger Mapping:
|
||||
- You guess at user needs based on assumptions
|
||||
- Features get prioritized by "coolness" not impact
|
||||
- Design feels generic and disconnected
|
||||
- No psychological foundation for UX decisions
|
||||
|
||||
With Trigger Mapping:
|
||||
- Design decisions grounded in user psychology
|
||||
- Clear feature prioritization based on impact
|
||||
- Personas with depth (not demographic stereotypes)
|
||||
- Connection between what users need and what business wants
|
||||
|
||||
---
|
||||
|
||||
**Previous Deliverable:** [Product Brief](product-brief.md)
|
||||
**Next Deliverable:** [Platform PRD & Architecture](platform-prd.md)
|
||||
|
||||
|
|
@ -0,0 +1,358 @@
|
|||
# Tutorial 06: Platform Architecture
|
||||
|
||||
**Let Idunn translate your product vision into technical architecture - you speak design, she speaks code**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
You've designed the experience. Now you need the technical foundation to make it real. But you're a designer, not a developer - how do you define databases, APIs, and system architecture?
|
||||
|
||||
**You don't.** Idunn does.
|
||||
|
||||
You just describe your product in design language. Idunn translates it into Platform PRD.
|
||||
|
||||
**Time:** 30-45 minutes
|
||||
**Prerequisites:** Module 05 completed (Trigger Map ready)
|
||||
**What you'll create:** Platform PRD & Architecture Document
|
||||
|
||||
---
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
- What a Platform PRD is (and why it matters)
|
||||
- How to describe your product's technical needs without being technical
|
||||
- How Idunn helps you think through platform decisions
|
||||
- What questions she'll ask (so you're not surprised)
|
||||
|
||||
---
|
||||
|
||||
## What is Platform PRD?
|
||||
|
||||
**Platform PRD** = The technical blueprint developers need to build your product.
|
||||
|
||||
It includes:
|
||||
- **System Architecture:** How the pieces fit together
|
||||
- **Data Models:** What information needs to be stored
|
||||
- **APIs & Integrations:** How systems talk to each other
|
||||
- **Technical Requirements:** Performance, security, scalability
|
||||
|
||||
**Your superpower:** You don't need to know how to write this. You just need to know **what your product does**.
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Understand Your Role (2 min)
|
||||
|
||||
**Your job as designer:**
|
||||
- Describe what users need to do
|
||||
- Explain what data they create/view/edit
|
||||
- Identify third-party services you want (payments, auth, analytics)
|
||||
- Share any technical constraints you know about
|
||||
|
||||
**Idunn's job:**
|
||||
- Ask clarifying questions about technical needs
|
||||
- Translate your product into architecture decisions
|
||||
- Document data models, APIs, system diagrams
|
||||
- Flag technical risks and recommend solutions
|
||||
|
||||
**You bring product knowledge. She brings technical expertise.**
|
||||
|
||||
---
|
||||
|
||||
## What to Expect: The Conversation
|
||||
|
||||
**Here's how a real session with Idunn looks:**
|
||||
|
||||
### Idunn's Opening
|
||||
```
|
||||
Hi! I'm Idunn, your technical architect agent.
|
||||
|
||||
I see you've completed your Product Brief and Trigger Map.
|
||||
Let's translate your product vision into technical architecture.
|
||||
|
||||
I'll ask questions about your product in design language.
|
||||
You answer naturally - no need for technical terms.
|
||||
|
||||
Ready? Let's start with the basics.
|
||||
```
|
||||
|
||||
### Example Questions Idunn Asks
|
||||
|
||||
**About Your Product:**
|
||||
```
|
||||
Idunn: "What's the core thing users create or manage in your product?"
|
||||
|
||||
You: "Users create weekly schedules for family dog care - walks,
|
||||
feeding, vet appointments, etc."
|
||||
|
||||
Idunn: "Got it. Do these schedules need to be:
|
||||
- Private (only one family)?
|
||||
- Shared (multiple families can see each other's)?
|
||||
- Collaborative (family members edit together)?"
|
||||
|
||||
You: "Collaborative - all family members edit the same schedule."
|
||||
|
||||
Idunn: "Perfect. That tells me we need real-time sync and user permissions."
|
||||
```
|
||||
|
||||
**About Users & Authentication:**
|
||||
```
|
||||
Idunn: "How do you envision users signing up?"
|
||||
|
||||
You: "Email and password should work. Google login would be nice too."
|
||||
|
||||
Idunn: "Great! Should users be able to:
|
||||
- Invite family members?
|
||||
- Have different roles (admin vs. regular member)?"
|
||||
|
||||
You: "Yes! The person who creates the schedule is the admin.
|
||||
They can invite family and remove members if needed."
|
||||
|
||||
Idunn: "Understood. I'll design a role-based permission system."
|
||||
```
|
||||
|
||||
**About Data & Features:**
|
||||
```
|
||||
Idunn: "You mentioned tasks like 'walks' and 'feeding'.
|
||||
What information does each task need?"
|
||||
|
||||
You: "Task title, who's assigned, what time/date, and whether
|
||||
it's done or not."
|
||||
|
||||
Idunn: "Should tasks repeat? Like 'walk dog every morning'?"
|
||||
|
||||
You: "Oh yes! That would be super helpful."
|
||||
|
||||
Idunn: "I'll add recurring task patterns. Should we notify
|
||||
the assigned person before the task is due?"
|
||||
|
||||
You: "Definitely!"
|
||||
|
||||
Idunn: "I'll include a notification system in the architecture."
|
||||
```
|
||||
|
||||
### Built-in Guidance from Idunn
|
||||
|
||||
**When you're unsure:**
|
||||
```
|
||||
You: "I'm not sure if we need that..."
|
||||
|
||||
Idunn: "No problem! Let me explain the trade-offs:
|
||||
|
||||
WITH real-time sync:
|
||||
✅ Family sees changes instantly
|
||||
✅ No confusion about who's doing what
|
||||
❌ Slightly more complex to build
|
||||
❌ Requires internet connection
|
||||
|
||||
WITHOUT real-time sync:
|
||||
✅ Simpler to build
|
||||
✅ Can work offline
|
||||
❌ Family might have outdated info
|
||||
❌ Conflicts if two people edit at once
|
||||
|
||||
For family coordination, real-time is usually worth it.
|
||||
What feels right for your users?"
|
||||
```
|
||||
|
||||
**When technical terms come up:**
|
||||
```
|
||||
Idunn: "I'll use a REST API for communication between app and server."
|
||||
|
||||
You: "What's a REST API?"
|
||||
|
||||
Idunn: "Think of it as a waiter in a restaurant:
|
||||
- Your app (customer) asks for something
|
||||
- The API (waiter) takes the request to the server (kitchen)
|
||||
- The server prepares the response (food)
|
||||
- The API brings it back to your app
|
||||
|
||||
You don't need to know how it works - just that it's
|
||||
the standard way apps communicate with databases."
|
||||
```
|
||||
|
||||
**When prioritizing features:**
|
||||
```
|
||||
Idunn: "Based on your Product Brief, I see you want:
|
||||
- Task scheduling (core)
|
||||
- Notifications (important)
|
||||
- Calendar sync (nice-to-have)
|
||||
- Vet appointment reminders (nice-to-have)
|
||||
|
||||
For the Platform PRD, I'll design all of these.
|
||||
|
||||
But I'll flag which are 'MVP' (must-have) vs.
|
||||
'Phase 2' (add later) so developers know priorities.
|
||||
|
||||
Does that split make sense?"
|
||||
|
||||
You: "Yes, but actually calendar sync is really important."
|
||||
|
||||
Idunn: "Got it - moving calendar sync to MVP. I'll update the
|
||||
architecture to prioritize that integration."
|
||||
```
|
||||
|
||||
### What Idunn Creates While You Talk
|
||||
|
||||
As you answer, Idunn is:
|
||||
- ✍️ Documenting data models ("Task" entity with fields)
|
||||
- 🏗️ Sketching system architecture (app, API, database, notifications)
|
||||
- 🔐 Planning authentication flow (login, permissions, roles)
|
||||
- 🔗 Identifying integrations (Google Calendar, email notifications)
|
||||
- ⚠️ Flagging technical risks ("Real-time sync needs WebSocket support")
|
||||
|
||||
**You'll see progress updates:**
|
||||
```
|
||||
Idunn: "✅ Data model drafted - 3 main entities (User, Family, Task)
|
||||
✅ Authentication flow designed - Social login + email
|
||||
🔄 Working on notification system architecture..."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 2: Activate Idunn (2 min)
|
||||
|
||||
```
|
||||
@idunn
|
||||
|
||||
I'm ready to create the Platform PRD for [Your Product Name].
|
||||
|
||||
I have:
|
||||
- Product Brief (done)
|
||||
- Trigger Map (done)
|
||||
|
||||
Please help me define the technical architecture.
|
||||
```
|
||||
|
||||
**Idunn will respond** and start asking questions about your product's technical needs.
|
||||
|
||||
---
|
||||
|
||||
## Step 3: Answer Idunn's Questions (20-30 min)
|
||||
|
||||
Idunn will guide you through understanding your platform needs. She asks questions like:
|
||||
|
||||
### About Data
|
||||
- "What information do users create?"
|
||||
- "What needs to be saved vs. temporary?"
|
||||
- "Do users share data with each other?"
|
||||
|
||||
**Example answers (you don't need technical terms):**
|
||||
- "Users create weekly schedules for dog care tasks"
|
||||
- "Schedules need to be saved permanently and shared with family"
|
||||
- "Each task has: title, assigned person, date, completion status"
|
||||
|
||||
### About Authentication
|
||||
- "How do users log in?"
|
||||
- "Do you want social login (Google, Apple)?"
|
||||
- "Are there different user roles?"
|
||||
|
||||
**Example answers:**
|
||||
- "Email + password, plus Google login"
|
||||
- "Two roles: Admin (can assign tasks) and Family Member (can complete tasks)"
|
||||
|
||||
### About Integrations
|
||||
- "Do you need notifications?"
|
||||
- "Payment processing?"
|
||||
- "Calendar sync?"
|
||||
|
||||
**Example answers:**
|
||||
- "Yes! Send reminders before tasks are due"
|
||||
- "No payments needed"
|
||||
- "Would be nice to sync with phone calendar"
|
||||
|
||||
### About Performance & Scale
|
||||
- "How many users do you expect?"
|
||||
- "Any real-time features?"
|
||||
- "Mobile app or web?"
|
||||
|
||||
**Idunn translates this into:**
|
||||
- Database schemas
|
||||
- API specifications
|
||||
- System architecture diagrams
|
||||
- Technical requirements docs
|
||||
|
||||
---
|
||||
|
||||
## Step 4: Review & Refine (10 min)
|
||||
|
||||
Idunn will show you the Platform PRD. Don't panic if it looks technical - you don't need to understand every detail.
|
||||
|
||||
**What to check:**
|
||||
- ✅ Does it capture all the features you designed?
|
||||
- ✅ Are the user roles correct?
|
||||
- ✅ Did she understand your data needs?
|
||||
- ✅ Are integrations you wanted included?
|
||||
|
||||
**Ask questions like:**
|
||||
- "Can you explain this part in design terms?"
|
||||
- "How does this support [specific feature]?"
|
||||
- "What if we want to add [feature] later?"
|
||||
|
||||
**Idunn will clarify** and update the PRD until it's right.
|
||||
|
||||
---
|
||||
|
||||
## Step 5: Save Your Platform PRD (2 min)
|
||||
|
||||
Idunn will save the Platform PRD to your project:
|
||||
|
||||
```
|
||||
/docs/3-platform-prd/
|
||||
├── 01-platform-architecture.md
|
||||
├── 02-data-models.md
|
||||
├── 03-api-specifications.md
|
||||
└── 04-technical-constraints.md
|
||||
```
|
||||
|
||||
**You now have** everything developers need to understand the technical foundation.
|
||||
|
||||
---
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: Do I need to learn technical terms?**
|
||||
**A:** No. Speak in design/product language. Idunn translates.
|
||||
|
||||
**Q: What if I don't know the answer to her questions?**
|
||||
**A:** Say so! Idunn will explain the implications and suggest options.
|
||||
|
||||
**Q: Can developers change the architecture later?**
|
||||
**A:** Yes. This is a starting point. Developers may refine it.
|
||||
|
||||
**Q: Do I need to review APIs and database schemas?**
|
||||
**A:** Only if you want to. Focus on whether it supports your design.
|
||||
|
||||
---
|
||||
|
||||
## What You've Accomplished
|
||||
|
||||
🎉 **You just created a Platform PRD** - something that usually requires technical architects!
|
||||
|
||||
**You didn't need to:**
|
||||
- ❌ Learn database design
|
||||
- ❌ Understand API protocols
|
||||
- ❌ Draw system architecture diagrams
|
||||
- ❌ Write technical specifications
|
||||
|
||||
**You just:**
|
||||
- ✅ Described your product in design terms
|
||||
- ✅ Answered Idunn's questions
|
||||
- ✅ Reviewed to ensure it supports your design
|
||||
|
||||
**That's the WDS superpower:** You focus on design. The agents handle the technical translation.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
**Ready to design the UX?**
|
||||
→ [Module 08: Initialize Scenario](../module-08-initialize-scenario/tutorial-08.md)
|
||||
|
||||
**Want to skip Platform PRD for now?**
|
||||
You can come back to this after UX design if you prefer.
|
||||
|
||||
---
|
||||
|
||||
**Pro Tip:** Even if you're not building the platform yourself, having this PRD helps you communicate with developers and make informed design decisions. You'll know what's technically feasible without becoming a developer yourself.
|
||||
|
||||
|
|
@ -0,0 +1,515 @@
|
|||
# Tutorial 09: Design System
|
||||
|
||||
**Extract patterns from your pages - turn one-off designs into reusable superpowers**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
You've designed several pages. You notice you keep recreating the same buttons, cards, and form fields. There's a better way.
|
||||
|
||||
**Create a Design System** - extract reusable components once, use them everywhere.
|
||||
|
||||
**Your superpower:** Freyja helps you identify patterns, document components, and create a library that scales your design decisions across the entire product.
|
||||
|
||||
**Time:** 45-60 minutes
|
||||
**Prerequisites:** Module 08 completed (At least 2-3 pages designed)
|
||||
**What you'll create:** Component Library & Design Tokens
|
||||
|
||||
---
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
- What a Design System is (and why it saves you time)
|
||||
- How to identify reusable patterns in your designs
|
||||
- How Freyja extracts components automatically
|
||||
- How to document components for consistency
|
||||
|
||||
---
|
||||
|
||||
## What is a Design System?
|
||||
|
||||
**Design System** = Your design decisions, extracted and reusable.
|
||||
|
||||
Instead of:
|
||||
- ❌ Designing every button from scratch
|
||||
- ❌ Remembering which blue you used last time
|
||||
- ❌ Recreating forms on every page
|
||||
|
||||
You have:
|
||||
- ✅ Button component (all states documented)
|
||||
- ✅ Color tokens (brand blue, semantic colors)
|
||||
- ✅ Form patterns (ready to reuse)
|
||||
|
||||
**Think of it as:**
|
||||
Design System = Your design vocabulary, organized and ready to use
|
||||
|
||||
---
|
||||
|
||||
## What to Expect: The Extraction Process
|
||||
|
||||
**Here's how a real session with Freyja looks:**
|
||||
|
||||
### Freyja's Opening
|
||||
```
|
||||
Hi! Ready to create your Design System?
|
||||
|
||||
I've analyzed your page specifications. I found some great patterns!
|
||||
|
||||
Let me show you what I discovered, and you tell me if I got it right.
|
||||
We'll name things together and document them properly.
|
||||
|
||||
This will be collaborative - you're the design expert, I'm the organizer.
|
||||
```
|
||||
|
||||
### Example Pattern Recognition
|
||||
|
||||
**Freyja Identifies Components:**
|
||||
```
|
||||
Freyja: "I scanned your 3 pages and found these button patterns:
|
||||
|
||||
Pattern 1 (used 12 times):
|
||||
- Blue background (#1e3a5f)
|
||||
- White text, 18px, semibold
|
||||
- Rounded corners (8px)
|
||||
- Used for: Submit, Save, Confirm actions
|
||||
|
||||
Pattern 2 (used 8 times):
|
||||
- Transparent background
|
||||
- Blue border (#1e3a5f)
|
||||
- Blue text
|
||||
- Used for: Cancel, Back, Secondary actions
|
||||
|
||||
Pattern 3 (used 24 times):
|
||||
- No background, no border
|
||||
- Blue text with underline on hover
|
||||
- Used for: Navigation links, "Learn more"
|
||||
|
||||
Should we call these:
|
||||
- Button Primary
|
||||
- Button Secondary
|
||||
- Text Link
|
||||
|
||||
Sound good?"
|
||||
|
||||
You: "Yes! But let's call Pattern 3 'Link Button' instead."
|
||||
|
||||
Freyja: "Perfect. Updated! 🎯"
|
||||
```
|
||||
|
||||
**Freyja Finds Inconsistencies:**
|
||||
```
|
||||
Freyja: "Heads up! I found a slight inconsistency:
|
||||
|
||||
On Page 1, your primary button uses #1e3a5f (deep blue)
|
||||
On Page 3, it uses #1e4a7f (slightly different blue)
|
||||
|
||||
Which one should be the standard?"
|
||||
|
||||
You: "Oh! Page 1 is correct - #1e3a5f."
|
||||
|
||||
Freyja: "Got it. I'll document #1e3a5f as the brand primary color.
|
||||
Should I flag Page 3 for update in the spec?"
|
||||
|
||||
You: "Yes please!"
|
||||
|
||||
Freyja: "Done. Added to quality check list. ✅"
|
||||
```
|
||||
|
||||
### Example Questions Freyja Asks
|
||||
|
||||
**About Naming:**
|
||||
```
|
||||
Freyja: "I found 3 different card layouts. Help me name them:
|
||||
|
||||
Card Type A: Image on top, title, description, CTA button
|
||||
Card Type B: Small image left, title and text right
|
||||
Card Type C: Icon in circle, title, 3-line description
|
||||
|
||||
What should we call these?"
|
||||
|
||||
You: "Type A is a 'Feature Card'
|
||||
Type B is a 'Task Card'
|
||||
Type C is a 'Capability Card'"
|
||||
|
||||
Freyja: "Love it. Those names make sense! Documented. 📝"
|
||||
```
|
||||
|
||||
**About Design Tokens:**
|
||||
```
|
||||
Freyja: "I extracted these colors from your pages:
|
||||
|
||||
Blues: #1e3a5f, #2c4f7c, #3d6399
|
||||
Are these:
|
||||
- Different brand colors? OR
|
||||
- The same color in different states (default, hover, active)?
|
||||
|
||||
You: "#1e3a5f is the main brand blue
|
||||
#2c4f7c is hover state
|
||||
#3d6399 is... hmm, I'm not sure where that came from"
|
||||
|
||||
Freyja: "Found it - Page 2, Benefits section background.
|
||||
Should that be a separate color called 'Background Blue'?
|
||||
Or should it use the main brand blue?"
|
||||
|
||||
You: "Ah! It should be a lighter tint for backgrounds. Let's call it
|
||||
'Brand Blue Light' and make it consistent."
|
||||
|
||||
Freyja: "Perfect! I'll document:
|
||||
- Brand Blue (#1e3a5f) - primary
|
||||
- Brand Blue Hover (#2c4f7c) - interaction
|
||||
- Brand Blue Light (#3d6399) - backgrounds
|
||||
|
||||
Should I update Page 2 spec?"
|
||||
|
||||
You: "Yes!"
|
||||
```
|
||||
|
||||
### Built-in Guidance from Freyja
|
||||
|
||||
**When you're building your first Design System:**
|
||||
```
|
||||
Freyja: "This is your first Design System, right?
|
||||
|
||||
Pro tip: Don't try to document everything perfectly.
|
||||
Start with the basics:
|
||||
✅ Buttons (you use them everywhere)
|
||||
✅ Colors (brand consistency matters)
|
||||
✅ Typography (H1, H2, body text)
|
||||
✅ Spacing (consistent gaps)
|
||||
|
||||
We can add more as you design more pages.
|
||||
Sound good?"
|
||||
|
||||
You: "Yes! That feels manageable."
|
||||
|
||||
Freyja: "Great! Let's start there. We'll keep it simple and practical."
|
||||
```
|
||||
|
||||
**When components are almost the same:**
|
||||
```
|
||||
Freyja: "I found two button patterns that are 95% identical:
|
||||
|
||||
Both have:
|
||||
- Blue background
|
||||
- White text
|
||||
- 8px border radius
|
||||
|
||||
Only difference:
|
||||
- One is 44px tall (regular)
|
||||
- One is 56px tall (large)
|
||||
|
||||
Should we make these:
|
||||
- Two separate components? OR
|
||||
- One component with size variants?"
|
||||
|
||||
You: "One component with variants - 'Button Primary (Regular)'
|
||||
and 'Button Primary (Large)'"
|
||||
|
||||
Freyja: "Smart! That keeps your system clean. One component,
|
||||
two sizes. Documented! 🎯"
|
||||
```
|
||||
|
||||
**About Usage Guidelines:**
|
||||
```
|
||||
Freyja: "For Button Primary, I'm adding usage guidelines:
|
||||
|
||||
✅ Use for primary actions (submit, save, next)
|
||||
✅ Only one per page section
|
||||
❌ Don't use for destructive actions (delete, remove)
|
||||
|
||||
Does that match your intent?"
|
||||
|
||||
You: "Yes! And add: Button text should be action verbs."
|
||||
|
||||
Freyja: "Added! These guidelines will help keep your design consistent."
|
||||
```
|
||||
|
||||
### What Freyja Creates While You Talk
|
||||
|
||||
As you review patterns, Freyja is:
|
||||
- 📋 Cataloging components (buttons, forms, cards)
|
||||
- 🎨 Extracting design tokens (colors, spacing, typography)
|
||||
- 📏 Documenting variants (sizes, states, types)
|
||||
- ✍️ Writing usage guidelines (when to use, when not to)
|
||||
- 🔗 Linking to page specs (where each component is used)
|
||||
|
||||
**You'll see progress updates:**
|
||||
```
|
||||
Freyja: "✅ 5 button components documented
|
||||
✅ 8 color tokens extracted
|
||||
✅ 3 card patterns identified
|
||||
🔄 Working on form components..."
|
||||
```
|
||||
|
||||
### The Collaborative Flow
|
||||
|
||||
**It's a conversation, not a form:**
|
||||
```
|
||||
You: "Actually, I think the 'Task Card' should have a checkbox option."
|
||||
|
||||
Freyja: "Great catch! Should the checkbox be:
|
||||
- Always visible? OR
|
||||
- Only on hover? OR
|
||||
- A separate variant?"
|
||||
|
||||
You: "Separate variant - 'Task Card (Selectable)'"
|
||||
|
||||
Freyja: "Perfect. I'll document both variants:
|
||||
- Task Card (Standard)
|
||||
- Task Card (Selectable)
|
||||
|
||||
Updated the component library! ✅"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Understand the Power (5 min)
|
||||
|
||||
**Without Design System:**
|
||||
```
|
||||
Page 1: Create "Submit" button
|
||||
Page 2: Create "Submit" button (slightly different)
|
||||
Page 3: Create "Submit" button (now it's inconsistent)
|
||||
Update brand color → Update 47 buttons manually 😱
|
||||
```
|
||||
|
||||
**With Design System:**
|
||||
```
|
||||
Design System: Define Button Primary
|
||||
Page 1: Use Button Primary
|
||||
Page 2: Use Button Primary
|
||||
Page 3: Use Button Primary
|
||||
Update brand color → Update 1 component, changes everywhere 🎉
|
||||
```
|
||||
|
||||
**You save time. Users get consistency.**
|
||||
|
||||
---
|
||||
|
||||
## Step 2: Activate Freyja for Extraction (2 min)
|
||||
|
||||
```
|
||||
@freyja
|
||||
|
||||
I'm ready to create a Design System from my page specifications.
|
||||
|
||||
I have these pages designed:
|
||||
- [Page 1 name]
|
||||
- [Page 2 name]
|
||||
- [Page 3 name]
|
||||
|
||||
Please help me extract reusable components.
|
||||
```
|
||||
|
||||
**Freyja will analyze** your pages and identify patterns.
|
||||
|
||||
---
|
||||
|
||||
## Step 3: Review What Freyja Found (15 min)
|
||||
|
||||
Freyja scans your pages and identifies:
|
||||
|
||||
### Components She'll Extract
|
||||
- **Buttons:** Primary, Secondary, Text links
|
||||
- **Forms:** Input fields, Dropdowns, Checkboxes
|
||||
- **Cards:** Content cards, Profile cards
|
||||
- **Navigation:** Headers, Footers, Menus
|
||||
- **Feedback:** Success messages, Error states, Loading indicators
|
||||
|
||||
**She'll say something like:**
|
||||
```
|
||||
I found these patterns:
|
||||
|
||||
Buttons (3 variants):
|
||||
- Primary Button (used 12 times across 3 pages)
|
||||
- Secondary Button (used 8 times)
|
||||
- Text Link (used 24 times)
|
||||
|
||||
Cards (2 types):
|
||||
- Task Card (used 15 times)
|
||||
- Profile Card (used 3 times)
|
||||
|
||||
Do these look right? Any I missed?
|
||||
```
|
||||
|
||||
**Your job:**
|
||||
- ✅ Confirm patterns she found
|
||||
- ✅ Point out any she missed
|
||||
- ✅ Name variants clearly ("Primary Button" not "Blue Button")
|
||||
|
||||
---
|
||||
|
||||
## Step 4: Define Design Tokens (10 min)
|
||||
|
||||
**Design Tokens** = The atomic values your components use.
|
||||
|
||||
Freyja will extract:
|
||||
|
||||
### Colors
|
||||
```
|
||||
Brand Colors:
|
||||
- Primary: #1e3a5f (deep blue)
|
||||
- Accent: #ff6b35 (coral)
|
||||
|
||||
Semantic Colors:
|
||||
- Success: #22c55e
|
||||
- Error: #ef4444
|
||||
- Warning: #f59e0b
|
||||
```
|
||||
|
||||
### Typography
|
||||
```
|
||||
Heading 1: 48px, Bold, 1.2 line height
|
||||
Heading 2: 32px, Semibold, 1.3 line height
|
||||
Body: 16px, Regular, 1.6 line height
|
||||
```
|
||||
|
||||
### Spacing
|
||||
```
|
||||
xs: 4px
|
||||
sm: 8px
|
||||
md: 16px
|
||||
lg: 24px
|
||||
xl: 32px
|
||||
```
|
||||
|
||||
**Your job:**
|
||||
- ✅ Confirm these match your intent
|
||||
- ✅ Name them meaningfully ("Primary" not "Blue")
|
||||
- ✅ Add any she missed
|
||||
|
||||
---
|
||||
|
||||
## Step 5: Document Components (15 min)
|
||||
|
||||
For each component, Freyja creates documentation:
|
||||
|
||||
### Example: Primary Button
|
||||
|
||||
**Component Name:** Button Primary
|
||||
**Object ID Pattern:** `{page}-{section}-{element}`
|
||||
|
||||
**States:**
|
||||
- **Default:** Blue background, white text
|
||||
- **Hover:** Darker blue, scale 1.05
|
||||
- **Active:** Even darker, scale 0.98
|
||||
- **Disabled:** Gray background, gray text
|
||||
- **Loading:** Blue background, spinner icon
|
||||
|
||||
**Content Structure:**
|
||||
```
|
||||
- Label (EN): [Button text]
|
||||
- Icon (optional): [Icon name]
|
||||
```
|
||||
|
||||
**Usage Guidelines:**
|
||||
- Use for primary actions (submit, save, confirm)
|
||||
- Only ONE primary button per page/section
|
||||
- Button text = action verb ("Save", "Submit", "Confirm")
|
||||
|
||||
**Accessibility:**
|
||||
- Min touch target: 44x44px
|
||||
- Keyboard accessible (Enter/Space)
|
||||
- Focus indicator visible
|
||||
|
||||
**Freyja documents** all this. You just review and confirm.
|
||||
|
||||
---
|
||||
|
||||
## Step 6: Create the Component Library (5 min)
|
||||
|
||||
Freyja saves your Design System:
|
||||
|
||||
```
|
||||
/docs/5-design-system/
|
||||
├── 00-design-tokens.md
|
||||
├── components/
|
||||
│ ├── buttons.md
|
||||
│ ├── forms.md
|
||||
│ ├── cards.md
|
||||
│ └── navigation.md
|
||||
├── patterns/
|
||||
│ ├── form-patterns.md
|
||||
│ └── layout-patterns.md
|
||||
└── guidelines/
|
||||
├── accessibility.md
|
||||
└── usage-rules.md
|
||||
```
|
||||
|
||||
**Now you can:**
|
||||
- Reference components in new page specs
|
||||
- Ensure consistency across your product
|
||||
- Update once, apply everywhere
|
||||
|
||||
---
|
||||
|
||||
## Step 7: Use Your Design System (Ongoing)
|
||||
|
||||
**When designing new pages:**
|
||||
|
||||
Instead of:
|
||||
```markdown
|
||||
#### Submit Button
|
||||
- Style: Blue button, 18px, semibold...
|
||||
```
|
||||
|
||||
You write:
|
||||
```markdown
|
||||
#### Submit Button
|
||||
**Component:** Button Primary
|
||||
**Content:** "Save Changes"
|
||||
```
|
||||
|
||||
**Freyja knows** what "Button Primary" means. Developers know too. Consistency guaranteed.
|
||||
|
||||
---
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: When should I create a Design System?**
|
||||
**A:** After 2-3 pages are designed. Patterns become clear.
|
||||
|
||||
**Q: Can I update components later?**
|
||||
**A:** Yes! Update the Design System doc, then update specs that use it.
|
||||
|
||||
**Q: What if a page needs a unique button?**
|
||||
**A:** Document why it's unique. If you use it again, add it to the system.
|
||||
|
||||
**Q: Do I need Figma components?**
|
||||
**A:** Not required. WDS Design System is specification-focused. You can sync to Figma later if you want.
|
||||
|
||||
---
|
||||
|
||||
## What You've Accomplished
|
||||
|
||||
🎉 **You just created a Design System!**
|
||||
|
||||
**You didn't need to:**
|
||||
- ❌ Manually catalog every component
|
||||
- ❌ Create a Figma component library first
|
||||
- ❌ Understand design tokens theory
|
||||
- ❌ Build a Storybook
|
||||
|
||||
**You just:**
|
||||
- ✅ Designed a few pages naturally
|
||||
- ✅ Let Freyja identify patterns
|
||||
- ✅ Reviewed and confirmed
|
||||
- ✅ Named things clearly
|
||||
|
||||
**That's the WDS superpower:** Design naturally. Extract patterns automatically. Scale effortlessly.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
**Ready to hand off to developers?**
|
||||
→ [Module 10: Design Delivery](../module-10-design-delivery/tutorial-10.md)
|
||||
|
||||
**Want to design more pages first?**
|
||||
Go back to [Module 08: Initialize Scenario](../module-08-initialize-scenario/tutorial-08.md) and your Design System will grow with you.
|
||||
|
||||
---
|
||||
|
||||
**Pro Tip:** Your Design System doesn't need to be "complete" before you hand off. Start small (buttons, forms, colors). Add more as you design more pages. It's a living system that grows with your product.
|
||||
|
||||
|
|
@ -0,0 +1,604 @@
|
|||
# Tutorial 10: Design Delivery
|
||||
|
||||
**Package your design for developers - hand off with confidence, not confusion**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Your design is done. Specifications are complete. Design System is ready. Now what?
|
||||
|
||||
You need to **hand off to developers** - but how do you ensure they build what you designed?
|
||||
|
||||
**Your superpower:** Idunn transforms your design specs into a Developer PRD with epics, stories, and clear implementation guidance.
|
||||
|
||||
**Time:** 30-45 minutes
|
||||
**Prerequisites:** Module 08 & 09 completed (Pages designed, Design System ready)
|
||||
**What you'll create:** Design Delivery PRD with Epics & Stories
|
||||
|
||||
---
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
- What a Design Delivery PRD is (and why developers love it)
|
||||
- How Idunn organizes your specs into buildable chunks
|
||||
- How to prioritize what gets built first
|
||||
- What to include in the handoff package
|
||||
|
||||
---
|
||||
|
||||
## What is Design Delivery PRD?
|
||||
|
||||
**Design Delivery PRD** = Your design specs, organized for development.
|
||||
|
||||
It transforms:
|
||||
- **Your page specs** (what the design IS)
|
||||
- **Into developer tasks** (what to BUILD)
|
||||
|
||||
**Think of it as:**
|
||||
Your recipe (specs) → Shopping list + cooking steps (PRD)
|
||||
|
||||
---
|
||||
|
||||
## What to Expect: The Organization Process
|
||||
|
||||
**Here's how a real session with Idunn looks:**
|
||||
|
||||
### Idunn's Opening
|
||||
```
|
||||
Hi! Time to organize your design for developer handoff.
|
||||
|
||||
I've reviewed your:
|
||||
- Page specifications (3 pages)
|
||||
- Design System (ready)
|
||||
|
||||
I'll break this into epics and stories developers can actually build.
|
||||
|
||||
We'll work together to:
|
||||
1. Group related work into epics
|
||||
2. Create specific stories with acceptance criteria
|
||||
3. Prioritize what gets built first
|
||||
4. Package everything for handoff
|
||||
|
||||
Ready? Let's start by looking at the big picture.
|
||||
```
|
||||
|
||||
### Example Epic Breakdown
|
||||
|
||||
**Idunn Proposes Structure:**
|
||||
```
|
||||
Idunn: "I analyzed your 3 pages. Here's how I'd organize them:
|
||||
|
||||
EPIC 1: Landing Page Experience
|
||||
- Pages: 1.1 Start Page
|
||||
- Goal: Users understand WDS and can access it
|
||||
- Stories: 7 (Hero, Capabilities, Navigation, Footer...)
|
||||
- Priority: HIGH (this is your front door)
|
||||
|
||||
EPIC 2: Course Content Pages
|
||||
- Pages: 2.1 Modules List, 2.2 Tutorial Page
|
||||
- Goal: Users can learn WDS through tutorials
|
||||
- Stories: 12 (Module cards, Tutorial content, Progress tracking...)
|
||||
- Priority: MEDIUM (users need this after they sign up)
|
||||
|
||||
EPIC 3: Design System Components
|
||||
- Goal: Build reusable components library
|
||||
- Stories: 5 (Button system, Form components, Card library...)
|
||||
- Priority: HIGH (needed for all other epics)
|
||||
|
||||
Does this grouping make sense?
|
||||
Any epics missing?"
|
||||
|
||||
You: "Actually, Epic 3 should be built FIRST - other epics need it."
|
||||
|
||||
Idunn: "Smart! Let me reorder:
|
||||
|
||||
Phase 1: Epic 3 (Component Library)
|
||||
Phase 2: Epic 1 (Landing Page)
|
||||
Phase 3: Epic 2 (Course Content)
|
||||
|
||||
Better?"
|
||||
|
||||
You: "Perfect!"
|
||||
```
|
||||
|
||||
### Example Questions Idunn Asks
|
||||
|
||||
**About Priorities:**
|
||||
```
|
||||
Idunn: "Looking at Epic 1 (Landing Page), which story is most critical?
|
||||
|
||||
Story 1.1: Hero Section (first impression)
|
||||
Story 1.2: Capabilities Section (shows value)
|
||||
Story 1.3: Benefits Grid (builds trust)
|
||||
Story 1.4: Footer (contact info, links)
|
||||
|
||||
If we had to ship with ONLY ONE done, which one?"
|
||||
|
||||
You: "Story 1.1 - Hero Section. Users need to understand what WDS is."
|
||||
|
||||
Idunn: "Got it. I'll mark Story 1.1 as P0 (must-have).
|
||||
Others can be P1 (important but can wait).
|
||||
|
||||
Should developers build them in this order?"
|
||||
|
||||
You: "Yes, exactly."
|
||||
|
||||
Idunn: "Story sequence documented! 📋"
|
||||
```
|
||||
|
||||
**About Dependencies:**
|
||||
```
|
||||
Idunn: "I notice Story 2.3 (Tutorial Progress Tracking) needs:
|
||||
- User authentication (from Epic 0?)
|
||||
- Database to store progress
|
||||
|
||||
Should I create Epic 0: Foundation that includes auth?"
|
||||
|
||||
You: "Yes! Good catch."
|
||||
|
||||
Idunn: "Creating Epic 0: Platform Foundation
|
||||
- Story 0.1: User authentication system
|
||||
- Story 0.2: Database setup
|
||||
- Story 0.3: API infrastructure
|
||||
|
||||
This becomes Phase 1, and everything else depends on it.
|
||||
Sound right?"
|
||||
|
||||
You: "Absolutely."
|
||||
```
|
||||
|
||||
**About Story Details:**
|
||||
```
|
||||
Idunn: "For Story 1.2 (Capabilities Section with 7 cards),
|
||||
should this be:
|
||||
|
||||
Option A: ONE story (build all 7 cards at once)
|
||||
Option B: SEVEN stories (one per card)
|
||||
Option C: TWO stories (build card component, then populate all 7)
|
||||
|
||||
What makes sense?"
|
||||
|
||||
You: "Option C - developers create the card component first,
|
||||
then it's easy to replicate for all 7."
|
||||
|
||||
Idunn: "Perfect! Breaking it down:
|
||||
- Story 1.2a: Build Capability Card component
|
||||
- Story 1.2b: Populate 7 capability instances
|
||||
|
||||
Estimated: 2 days (component) + 1 day (content)
|
||||
Good?"
|
||||
|
||||
You: "Yes!"
|
||||
```
|
||||
|
||||
### Built-in Guidance from Idunn
|
||||
|
||||
**When stories are too big:**
|
||||
```
|
||||
Idunn: "Story 2.1 is getting large. It includes:
|
||||
- Module card grid
|
||||
- Filtering by category
|
||||
- Search functionality
|
||||
- Sort by difficulty
|
||||
|
||||
This could take 2-3 weeks. Should we split it?
|
||||
|
||||
Suggested split:
|
||||
- Story 2.1a: Module grid (basic display)
|
||||
- Story 2.1b: Add filtering
|
||||
- Story 2.1c: Add search
|
||||
- Story 2.1d: Add sorting
|
||||
|
||||
Then developers can ship 2.1a quickly, and add features
|
||||
in 2.1b-d later. Sound good?"
|
||||
|
||||
You: "Yes! I like that incremental approach."
|
||||
|
||||
Idunn: "Great! Smaller stories = faster feedback = better quality."
|
||||
```
|
||||
|
||||
**About Acceptance Criteria:**
|
||||
```
|
||||
Idunn: "For Story 1.1 (Hero Section), I'm writing acceptance criteria:
|
||||
|
||||
✅ H1 headline displays correctly
|
||||
✅ Tagline text matches spec
|
||||
✅ CTA button links to GitHub
|
||||
✅ Section is responsive (mobile/desktop)
|
||||
✅ All Object IDs match page spec
|
||||
|
||||
Am I missing anything?"
|
||||
|
||||
You: "Yes - the CTA should have a hover animation (scale 1.05)"
|
||||
|
||||
Idunn: "Added! ✅ CTA has hover state (scale 1.05, smooth transition)
|
||||
|
||||
These criteria help developers know when they're 'done'."
|
||||
```
|
||||
|
||||
**About Testing Expectations:**
|
||||
```
|
||||
Idunn: "Should I include testing requirements in each story?
|
||||
|
||||
For example:
|
||||
✅ Works in Chrome, Firefox, Safari
|
||||
✅ Responsive on mobile (375px+)
|
||||
✅ Keyboard accessible (tab navigation)
|
||||
✅ Screen reader compatible"
|
||||
|
||||
You: "Yes! Accessibility is important."
|
||||
|
||||
Idunn: "Adding accessibility criteria to all stories.
|
||||
I'll also create a separate 'Definition of Done' document
|
||||
so developers know the quality bar. ✅"
|
||||
```
|
||||
|
||||
### What Idunn Creates While You Talk
|
||||
|
||||
As you discuss priorities and structure, Idunn is:
|
||||
- 📊 Creating epic breakdown (major features)
|
||||
- ✍️ Writing user stories (As a [persona], I want...)
|
||||
- ✅ Defining acceptance criteria (testable conditions)
|
||||
- 🔗 Linking to page specs (where to find details)
|
||||
- 📅 Suggesting implementation phases (what builds when)
|
||||
- 📋 Assembling handoff package (everything developers need)
|
||||
|
||||
**You'll see progress updates:**
|
||||
```
|
||||
Idunn: "✅ 3 epics structured
|
||||
✅ 24 stories written
|
||||
✅ Dependencies mapped
|
||||
🔄 Creating handoff documentation..."
|
||||
```
|
||||
|
||||
### The Collaborative Flow
|
||||
|
||||
**It's iterative, not final:**
|
||||
```
|
||||
You: "Actually, looking at this, Story 2.2 could be combined with 2.3.
|
||||
They're both about tutorial pages."
|
||||
|
||||
Idunn: "Good point! Let me merge them:
|
||||
|
||||
OLD:
|
||||
- Story 2.2: Tutorial content display
|
||||
- Story 2.3: Tutorial navigation
|
||||
|
||||
NEW:
|
||||
- Story 2.2: Complete tutorial page experience
|
||||
|
||||
This makes more sense as one unit of work. Updated! 🎯"
|
||||
```
|
||||
|
||||
**Idunn catches gaps:**
|
||||
```
|
||||
Idunn: "Wait - I don't see any stories for error states.
|
||||
|
||||
What should happen if:
|
||||
- GitHub API is down (CTA link fails)?
|
||||
- Images don't load?
|
||||
- Page content is missing?
|
||||
|
||||
Should I add error handling stories?"
|
||||
|
||||
You: "Yes! Good catch. Add graceful error states."
|
||||
|
||||
Idunn: "Adding Epic 4: Error Handling & Edge Cases
|
||||
- Story 4.1: Network error states
|
||||
- Story 4.2: Missing content fallbacks
|
||||
- Story 4.3: Loading states
|
||||
|
||||
This ensures a polished experience. ✅"
|
||||
```
|
||||
|
||||
### The Handoff Package
|
||||
|
||||
**Idunn Shows You the Final Structure:**
|
||||
```
|
||||
Idunn: "Here's what developers will receive:
|
||||
|
||||
📁 Design Delivery PRD/
|
||||
├── 00-handoff-overview.md (start here!)
|
||||
├── 01-epic-breakdown.md (big picture)
|
||||
├── 02-implementation-roadmap.md (build order)
|
||||
├── 03-definition-of-done.md (quality criteria)
|
||||
└── stories/
|
||||
├── epic-0-foundation/
|
||||
│ ├── story-0.1-authentication.md
|
||||
│ └── story-0.2-database.md
|
||||
├── epic-1-landing-page/
|
||||
│ ├── story-1.1-hero-section.md
|
||||
│ └── story-1.2-capabilities.md
|
||||
└── ...
|
||||
|
||||
Each story links to:
|
||||
- Your page specifications
|
||||
- Design System components
|
||||
- Acceptance criteria
|
||||
- Technical notes
|
||||
|
||||
Developers have everything they need. Ready to hand off?"
|
||||
|
||||
You: "Yes! This is so organized."
|
||||
|
||||
Idunn: "Great! I'll export everything.
|
||||
|
||||
Want me to draft an email to your dev team too? 📧"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Understand the Translation (5 min)
|
||||
|
||||
**What you have:**
|
||||
```
|
||||
Page Specifications:
|
||||
- 1.1 Start Page (Hero, Features, CTA)
|
||||
- 1.2 Benefits Page (3 sections)
|
||||
- 1.3 Pricing Page (Pricing table, FAQ)
|
||||
```
|
||||
|
||||
**What developers need:**
|
||||
```
|
||||
Epic 1: Landing Page
|
||||
├── Story 1: Build Hero Section
|
||||
├── Story 2: Build Features Section
|
||||
└── Story 3: Build CTA Section
|
||||
|
||||
Epic 2: Benefits Page
|
||||
├── Story 4: Build Benefits Grid
|
||||
└── Story 5: Add Testimonials
|
||||
|
||||
Epic 3: Pricing Page
|
||||
...
|
||||
```
|
||||
|
||||
**Idunn creates this structure** from your specs.
|
||||
|
||||
---
|
||||
|
||||
## Step 2: Activate Idunn for Handoff (2 min)
|
||||
|
||||
```
|
||||
@idunn
|
||||
|
||||
I'm ready to create the Design Delivery PRD.
|
||||
|
||||
I have:
|
||||
- Page specifications (complete)
|
||||
- Design System (ready)
|
||||
|
||||
Please help me organize this for developer handoff.
|
||||
```
|
||||
|
||||
**Idunn will analyze** your specs and propose an implementation structure.
|
||||
|
||||
---
|
||||
|
||||
## Step 3: Review Idunn's Epic Breakdown (10 min)
|
||||
|
||||
Idunn creates **Epics** (major features) and **Stories** (specific tasks).
|
||||
|
||||
**Example:**
|
||||
|
||||
### Epic 1: Core Landing Experience
|
||||
```
|
||||
Goal: Users can understand WDS value and sign up
|
||||
Pages: Start Page + Benefits Page
|
||||
Priority: HIGH
|
||||
Estimated: 2-3 weeks
|
||||
```
|
||||
|
||||
**Stories in this Epic:**
|
||||
1. ✅ **Story 1.1:** Build Hero Section
|
||||
- Page: 1.1 Start Page
|
||||
- Components: Hero Headline, Hero Body, CTA Button, Hero Image
|
||||
- Acceptance: Matches spec exactly, responsive, CTA links to GitHub
|
||||
|
||||
2. ✅ **Story 1.2:** Build Capabilities Section (Right Column)
|
||||
- Page: 1.1 Start Page
|
||||
- Components: 7 Capability Cards with icons, links
|
||||
- Acceptance: Cards link to deliverable pages, hover states work
|
||||
|
||||
3. ✅ **Story 1.3:** Build Benefits Grid
|
||||
- Page: 1.2 Benefits Page
|
||||
- Components: 3 Benefit Cards
|
||||
- Acceptance: Responsive grid, icons display correctly
|
||||
|
||||
**Your job:**
|
||||
- ✅ Confirm epics make sense
|
||||
- ✅ Adjust priorities if needed
|
||||
- ✅ Suggest different groupings if you see dependencies
|
||||
|
||||
---
|
||||
|
||||
## Step 4: Prioritize Implementation Order (10 min)
|
||||
|
||||
**Idunn will ask:**
|
||||
|
||||
"Which epics should developers build first?"
|
||||
|
||||
**Think about:**
|
||||
- What's the **MVP** (Minimum Viable Product)?
|
||||
- What do users need **most urgently**?
|
||||
- Are there **dependencies** (Epic 2 needs Epic 1 first)?
|
||||
|
||||
**Example prioritization:**
|
||||
```
|
||||
Phase 1 (MVP - Week 1-2):
|
||||
- Epic 1: Core Landing Experience
|
||||
(Users can learn about WDS and access it)
|
||||
|
||||
Phase 2 (Enhancement - Week 3-4):
|
||||
- Epic 2: Course Content
|
||||
(Users can follow tutorials)
|
||||
|
||||
Phase 3 (Nice-to-have - Week 5+):
|
||||
- Epic 3: Community Features
|
||||
(Users can connect with each other)
|
||||
```
|
||||
|
||||
**Idunn documents this** so developers know what to build when.
|
||||
|
||||
---
|
||||
|
||||
## Step 5: Review Story Details (10 min)
|
||||
|
||||
For each story, Idunn includes:
|
||||
|
||||
### Story Format
|
||||
```
|
||||
Story 1.1: Build Hero Section
|
||||
|
||||
As a designer visiting the WDS page,
|
||||
I want to see a clear hero section,
|
||||
So that I understand what WDS is in 5 seconds.
|
||||
|
||||
Acceptance Criteria:
|
||||
✅ H1 headline displays: "Whiteport Design Studio, WDS"
|
||||
✅ Tagline displays with correct formatting
|
||||
✅ CTA button links to GitHub repo
|
||||
✅ Hero image displays on right side (desktop)
|
||||
✅ Section is responsive (stacks on mobile)
|
||||
✅ Matches page specification: docs/4-scenarios/1.1-wds-presentation.md
|
||||
|
||||
Components Used:
|
||||
- wds-hero-headline (H1 Heading)
|
||||
- wds-hero-tagline (H2 Heading)
|
||||
- wds-hero-body (Body Paragraph)
|
||||
- wds-hero-cta (Button Primary)
|
||||
- wds-hero-illustration (Hero Image)
|
||||
|
||||
Design System References:
|
||||
- Button Primary (see: docs/5-design-system/components/buttons.md)
|
||||
- Heading styles (see: docs/5-design-system/00-design-tokens.md)
|
||||
|
||||
Technical Notes:
|
||||
- Ensure Object IDs match spec (for future updates)
|
||||
- Image should be lazy-loaded for performance
|
||||
- CTA should have proper focus state for accessibility
|
||||
```
|
||||
|
||||
**Your job:**
|
||||
- ✅ Confirm acceptance criteria are clear
|
||||
- ✅ Ensure all components are referenced
|
||||
- ✅ Add any missing requirements
|
||||
|
||||
---
|
||||
|
||||
## Step 6: Create the Handoff Package (5 min)
|
||||
|
||||
Idunn assembles everything into a handoff package:
|
||||
|
||||
```
|
||||
/docs/6-design-delivery/
|
||||
├── 00-handoff-overview.md
|
||||
├── 01-epic-breakdown.md
|
||||
├── 02-implementation-roadmap.md
|
||||
├── stories/
|
||||
│ ├── story-1.1-hero-section.md
|
||||
│ ├── story-1.2-capabilities-section.md
|
||||
│ └── ...
|
||||
└── developer-guide.md
|
||||
```
|
||||
|
||||
**Handoff Overview includes:**
|
||||
- Links to all page specifications
|
||||
- Links to Design System
|
||||
- How to read Object IDs
|
||||
- How to interpret content with language tags
|
||||
- Testing expectations
|
||||
|
||||
---
|
||||
|
||||
## Step 7: Hand Off to Developers (5 min)
|
||||
|
||||
**Share with your dev team:**
|
||||
|
||||
1. **The handoff package** (folder above)
|
||||
2. **Access to full specs** (all `/docs/` folders)
|
||||
3. **A kickoff meeting** (30 min to walk through)
|
||||
|
||||
**In the meeting, explain:**
|
||||
- "Here's the Design Delivery PRD - epics and stories"
|
||||
- "Each story links to page specifications"
|
||||
- "All components are in the Design System docs"
|
||||
- "Object IDs help you track what's what"
|
||||
- "Questions? Ask now or ping me anytime"
|
||||
|
||||
**Developers now have:**
|
||||
- ✅ Clear implementation roadmap
|
||||
- ✅ Detailed specifications for every element
|
||||
- ✅ Component library for consistency
|
||||
- ✅ Acceptance criteria for every story
|
||||
- ✅ Your design intent preserved
|
||||
|
||||
---
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: Do developers have to follow the stories exactly?**
|
||||
**A:** Stories are a starting point. Developers may adjust based on technical constraints. Stay in the loop!
|
||||
|
||||
**Q: What if developers have questions?**
|
||||
**A:** Encourage them to reference page specs and Design System first. Then ping you for clarification.
|
||||
|
||||
**Q: Should I attend standup meetings?**
|
||||
**A:** YES! Stay involved to catch misinterpretations early.
|
||||
|
||||
**Q: What if they want to change the design?**
|
||||
**A:** Discuss WHY (technical constraints? Better UX idea?). Update specs if agreed.
|
||||
|
||||
---
|
||||
|
||||
## What You've Accomplished
|
||||
|
||||
🎉 **You just handed off your design like a pro!**
|
||||
|
||||
**You didn't need to:**
|
||||
- ❌ Write user stories yourself
|
||||
- ❌ Estimate development time
|
||||
- ❌ Create Jira tickets manually
|
||||
- ❌ Translate design language to dev language
|
||||
|
||||
**You just:**
|
||||
- ✅ Confirmed Idunn's epic breakdown made sense
|
||||
- ✅ Prioritized implementation order
|
||||
- ✅ Reviewed stories for accuracy
|
||||
- ✅ Handed off with confidence
|
||||
|
||||
**That's the WDS superpower:** Design with intent. Hand off with clarity. Trust it gets built right.
|
||||
|
||||
---
|
||||
|
||||
## What Happens Next?
|
||||
|
||||
**Developers build.** Your specs guide them.
|
||||
|
||||
**Your role during development:**
|
||||
- Answer questions (specs might need clarification)
|
||||
- Review implementations (does it match the spec?)
|
||||
- Update specs if requirements change
|
||||
|
||||
**After launch:**
|
||||
BMM workflows take over for testing, iteration, and ongoing development.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
**Want to learn more?**
|
||||
- Review the [Design Delivery Workflow](../../workflows/6-design-deliveries/) for advanced topics
|
||||
- Explore BMM (BMAD Management Method) for ongoing development
|
||||
|
||||
**Start a new project?**
|
||||
- Go back to [Module 03: Alignment & Signoff](../module-03-alignment-signoff/tutorial-03.md)
|
||||
- Or jump to [Module 04: Project Brief](../module-04-project-brief/tutorial-04.md)
|
||||
|
||||
---
|
||||
|
||||
**Pro Tip:** Great handoffs aren't "throw it over the wall." Stay engaged during development. Answer questions. Review builds. Your design intent is worth protecting. WDS gives you the tools - you provide the oversight.
|
||||
|
||||
🎯 **Congratulations! You've completed the core WDS workflow!**
|
||||
|
||||
|
|
@ -0,0 +1,241 @@
|
|||
### 1.1 WDS Page
|
||||
|
||||
|
||||
|
||||
# 1.1 WDS Page
|
||||
|
||||
The WDS Presentation page serves as the primary entry point for designers discovering WDS for the first time. This page addresses the universal pain point of feeling threatened and overwhelmed by AI while promising the emotional transformation to empowered strategic leadership. The page must convert curious visitors into engaged learners by demonstrating immediate value and removing adoption barriers.
|
||||
|
||||
**User Situation**: Stina the Strategist, a designer feeling overwhelmed by AI disruption, job hunting, AI-curious but lacking confidence. She's skeptical but hopeful - doesn't want to waste time on another tool. Needs quick value assessment: "Is this worth my time?"
|
||||
|
||||
**Page Purpose**: Convert visitors into learners/users by addressing core emotional drivers from the trigger map - eliminating overwhelm while building confidence that designers can thrive (not just survive) in the AI era through structured methodology and strategic leadership.
|
||||
|
||||
---
|
||||
|
||||
## Reference Materials
|
||||
|
||||
**Strategic Foundation:**
|
||||
- [Product Brief](../../1-project-brief/01-product-brief.md)
|
||||
- [Content Strategy](../../1-project-brief/02-content-strategy.md) - Messaging guidelines and tone
|
||||
- [Trigger Map](../../2-trigger-map/00-trigger-map.md)
|
||||
- [Stina Persona](../../2-trigger-map/02-Stina-the-Strategist.md)
|
||||
- [Feature Impact](../../2-trigger-map/06-Feature-Impact.md)
|
||||
|
||||
**Design Principles:**
|
||||
1. **Build confidence, don't overwhelm** - Progressive disclosure
|
||||
2. **Show tangible value fast** - "You'll create THIS"
|
||||
3. **Make AI friendly** - Co-pilot language, not replacement
|
||||
4. **Provide structure** - Clear path forward
|
||||
5. **Prove credibility** - BMad foundation, real results
|
||||
|
||||
**Success Metrics:**
|
||||
- Engagement: 3+ min time on page, 40%+ scroll to capabilities, 20%+ click GitHub/course
|
||||
- Conversion: 10%+ click CTA, 5%+ watch Module 01, 2%+ clone repository
|
||||
|
||||
---
|
||||
|
||||
## Page Sections
|
||||
|
||||
### Hero Object
|
||||
**Purpose**: Capture attention and communicate core value in 5 seconds
|
||||
|
||||
**Strategic Rationale:** See [Content Strategy - Hero Section](../../1-project-brief/02-content-strategy.md#hero-section) for messaging decisions and psychology.
|
||||
|
||||
#### Main Headline
|
||||
**OBJECT ID**: `wds-hero-headline`
|
||||
- **Component**: H1 heading (`.text-heading-1`)
|
||||
- **Content**: "Whiteport Design Studio, WDS"
|
||||
- **Behavior**: Static text
|
||||
- **Style**: Bold, Current Whiteport heading font, ~48px, Color: White, Line height: 1.2
|
||||
- **Rationale**: Clear, branded, professional. Not trying to be clever.
|
||||
|
||||
#### Battle Cry Tagline
|
||||
**OBJECT ID**: `wds-hero-tagline`
|
||||
- **Component**: H2 heading (`.text-heading-2`)
|
||||
- **Content**: "Shoulder the complexity, break it down using AI as your co-pilot. Not as a burden, but with excitement. Not as a task, but as a calling!"
|
||||
- **Behavior**: Static text
|
||||
- **Style**: Same font as H1, ~28px, Medium weight, White (90% transparency), Line height: 1.4, Italic for emotional quality
|
||||
- **Rationale**: Acknowledges complexity (honest), positions AI as helper (co-pilot), emotional shift: burden → calling
|
||||
|
||||
#### Hero Body Copy
|
||||
**OBJECT ID**: `wds-hero-body`
|
||||
- **Component**: Body text paragraph (`.text-body`)
|
||||
- **Content**: "Free and open-source design methodology and AI agents for designers who mean business. Transform from overwhelmed task-doer into empowered strategic leader. Create specifications that become AI-ready super-prompts, preserving your design intent through to implementation. Built on 25 years of proven methodology. For designers everywhere."
|
||||
- **Behavior**: Static text
|
||||
- **Style**: Body font, ~18px, Regular weight, White or light gray, Line height: 1.6, Max width: 540px
|
||||
- **Word Count**: ~50 words (5-7 second read)
|
||||
- **Rationale**: Line 1 establishes category + audience, Line 2 shows transformation journey, Line 3 builds credibility (25 years) + accessibility
|
||||
|
||||
#### Primary CTA Button
|
||||
**OBJECT ID**: `wds-hero-cta`
|
||||
- **Component**: Button Primary Large
|
||||
- **Content**: "Get WDS Now - Free on GitHub"
|
||||
- **Behavior**: onClick → Navigate to `https://github.com/whiteport/wds`
|
||||
- **Style**: ~18px, Semibold, White text, Button font (heading), No text transform
|
||||
- **Colors**:
|
||||
- Background: Contrasting color (lighter blue or white on blue background)
|
||||
- Hover: Darken/shift hue, Scale 1.05, Increase shadow depth, 200ms transition
|
||||
- Active: Scale 0.98, Reduce shadow
|
||||
- Focus: 2px blue outline ring
|
||||
- **Rationale**: Action-oriented ("Get" not "Learn More"), transparency ("Free on GitHub"), single CTA reduces decision paralysis
|
||||
|
||||
#### Hero Illustration
|
||||
**OBJECT ID**: `wds-hero-illustration`
|
||||
- **Component**: Hero image/illustration
|
||||
- **Content**: Designer working with specifications/tablet visual
|
||||
- **Behavior**: Static display (optional: subtle animation on designer working)
|
||||
- **Position**: Right side of hero section (~45-50% width)
|
||||
- **Style**: Deep blue background theme, modern clean lines, professional aesthetic
|
||||
- **Layout**: Two-column desktop (>1024px), responsive stacks on mobile (<768px)
|
||||
- **Colors**: Matches overall blue theme, doesn't compete with text
|
||||
|
||||
---
|
||||
|
||||
### Benefits Section
|
||||
**Purpose**: Quickly grasp the three key differentiators
|
||||
|
||||
*[To be completed]*
|
||||
|
||||
---
|
||||
|
||||
### WDS Capabilities Object (Right Column)
|
||||
**Purpose**: Show designers what they can accomplish with WDS through actionable phases
|
||||
|
||||
**Strategic Rationale:** See [Content Strategy - Capabilities Section](../../1-project-brief/02-content-strategy.md#capabilities-section-right-column) for messaging decisions and psychology.
|
||||
|
||||
#### Section Headline
|
||||
**OBJECT ID**: `wds-capabilities-headline`
|
||||
- **Component**: H2 heading
|
||||
- **Content**: "What You Can Create with WDS"
|
||||
- **Behavior**: Static text
|
||||
- **Style**: Wavy underline or decorative element
|
||||
- **Rationale**: Direct, action-oriented, focuses on designer capability
|
||||
|
||||
#### Phase 1: Win Client Buy-In
|
||||
**OBJECT ID**: `wds-capability-phase-1`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🎯 (target/presentation)
|
||||
- **Title**: "Win Client Buy-In"
|
||||
- **Description**: "Present your vision in business language that stakeholders understand. Get everyone aligned on goals, budget, and commitment before you start. Stop projects from dying in "maybe" meetings. Saga helps you articulate value and create professional agreements."
|
||||
- **Output**: "→ Pitch & Service Agreement"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/1-project-brief/alignment-signoff`
|
||||
- **Behavior**: onClick → Open GitHub link in new tab
|
||||
|
||||
#### Phase 2: Define Your Project
|
||||
**OBJECT ID**: `wds-capability-phase-2`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 📋 (clipboard/document)
|
||||
- **Title**: "Define Your Project"
|
||||
- **Description**: "Get crystal clear on what you're building, who it's for, and why it matters. Create a strategic foundation that guides every design decision. No more scope creep or confused teams. This brief becomes your north star when things get messy."
|
||||
- **Output**: "→ Product Brief"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/1-product-brief`
|
||||
- **Behavior**: onClick → Open GitHub link in new tab
|
||||
|
||||
#### Phase 3: Map Business Goals to User Needs
|
||||
**OBJECT ID**: `wds-capability-phase-3`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🗺️ (map/compass)
|
||||
- **Title**: "Map Business Goals to User Needs"
|
||||
- **Description**: "Connect what the business wants to what users actually need. Identify the emotional triggers and pain points that make your design work. Stop guessing and start designing with psychological insight. Cascade helps you create personas grounded in real driving forces."
|
||||
- **Output**: "→ Trigger Map & Personas"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/2-trigger-mapping`
|
||||
- **Behavior**: onClick → Open GitHub link in new tab
|
||||
|
||||
#### Phase 4: Architect the Platform
|
||||
**OBJECT ID**: `wds-capability-phase-4`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🏗️ (building/architecture)
|
||||
- **Title**: "Architect the Platform"
|
||||
- **Description**: "Define the technical foundation, data structure, and system architecture. Make smart decisions about what to build and how it fits together. Bridge the gap between design vision and technical reality. Idunn helps you think through the platform without getting lost in code."
|
||||
- **Output**: "→ Platform PRD & Architecture"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/3-prd-platform`
|
||||
- **Behavior**: onClick → Open GitHub link in new tab
|
||||
|
||||
#### Phase 5: Design the Experience
|
||||
**OBJECT ID**: `wds-capability-phase-5`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🎨 (palette/design)
|
||||
- **Title**: "Design the Experience"
|
||||
- **Description**: "Turn sketches into complete specifications with interactive prototypes. Capture not just WHAT it looks like, but WHY you designed it that way. Preserve your design intent from concept to code. Freyja helps you create specifications that developers actually understand and respect."
|
||||
- **Output**: "→ Page Specs & Prototypes"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/4-ux-design`
|
||||
- **Behavior**: onClick → Open GitHub link in new tab
|
||||
|
||||
#### Phase 6: Build Your Design System
|
||||
**OBJECT ID**: `wds-capability-phase-6`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🧩 (puzzle pieces/system)
|
||||
- **Title**: "Build Your Design System"
|
||||
- **Description**: "Extract reusable components, patterns, and design tokens from your pages. Create consistency across your entire product without starting from scratch every time. Scale your design decisions efficiently. Stop reinventing buttons and start building systems."
|
||||
- **Output**: "→ Component Library & Tokens"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/5-design-system`
|
||||
- **Behavior**: onClick → Open GitHub link in new tab
|
||||
|
||||
#### Phase 7: Hand Off to Developers
|
||||
**OBJECT ID**: `wds-capability-phase-7`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 📦 (package/delivery)
|
||||
- **Title**: "Hand Off to Developers"
|
||||
- **Description**: "Package everything developers need in organized PRD documents with epics and stories. No more "what did you mean by this?" meetings. No more guesswork or lost design intent. Idunn creates implementation guides that turn your specs into buildable tasks."
|
||||
- **Output**: "→ PRD, Epics & Stories"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/6-design-deliveries`
|
||||
- **Behavior**: onClick → Open GitHub link in new tab
|
||||
|
||||
#### Phase 8: Validate the Build
|
||||
**OBJECT ID**: `wds-capability-phase-8`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: ✅ (checkmark/validation)
|
||||
- **Title**: "Validate the Build"
|
||||
- **Description**: "Ensure what's built matches what you designed. Catch misinterpretations before they reach users. Create test plans that validate both function and design intent. Freyja helps you compare implementations to specifications systematically."
|
||||
- **Output**: "→ Test Plans & Reports"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/7-testing`
|
||||
- **Behavior**: onClick → Open GitHub link in new tab
|
||||
|
||||
---
|
||||
|
||||
### Testimonials Section
|
||||
**Purpose**: Build trust through social proof
|
||||
|
||||
*[To be completed]*
|
||||
|
||||
---
|
||||
|
||||
### CTA Section
|
||||
**Purpose**: Remove barriers to action
|
||||
|
||||
*[To be completed]*
|
||||
|
||||
---
|
||||
|
||||
### Footer Section
|
||||
**Purpose**: Additional information and contact
|
||||
|
||||
*[To be completed]*
|
||||
|
||||
---
|
||||
|
||||
## Object Registry
|
||||
|
||||
| Object ID | Component Type | Parent Section | Status |
|
||||
|-----------|---------------|----------------|---------|
|
||||
| `wds-hero-headline` | H1 Heading | Hero Object | ✅ Specified |
|
||||
| `wds-hero-tagline` | H2 Heading | Hero Object | ✅ Specified |
|
||||
| `wds-hero-body` | Body Paragraph | Hero Object | ✅ Specified |
|
||||
| `wds-hero-cta` | Button Primary Large | Hero Object | ✅ Specified |
|
||||
| `wds-hero-illustration` | Hero Image | Hero Object | ✅ Specified |
|
||||
| `wds-capabilities-headline` | H2 Heading | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-1` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-2` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-3` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-4` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-5` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-6` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-7` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-8` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
|
||||
---
|
||||
|
||||
**Status:** In Progress (Hero & Capabilities Sections Restructured to WDS Standards)
|
||||
**Designer:** Freyja WDS Designer Agent
|
||||
**Created:** December 27, 2025
|
||||
**Last Updated:** December 28, 2025
|
||||
|
|
@ -105,7 +105,7 @@ The WDS Presentation page serves as the primary entry point for designers discov
|
|||
- **Title (EN):** "Win Client Buy-In"
|
||||
- **Description (EN):** "Present your vision in business language that stakeholders understand. Get everyone aligned on goals, budget, and commitment before you start. Stop projects from dying in "maybe" meetings. Saga helps you articulate value and create professional agreements."
|
||||
- **Output (EN):** "→ Pitch & Service Agreement"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/1-project-brief/alignment-signoff`
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/course/deliverables/project-pitch.md`
|
||||
|
||||
#### Phase 2: Define Your Project
|
||||
**OBJECT ID**: `wds-capability-phase-2`
|
||||
|
|
@ -115,7 +115,7 @@ The WDS Presentation page serves as the primary entry point for designers discov
|
|||
- **Title (EN):** "Define Your Project"
|
||||
- **Description (EN):** "Get crystal clear on what you're building, who it's for, and why it matters. Create a strategic foundation that guides every design decision. No more scope creep or confused teams. This brief becomes your north star when things get messy."
|
||||
- **Output (EN):** "→ Product Brief"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/1-product-brief`
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/course/deliverables/product-brief.md`
|
||||
|
||||
#### Phase 3: Map Business Goals to User Needs
|
||||
**OBJECT ID**: `wds-capability-phase-3`
|
||||
|
|
@ -125,7 +125,7 @@ The WDS Presentation page serves as the primary entry point for designers discov
|
|||
- **Title (EN):** "Map Business Goals to User Needs"
|
||||
- **Description (EN):** "Connect what the business wants to what users actually need. Identify the emotional triggers and pain points that make your design work. Stop guessing and start designing with psychological insight. Cascade helps you create personas grounded in real driving forces."
|
||||
- **Output (EN):** "→ Trigger Map & Personas"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/2-trigger-mapping`
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/course/deliverables/trigger-map.md`
|
||||
|
||||
#### Phase 4: Architect the Platform
|
||||
**OBJECT ID**: `wds-capability-phase-4`
|
||||
|
|
@ -135,7 +135,7 @@ The WDS Presentation page serves as the primary entry point for designers discov
|
|||
- **Title (EN):** "Architect the Platform"
|
||||
- **Description (EN):** "Define the technical foundation, data structure, and system architecture. Make smart decisions about what to build and how it fits together. Bridge the gap between design vision and technical reality. Idunn helps you think through the platform without getting lost in code."
|
||||
- **Output (EN):** "→ Platform PRD & Architecture"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/3-prd-platform`
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/course/deliverables/platform-prd.md`
|
||||
|
||||
#### Phase 5: Design the Experience
|
||||
**OBJECT ID**: `wds-capability-phase-5`
|
||||
|
|
@ -145,7 +145,7 @@ The WDS Presentation page serves as the primary entry point for designers discov
|
|||
- **Title (EN):** "Design the Experience"
|
||||
- **Description (EN):** "Turn sketches into complete specifications with interactive prototypes. Capture not just WHAT it looks like, but WHY you designed it that way. Preserve your design intent from concept to code. Freyja helps you create specifications that developers actually understand and respect."
|
||||
- **Output (EN):** "→ Page Specs & Prototypes"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/4-ux-design`
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/course/deliverables/page-specifications.md`
|
||||
|
||||
#### Phase 6: Build Your Design System
|
||||
**OBJECT ID**: `wds-capability-phase-6`
|
||||
|
|
@ -155,7 +155,7 @@ The WDS Presentation page serves as the primary entry point for designers discov
|
|||
- **Title (EN):** "Build Your Design System"
|
||||
- **Description (EN):** "Extract reusable components, patterns, and design tokens from your pages. Create consistency across your entire product without starting from scratch every time. Scale your design decisions efficiently. Stop reinventing buttons and start building systems."
|
||||
- **Output (EN):** "→ Component Library & Tokens"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/5-design-system`
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/course/deliverables/design-system.md`
|
||||
|
||||
#### Phase 7: Hand Off to Developers
|
||||
**OBJECT ID**: `wds-capability-phase-7`
|
||||
|
|
@ -164,18 +164,8 @@ The WDS Presentation page serves as the primary entry point for designers discov
|
|||
- **Content:**
|
||||
- **Title (EN):** "Hand Off to Developers"
|
||||
- **Description (EN):** "Package everything developers need in organized PRD documents with epics and stories. No more "what did you mean by this?" meetings. No more guesswork or lost design intent. Idunn creates implementation guides that turn your specs into buildable tasks."
|
||||
- **Output (EN):** "→ PRD, Epics & Stories"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/6-design-deliveries`
|
||||
|
||||
#### Phase 8: Validate the Build
|
||||
**OBJECT ID**: `wds-capability-phase-8`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: ✅ (checkmark/validation)
|
||||
- **Content:**
|
||||
- **Title (EN):** "Validate the Build"
|
||||
- **Description (EN):** "Ensure what's built matches what you designed. Catch misinterpretations before they reach users. Create test plans that validate both function and design intent. Freyja helps you compare implementations to specifications systematically."
|
||||
- **Output (EN):** "→ Test Plans & Reports"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/workflows/7-testing`
|
||||
- **Output (EN):** "→ Design Delivery PRD"
|
||||
- **Link**: `https://github.com/whiteport/wds/tree/main/src/modules/wds/course/deliverables/design-delivery-prd.md`
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -217,7 +207,6 @@ The WDS Presentation page serves as the primary entry point for designers discov
|
|||
| `wds-capability-phase-5` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-6` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-7` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
| `wds-capability-phase-8` | Capability Card | WDS Capabilities Object | ✅ Specified |
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue