# WDS Presentation Page - Content Strategy

**Purpose:** Define messaging strategy, tone, and content boundaries for the WDS Presentation landing page.

**Target Persona:** Stina the Strategist (Primary)  
**Secondary Personas:** Lars the Leader, Felix the Full-Stack

---

## Strategic Content Principles

### 1. AI as Co-Pilot, Not Replacement

**Messaging:**
- Position AI agents as collaborative tools that enhance designer expertise
- Emphasize "strategic leader" role for designers
- Use "co-pilot" language consistently

**Why:**
- Addresses Stina's fear of being replaced by AI
- Elevates her role rather than threatening it
- Builds confidence in AI adoption

**Examples:**
- ✅ "Design with AI co-pilots"
- ✅ "AI agents that amplify your expertise"
- ❌ "AI does the design for you"
- ❌ "Replace manual design work"

---

### 2. Empowering, Not Easy

**Messaging:**
- Acknowledge the learning curve honestly
- Emphasize capability-building over simplicity
- Use language like "empowering," "strategic," "professional"

**Why:**
- Stina is skeptical of "easy" promises (been burned before)
- WDS genuinely requires skill and thoughtfulness
- Respect for expertise builds trust

**Examples:**
- ✅ "Build professional design specifications"
- ✅ "Master strategic UX methodology"
- ❌ "Easy to use"
- ❌ "Anyone can design"
- ❌ "No experience needed"

---

### 3. Free as Generosity, Not Cheap

**Messaging:**
- Mention "free" but don't overemphasize it
- Focus on value and capability, price is secondary
- GitHub open-source positioning builds credibility

**Why:**
- Over-emphasizing "free" can devalue the methodology
- Stina values quality over price
- Open-source = transparency, not "cheap"

