BMAD-METHOD/src/modules/wds/workflows/4-ux-design/CONTENT-PLACEMENT-GUIDE.md

11 KiB

Content Placement Guide

Where to Document Content: Page vs Component vs Feature


Quick Decision Tree

Is this CONTENT (text, images, data)?
│
├─ YES → Does it vary by page context?
│        │
│        ├─ YES → Page File
│        │        (e.g., "Welcome to Dog Week" on Home, "About Dog Week" on About)
│        │
│        └─ NO → Feature File
│                 (e.g., "Submit" button text is always the same)
│
└─ NO → Is this VISUAL design (colors, spacing, states)?
         │
         └─ YES → Component File
                  (e.g., button is blue, 48px height, has hover state)

The Three File Types

1. Page File (WHERE)

Contains:

  • Position & size
  • Page-specific content (headings, text, images that change per page)
  • Page-specific data (API endpoints with page context)
  • Component references
  • Feature references

Example:

Pages/01-home-page.md
---
### Hero Section

**Component:** `hero-banner.component.md`

**Position:** Top of page, full-width
**Size:** 400px height (desktop), 300px (mobile)

**Page-Specific Content:**
- Heading: "Welcome to Dog Week" / "Välkommen till Dog Week"
- Subheading: "Coordinate your family's dog walks effortlessly"
- Background Image: `/images/hero-home-happy-dog.jpg`
- CTA Button Text: "Get Started" / "Kom igång"
- CTA Button Link: → `/onboarding/start`

2. Component File (HOW IT LOOKS)

Contains:

  • Visual specifications (colors, spacing, typography)
  • States (default, hover, active, disabled, loading, error)
  • Variants (sizes, types, themes)
  • Figma component mapping
  • Responsive behavior
  • Accessibility
  • NO content (no text, no images, no data)

Example:

Components/hero-banner.component.md
---
# Hero Banner Component

**Visual Specifications:**
- Height: 400px (desktop), 300px (mobile)
- Layout: Centered text over background image
- Background: Image with dark overlay (40% opacity)
- Typography:
  - Heading: 48px Bold, white color
  - Subheading: 18px Regular, white color
- CTA Button: Primary button style (blue background, white text)

**Content Slots:**
- Heading text (configurable per page)
- Subheading text (configurable per page)
- Background image (configurable per page)
- CTA button text + link (configurable per page)

**States:**
- Default: Full opacity
- Loading: Skeleton placeholder

3. Feature File (WHAT IT DOES)

Contains:

  • User interactions & system responses
  • Business rules & validation
  • State management
  • Generic content (content that's the same everywhere)
  • Generic data (API endpoints without page context)
  • Error handling
  • Configuration options
  • NO visual design (no colors, no spacing, no states)

Example:

Features/hero-cta-logic.feature.md
---
# Hero CTA Logic Feature

**User Interactions:**

### Click CTA Button
1. User clicks CTA button
2. System validates user session
3. If logged in → Navigate to destination
4. If not logged in → Show login modal first

**Generic Content:**
- Loading text: "Loading..." / "Laddar..."
- Error message: "Something went wrong" / "Något gick fel"

**API Endpoints:**
- GET /api/user/session (check if logged in)

**Business Rules:**
- CTA disabled during loading
- CTA shows loading spinner when clicked

Content Placement Examples

Example 1: Hero Section

Scenario: Hero banner appears on multiple pages with different content

Page File (Home):

**Page-Specific Content:**
- Heading: "Welcome to Dog Week"
- Subheading: "Coordinate your family's dog walks"
- Background Image: `/images/hero-home.jpg`
- CTA Text: "Get Started"
- CTA Link: `/onboarding/start`

Page File (About):

**Page-Specific Content:**
- Heading: "About Dog Week"
- Subheading: "Our mission to simplify dog care"
- Background Image: `/images/hero-about.jpg`
- CTA Text: "Contact Us"
- CTA Link: `/contact`

Component File:

**Visual Specifications:**
- Height: 400px
- Typography: 48px Bold heading, 18px Regular subheading
- Layout: Centered text over image

**Content Slots:**
- Heading (configurable)
- Subheading (configurable)
- Background image (configurable)
- CTA button (configurable)

Feature File:

**Generic Content:**
- Loading text: "Loading..."

**Interactions:**
- Click CTA → Navigate to link

Scenario: Search bar appears on Product page and Help page with different scopes

Page File (Product Catalog):

**Page-Specific Content:**
- Placeholder: "Search products..." / "Sök produkter..."

**Page-Specific Data:**
- API Endpoint: GET /api/products/search?q=:query
- Scope: Products only
- Result Display: Product cards grid

Page File (Help Center):

**Page-Specific Content:**
- Placeholder: "Search help articles..." / "Sök hjälpartiklar..."

**Page-Specific Data:**
- API Endpoint: GET /api/help/search?q=:query
- Scope: Help articles only
- Result Display: Article list

Component File:

**Visual Specifications:**
- Height: 48px
- Border: 1px solid gray
- States:
  - Default: Gray border
  - Focused: Blue border
  - Loading: Spinner icon on right
  - Results: Dropdown below input

**Content Slots:**
- Placeholder text (configurable per page)

Feature File:

**Generic Content:**
- No results message: "No results found" / "Inga resultat"
- Error message: "Search failed" / "Sökning misslyckades"

**Interactions:**
- User types → Debounce 300ms → API call
- Min 3 characters required
- Max 10 results displayed
- Keyboard navigation (arrow keys, enter, escape)

**Business Rules:**
- Debounce: 300ms
- Min characters: 3
- Max results: 10

Example 3: Calendar Widget

Scenario: Calendar appears only on Calendar page, shows current user's family data

Page File (Calendar Page):

**Page-Specific Content:**
- Header Format: "[Family Name]: Vecka [Week Number]"
  - SE: "Familjen Svensson: Vecka 40"
  - EN: "Svensson Family: Week 40"

**Page-Specific Data:**
- Data Source: Current user's family from session
- API Endpoint: GET /api/families/:currentFamilyId/walks?week=:weekNumber
- Dogs Displayed: All dogs in current user's family
- Family Members: All members in current user's family

**Configuration:**
- Initial View: Current week, scrolled to today
- Time Slots: 4 hardcoded (8-11, 12-13, 15-17, 18-20)

Component File:

**Visual Specifications:**
- 6 walk states (WHITE, GRAY, ORANGE, BLUE, GREEN, RED)
- Week circles: 7 days with quarter segments
- Leaderboard cards: Avatar + badge + name

**Content Slots:**
- Header text (configurable per page)
- Time slot labels (configurable)

Feature File:

**Generic Content:**
- Empty state: "Add a dog to start planning walks"
- Error message: "Failed to load walks"
- Countdown format: "32 min left" / "32 min kvar"
- Duration format: "32 min walk" / "32 min promenad"

**Interactions:**
- Book walk → GRAY state
- Start walk → BLUE state
- Complete walk → GREEN state
- Miss walk → RED state

**Business Rules:**
- One active walk per dog
- Can't book if slot taken
- Countdown starts at slot start time

**API Endpoints:**
- GET /api/families/:familyId/walks?week=:weekNumber
- POST /api/walks (create booking)
- PUT /api/walks/:walkId/start
- PUT /api/walks/:walkId/complete

Example 4: Submit Button

Scenario: Submit button appears on multiple forms, always says "Submit"

Page File:

**Position:** Bottom of form, right-aligned
**Size:** Full-width on mobile, auto-width on desktop

**Component:** `button-primary.component.md`
**Feature:** `form-submit-logic.feature.md`

(No page-specific content - button text is always "Submit")

Component File:

**Visual Specifications:**
- Background: Blue (#3B82F6)
- Text: White, 16px Medium
- Height: 48px
- Border Radius: 8px
- States:
  - Default: Blue background
  - Hover: Darker blue
  - Active: Even darker blue
  - Disabled: Gray background
  - Loading: Blue background + spinner

Feature File:

**Generic Content:**
- Button text: "Submit" / "Skicka"
- Loading text: "Submitting..." / "Skickar..."
- Success message: "Submitted successfully" / "Skickat"
- Error message: "Submission failed" / "Misslyckades"

**Interactions:**
- Click → Validate form
- If valid → Submit to API
- If invalid → Show validation errors
- Show loading state during submission

Decision Matrix

Content Type Page-Specific? Where to Document
Hero heading YES (different per page) Page File
Hero background image YES (different per page) Page File
Search placeholder YES (different per page) Page File
Calendar header YES (shows user's family name) Page File
API endpoint with user context YES (varies by user/page) Page File
Submit button text NO (always "Submit") Feature File
Error messages NO (generic validation) Feature File
Loading text NO (always "Loading...") Feature File
Tooltip text NO (generic interaction) Feature File
API endpoint (generic) NO (same for all users) Feature File
Button color NO (visual design) Component File
Font size NO (visual design) Component File
Hover state NO (visual design) Component File
Layout spacing NO (visual design) Component File

Common Mistakes

Mistake 1: Putting page-specific content in Feature file

Wrong:

Features/hero-logic.feature.md
---
**Content:**
- Heading: "Welcome to Dog Week" (Home page)
- Heading: "About Dog Week" (About page)

Right:

Pages/01-home-page.md
---
**Page-Specific Content:**
- Heading: "Welcome to Dog Week"

Pages/02-about-page.md
---
**Page-Specific Content:**
- Heading: "About Dog Week"

Mistake 2: Putting generic content in Page file

Wrong:

Pages/01-home-page.md
---
**Content:**
- Submit button: "Submit"
- Error message: "Invalid email"

Right:

Features/form-submit-logic.feature.md
---
**Generic Content:**
- Submit button: "Submit"
- Error message: "Invalid email"

Mistake 3: Putting visual design in Feature file

Wrong:

Features/button-logic.feature.md
---
**Visual:**
- Background: Blue
- Height: 48px
- Hover: Darker blue

Right:

Components/button-primary.component.md
---
**Visual Specifications:**
- Background: Blue (#3B82F6)
- Height: 48px
- States:
  - Hover: Darker blue (#2563EB)

Summary

Content Placement Rule:

Does content vary by page context?
├─ YES → Page File
│        (Hero heading, search placeholder, user-specific data)
│
└─ NO → Feature File
         (Button text, error messages, generic tooltips)

Is this visual design?
└─ YES → Component File
         (Colors, spacing, states, typography)

Key Principle:

  • Page File = WHERE + WHAT (page-specific)
  • Component File = HOW IT LOOKS (visual design)
  • Feature File = WHAT IT DOES (functionality + generic content)

Result:

  • Clear separation of concerns
  • Easy to maintain and update
  • Clean handoffs to designers and developers
  • No confusion about where content belongs