**Examples:**
- ✅ "Available on GitHub"
- ✅ "Open-source methodology"
- ⚠️ "Free forever" (OK but don't lead with it)
- ❌ "Free because we can't charge for this"
- ❌ "Get it for free before we start charging"

---

### 4. Show Outcomes, Not Features

**Messaging:**
- Lead with what designers can CREATE (deliverables)
- Show tangible artifacts (PRDs, specs, prototypes)
- Link to GitHub examples

**Why:**
- Stina needs to see concrete value quickly
- Deliverables prove this isn't vaporware
- Real examples build confidence

**Examples:**
- ✅ "Create professional Product Briefs"
- ✅ "Generate interactive prototypes"
- ❌ "Has 8 different agents"
- ❌ "Includes many templates"

---

## Section-Specific Strategy

### Hero Section

**Primary Goal:** Emotional connection + immediate value proposition

**Content Strategy:**
- **Battle Cry First** - Lead with emotional transformation
- **Illustration Shows Designer** - Stina sees herself in the tool
- **Single CTA** - One clear action (GitHub)
- **Blue Background** - Professional, brand-consistent

**Messaging Focus:**
- Design methodology, not just software
- Strategic leadership role
- Creative empowerment

**Psychology:**
- **Addresses Fear:** "Being replaced" → Shows designer in control
- **Triggers Want:** "Be strategic expert" → Methodology focus

---

### Benefits Section

**Primary Goal:** Quick differentiation from Figma/standard tools

**Content Strategy:**
- 3 key differentiators only (not overwhelming)
- Each benefit = problem solved + outcome delivered
- Visual icons to aid scanning

**Messaging Focus:**
- What makes WDS DIFFERENT (not better)
- Problems other tools don't solve
- Designer + AI collaboration model

**Psychology:**
- **Addresses Fear:** "Wasting time" → Shows specific value
- **Triggers Want:** "Make real impact" → Business outcomes

---

### Capabilities Section (Right Column)

**Primary Goal:** Show tangible outputs and build confidence

**Content Strategy:**
- 8 phases presented as capabilities
- Each = Action verb + Outcome + GitHub link
- 4 lines max per capability (scannable)
- Deliverable clearly marked

**Messaging Focus:**
- WHAT you create (not how it works)
- Complete workflow visibility
- Professional artifacts

**Psychology:**
- **Addresses Fear:** "Too complex for me" → Broken into clear steps
- **Triggers Want:** "See complete picture" → Full workflow

**See detailed capability descriptions in:** [Capability Messaging](#capability-messaging)

---

### Testimonials Section

**Primary Goal:** Build trust through social proof

**Content Strategy:**
- Real people (eventually) with real results
- Focus on transformation, not features
- Include persona-specific testimonials

**Messaging Focus:**
- Before/after emotional states
- Specific outcomes achieved
- Credible, authentic voices

**Psychology:**
- **Addresses Fear:** "This won't work for me" → Others succeeded
- **Triggers Want:** "Be recognized" → Social validation

---

### CTA Section

**Primary Goal:** Remove barriers to action

**Content Strategy:**
- Clear next step (GitHub or Course)
- Low commitment language
- Emphasize exploratory, risk-free approach

**Messaging Focus:**
- Invitation, not pressure
- Multiple entry points (browse, learn, try)
- Open-source transparency

**Psychology:**
- **Addresses Fear:** "Being locked in" → Can explore freely
- **Triggers Want:** "Learn confidently" → Safe exploration

---

## Content Boundaries (WHAT NOT TO DO)

### Don't Lead with Technical Details

**Avoid upfront:**
- IDE requirements (Cursor)
- Text-based workflows
- Terminal/command line mentions
- Technical architecture

**Why:**
- Too intimidating for Stina initially
- Save technical details for "Getting Started"
- Focus on outcomes first, mechanics later

**When to introduce:**
- After emotional connection established
- In "How It Works" or "Getting Started" section
- With supportive, educational framing

---

### Don't Use "Easy" or "Simple" Language

**Avoid:**
- "Easy to use"
- "Simple design tool"
- "No learning curve"
- "Anyone can do it"

**Use instead:**
- "Empowering"
- "Strategic"
- "Professional"
- "Systematic"

**Why:**
- WDS genuinely requires skill
- Stina is skeptical of false promises
- Respect for expertise builds trust

---

### Don't Show Code/Terminal Screenshots

**Avoid upfront:**
- Terminal windows
- Code syntax
- File system screenshots
- Technical editor views

**Show instead:**
- Finished deliverables (specs, PRDs)
- Visual outputs (prototypes, diagrams)
- Designer-agent conversation flows
- Beautiful page examples

**Why:**
- Code looks intimidating
- Focus on outputs, not inputs
- Visual outcomes are more compelling

---

### Don't Use Multiple CTAs

**Avoid:**
- Multiple buttons in hero
- Competing calls to action
- "Try now" + "Learn more" + "Sign up"

**Use instead:**
- One primary CTA per section
- Clear hierarchy (primary vs. secondary)
- Consistent action across sections

**Why:**
- Multiple CTAs create decision paralysis
- Stina needs clear path forward
- Reduces cognitive load

---

### Don't Use Comparison Language

**Avoid:**
- "Better than Figma"
- "Replace your design tools"
- "Unlike other UX tools"
- Competitor name-dropping

**Use instead:**
- "Different approach"
- "Complements your existing tools"
- "Text-based design methodology"
- Focus on what WDS DOES, not what others don't

**Why:**
- Creates defensiveness (Stina probably uses Figma)
- Comparison feels aggressive
- WDS is additive, not replacement

---

### Don't Use Aggressive AI Replacement Messaging

**Avoid:**
- "AI does the design work"
- "Replace your design team"
- "Automated UX design"
- "AI-first workflow"

**Use instead:**
- "AI co-pilots"
- "AI-assisted design"
- "Collaborative agents"
- "AI amplifies your expertise"

**Why:**
- Threatens designer identity
- Stina fears being replaced
- Co-pilot framing reduces anxiety

---

### Don't Overemphasize "Free"

**Avoid:**
- "Free forever!" as headline
- "No credit card required" everywhere
- Price comparison tables
- "Get it free before we charge"

**Use instead:**
- "Available on GitHub"
- "Open-source methodology"
- Mention free once, move on
- Focus on value, not price

**Why:**
- Over-emphasizing free devalues the work
- Stina values quality over price
- Free can signal "cheap" or "unfinished"

---

## Capability Messaging

*[This section contains the detailed messaging for the 8 WDS capabilities/phases]*

### Phase 1: Win Client Buy-In

**Headline:** "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.
```

**Deliverable:** "→ Pitch & Service Agreement"

**Psychology:**
- **Problem:** Projects stuck in "maybe" limbo
- **Outcome:** Commitment and alignment
- **Agent Help:** Saga translates design vision to business language

---

### Phase 2: Define Your Project

**Headline:** "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.
```

**Deliverable:** "→ Product Brief"

**Psychology:**
- **Problem:** Scope creep, confusion
- **Outcome:** Strategic clarity
- **Agent Help:** Structured questioning process

---

### Phase 3: Map Business Goals to User Needs

**Headline:** "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.
```

**Deliverable:** "→ Trigger Map & Personas"

**Psychology:**
- **Problem:** Designing by guesswork
- **Outcome:** Psychological insight
- **Agent Help:** Cascade guides trigger mapping

---

### Phase 4: Architect the Platform

**Headline:** "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.
```

**Deliverable:** "→ Platform PRD & Architecture"

**Psychology:**
- **Problem:** Design-dev disconnect
- **Outcome:** Technical clarity without coding
- **Agent Help:** Idunn translates design to technical specs

---

### Phase 5: Design the Experience

**Headline:** "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. Freya helps you create specifications that developers actually understand and respect.
```

**Deliverable:** "→ Page Specs & Prototypes"

**Psychology:**
- **Problem:** Design intent lost in handoff
- **Outcome:** Specifications developers respect
- **Agent Help:** Freya captures WHY, not just WHAT

---

### Phase 6: Build Your Design System

**Headline:** "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.
```

**Deliverable:** "→ Component Library & Tokens"

**Psychology:**
- **Problem:** Reinventing components repeatedly
- **Outcome:** Systematic consistency
- **Agent Help:** Pattern extraction and documentation

---

### Phase 7: Hand Off to Developers

**Headline:** "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.
```

**Deliverable:** "→ PRD, Epics & Stories"

**Psychology:**
- **Problem:** Endless clarification meetings
- **Outcome:** Clear implementation roadmap
- **Agent Help:** Idunn translates specs to dev tasks

---

### Phase 8: Validate the Build

**Headline:** "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. Freya 
helps you compare implementations to specifications systematically.
```

**Deliverable:** "→ Test Plans & Reports"

**Psychology:**
- **Problem:** Design compromised in implementation
- **Outcome:** Fidelity to original vision
- **Agent Help:** Freya validates against specs

---

## Tone Guidelines

### Overall Tone

**Be:**
- Honest about learning curve
- Enthusiastic about possibilities
- Respectful of expertise
- Inviting to responsibility

**Avoid:**
- Overpromising
- Condescension
- Hype or exaggeration
- Gatekeeping

---

### Language Patterns

**Use:**
- "Create," "Build," "Design" (active verbs)
- "You," "Your" (direct address)
- "Professional," "Strategic," "Systematic" (quality descriptors)
- Specific deliverables (not vague promises)

**Avoid:**
- Passive voice
- Technical jargon (upfront)
- Marketing clichés
- Vague value propositions

---

## Reference Links

**For Page Specifications:**
- Link to this document from page specs: `[Content Strategy](../../1-project-brief/02-content-strategy.md)`
- Use this as source of truth for messaging decisions
- Update this document when strategy evolves

**For Agents:**
- Saga (Analyst) - Client buy-in messaging
- Cascade (Trigger Mapping) - User psychology insights
- Freya (UX Designer) - Design specification approach
- Idunn (Technical Architect) - Platform/PRD messaging

---

**Last Updated:** December 28, 2025  
**Owner:** Product Team  
**Review Cycle:** After each major iteration

