feat(wds): Enhance UX design documentation and workflow structure
Updated the UX design documentation to reflect changes in project phases, including the addition of a new phase for ongoing product cycles. Revised terminology for clarity, replacing "detailed specifications" with "conceptual specifications." Enhanced the workflow initialization process by defining project structure and delivery configurations, ensuring a more streamlined setup for users. Additionally, updated examples and scenarios to align with the new project focus on TaskFlow, improving overall consistency and user guidance.
This commit is contained in:
Mårten Angner
parent
13f51ca75e
commit
8f3af396dd
|
|
@ -39,11 +39,11 @@ docs/
|
|||
|
||||
## 🌟 My Expertise
|
||||
|
||||
**Phase 4: UX Design** - Creating scenarios, sketches, interactive prototypes, and detailed specifications
|
||||
**Phase 4: UX Design** - Creating scenarios, sketches, interactive prototypes, and conceptual specifications
|
||||
**Phase 5: Design System** - Building design tokens, component libraries, and style guides
|
||||
**Phase 7: Testing** - Validating designs through usability testing and implementation review
|
||||
|
||||
**I create interactive prototypes** you can actually click through and test before any code is written!
|
||||
**Phase 6: Design Deliverables** - Preparing handoff packages for development with all specifications and assets
|
||||
**Phase 7: Testing** - Validating designs through usability testing and implementation review
|
||||
**Phase 8: Ongoing Product Cycles** - Iterative improvements and feature evolution for existing products
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,36 @@
|
|||
**Project:** WDS Official Presentation Page
|
||||
**Date:** December 24, 2025
|
||||
**Author:** Saga WDS Analyst Agent
|
||||
**Status:** In Progress
|
||||
**Status:** Complete
|
||||
|
||||
---
|
||||
|
||||
## Project Structure
|
||||
|
||||
**Type:** simple_website
|
||||
**Description:** Single-page marketing site with multiple content sections
|
||||
**Scenarios:** single
|
||||
**Pages:** single (with potential variants)
|
||||
|
||||
This is a simple website project with a single primary landing page. The page contains multiple sections but represents one continuous user journey. Future variants (e.g., for different audiences) may be added as page variants.
|
||||
|
||||
---
|
||||
|
||||
## Delivery Configuration
|
||||
|
||||
**Format:** WordPress Markup
|
||||
**Target Platform:** WordPress CMS (Whiteport.com)
|
||||
**Requires PRD:** No
|
||||
|
||||
**Delivery Description:**
|
||||
Ready-to-paste WordPress page editor code with properly formatted blocks, content sections, and embedded media. No separate PRD phase needed since the specifications translate directly to WordPress implementation.
|
||||
|
||||
**Deliverables:**
|
||||
- WordPress editor code blocks (headings, paragraphs, lists, tables)
|
||||
- YouTube embeds with proper shortcodes
|
||||
- Image placements with alt text
|
||||
- Links formatted as WordPress links
|
||||
- Paste-ready content sections
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,562 @@
|
|||
# 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. Freyja 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:** Freyja 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. Freyja
|
||||
helps you compare implementations to specifications systematically.
|
||||
```
|
||||
|
||||
**Deliverable:** "→ Test Plans & Reports"
|
||||
|
||||
**Psychology:**
|
||||
- **Problem:** Design compromised in implementation
|
||||
- **Outcome:** Fidelity to original vision
|
||||
- **Agent Help:** Freyja 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
|
||||
- Freyja (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
|
||||
|
||||
|
|
@ -0,0 +1,228 @@
|
|||
### 1.1 WDS Presentation
|
||||
|
||||
|
||||
|
||||
# 1.1 WDS Presentation
|
||||
|
||||
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
|
||||
- **Content:**
|
||||
- **EN:** "Whiteport Design Studio, WDS"
|
||||
- **Rationale**: Clear, branded, professional. Not trying to be clever.
|
||||
|
||||
#### Battle Cry Tagline
|
||||
**OBJECT ID**: `wds-hero-tagline`
|
||||
- **Component**: H2 heading
|
||||
- **Content:**
|
||||
- **EN:** "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!"
|
||||
- **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
|
||||
- **Content:**
|
||||
- **EN:** "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."
|
||||
- **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
|
||||
- **Content:**
|
||||
- **EN:** "Get WDS Now - Free on GitHub"
|
||||
- **Link**: `https://github.com/whiteport/wds`
|
||||
- **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
|
||||
- **Content**: Designer working with specifications/tablet visual
|
||||
- **Note**: Illustration shows designer as expert with specifications, matches existing Whiteport style
|
||||
|
||||
---
|
||||
|
||||
### 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:**
|
||||
- **EN:** "What You Can Create with WDS"
|
||||
- **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)
|
||||
- **Content:**
|
||||
- **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`
|
||||
|
||||
#### Phase 2: Define Your Project
|
||||
**OBJECT ID**: `wds-capability-phase-2`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 📋 (clipboard/document)
|
||||
- **Content:**
|
||||
- **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`
|
||||
|
||||
#### Phase 3: Map Business Goals to User Needs
|
||||
**OBJECT ID**: `wds-capability-phase-3`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🗺️ (map/compass)
|
||||
- **Content:**
|
||||
- **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`
|
||||
|
||||
#### Phase 4: Architect the Platform
|
||||
**OBJECT ID**: `wds-capability-phase-4`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🏗️ (building/architecture)
|
||||
- **Content:**
|
||||
- **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`
|
||||
|
||||
#### Phase 5: Design the Experience
|
||||
**OBJECT ID**: `wds-capability-phase-5`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🎨 (palette/design)
|
||||
- **Content:**
|
||||
- **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`
|
||||
|
||||
#### Phase 6: Build Your Design System
|
||||
**OBJECT ID**: `wds-capability-phase-6`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 🧩 (puzzle pieces/system)
|
||||
- **Content:**
|
||||
- **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`
|
||||
|
||||
#### Phase 7: Hand Off to Developers
|
||||
**OBJECT ID**: `wds-capability-phase-7`
|
||||
- **Component**: Capability card
|
||||
- **Icon**: 📦 (package/delivery)
|
||||
- **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`
|
||||
|
||||
---
|
||||
|
||||
### 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
|
||||
**Page Name:** 1.1 WDS Presentation
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 517 KiB |
|
|
@ -0,0 +1,111 @@
|
|||
# WDS Workflow Status
|
||||
# Tracks progress through WDS design methodology
|
||||
|
||||
# Project information
|
||||
generated: "2025-12-28"
|
||||
project: "WDS Presentation Page"
|
||||
project_type: "simple_website"
|
||||
workflow_path: "full-product"
|
||||
|
||||
# Project structure (defines folder organization)
|
||||
project_structure:
|
||||
type: "simple_website" # Single-page marketing site with multiple sections
|
||||
scenarios: "single" # Single user journey (landing page flow)
|
||||
pages: "single" # One primary page with multiple sections (potential variants later)
|
||||
notes: "Single scenario with potential for page variants or additional pages in future"
|
||||
|
||||
# Delivery configuration (what gets handed off)
|
||||
delivery:
|
||||
format: "wordpress" # WordPress page editor markup
|
||||
target_platform: "wordpress" # WordPress CMS on Whiteport.com
|
||||
requires_prd: false # Direct implementation from specs
|
||||
description: "Ready-to-paste WordPress page editor code with properly formatted blocks, content sections, and embedded media"
|
||||
|
||||
# Configuration
|
||||
config:
|
||||
folder_prefix: "numbers" # Using numbered folders (1-, 2-, 3-, 4-)
|
||||
folder_case: "lowercase" # Folder names use lowercase-with-hyphens
|
||||
brief_level: "complete" # Complete product brief with full strategic context
|
||||
include_design_system: false # No separate design system needed for single page
|
||||
component_library: "none" # Using standard WordPress blocks
|
||||
specification_language: "EN" # Specs written in English
|
||||
product_languages: ["EN"] # Product supports English
|
||||
|
||||
# Folder mapping
|
||||
folders:
|
||||
product_brief: "1-project-brief/"
|
||||
trigger_map: "2-trigger-map/"
|
||||
platform_requirements: "3-prd-platform/" # Skipped (not needed for WordPress)
|
||||
scenarios: "4-scenarios/"
|
||||
design_system: "5-design-system/" # Skipped
|
||||
prd_finalization: "6-design-deliveries/" # Skipped
|
||||
|
||||
# Workflow status tracking
|
||||
workflow_status:
|
||||
phase_1_project_brief:
|
||||
status: "complete"
|
||||
agent: "saga-analyst"
|
||||
folder: "1-project-brief/"
|
||||
brief_level: "complete"
|
||||
artifacts:
|
||||
- "01-product-brief.md"
|
||||
- "02-content-strategy.md"
|
||||
completed_date: "2025-12-24"
|
||||
|
||||
phase_2_trigger_mapping:
|
||||
status: "complete"
|
||||
agent: "cascade-analyst"
|
||||
folder: "2-trigger-map/"
|
||||
artifacts:
|
||||
- "00-trigger-map.md"
|
||||
- "01-Business-Goals.md"
|
||||
- "02-Stina-the-Strategist.md"
|
||||
- "03-Lars-the-Leader.md"
|
||||
- "04-Felix-the-Full-Stack.md"
|
||||
- "05-Key-Insights.md"
|
||||
- "06-Feature-Impact.md"
|
||||
completed_date: "2025-12-27"
|
||||
|
||||
phase_3_prd_platform:
|
||||
status: "skipped"
|
||||
reason: "WordPress delivery - no platform PRD needed"
|
||||
|
||||
phase_4_ux_design:
|
||||
status: "in-progress"
|
||||
agent: "freyja-wds-designer"
|
||||
folder: "4-scenarios/"
|
||||
current_page: "1.1-start-page"
|
||||
artifacts:
|
||||
- "1.1-start-page/1.1-start-page.md"
|
||||
- "1.1-start-page/sketches/1-1-start-page-desktop-concept.jpg"
|
||||
notes: "Hero section complete, WDS Capabilities section specified, other sections TBD"
|
||||
|
||||
phase_5_design_system:
|
||||
status: "skipped"
|
||||
reason: "Single page project - no design system needed"
|
||||
|
||||
phase_6_design_deliveries:
|
||||
status: "pending"
|
||||
reason: "Awaiting UX design completion"
|
||||
|
||||
# Current scenario tracking
|
||||
current_scenario:
|
||||
number: "1"
|
||||
name: "Landing Page Journey"
|
||||
status: "in-progress"
|
||||
pages:
|
||||
- number: "1.1"
|
||||
name: "Start Page"
|
||||
status: "in-progress"
|
||||
device: "desktop"
|
||||
completion: "60%"
|
||||
sections_complete:
|
||||
- "Hero Section"
|
||||
- "WDS Capabilities (Right Column)"
|
||||
sections_pending:
|
||||
- "Benefits Section"
|
||||
- "Main Content Section"
|
||||
- "Testimonials Section"
|
||||
- "CTA Section"
|
||||
- "Footer Section"
|
||||
|
||||
|
|
@ -20,6 +20,24 @@ project: "{{project_name}}"
|
|||
project_type: "{{project_type}}"
|
||||
workflow_path: "{{workflow_path_file}}"
|
||||
|
||||
# Project structure (defines folder organization)
|
||||
project_structure:
|
||||
type: "{{structure_type}}" # landing_page | simple_website | web_application
|
||||
scenarios: "{{structure_scenarios}}" # single | multiple
|
||||
pages: "{{structure_pages}}" # single | multiple
|
||||
# This determines how scenarios and pages are organized in 4-scenarios/
|
||||
|
||||
# Delivery configuration (what gets handed off)
|
||||
delivery:
|
||||
format: "{{delivery_format}}" # prd | wordpress | figma | prototype | direct-code | other
|
||||
target_platform: "{{target_platform}}" # wordpress | react | vue | html | custom
|
||||
requires_prd: {{requires_prd}} # true | false
|
||||
description: "{{delivery_description}}"
|
||||
# Examples:
|
||||
# - "WordPress page editor code with markup and content sections"
|
||||
# - "Complete PRD for development team"
|
||||
# - "Interactive Figma prototype"
|
||||
|
||||
# Configuration
|
||||
config:
|
||||
folder_prefix: "{{folder_prefix}}" # letters or numbers
|
||||
|
|
|
|||
|
|
@ -0,0 +1,617 @@
|
|||
# Sketch-First Workflow - Implementation Plan
|
||||
|
||||
**Feature**: Intelligent sketch-driven project initialization
|
||||
**Agents**: Mimer (Detection), Freyja (UX), Saga (Brief), Cascade (Trigger Map)
|
||||
**When**: User uploads sketch(es) to repository
|
||||
**Purpose**: Enable designers to start with sketches, build foundation retroactively
|
||||
**Vision**: From "15 wireframes in a folder" → "Complete WDS project with specs & prototypes"
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This plan establishes a **sketch-first initialization flow** where users can:
|
||||
1. Upload one or multiple sketches
|
||||
2. Get intelligent analysis and grouping
|
||||
3. Choose to build full WDS foundation or quick specs
|
||||
4. End with complete documentation, navigation, and prototypes
|
||||
|
||||
**Key Innovation**: Start with what's fun (sketching) → Agent guides to proper process
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Manual Trigger (Now - v1.0)
|
||||
|
||||
### **Core Principle: Human-in-Loop**
|
||||
|
||||
All processing requires manual trigger and human confirmation at every decision point.
|
||||
|
||||
### **Detection (Passive Monitoring)**
|
||||
|
||||
**What Agent Monitors:**
|
||||
```
|
||||
Watch folders:
|
||||
├── /sketches/
|
||||
├── /docs/*/sketches/
|
||||
├── /4-scenarios/*/sketches/
|
||||
└── Any configured sketch directories
|
||||
|
||||
Detects:
|
||||
├── New files added
|
||||
├── Files modified (date/size changed)
|
||||
├── Files renamed
|
||||
└── Files moved
|
||||
```
|
||||
|
||||
**Agent Behavior:**
|
||||
```
|
||||
User: [drops 5 sketches in /sketches/]
|
||||
|
||||
Mimer: "👋 Hey! I noticed some changes:
|
||||
|
||||
**New Sketches** (5):
|
||||
✨ landing-page.jpg
|
||||
✨ signin.jpg
|
||||
✨ dashboard.jpg
|
||||
✨ profile.jpg
|
||||
✨ settings.jpg
|
||||
|
||||
Would you like me to analyze them?
|
||||
|
||||
[Yes, analyze now] [Remind me later]"
|
||||
```
|
||||
|
||||
**User must trigger** - No automatic processing
|
||||
|
||||
---
|
||||
|
||||
### **Single Sketch Analysis**
|
||||
|
||||
**Workflow: workshop-a-sketch-to-page.md**
|
||||
|
||||
```
|
||||
User: [uploads landing-page.jpg]
|
||||
|
||||
Mimer: "I see a sketch! Activating Freyja..."
|
||||
|
||||
Freyja: "Hi! Let me analyze this sketch...
|
||||
|
||||
🔍 Analysis:
|
||||
- Landing page concept
|
||||
- Hero, features, testimonials, CTA
|
||||
- Looks like SaaS product
|
||||
|
||||
📋 Is this part of a larger project?
|
||||
[A] Yes, let's set up full WDS project
|
||||
[B] No, just specify this page
|
||||
[C] Let me think about it"
|
||||
|
||||
User: "A"
|
||||
|
||||
Freyja: "Perfect! Since this is a new project, let's
|
||||
build the foundation first.
|
||||
|
||||
I'll hand you to Saga for Product Brief,
|
||||
then we'll come back to spec this sketch
|
||||
with full context.
|
||||
|
||||
🎯 Activating Saga..."
|
||||
|
||||
→ Product Brief workflow
|
||||
→ Trigger Mapping workflow (if needed)
|
||||
→ Return to Freyja for page specification
|
||||
```
|
||||
|
||||
**Human confirms:**
|
||||
- ✅ Sketch interpretation (sections, objects)
|
||||
- ✅ Project scope (full WDS vs. quick spec)
|
||||
- ✅ Page naming and purpose
|
||||
- ✅ Content and translations
|
||||
- ✅ Final specification
|
||||
|
||||
---
|
||||
|
||||
### **Batch Sketch Analysis**
|
||||
|
||||
**Workflow: workshop-b-batch-sketch-analysis.md**
|
||||
|
||||
```
|
||||
User: [uploads 15 wireframes]
|
||||
|
||||
Mimer: "Whoa! I see 15 sketches! 🎨
|
||||
Let me analyze them all...
|
||||
|
||||
[Analyzing patterns and relationships...]
|
||||
|
||||
📊 **What I Found:**
|
||||
|
||||
**Scenario 1: User Onboarding** (6 pages)
|
||||
1. landing-page.jpg → Start/Hero
|
||||
2. signin.jpg → Authentication
|
||||
3. profile-setup.jpg → Profile creation
|
||||
4. family-setup.jpg → Family info
|
||||
5. dog-profile.jpg → Add dog
|
||||
6. dashboard.jpg → Success/overview
|
||||
|
||||
**Scenario 2: Daily Features** (7 pages)
|
||||
7. calendar-view.jpg → Schedule
|
||||
...
|
||||
|
||||
**Standalone** (2 pages)
|
||||
14. about.jpg
|
||||
15. contact.jpg
|
||||
|
||||
🤔 **Questions:**
|
||||
1. Did I group these correctly?
|
||||
2. Ready to build full WDS project?
|
||||
3. Want to adjust grouping first?"
|
||||
|
||||
User: "Grouping looks good. Let's build the project!"
|
||||
|
||||
Mimer: "Perfect! Here's the plan:
|
||||
|
||||
**Phase 1: Foundation** (10 min)
|
||||
→ Saga: Product Brief (using sketch 1 as context)
|
||||
→ Cascade: Trigger Map (validating against sketches)
|
||||
|
||||
**Phase 2: Structure** (5 min)
|
||||
→ Create scenario folders
|
||||
→ Map sketches to pages
|
||||
→ Establish navigation flow
|
||||
|
||||
**Phase 3: Specification** (iterative)
|
||||
→ Freyja analyzes each sketch
|
||||
→ You review and refine
|
||||
|
||||
**Phase 4: Prototypes** (automatic)
|
||||
→ Generate interactive HTML prototypes
|
||||
→ Link all pages together
|
||||
→ Create clickable flows
|
||||
|
||||
**Result:**
|
||||
✅ Complete WDS project
|
||||
✅ All 15 pages documented
|
||||
✅ All 15 pages prototyped
|
||||
✅ Navigation mapped
|
||||
✅ Interactive demo
|
||||
✅ Ready for development & testing
|
||||
|
||||
Let's start! [Begin] [Adjust plan]"
|
||||
|
||||
User: "Begin"
|
||||
|
||||
→ Full workflow execution with human confirmation at key points
|
||||
```
|
||||
|
||||
**Human confirms:**
|
||||
- ✅ Scenario grouping (can adjust)
|
||||
- ✅ Page naming and sequence
|
||||
- ✅ Each sketch interpretation
|
||||
- ✅ Phase completion before proceeding
|
||||
|
||||
---
|
||||
|
||||
### **Iterative Page Updates**
|
||||
|
||||
**Workflow: workshop-c-page-update.md**
|
||||
|
||||
```
|
||||
User: [uploads landing-page-v2.jpg]
|
||||
|
||||
Freyja: "I see we already have specs for Landing Page.
|
||||
Let me compare this to version 1...
|
||||
|
||||
🔍 **Changes detected:**
|
||||
✅ Hero section - unchanged
|
||||
✅ Feature Cards - unchanged
|
||||
➕ Feature Card 3 - NOW COMPLETE (was TBD)
|
||||
✏️ Header - NEW: Search bar with filters
|
||||
➕ Footer - NOW COMPLETE (was blank)
|
||||
|
||||
Should I:
|
||||
[A] Update all changed sections
|
||||
[B] Pick specific sections to update
|
||||
[C] Show me detailed comparison first"
|
||||
|
||||
User: "A"
|
||||
|
||||
Freyja: "Great! I'll update:
|
||||
1. Add search bar specs to Header
|
||||
2. Complete Feature Card 3
|
||||
3. Generate Footer specifications
|
||||
|
||||
Preserving existing:
|
||||
✅ Hero (no changes)
|
||||
✅ Feature Cards 1-2 (no changes)
|
||||
|
||||
Ready to proceed? [Yes/Adjust]"
|
||||
|
||||
User: "Yes"
|
||||
|
||||
→ Updates only changed sections, preserves rest
|
||||
```
|
||||
|
||||
**Human confirms:**
|
||||
- ✅ Change detection accuracy
|
||||
- ✅ Which sections to update
|
||||
- ✅ New specifications
|
||||
- ✅ Preserved sections remain unchanged
|
||||
|
||||
---
|
||||
|
||||
### **Configuration (v1.0)**
|
||||
|
||||
```yaml
|
||||
# wds-workflow-status.yaml
|
||||
|
||||
sketch_monitoring:
|
||||
enabled: true
|
||||
watch_folders:
|
||||
- "sketches/"
|
||||
- "4-scenarios/**/sketches/"
|
||||
detection_mode: "passive" # Detects but doesn't process
|
||||
notification_mode: "proactive" # Alerts user immediately
|
||||
auto_process: false # Requires manual trigger
|
||||
human_confirmation: "all" # Every decision needs confirmation
|
||||
batch_threshold: 5 # Group if 5+ sketches detected
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Semi-Auto (Future - v1.5-2.0)
|
||||
|
||||
### **Enhanced Detection**
|
||||
|
||||
**Smart Categorization:**
|
||||
```
|
||||
Agent behavior:
|
||||
├── 👀 Monitor: Continuous detection
|
||||
├── 🧠 Analyze: Auto-categorize when idle
|
||||
├── 📋 Queue: Store results for review
|
||||
├── 🔔 Notify: "Ready for your review"
|
||||
└── 🤝 Review: Human approves/adjusts
|
||||
|
||||
New sketch detected: payment-flow.jpg
|
||||
├─ Check: Matching page spec exists?
|
||||
│ ├─ YES → "Updated sketch for existing page"
|
||||
│ └─ NO → "New sketch, needs page creation"
|
||||
│
|
||||
├─ Check: Name suggests scenario?
|
||||
│ ├─ "payment-flow" → Could be new scenario
|
||||
│ └─ "landing-v2" → Update to existing
|
||||
│
|
||||
├─ Check: Where was it added?
|
||||
│ ├─ /4-scenarios/2-checkout/ → Part of existing scenario
|
||||
│ └─ /sketches/ → Needs placement
|
||||
│
|
||||
└─ Confidence Level:
|
||||
├─ High → Can suggest auto-processing
|
||||
└─ Low → Requires manual review
|
||||
```
|
||||
|
||||
**Smart Batching:**
|
||||
```
|
||||
Agent groups by:
|
||||
├── Related scenarios
|
||||
├── Update vs. new
|
||||
├── Priority (core pages first)
|
||||
└── Dependencies (flows must be sequential)
|
||||
|
||||
Example:
|
||||
Batch 1: "Core Flow Updates" (3 sketches - HIGH priority)
|
||||
→ Existing pages, quick updates
|
||||
→ Estimated: 10 minutes
|
||||
→ [Auto-process] [Review first] [Skip]
|
||||
|
||||
Batch 2: "New Booking Feature" (8 sketches - MEDIUM priority)
|
||||
→ New scenario, full specification
|
||||
→ Estimated: 30 minutes
|
||||
→ [Auto-process] [Review first] [Later]
|
||||
```
|
||||
|
||||
**Auto-Analysis During Idle:**
|
||||
```
|
||||
Agent: "While you were away, I analyzed 5 sketches.
|
||||
Here's what I found. Please review:
|
||||
|
||||
Sketch 1: landing-page.jpg
|
||||
├── Sections: Hero, Features, CTA
|
||||
├── Status: Ready for spec
|
||||
├── Confidence: High ✅
|
||||
└── [Approve] [Adjust] [Reject]
|
||||
|
||||
Sketch 2: dashboard.jpg
|
||||
├── Sections: Complex layout detected
|
||||
├── Status: Needs clarification
|
||||
├── Confidence: Medium ⚠️
|
||||
└── [Manual Review Required]
|
||||
|
||||
[Approve All High-Confidence] [Review Each]"
|
||||
```
|
||||
|
||||
**Why Later:**
|
||||
- ⚠️ Requires mature AI with proven accuracy
|
||||
- ⚠️ Risk of incorrect auto-interpretation
|
||||
- ✅ Saves time on obvious cases
|
||||
- ✅ Human still reviews all decisions
|
||||
|
||||
---
|
||||
|
||||
### **Configuration (v1.5-2.0)**
|
||||
|
||||
```yaml
|
||||
sketch_monitoring:
|
||||
enabled: true
|
||||
detection_mode: "active" # Processes when idle
|
||||
notification_mode: "batch_summary" # Summarizes results
|
||||
auto_analysis: true # Analyzes during idle time
|
||||
auto_process: false # Still requires approval
|
||||
human_confirmation: "changes" # Only for modifications
|
||||
confidence_threshold: 0.85 # High confidence threshold
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Full Auto (Far Future - v3.0+)
|
||||
|
||||
### **Autonomous Processing**
|
||||
|
||||
**Only when:**
|
||||
- ⚠️ Extremely high AI accuracy (>95%)
|
||||
- ⚠️ User explicitly opts in
|
||||
- ⚠️ Well-established patterns in project
|
||||
- ✅ Full audit trail available
|
||||
- ✅ Easy rollback mechanism
|
||||
|
||||
```
|
||||
Agent behavior:
|
||||
├── 👀 Monitor: Continuous
|
||||
├── 🤖 Process: Fully automatic
|
||||
├── ✅ Execute: Generate specs & prototypes
|
||||
├── 📧 Notify: "5 pages completed"
|
||||
└── 🔄 Review: "Review when ready"
|
||||
|
||||
Example:
|
||||
Agent: "I processed 5 sketches automatically:
|
||||
|
||||
✅ 5 specifications generated
|
||||
✅ 5 prototypes created
|
||||
✅ Navigation updated
|
||||
✅ Tests passed
|
||||
|
||||
📋 Review PR #47 when ready.
|
||||
|
||||
All changes are in a branch for your review."
|
||||
```
|
||||
|
||||
**Why Far Future:**
|
||||
- ⚠️ Requires extremely high accuracy
|
||||
- ⚠️ Less learning for user
|
||||
- ⚠️ Could miss important context
|
||||
- ⚠️ Only for mature, well-established projects
|
||||
|
||||
---
|
||||
|
||||
## Workflows to Create
|
||||
|
||||
### **Immediate (v1.0)**
|
||||
|
||||
1. **workshop-a-sketch-to-page.md**
|
||||
- Single sketch → page specification
|
||||
- Context detection (new vs. existing project)
|
||||
- Routes to Product Brief if needed
|
||||
- Full human-in-loop
|
||||
|
||||
2. **workshop-b-batch-sketch-analysis.md**
|
||||
- Multiple sketches → scenario grouping
|
||||
- Pattern recognition & relationship detection
|
||||
- Smart grouping with user confirmation
|
||||
- Complete project initialization
|
||||
|
||||
3. **workshop-c-page-update.md**
|
||||
- Updated sketch → incremental update
|
||||
- Change detection & comparison
|
||||
- Selective section updates
|
||||
- Preserve unchanged specifications
|
||||
|
||||
4. **page-init-lightweight.md**
|
||||
- Quick page setup: name, purpose, navigation
|
||||
- Create folder structure
|
||||
- Generate placeholder with navigation
|
||||
- Ready for sketch analysis
|
||||
|
||||
### **Future (v1.5+)**
|
||||
|
||||
5. **smart-batch-processor.md**
|
||||
- Auto-categorization during idle
|
||||
- Confidence-based suggestions
|
||||
- Queue for review
|
||||
|
||||
6. **change-detection-engine.md**
|
||||
- Advanced visual comparison
|
||||
- Semantic diff understanding
|
||||
- Smart merge strategies
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### **v1.0 (Manual Trigger)**
|
||||
- ✅ Detection accuracy: 100% (all sketches found)
|
||||
- ✅ User triggers: 100% required
|
||||
- ✅ Confirmation points: All decisions
|
||||
- ✅ Time saved: 50% vs. manual documentation
|
||||
|
||||
### **v1.5 (Semi-Auto)**
|
||||
- ✅ Analysis accuracy: 85%+
|
||||
- ✅ Auto-categorization: 80%+
|
||||
- ✅ Human review: All results
|
||||
- ✅ Time saved: 70% vs. manual
|
||||
|
||||
### **v2.0+ (Full Auto)**
|
||||
- ✅ Processing accuracy: 95%+
|
||||
- ✅ Auto-approval: High confidence only
|
||||
- ✅ Human review: Available
|
||||
- ✅ Time saved: 90% vs. manual
|
||||
|
||||
---
|
||||
|
||||
## Benefits
|
||||
|
||||
### **For Designers**
|
||||
- ✅ Start with fun part (sketching)
|
||||
- ✅ Agent builds foundation retroactively
|
||||
- ✅ Complete documentation from wireframes
|
||||
- ✅ Interactive prototypes automatically
|
||||
|
||||
### **For Teams**
|
||||
- ✅ Consistent documentation
|
||||
- ✅ Navigable specifications
|
||||
- ✅ Development-ready handoffs
|
||||
- ✅ Testable prototypes
|
||||
|
||||
### **For Process**
|
||||
- ✅ Lower barrier to entry
|
||||
- ✅ Encourages proper documentation
|
||||
- ✅ Validates designs against strategy
|
||||
- ✅ Creates institutional knowledge
|
||||
|
||||
---
|
||||
|
||||
## Implementation Priority
|
||||
|
||||
### **Now (Week 1-2)**
|
||||
1. Passive sketch detection (Mimer)
|
||||
2. Single sketch analysis workflow (Freyja)
|
||||
3. Page init lightweight (navigation setup)
|
||||
4. Basic change detection
|
||||
|
||||
### **Soon (Week 3-4)**
|
||||
5. Batch sketch analysis
|
||||
6. Smart scenario grouping
|
||||
7. Complete project initialization
|
||||
8. Prototype generation integration
|
||||
|
||||
### **Later (Month 2-3)**
|
||||
9. Auto-analysis during idle
|
||||
10. Confidence-based suggestions
|
||||
11. Smart batching
|
||||
12. Advanced change detection
|
||||
|
||||
---
|
||||
|
||||
## Technical Requirements
|
||||
|
||||
### **Detection System**
|
||||
- File system watcher
|
||||
- Pattern matching (new/modified/moved)
|
||||
- Folder configuration (watch list)
|
||||
- Event throttling (batch rapid changes)
|
||||
|
||||
### **Analysis Engine**
|
||||
- Image analysis (if AI vision available)
|
||||
- Pattern recognition (grouping similar pages)
|
||||
- Relationship detection (flow connections)
|
||||
- Confidence scoring
|
||||
|
||||
### **Human-in-Loop Interface**
|
||||
- Clear confirmation points
|
||||
- Visual diffs (old vs. new)
|
||||
- Batch approval options
|
||||
- Undo/rollback capability
|
||||
|
||||
### **Integration Points**
|
||||
- Existing sketch analysis workflow (4b-sketch-analysis.md)
|
||||
- Product Brief workflow (Saga)
|
||||
- Trigger Map workflow (Cascade)
|
||||
- Prototype generation
|
||||
|
||||
---
|
||||
|
||||
## Configuration Example
|
||||
|
||||
```yaml
|
||||
# wds-workflow-status.yaml
|
||||
|
||||
# Phase 1: Manual Trigger (v1.0)
|
||||
sketch_workflow:
|
||||
version: "1.0"
|
||||
mode: "manual-trigger"
|
||||
|
||||
monitoring:
|
||||
enabled: true
|
||||
watch_folders:
|
||||
- "sketches/"
|
||||
- "4-scenarios/**/sketches/"
|
||||
detect_changes: true
|
||||
notify_user: true
|
||||
|
||||
processing:
|
||||
auto_analyze: false # Requires manual trigger
|
||||
auto_process: false # Requires approval
|
||||
human_confirmation: "all" # Every decision point
|
||||
|
||||
batching:
|
||||
enabled: true
|
||||
threshold: 5 # Group if 5+ sketches
|
||||
suggest_grouping: true # Show suggested groups
|
||||
require_approval: true # User must approve
|
||||
|
||||
workflows:
|
||||
single_sketch: "workshop-a-sketch-to-page.md"
|
||||
batch_sketches: "workshop-b-batch-sketch-analysis.md"
|
||||
page_update: "workshop-c-page-update.md"
|
||||
page_init: "page-init-lightweight.md"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Guardrails
|
||||
|
||||
### **Always Required**
|
||||
- ✅ User triggers all processing
|
||||
- ✅ Human confirms all interpretations
|
||||
- ✅ Clear undo/rollback mechanism
|
||||
- ✅ Audit trail of all changes
|
||||
- ✅ Preserve user's work
|
||||
|
||||
### **Never Allowed**
|
||||
- ❌ Auto-process without trigger
|
||||
- ❌ Auto-approve without review
|
||||
- ❌ Overwrite without confirmation
|
||||
- ❌ Delete user's specifications
|
||||
- ❌ Skip confirmation points
|
||||
|
||||
---
|
||||
|
||||
**Created**: December 28, 2025
|
||||
**Feature Owner**: Freyja (UX), Mimer (Detection)
|
||||
**Status**: Planning Complete → Ready for Implementation
|
||||
**Next Step**: Create v1.0 workflows (manual trigger, human-in-loop)
|
||||
|
||||
---
|
||||
|
||||
## Summary: From Sketches to Specs
|
||||
|
||||
```
|
||||
Before:
|
||||
├── 15 random wireframes in a folder
|
||||
├── No documentation
|
||||
├── No structure
|
||||
└── "Now what?"
|
||||
|
||||
After (v1.0):
|
||||
├── Complete WDS project
|
||||
├── All pages documented with specs
|
||||
├── Proper navigation between pages
|
||||
├── Interactive prototypes
|
||||
├── Strategic foundation (Brief + Trigger Map)
|
||||
└── Ready for development & testing
|
||||
|
||||
Time: 1-2 hours vs. 2-3 days manual
|
||||
Quality: Consistent, complete, navigable
|
||||
Experience: Start with fun, end with foundation
|
||||
```
|
||||
|
||||
**The Magic**: Agent detects → User triggers → Human confirms → Complete project! 🎨→📋→💻
|
||||
|
||||
|
|
@ -39,12 +39,12 @@ Does CONTENT vary by page context?
|
|||
❌ Wrong: Features/hero-logic.feature.md
|
||||
**Content:**
|
||||
|
||||
- Heading: "Welcome to Dog Week" (Home page)
|
||||
- Heading: "About Dog Week" (About page)
|
||||
- Heading: "Welcome to TaskFlow" (Home page)
|
||||
- Heading: "About TaskFlow" (About page)
|
||||
|
||||
✅ Right: Put in respective Page files
|
||||
Pages/01-home-page.md → "Welcome to Dog Week"
|
||||
Pages/02-about-page.md → "About Dog Week"
|
||||
Pages/01-home-page.md → "Welcome to TaskFlow"
|
||||
Pages/02-about-page.md → "About TaskFlow"
|
||||
```
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ A **storyboard** is a visual sequence showing:
|
|||
- Easy to iterate
|
||||
- Focus on functionality, not polish
|
||||
|
||||
**Example:** Dog Week `App-Main-Booking-States.jpg`
|
||||
**Example:** TaskFlow `task-status-states.jpg`
|
||||
|
||||
- 6 frames showing walk states
|
||||
- Numbered sequentially
|
||||
|
|
|
|||
|
|
@ -8,23 +8,23 @@
|
|||
|
||||
✅ **Components with 3+ states**
|
||||
|
||||
- Example (Dog Week): Walk slots (WHITE, GRAY, ORANGE, BLUE, GREEN, RED)
|
||||
- Example (TaskFlow): Task status (TODO, IN_PROGRESS, BLOCKED, DONE, ARCHIVED)
|
||||
|
||||
✅ **Time-based transitions**
|
||||
|
||||
- Example (Dog Week): Countdown timers, auto-state changes
|
||||
- Example (TaskFlow): Deadline reminders, auto-status updates
|
||||
|
||||
✅ **Multi-step user flows**
|
||||
|
||||
- Example (Dog Week): Booking → Starting → Completing a walk
|
||||
- Example (TaskFlow): Creating → Assigning → Completing a task
|
||||
|
||||
✅ **Complex interactions between components**
|
||||
|
||||
- Example (Dog Week): Calendar updates leaderboard and week view
|
||||
- Example (TaskFlow): Task completion updates dashboard and team notifications
|
||||
|
||||
✅ **State machines with branching paths**
|
||||
|
||||
- Example (Dog Week): Success path vs error path vs timeout path
|
||||
- Example (TaskFlow): Happy path vs validation error vs timeout
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -48,7 +48,7 @@
|
|||
|
||||
### Need Storyboard:
|
||||
|
||||
- **Dog Week:** Calendar booking (6 states, time-based)
|
||||
- **TaskFlow:** Task status board (5 states, time-based reminders)
|
||||
- **Future Project:** Search with autocomplete (5 states, real-time)
|
||||
- **Future Project:** Multi-step form (progress tracking)
|
||||
- **Future Project:** Payment flow (multiple steps, error handling)
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ C) Skip for now, mark as TODO
|
|||
|
||||
---
|
||||
|
||||
## Example: Dog Week Calendar Page
|
||||
## Example: TaskFlow Calendar Page
|
||||
|
||||
### Full Workflow
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Visual state references
|
|||
|
||||
## Examples
|
||||
|
||||
### [Dog Week Calendar States](examples/calendar-states.md)
|
||||
### [TaskFlow Task States](examples/task-states.md)
|
||||
|
||||
6-state walk booking storyboard
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,318 @@
|
|||
# Page Specification Quality Workflow
|
||||
|
||||
**Purpose:** Ensure every WDS page specification meets quality standards with complete structure, Object IDs, and traceability.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This Workflow
|
||||
|
||||
### During Page Creation ✨
|
||||
Use this workflow step-by-step to build specifications correctly from the start:
|
||||
- Creating a new page specification from a sketch
|
||||
- Converting rough notes into proper spec format
|
||||
- Building specs incrementally as design evolves
|
||||
|
||||
### After Page Updates 🔄
|
||||
Use this workflow to validate changes maintain standards:
|
||||
- Updated sketch with new elements
|
||||
- Content revisions
|
||||
- Added sections or components
|
||||
- Design iteration
|
||||
|
||||
### Quality Audits 🔍
|
||||
Use this workflow to check existing specifications:
|
||||
- Pre-handoff quality check
|
||||
- Sprint review preparation
|
||||
- Onboarding new team members
|
||||
- Fixing legacy specs
|
||||
|
||||
---
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
This workflow consists of 5 sequential steps:
|
||||
|
||||
```
|
||||
Step 1: Navigation Structure
|
||||
↓
|
||||
Step 2: Page Overview
|
||||
↓
|
||||
Step 3: Page Sections & Objects
|
||||
↓
|
||||
Step 4: Object Registry
|
||||
↓
|
||||
Step 5: Final Validation
|
||||
```
|
||||
|
||||
Each step focuses on one structural element to ensure nothing is missed.
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
### For Freyja (AI Agent)
|
||||
|
||||
<action>Load and execute: instructions.md</action>
|
||||
|
||||
This will start the sequential workflow, automatically progressing through each step.
|
||||
|
||||
### For Human Designers
|
||||
|
||||
1. **Open your page specification**
|
||||
2. **Start at Step 1** (Navigation Structure)
|
||||
3. **Work through each step sequentially**
|
||||
4. **Use the checklists** to validate each section
|
||||
5. **Generate quality report** at Step 5
|
||||
|
||||
---
|
||||
|
||||
## What This Workflow Checks
|
||||
|
||||
### ✅ Navigation Structure (Step 1)
|
||||
- H3 and H1 headers with page numbers
|
||||
- "Next Step" links before and after sketch
|
||||
- Embedded sketch image
|
||||
- Correct relative paths
|
||||
|
||||
### ✅ Page Overview (Step 2)
|
||||
- Page description (1-2 paragraphs)
|
||||
- User Situation section
|
||||
- Page Purpose section
|
||||
- Emotional context and pain points
|
||||
|
||||
### ✅ Page Sections (Step 3)
|
||||
- "## Page Sections" header
|
||||
- Section Objects (H3) with Purpose
|
||||
- Component specs (H4) with Object IDs
|
||||
- Design system links
|
||||
- Content specifications
|
||||
- Behavior specifications
|
||||
|
||||
### ✅ Object Registry (Step 4)
|
||||
- "## Object Registry" header
|
||||
- Introduction paragraph
|
||||
- Master Object List tables
|
||||
- 100% coverage of all Object IDs
|
||||
- Proper table formatting
|
||||
|
||||
### ✅ Final Validation (Step 5)
|
||||
- Cross-reference all sections
|
||||
- Verify sketch coverage
|
||||
- Check for broken links
|
||||
- Validate naming conventions
|
||||
- Generate quality report
|
||||
|
||||
---
|
||||
|
||||
## Example: Standard WDS Pattern
|
||||
|
||||
This workflow ensures all WDS page specifications follow a consistent, high-quality pattern.
|
||||
|
||||
**Key Pattern Elements:**
|
||||
- Clear navigation with scenario context
|
||||
- Embedded sketch images
|
||||
- Section Objects with Purpose statements
|
||||
- Component specs with Object IDs
|
||||
- Complete Object Registry table
|
||||
- Design system component links
|
||||
|
||||
---
|
||||
|
||||
## Output: Quality Report
|
||||
|
||||
At the end of Step 5, you'll have:
|
||||
|
||||
**Comprehensive Quality Report** including:
|
||||
- Pass/Fail status for each section
|
||||
- List of critical issues (must fix)
|
||||
- List of warnings (should fix)
|
||||
- List of recommendations (nice to have)
|
||||
- Object ID audit (duplicates, missing, orphans)
|
||||
- Sketch coverage analysis (missing elements)
|
||||
- Broken links report
|
||||
- Next actions for handoff
|
||||
|
||||
**Report Status Levels:**
|
||||
- ✅ **READY FOR HANDOFF** - Zero critical issues, ready for dev
|
||||
- ⚠️ **NEEDS REVISION** - 1-3 critical issues, fixable quickly
|
||||
- ❌ **INCOMPLETE** - 4+ critical issues, needs substantial work
|
||||
|
||||
---
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### Use Case 1: New Page from Sketch
|
||||
|
||||
**Scenario:** Designer uploads a new sketch and needs to create specification.
|
||||
|
||||
**Process:**
|
||||
1. Run Step 1: Generate navigation structure
|
||||
2. Run Step 2: Define page overview based on trigger map
|
||||
3. Run Step 3: Analyze sketch, create sections and Object IDs
|
||||
4. Run Step 4: Auto-generate Object Registry from sections
|
||||
5. Run Step 5: Validate and generate report
|
||||
|
||||
**Outcome:** Complete, validated specification ready for handoff.
|
||||
|
||||
---
|
||||
|
||||
### Use Case 2: Updated Sketch
|
||||
|
||||
**Scenario:** Designer updates existing sketch with new elements.
|
||||
|
||||
**Process:**
|
||||
1. Skip to Step 3: Check existing sections
|
||||
2. Add new sections/objects from updated sketch
|
||||
3. Run Step 4: Update Object Registry with new IDs
|
||||
4. Run Step 5: Validate changes and generate report
|
||||
|
||||
**Outcome:** Updated specification with change tracking.
|
||||
|
||||
---
|
||||
|
||||
### Use Case 3: Quality Audit Before Handoff
|
||||
|
||||
**Scenario:** Team lead wants to verify spec quality before developer handoff.
|
||||
|
||||
**Process:**
|
||||
1. Run entire workflow in "validation mode"
|
||||
2. Step 1-4: Check each section against checklists
|
||||
3. Step 5: Generate comprehensive quality report
|
||||
4. Share report with team, fix critical issues
|
||||
5. Re-run Step 5 after fixes
|
||||
|
||||
**Outcome:** Confidence in specification completeness.
|
||||
|
||||
---
|
||||
|
||||
### Use Case 4: Fixing Legacy Spec
|
||||
|
||||
**Scenario:** Old specification doesn't follow WDS standards.
|
||||
|
||||
**Process:**
|
||||
1. Run Step 1-4 in "validation mode" to identify gaps
|
||||
2. Fix missing navigation structure
|
||||
3. Add missing Object IDs to all interactive elements
|
||||
4. Create Object Registry if missing
|
||||
5. Run Step 5 to verify all issues resolved
|
||||
|
||||
**Outcome:** Legacy spec brought up to current standards.
|
||||
|
||||
---
|
||||
|
||||
## Benefits
|
||||
|
||||
### For Designers 🎨
|
||||
- Clear checklist to follow
|
||||
- Confidence nothing is missed
|
||||
- Professional, consistent output
|
||||
- Easy communication with developers
|
||||
|
||||
### For Developers 💻
|
||||
- Complete, trustworthy specifications
|
||||
- All interactive elements have Object IDs
|
||||
- Clear implementation order (top to bottom)
|
||||
- Easy to test (Object IDs as test targets)
|
||||
|
||||
### For Teams 👥
|
||||
- Shared quality standards
|
||||
- Consistent specification format
|
||||
- Easy onboarding for new members
|
||||
- Reduced back-and-forth during handoff
|
||||
|
||||
### For Project Management 📊
|
||||
- Clear completion criteria
|
||||
- Quality metrics tracking
|
||||
- Reduced rework
|
||||
- Faster handoffs
|
||||
|
||||
---
|
||||
|
||||
## Integration with WDS Workflows
|
||||
|
||||
This quality workflow integrates with:
|
||||
|
||||
**Before:**
|
||||
- [Page Init Workflow](../steps/step-02-substeps/page-init/) - Creates initial page structure
|
||||
- [Sketch Analysis](../substeps/4b-sketch-analysis.md) - Identifies page elements
|
||||
|
||||
**After:**
|
||||
- [Interactive Prototypes](../interactive-prototypes/) - Builds HTML demos from specs
|
||||
- [Design Deliveries](../../../6-design-deliveries/) - Packages specs for handoff
|
||||
- [PRD Generation](../../../3-prd-platform/) - Creates developer stories from specs
|
||||
|
||||
---
|
||||
|
||||
## Tips for Success
|
||||
|
||||
### Do:
|
||||
- ✅ Run the workflow every time you create or update a page
|
||||
- ✅ Use checklists systematically (don't skip items)
|
||||
- ✅ Fix critical issues before proceeding to next step
|
||||
- ✅ Save quality reports for project history
|
||||
- ✅ Track metrics over time to improve process
|
||||
|
||||
### Don't:
|
||||
- ❌ Skip steps (each builds on the previous)
|
||||
- ❌ Ignore warnings (they become critical issues later)
|
||||
- ❌ Rush through validation (thoroughness matters)
|
||||
- ❌ Mix validation with creation (separate concerns)
|
||||
- ❌ Forget to re-validate after fixes
|
||||
|
||||
---
|
||||
|
||||
## Customization
|
||||
|
||||
### For Your Project
|
||||
|
||||
You can customize this workflow by:
|
||||
|
||||
**Adjusting Standards:**
|
||||
- Modify Object ID naming conventions
|
||||
- Add project-specific sections
|
||||
- Extend validation checklists
|
||||
- Add custom quality metrics
|
||||
|
||||
**Adding Steps:**
|
||||
- Step 3.5: Accessibility audit
|
||||
- Step 4.5: Content strategy review
|
||||
- Step 5.5: Stakeholder approval
|
||||
|
||||
**Location:**
|
||||
Customizations should be documented in:
|
||||
`/examples/[PROJECT]/docs/quality-standards.md`
|
||||
|
||||
---
|
||||
|
||||
## Support
|
||||
|
||||
### Questions or Issues?
|
||||
|
||||
**Documentation:**
|
||||
- [WDS Specification Pattern](../WDS-SPECIFICATION-PATTERN.md)
|
||||
- [Object Types](../object-types/)
|
||||
- [Component File Structure](../COMPONENT-FILE-STRUCTURE.md)
|
||||
|
||||
**Examples:**
|
||||
- See fictional TaskFlow examples in workflow steps
|
||||
- Check existing WDS project specifications for real-world patterns
|
||||
|
||||
**Contact:**
|
||||
- File issues in project repo
|
||||
- Discuss in team channel
|
||||
- Reference this workflow in PRs
|
||||
|
||||
---
|
||||
|
||||
## Version History
|
||||
|
||||
**v1.0.0** - 2025-12-28
|
||||
- Initial release
|
||||
- Pattern extracted from successful WDS projects
|
||||
- 6-step sequential workflow
|
||||
- Quality report generation
|
||||
|
||||
---
|
||||
|
||||
**Start the workflow:** [instructions.md](instructions.md)
|
||||
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
# Page Specification Quality Workflow
|
||||
|
||||
**Purpose:** Ensure every page specification follows WDS standards with complete structure, Object IDs, and traceability.
|
||||
|
||||
**Use Cases:**
|
||||
1. **During Page Creation** - Build specs correctly from the start
|
||||
2. **After Page Updates** - Validate changes maintain standards
|
||||
3. **Quality Audit** - Check existing specs for missing elements
|
||||
|
||||
---
|
||||
|
||||
## Process Overview
|
||||
|
||||
This workflow guides you through creating or validating a page specification step by step. Each step focuses on one structural element to ensure nothing is missed.
|
||||
|
||||
**Sequential Flow:** Each step must be completed before moving to the next.
|
||||
|
||||
---
|
||||
|
||||
## Workflow Steps
|
||||
|
||||
<action>Load and execute: step-01-navigation.md</action>
|
||||
|
||||
|
|
@ -0,0 +1,239 @@
|
|||
# Step 1: Navigation Structure
|
||||
|
||||
**Purpose:** Establish clear page context and navigation paths at the top of the specification.
|
||||
|
||||
---
|
||||
|
||||
## What Navigation Provides
|
||||
|
||||
**For Designers:**
|
||||
- Immediately understand where this page fits in the scenario
|
||||
- See the path forward (next page) without reading entire spec
|
||||
- Context for user journey and flow
|
||||
|
||||
**For Developers:**
|
||||
- Clear routing requirements
|
||||
- Navigation implementation specs
|
||||
- Page hierarchy understanding
|
||||
|
||||
**For Project Management:**
|
||||
- Scenario structure visibility
|
||||
- Completion tracking
|
||||
- Flow dependencies
|
||||
|
||||
---
|
||||
|
||||
## Standard Format
|
||||
|
||||
### Required Elements
|
||||
|
||||
```markdown
|
||||
### [Scenario Number].[Page Number] [Page Name]
|
||||
|
||||
**Next Step**: → [Next Page Name](relative/path/to/next-page.md)
|
||||
|
||||
|
||||
|
||||
**Next Step**: → [Next Page Name](relative/path/to/next-page.md)
|
||||
|
||||
# [Scenario Number].[Page Number] [Page Name]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Format Example (Fictional Project)
|
||||
|
||||
```markdown
|
||||
### 1.1 Home Page
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
# 1.1 Home Page
|
||||
```
|
||||
|
||||
**Why Repeated Next Step?**
|
||||
- First instance: Immediate context before visual
|
||||
- Second instance: Natural progression after viewing sketch
|
||||
|
||||
---
|
||||
|
||||
## Creation Instructions
|
||||
|
||||
<if condition="Creating new specification">
|
||||
|
||||
### Extract Context
|
||||
|
||||
1. **Determine page numbering:**
|
||||
- Single page project: Use `1.1-page-name`
|
||||
- Single scenario: `1.1`, `1.2`, `1.3` (sequential pages)
|
||||
- Multiple scenarios: `1.1`, `1.2` (scenario 1), `2.1`, `2.2` (scenario 2)
|
||||
|
||||
2. **Identify next page:**
|
||||
- Review scenario structure
|
||||
- Find the logical next step in user flow
|
||||
- **Cross-scenario navigation:** If last page of scenario connects naturally to next scenario, link to first page of next scenario
|
||||
- **Journey end:** Only the final page of the final scenario has no "Next Step"
|
||||
|
||||
3. **Locate sketch file:**
|
||||
- Check `/sketches/` subfolder
|
||||
- Use format: `sketches/[scenario]-[page]-[variant].jpg`
|
||||
|
||||
### Generate Navigation Block
|
||||
|
||||
<output>
|
||||
Generate the complete navigation block following the standard format.
|
||||
|
||||
**Template Variables:**
|
||||
- `{scenario}`: Scenario number
|
||||
- `{page}`: Page number
|
||||
- `{page_name}`: Human-readable page name
|
||||
- `{next_page_name}`: Name of next page in flow
|
||||
- `{next_page_path}`: Relative path to next page .md file
|
||||
- `{sketch_filename}`: Sketch file name with extension
|
||||
- `{sketch_description}`: Brief description of what sketch shows
|
||||
|
||||
**Output Format:**
|
||||
```markdown
|
||||
### {scenario}.{page} {page_name}
|
||||
|
||||
**Next Step**: → [{next_page_name}]({next_page_path})
|
||||
|
||||
|
||||
|
||||
**Next Step**: → [{next_page_name}]({next_page_path})
|
||||
|
||||
# {scenario}.{page} {page_name}
|
||||
```
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Quality Check Instructions
|
||||
|
||||
<if condition="Analyzing existing specification">
|
||||
|
||||
### Navigation Checklist
|
||||
|
||||
Run through each item. Report any failures.
|
||||
|
||||
**Required Elements:**
|
||||
|
||||
- [ ] **H3 header** with page number and name (`### X.X Page Name`)
|
||||
- [ ] **First "Next Step"** link (before sketch)
|
||||
- [ ] **Embedded sketch image** with descriptive alt text
|
||||
- [ ] **Second "Next Step"** link (after sketch)
|
||||
- [ ] **H1 header** with page number and name (same as H3)
|
||||
|
||||
**Path Validation:**
|
||||
|
||||
- [ ] Next Step path uses **relative path** format
|
||||
- [ ] Next Step path points to existing `.md` file
|
||||
- [ ] Sketch path uses **relative path** from current file
|
||||
- [ ] Sketch file exists in specified location
|
||||
|
||||
**Naming Consistency:**
|
||||
|
||||
- [ ] H3 and H1 have **identical** page number
|
||||
- [ ] H3 and H1 have **identical** page name
|
||||
- [ ] Page number follows project structure (scenario.page)
|
||||
|
||||
**Edge Cases:**
|
||||
|
||||
- [ ] **Last page in scenario:** Include "Next Step" link to first page of next scenario if flow continues naturally
|
||||
- [ ] **Last page in final scenario:** "Next Step" should be absent (journey ends here)
|
||||
- [ ] **Single page project:** No "Next Step" link
|
||||
- [ ] **Sketch alt text** is descriptive, not just filename
|
||||
|
||||
### Report Format
|
||||
|
||||
<output>
|
||||
**Navigation Quality Report**
|
||||
|
||||
**Status:** ✅ PASS / ❌ FAIL
|
||||
|
||||
**Missing Elements:**
|
||||
- [List any missing required elements]
|
||||
|
||||
**Path Issues:**
|
||||
- [List any broken or incorrect paths]
|
||||
|
||||
**Inconsistencies:**
|
||||
- [List any naming or numbering mismatches]
|
||||
|
||||
**Recommendations:**
|
||||
- [Suggest fixes for any issues found]
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Common Errors to Avoid
|
||||
|
||||
**❌ Don't:**
|
||||
- Skip the H3 header (only using H1)
|
||||
- Use absolute URLs for internal links
|
||||
- Forget to embed the sketch image
|
||||
- Duplicate "Next Step" without the sketch between them
|
||||
- Mix numbering schemes (1.1 vs 1-1 vs 01.01)
|
||||
|
||||
**✅ Do:**
|
||||
- Use consistent numbering format across entire project
|
||||
- Keep sketch image between the two "Next Step" links
|
||||
- Use descriptive alt text for sketch images
|
||||
- Verify all paths before saving
|
||||
|
||||
---
|
||||
|
||||
## Example Fixes
|
||||
|
||||
### ❌ Incorrect: Missing H3 and sketch
|
||||
|
||||
```markdown
|
||||
# 1.1 Home Page
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
```
|
||||
|
||||
### ✅ Correct: Complete navigation structure (within scenario)
|
||||
|
||||
```markdown
|
||||
### 1.1 Home Page
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
# 1.1 Home Page
|
||||
```
|
||||
|
||||
### ✅ Correct: Cross-scenario navigation
|
||||
|
||||
```markdown
|
||||
### 1.3 Thank You Page
|
||||
|
||||
**Next Step**: → [2.1 Dashboard](../../02-user-dashboard/2.1-dashboard/2.1-dashboard.md)
|
||||
|
||||
|
||||
|
||||
**Next Step**: → [2.1 Dashboard](../../02-user-dashboard/2.1-dashboard/2.1-dashboard.md)
|
||||
|
||||
# 1.3 Thank You Page
|
||||
```
|
||||
|
||||
**Rationale:** Scenario 1 (signup flow) naturally continues into Scenario 2 (main application), so the last page of Scenario 1 links to the first page of Scenario 2.
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
<action>Load and execute: step-02-page-overview.md</action>
|
||||
|
||||
|
|
@ -0,0 +1,310 @@
|
|||
# Step 2: Page Visualization
|
||||
|
||||
**Purpose:** Ensure the sketch/visualization is present, properly referenced, and analyzed for completeness.
|
||||
|
||||
---
|
||||
|
||||
## What Page Visualization Provides
|
||||
|
||||
**For Designers:**
|
||||
- Visual reference for all specifications
|
||||
- Clear picture of layout and composition
|
||||
- Design intent and aesthetic direction
|
||||
|
||||
**For Developers:**
|
||||
- Visual target for implementation
|
||||
- Layout and spacing reference
|
||||
- Component placement understanding
|
||||
|
||||
**For Team Communication:**
|
||||
- Shared visual language
|
||||
- Quick page understanding without reading full spec
|
||||
- Design evolution documentation
|
||||
|
||||
---
|
||||
|
||||
## Standard Format
|
||||
|
||||
### Required Elements
|
||||
|
||||
**Sketch Location:**
|
||||
- Embedded in navigation section (Step 1)
|
||||
- Located in `/sketches/` subfolder
|
||||
- Named following convention: `[scenario]-[page]-[variant]-[device].jpg`
|
||||
|
||||
**Sketch Reference:**
|
||||
```markdown
|
||||
|
||||
```
|
||||
|
||||
**Additional Sketch Documentation (Optional):**
|
||||
```markdown
|
||||
## Sketch Information
|
||||
|
||||
**Sketch File:** `sketches/[filename].jpg`
|
||||
**Device:** Desktop / Mobile / Tablet
|
||||
**Variant:** Concept / Iteration 1 / Final
|
||||
**Date:** YYYY-MM-DD
|
||||
**Designer:** [Name]
|
||||
|
||||
**Sketch Notes:**
|
||||
- [Any specific notes about the sketch]
|
||||
- [Incomplete sections marked as TBD]
|
||||
- [Design decisions or rationale]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Format Example (Fictional Project)
|
||||
|
||||
```markdown
|
||||
### 1.1 Home Page
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
# 1.1 Home Page
|
||||
```
|
||||
|
||||
**Note:** The sketch is embedded in the navigation section without additional documentation. This is the minimal acceptable format.
|
||||
|
||||
---
|
||||
|
||||
## Creation Instructions
|
||||
|
||||
<if condition="Creating new specification">
|
||||
|
||||
### Ensure Sketch Exists
|
||||
|
||||
1. **Check for sketch file:**
|
||||
- Look in `/sketches/` subfolder of page directory
|
||||
- Verify file exists and is accessible
|
||||
- Check file format (JPG, PNG acceptable)
|
||||
|
||||
2. **Verify sketch is embedded in navigation:**
|
||||
- Already handled in Step 1
|
||||
- Sketch should be between the two "Next Step" links
|
||||
|
||||
3. **Analyze sketch completeness:**
|
||||
- Is entire page visible or only sections?
|
||||
- Are all sections clearly defined?
|
||||
- Is text readable or represented?
|
||||
- Are states/variants shown (hover, active, etc.)?
|
||||
|
||||
### Document Sketch Status (Optional)
|
||||
|
||||
<output>
|
||||
If sketch is incomplete or requires notes, add a sketch documentation section after navigation:
|
||||
|
||||
```markdown
|
||||
## Sketch Information
|
||||
|
||||
**Sketch File:** `sketches/{filename}.jpg`
|
||||
**Device:** {Desktop/Mobile/Tablet}
|
||||
**Variant:** {Concept/Iteration/Final}
|
||||
**Date:** {YYYY-MM-DD}
|
||||
|
||||
**Sketch Notes:**
|
||||
- {Note about incomplete sections}
|
||||
- {Note about design decisions}
|
||||
- {Note about variants or states not shown}
|
||||
```
|
||||
|
||||
**Most projects:** Skip this optional section unless sketch requires clarification.
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Quality Check Instructions
|
||||
|
||||
<if condition="Analyzing existing specification">
|
||||
|
||||
### Visualization Checklist
|
||||
|
||||
Run through each item. Report any failures.
|
||||
|
||||
**Sketch File Validation:**
|
||||
|
||||
- [ ] **Sketch file exists** in specified location
|
||||
- [ ] **Sketch path is correct** in navigation section (from Step 1)
|
||||
- [ ] **File format is appropriate** (JPG, PNG, WebP acceptable)
|
||||
- [ ] **File size is reasonable** (<5MB for web viewing)
|
||||
- [ ] **Sketch is embedded** between the two "Next Step" links (validated in Step 1)
|
||||
|
||||
**Sketch Quality:**
|
||||
|
||||
- [ ] **Image is viewable** (not corrupted)
|
||||
- [ ] **Resolution is sufficient** (text readable, elements identifiable)
|
||||
- [ ] **Full page visible** or clearly marked sections
|
||||
- [ ] **Device/viewport clear** (desktop, mobile, tablet)
|
||||
|
||||
**Sketch Completeness:**
|
||||
|
||||
- [ ] All major **sections are visible**
|
||||
- [ ] **Layout and spacing** are clear
|
||||
- [ ] **Text content** is readable or clearly represented
|
||||
- [ ] **Interactive elements** (buttons, inputs) are identifiable
|
||||
- [ ] **Incomplete sections** are marked or noted
|
||||
|
||||
**Documentation (Optional):**
|
||||
|
||||
- [ ] If sketch incomplete: **Notes explain what's TBD**
|
||||
- [ ] If multiple variants exist: **Which variant this represents**
|
||||
- [ ] If design evolved: **Version or iteration number**
|
||||
|
||||
### Sketch Analysis Output
|
||||
|
||||
<output>
|
||||
**Sketch Analysis:**
|
||||
|
||||
**Visible Sections:**
|
||||
1. [List all sections visible in sketch]
|
||||
2. [E.g., Header, Hero, Features, Footer]
|
||||
|
||||
**Incomplete or Unclear Elements:**
|
||||
- [List any elements that are unclear or missing]
|
||||
- [E.g., "Right column content is blank"]
|
||||
- [E.g., "Footer text not readable"]
|
||||
|
||||
**Sketch Completeness:** {X}% (estimated coverage of full page)
|
||||
|
||||
**Recommendation:**
|
||||
- [Suggest if sketch is sufficient for specification]
|
||||
- [Note if updated sketch is needed before proceeding]
|
||||
</output>
|
||||
|
||||
### Report Format
|
||||
|
||||
<output>
|
||||
**Page Visualization Quality Report**
|
||||
|
||||
**Status:** ✅ PASS / ⚠️ INCOMPLETE SKETCH / ❌ FAIL
|
||||
|
||||
**File Issues:**
|
||||
- [Sketch file missing?]
|
||||
- [Path incorrect?]
|
||||
- [File corrupted?]
|
||||
|
||||
**Quality Issues:**
|
||||
- [Resolution too low?]
|
||||
- [Elements not identifiable?]
|
||||
|
||||
**Completeness Issues:**
|
||||
- [Sections missing or blank?]
|
||||
- [Text not readable?]
|
||||
- [States/variants needed but not shown?]
|
||||
|
||||
**Recommendations:**
|
||||
- [Specific actions needed]
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Common Errors to Avoid
|
||||
|
||||
**❌ Don't:**
|
||||
- Proceed without a sketch (specifications need visual reference)
|
||||
- Use sketches with unreadable text or unclear elements
|
||||
- Forget to place sketch in `/sketches/` subfolder
|
||||
- Use inconsistent naming (breaks path references)
|
||||
- Include multiple pages in one sketch (confuses specifications)
|
||||
- Use extremely large files (>5MB, slows down viewing)
|
||||
|
||||
**✅ Do:**
|
||||
- Ensure sketch exists before creating specifications
|
||||
- Use clear, readable sketches (sufficient resolution)
|
||||
- Follow naming convention consistently
|
||||
- Keep one page per sketch file
|
||||
- Optimize file size for web viewing
|
||||
- Mark incomplete sections clearly in sketch or notes
|
||||
|
||||
---
|
||||
|
||||
## Example Scenarios
|
||||
|
||||
### ❌ Incorrect: Missing sketch
|
||||
|
||||
```markdown
|
||||
### 1.1 Home Page
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
# 1.1 Home Page
|
||||
|
||||
The home page serves as...
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- No sketch embedded between "Next Step" links
|
||||
- Specifications will be created without visual reference
|
||||
- Team has no shared visual understanding
|
||||
|
||||
### ✅ Correct: Sketch properly embedded
|
||||
|
||||
```markdown
|
||||
### 1.1 Home Page
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
|
||||
|
||||
**Next Step**: → [1.2 Features](../1.2-features/1.2-features.md)
|
||||
|
||||
# 1.1 Home Page
|
||||
```
|
||||
|
||||
**Strengths:**
|
||||
- Sketch properly embedded
|
||||
- Descriptive alt text
|
||||
- Follows naming convention
|
||||
- Located in `/sketches/` subfolder
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Acceptable: Incomplete sketch with documentation
|
||||
|
||||
```markdown
|
||||
### 2.1 Dashboard
|
||||
|
||||
**Next Step**: → [2.2 Analytics](../2.2-analytics/2.2-analytics.md)
|
||||
|
||||
|
||||
|
||||
**Next Step**: → [2.2 Analytics](../2.2-analytics/2.2-analytics.md)
|
||||
|
||||
# 2.1 Dashboard
|
||||
|
||||
## Sketch Information
|
||||
|
||||
**Sketch File:** `sketches/2-1-dashboard-desktop-concept.jpg`
|
||||
**Device:** Desktop
|
||||
**Variant:** Initial Concept
|
||||
**Date:** 2025-12-28
|
||||
|
||||
**Sketch Notes:**
|
||||
- Header and navigation fully defined
|
||||
- Main widget area is placeholder - to be defined in next iteration
|
||||
- Sidebar navigation complete
|
||||
- Footer section not yet sketched - TBD
|
||||
|
||||
**Completeness:** ~65% - Sufficient to begin header and navigation specifications
|
||||
```
|
||||
|
||||
**When to use:**
|
||||
- Sketch is incomplete but sufficient to start specs
|
||||
- Clear documentation of what's TBD
|
||||
- Team agreement to proceed incrementally
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
<action>Load and execute: step-03-page-overview.md</action>
|
||||
|
||||
|
|
@ -0,0 +1,221 @@
|
|||
# Step 3: Page Overview
|
||||
|
||||
**Purpose:** Provide essential context about the page's purpose, user situation, and success criteria.
|
||||
|
||||
---
|
||||
|
||||
## What Page Overview Provides
|
||||
|
||||
**For Designers:**
|
||||
- Understand the "why" behind the page
|
||||
- User emotional state and needs
|
||||
- Success criteria to measure effectiveness
|
||||
|
||||
**For Developers:**
|
||||
- Implementation priorities
|
||||
- Business logic context
|
||||
- Testing criteria
|
||||
|
||||
**For Stakeholders:**
|
||||
- Business value
|
||||
- User impact
|
||||
- Measurable outcomes
|
||||
|
||||
---
|
||||
|
||||
## Standard Format
|
||||
|
||||
### Required Elements
|
||||
|
||||
```markdown
|
||||
# [Page Number] [Page Name]
|
||||
|
||||
[1-2 paragraph description of page purpose, addressing user pain points and desired outcomes]
|
||||
|
||||
**User Situation**: [Description of user's context, emotional state, and needs when arriving at this page]
|
||||
|
||||
**Page Purpose**: [Clear statement of what this page accomplishes for the user and business]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Format Example (Fictional Project)
|
||||
|
||||
```markdown
|
||||
# 1.1 Home Page
|
||||
|
||||
The home page serves as the primary entry point for users discovering TaskFlow for the first time. This page addresses the universal pain point of project management overwhelm while promising the emotional transformation from chaos to control. The page must convert curious visitors into engaged users by demonstrating immediate value and removing adoption barriers.
|
||||
|
||||
**User Situation**: Small business owners and freelancers experiencing daily stress and confusion about task prioritization, seeking a solution that helps them focus on what matters most without complex setup.
|
||||
|
||||
**Page Purpose**: Convert visitors into users by addressing the core emotional drivers - eliminating task chaos while building confidence that they can manage their workload effectively without requiring a project management degree.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Creation Instructions
|
||||
|
||||
<if condition="Creating new specification">
|
||||
|
||||
### Extract Context
|
||||
|
||||
1. **Review trigger map and personas**
|
||||
- Identify primary persona for this page
|
||||
- Note their fears, wants, and pain points
|
||||
- Understand their emotional state at this point in journey
|
||||
|
||||
2. **Define page goal**
|
||||
- What action should user take?
|
||||
- What problem does this page solve?
|
||||
- How does this connect to business goals?
|
||||
|
||||
3. **Capture user situation**
|
||||
- Where is user coming from? (previous page, external link, search)
|
||||
- What is their emotional state? (curious, frustrated, confident, overwhelmed)
|
||||
- What do they need right now?
|
||||
|
||||
### Generate Overview
|
||||
|
||||
<output>
|
||||
Generate complete page overview following the standard format.
|
||||
|
||||
**Template Variables:**
|
||||
- `{page_number}`: Page number (e.g., "1.1")
|
||||
- `{page_name}`: Page name
|
||||
- `{page_description}`: 1-2 paragraphs explaining page purpose and transformation
|
||||
- `{user_situation}`: User's context and emotional state
|
||||
- `{page_purpose}`: Clear success criteria
|
||||
|
||||
**Output Format:**
|
||||
```markdown
|
||||
# {page_number} {page_name}
|
||||
|
||||
{page_description}
|
||||
|
||||
**User Situation**: {user_situation}
|
||||
|
||||
**Page Purpose**: {page_purpose}
|
||||
```
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Quality Check Instructions
|
||||
|
||||
<if condition="Analyzing existing specification">
|
||||
|
||||
### Overview Checklist
|
||||
|
||||
Run through each item. Report any failures.
|
||||
|
||||
**Required Elements:**
|
||||
|
||||
- [ ] **Page description** (1-2 paragraphs) present
|
||||
- [ ] Description mentions **user pain points**
|
||||
- [ ] Description mentions **desired outcome/transformation**
|
||||
- [ ] **User Situation** section present and starts with "User Situation:"
|
||||
- [ ] **Page Purpose** section present and starts with "Page Purpose:"
|
||||
|
||||
**Content Quality:**
|
||||
|
||||
- [ ] Description is **specific to this page** (not generic)
|
||||
- [ ] User Situation includes **emotional state** or context
|
||||
- [ ] Page Purpose clearly states **what success looks like**
|
||||
- [ ] Language is **user-centric** (not feature-centric)
|
||||
- [ ] Connects to **trigger map** or **persona needs**
|
||||
|
||||
**Format Consistency:**
|
||||
|
||||
- [ ] Page number matches navigation section
|
||||
- [ ] H1 header uses correct format (`# X.X Page Name`)
|
||||
- [ ] User Situation uses bold label format
|
||||
- [ ] Page Purpose uses bold label format
|
||||
|
||||
### Report Format
|
||||
|
||||
<output>
|
||||
**Page Overview Quality Report**
|
||||
|
||||
**Status:** ✅ PASS / ❌ FAIL
|
||||
|
||||
**Missing Elements:**
|
||||
- [List any missing required sections]
|
||||
|
||||
**Content Issues:**
|
||||
- [List vague or generic descriptions]
|
||||
- [Note missing emotional context]
|
||||
- [Identify unclear success criteria]
|
||||
|
||||
**Recommendations:**
|
||||
- [Suggest specific improvements]
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Common Errors to Avoid
|
||||
|
||||
**❌ Don't:**
|
||||
- Write generic descriptions that could apply to any page
|
||||
- Focus only on features ("This page has a form and buttons")
|
||||
- Skip emotional context ("User wants to sign up")
|
||||
- Forget to connect to business goals
|
||||
- Use technical jargon instead of user language
|
||||
|
||||
**✅ Do:**
|
||||
- Reference specific personas by name
|
||||
- Include emotional drivers (stress, confidence, fear, hope)
|
||||
- Connect to trigger map pain points
|
||||
- State clear, measurable outcomes
|
||||
- Use empathetic, user-centric language
|
||||
|
||||
---
|
||||
|
||||
## Example Fixes
|
||||
|
||||
### ❌ Incorrect: Generic and feature-focused
|
||||
|
||||
```markdown
|
||||
# 1.1 Home Page
|
||||
|
||||
This is the home page. It has a hero section, some text, and a button.
|
||||
|
||||
**User Situation**: User arrives at the page.
|
||||
|
||||
**Page Purpose**: Show information about the product.
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- No user pain points mentioned
|
||||
- No emotional context
|
||||
- Vague purpose
|
||||
- Could describe any landing page
|
||||
|
||||
### ✅ Correct: Specific and user-centric
|
||||
|
||||
```markdown
|
||||
# 1.1 Home Page
|
||||
|
||||
The home page serves as the primary entry point for users discovering TaskFlow for the first time. This page addresses the universal pain point of project management overwhelm while promising the emotional transformation from chaos to control. The page must convert curious visitors into engaged users by demonstrating immediate value and removing adoption barriers.
|
||||
|
||||
**User Situation**: Small business owners and freelancers experiencing daily stress and confusion about task prioritization, seeking a solution that helps them focus on what matters most without complex setup.
|
||||
|
||||
**Page Purpose**: Convert visitors into users by addressing the core emotional drivers - eliminating task chaos while building confidence that they can manage their workload effectively without requiring a project management degree.
|
||||
```
|
||||
|
||||
**Strengths:**
|
||||
- Specific target users (small business owners, freelancers)
|
||||
- Clear pain point (project management overwhelm)
|
||||
- Emotional transformation (chaos → control)
|
||||
- Measurable outcome (convert visitors to users)
|
||||
- User-centric language
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
<action>Load and execute: step-04-page-sections.md</action>
|
||||
|
||||
|
|
@ -0,0 +1,327 @@
|
|||
# Step 4: Object Registry
|
||||
|
||||
**Purpose:** Create a master reference table of all page objects for quick lookup and traceability.
|
||||
|
||||
---
|
||||
|
||||
## What Object Registry Provides
|
||||
|
||||
**For Designers:**
|
||||
- Quick reference of all page elements
|
||||
- Easy communication ("update object start-hero-cta")
|
||||
- Complete page inventory
|
||||
|
||||
**For Developers:**
|
||||
- Testing targets (selenium, playwright)
|
||||
- Element reference for implementation
|
||||
- Content management system mapping
|
||||
|
||||
**For Content Teams:**
|
||||
- Translation targets
|
||||
- Content update references
|
||||
- CMS field mapping
|
||||
|
||||
**For QA/Testing:**
|
||||
- Systematic test coverage
|
||||
- Element identification
|
||||
- Regression testing targets
|
||||
|
||||
---
|
||||
|
||||
## Standard Format
|
||||
|
||||
### Required Structure
|
||||
|
||||
```markdown
|
||||
## Object Registry
|
||||
|
||||
This page uses a systematic Object ID system for precise element identification across specifications, HTML demos, and production code.
|
||||
|
||||
### Master Object List - [Section Name]
|
||||
|
||||
| Object ID | Object | Content Type | Description | Interactions |
|
||||
|-----------|--------|--------------|-------------|--------------|
|
||||
| `object-id` | Section | Type | Brief description | User actions |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Format Example (Fictional Project)
|
||||
|
||||
```markdown
|
||||
## Object Registry
|
||||
|
||||
This page uses a systematic Object ID system for precise element identification across specifications, HTML demos, and production code.
|
||||
|
||||
### Master Object List - Header & Hero
|
||||
|
||||
| Object ID | Object | Content Type | Description | Interactions |
|
||||
|-----------|--------|--------------|-------------|--------------|
|
||||
| `home-header-logo` | Header | Brand logo | TaskFlow logotype | onClick → home |
|
||||
| `home-header-signin` | Header | Navigation button | Sign in button | onClick → sign-in |
|
||||
| `home-hero-headline` | Hero | Primary headline | Value proposition | Static text |
|
||||
| `home-hero-cta` | Hero | Primary CTA button | Main call-to-action | onClick → registration |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Creation Instructions
|
||||
|
||||
<if condition="Creating new specification">
|
||||
|
||||
### Extract All Objects
|
||||
|
||||
1. **Review all Page Sections** created in Step 3
|
||||
2. **List every Object ID** found in the specifications
|
||||
3. **Group objects by section** (Header, Hero, Features, Footer, etc.)
|
||||
4. **Determine content type** for each object
|
||||
5. **Summarize interaction** in one phrase
|
||||
|
||||
### Content Type Classification
|
||||
|
||||
**Common Content Types:**
|
||||
- Brand logo
|
||||
- Navigation button
|
||||
- Primary headline
|
||||
- Secondary headline
|
||||
- Body paragraph
|
||||
- CTA button
|
||||
- Text input
|
||||
- Image/Illustration
|
||||
- Icon
|
||||
- Link
|
||||
- Trust indicator
|
||||
- Feature card
|
||||
- Testimonial card
|
||||
- FAQ item
|
||||
|
||||
### Interaction Classification
|
||||
|
||||
**Common Interactions:**
|
||||
- `onClick → [destination]`
|
||||
- `onChange → [action]`
|
||||
- `onSubmit → [action]`
|
||||
- `onHover → [effect]`
|
||||
- `Static display`
|
||||
- `Static text, language-aware`
|
||||
|
||||
### Generate Registry Tables
|
||||
|
||||
<output>
|
||||
Generate complete Object Registry following the standard format.
|
||||
|
||||
**Structure:**
|
||||
1. Registry introduction paragraph (copy exactly as shown)
|
||||
2. One table per logical section grouping
|
||||
3. All objects from Page Sections included
|
||||
|
||||
**Table Format:**
|
||||
```markdown
|
||||
### Master Object List - [Section Group Name]
|
||||
|
||||
| Object ID | Object | Content Type | Description | Interactions |
|
||||
|-----------|--------|--------------|-------------|--------------|
|
||||
| `object-id` | Section | Type | Brief description | User action |
|
||||
```
|
||||
|
||||
**Grouping Guidelines:**
|
||||
- Combine small related sections (Header & Hero)
|
||||
- Keep large sections separate (Features, FAQ, Footer)
|
||||
- Aim for 4-8 objects per table
|
||||
- Maximum 12 objects per table
|
||||
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Quality Check Instructions
|
||||
|
||||
<if condition="Analyzing existing specification">
|
||||
|
||||
### Registry Checklist
|
||||
|
||||
**Structure Validation:**
|
||||
|
||||
- [ ] **"## Object Registry"** heading present
|
||||
- [ ] **Introduction paragraph** present (explaining Object ID system)
|
||||
- [ ] At least one **Master Object List** table exists
|
||||
- [ ] Tables use correct markdown format (pipes and hyphens)
|
||||
- [ ] Column headers are: **Object ID | Object | Content Type | Description | Interactions**
|
||||
|
||||
**Completeness:**
|
||||
|
||||
- [ ] **All Object IDs** from Page Sections appear in registry
|
||||
- [ ] **No duplicate Object IDs** in registry
|
||||
- [ ] **No orphan Object IDs** (in registry but not in Page Sections)
|
||||
- [ ] Objects are **grouped logically** by section
|
||||
|
||||
**Content Quality:**
|
||||
|
||||
- [ ] Object IDs use **backtick formatting** (`` `object-id` ``)
|
||||
- [ ] Content Types are **descriptive and consistent**
|
||||
- [ ] Descriptions are **brief** (3-8 words)
|
||||
- [ ] Interactions use **standard format** (`onClick →`, `onChange →`, etc.)
|
||||
- [ ] **No empty cells** in table
|
||||
|
||||
**Cross-Reference Validation:**
|
||||
|
||||
Run a comparison between Page Sections and Object Registry:
|
||||
|
||||
1. **List all Object IDs from Page Sections**
|
||||
2. **List all Object IDs from Object Registry**
|
||||
3. **Compare lists:**
|
||||
- Missing in Registry = ❌ Add to registry
|
||||
- Missing in Sections = ❌ Remove from registry or add to sections
|
||||
- Mismatched = ❌ Fix typo
|
||||
|
||||
### Report Format
|
||||
|
||||
<output>
|
||||
**Object Registry Quality Report**
|
||||
|
||||
**Status:** ✅ PASS / ❌ FAIL
|
||||
|
||||
**Structure Issues:**
|
||||
- [Missing registry section?]
|
||||
- [Missing introduction paragraph?]
|
||||
- [Table formatting errors?]
|
||||
|
||||
**Completeness:**
|
||||
- **Total Object IDs in Sections:** X
|
||||
- **Total Object IDs in Registry:** Y
|
||||
- **Match:** ✅ / ❌
|
||||
|
||||
**Missing from Registry:**
|
||||
- [List Object IDs in sections but not in registry]
|
||||
|
||||
**Orphan Object IDs:**
|
||||
- [List Object IDs in registry but not in sections]
|
||||
|
||||
**Content Issues:**
|
||||
- [Vague descriptions]
|
||||
- [Inconsistent content types]
|
||||
- [Missing interaction specifications]
|
||||
|
||||
**Recommendations:**
|
||||
- [Specific fixes needed]
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Common Errors to Avoid
|
||||
|
||||
**❌ Don't:**
|
||||
- Skip the registry ("it's just a duplicate")
|
||||
- Use inconsistent content type names
|
||||
- Leave cells empty (use "N/A" or "Static" if truly non-interactive)
|
||||
- Forget backticks around Object IDs
|
||||
- Create registry before Page Sections (order matters)
|
||||
- Use vague descriptions ("button", "text")
|
||||
|
||||
**✅ Do:**
|
||||
- Include every single Object ID from Page Sections
|
||||
- Use consistent content type terminology
|
||||
- Keep descriptions brief but specific
|
||||
- Format Object IDs with backticks
|
||||
- Group objects logically by section
|
||||
- Cross-reference to ensure 100% match
|
||||
|
||||
---
|
||||
|
||||
## Example Fixes
|
||||
|
||||
### ❌ Incorrect: Incomplete and poorly formatted
|
||||
|
||||
```markdown
|
||||
## Objects
|
||||
|
||||
| ID | Type | Description |
|
||||
|----|------|-------------|
|
||||
| start-logo | Logo | Logo |
|
||||
| start-button | Button | Button to sign in |
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- Wrong section title ("Objects" not "Object Registry")
|
||||
- Missing introduction paragraph
|
||||
- Wrong table headers
|
||||
- Object IDs not in backticks
|
||||
- Missing "Object" and "Interactions" columns
|
||||
- Vague descriptions
|
||||
- Incomplete (missing objects)
|
||||
|
||||
### ✅ Correct: Complete and properly formatted
|
||||
|
||||
```markdown
|
||||
## Object Registry
|
||||
|
||||
This page uses a systematic Object ID system for precise element identification across specifications, HTML demos, and production code.
|
||||
|
||||
### Master Object List - Header & Hero
|
||||
|
||||
| Object ID | Object | Content Type | Description | Interactions |
|
||||
|-----------|--------|--------------|-------------|--------------|
|
||||
| `home-header-logo` | Header | Brand logo | TaskFlow logotype | onClick → home |
|
||||
| `home-header-signin` | Header | Navigation button | Sign in button | onClick → sign-in |
|
||||
| `home-hero-headline` | Hero | Primary headline | Value proposition | Static text |
|
||||
| `home-hero-cta` | Hero | Primary CTA button | Main call-to-action | onClick → registration |
|
||||
```
|
||||
|
||||
**Strengths:**
|
||||
- Correct section title
|
||||
- Introduction paragraph present
|
||||
- All five columns present
|
||||
- Object IDs in backticks
|
||||
- Descriptive content types
|
||||
- Clear, brief descriptions
|
||||
- Specific interaction specs
|
||||
- Logical grouping
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes Section
|
||||
|
||||
### Optional Addition
|
||||
|
||||
After the registry tables, you may include an "Implementation Notes" section:
|
||||
|
||||
```markdown
|
||||
### Implementation Notes
|
||||
|
||||
**HTML Demo Integration:**
|
||||
- Each object includes `id="object-id"` and `data-object-id="object-id"` attributes
|
||||
- JavaScript uses Object IDs for content updates and event handling
|
||||
- Translation system maps content directly to Object IDs
|
||||
|
||||
**Production Code Mapping:**
|
||||
- Object IDs become component props or data attributes
|
||||
- Content management systems can reference Object IDs for updates
|
||||
- Testing frameworks can target elements by Object ID for reliable automation
|
||||
|
||||
**Designer-Developer Workflow:**
|
||||
- Designer uses Object IDs as component names in Figma
|
||||
- Specifications provide structure, designer modifies as needed
|
||||
- Developer updates specs based on design iterations
|
||||
- GitHub specifications remain single source of truth
|
||||
|
||||
**Content Traceability:**
|
||||
- Every interactive element has a unique Object ID
|
||||
- Changes to specifications automatically propagate to HTML demos and production code
|
||||
- Clear communication: "Update the CTA in start-hero-cta"
|
||||
```
|
||||
|
||||
**Include this section if:**
|
||||
- Project has interactive prototypes
|
||||
- Project uses CMS or translation system
|
||||
- Team wants implementation guidance
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
<action>Load and execute: step-05-final-validation.md</action>
|
||||
|
||||
|
|
@ -0,0 +1,319 @@
|
|||
# Step 4: Page Sections Structure
|
||||
|
||||
**Purpose:** Organize all page elements into logical sections with clear hierarchy and Object IDs.
|
||||
|
||||
---
|
||||
|
||||
## What Page Sections Provide
|
||||
|
||||
**For Designers:**
|
||||
- Clear visual hierarchy
|
||||
- Section-level organization
|
||||
- Understanding of page flow
|
||||
|
||||
**For Developers:**
|
||||
- Component boundaries
|
||||
- Implementation order
|
||||
- Semantic HTML structure
|
||||
|
||||
**For Everyone:**
|
||||
- Shared vocabulary
|
||||
- Clear references ("update the hero section")
|
||||
- Traceability
|
||||
|
||||
---
|
||||
|
||||
## Standard Format
|
||||
|
||||
### Required Structure
|
||||
|
||||
```markdown
|
||||
## Page Sections
|
||||
|
||||
### [Section Name] Object
|
||||
**Purpose**: [One sentence explaining section's role]
|
||||
|
||||
#### [Component Name]
|
||||
**OBJECT ID**: `page-section-component`
|
||||
- **Component**: [Link to design system component if exists]
|
||||
- **Content**: [What text/media this contains]
|
||||
- **Behavior**: [What happens on interaction]
|
||||
- **Position**: [Where it's located]
|
||||
- **[Other relevant specs]**: [Values]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Format Example (Fictional Project)
|
||||
|
||||
```markdown
|
||||
## Page Sections
|
||||
|
||||
### Header Object
|
||||
**Purpose**: Navigation and user access
|
||||
|
||||
#### Company Logo
|
||||
**OBJECT ID**: `home-header-logo`
|
||||
- **Component**: [Logo Component](/docs/design-system/components/Logo.md)
|
||||
- **Content**: "TaskFlow" logotype
|
||||
- **Behavior**: Links to home page
|
||||
- **Position**: Left-aligned
|
||||
|
||||
#### Sign In Button
|
||||
**OBJECT ID**: `home-header-signin`
|
||||
- **Component**: [Button Secondary](/docs/design-system/components/Buttons/Button-Secondary.md)
|
||||
- **Content**: "Sign in"
|
||||
- **Behavior**: Navigate to sign-in page
|
||||
- **Color**: `var(--primary-600)`
|
||||
- **Position**: Right side
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Hierarchy Rules
|
||||
|
||||
### Section Types
|
||||
|
||||
**H3 Level (###): Section Objects**
|
||||
- Major visual sections (Header, Hero, Footer, etc.)
|
||||
- Each section has a **Purpose** statement
|
||||
- Sections contain multiple components
|
||||
|
||||
**H4 Level (####): Components**
|
||||
- Individual interactive or visual elements
|
||||
- Each has an **OBJECT ID**
|
||||
- Components can reference design system
|
||||
|
||||
**Object ID Naming Convention:**
|
||||
```
|
||||
{page-prefix}-{section}-{component}
|
||||
```
|
||||
|
||||
Examples:
|
||||
- `start-header-logo`
|
||||
- `start-hero-cta`
|
||||
- `start-footer-newsletter-button`
|
||||
|
||||
---
|
||||
|
||||
## Creation Instructions
|
||||
|
||||
<if condition="Creating new specification">
|
||||
|
||||
### Analyze Sketch
|
||||
|
||||
1. **Identify visual sections from top to bottom:**
|
||||
- Header/Navigation
|
||||
- Hero/Main message
|
||||
- Content sections (Features, Benefits, etc.)
|
||||
- Footer
|
||||
|
||||
2. **For each section, list all components:**
|
||||
- Text elements (headlines, paragraphs)
|
||||
- Interactive elements (buttons, inputs, links)
|
||||
- Visual elements (images, icons, illustrations)
|
||||
- Containers (cards, panels, modals)
|
||||
|
||||
3. **Determine section purpose:**
|
||||
- Why does this section exist?
|
||||
- What user need does it serve?
|
||||
|
||||
### Generate Section Specifications
|
||||
|
||||
<output>
|
||||
For each section, generate:
|
||||
|
||||
**Section Header:**
|
||||
```markdown
|
||||
### [Section Name] Object
|
||||
**Purpose**: [Clear, one-sentence purpose]
|
||||
```
|
||||
|
||||
**For each component in section:**
|
||||
```markdown
|
||||
#### [Component Name]
|
||||
**OBJECT ID**: `{page}-{section}-{component}`
|
||||
- **Component**: [Link if design system exists, or "TBD"]
|
||||
- **Content**: [Actual text or description]
|
||||
- **Behavior**: [User interaction or static]
|
||||
- **Position**: [Location within section]
|
||||
- **[Relevant specs]**: [Values specific to this component]
|
||||
```
|
||||
|
||||
**Spec Fields by Component Type:**
|
||||
|
||||
**Buttons:**
|
||||
- Component, Content (with translations), Behavior, Colors, Position
|
||||
|
||||
**Text Elements:**
|
||||
- Component (H1, H2, body, etc.), Content (with translations), Behavior (if clickable), Style
|
||||
|
||||
**Images:**
|
||||
- Component, Content (description), Behavior, Layout, Image Source, Dimensions
|
||||
|
||||
**Inputs:**
|
||||
- Component, API Data Field, Placeholder (with translations), Validation
|
||||
|
||||
**Links:**
|
||||
- Component, Content (with translations), Behavior (destination)
|
||||
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Quality Check Instructions
|
||||
|
||||
<if condition="Analyzing existing specification">
|
||||
|
||||
### Sections Checklist
|
||||
|
||||
**Structure Validation:**
|
||||
|
||||
- [ ] **"## Page Sections"** heading present
|
||||
- [ ] Each section uses **H3** (`###`) with "Object" suffix
|
||||
- [ ] Each section has **Purpose** statement
|
||||
- [ ] Each component uses **H4** (`####`)
|
||||
- [ ] Every component has **OBJECT ID**
|
||||
|
||||
**Object ID Validation:**
|
||||
|
||||
- [ ] Object IDs follow naming convention: `{page}-{section}-{component}`
|
||||
- [ ] Object IDs are **unique** across entire page
|
||||
- [ ] Object IDs use **lowercase** with hyphens
|
||||
- [ ] Object IDs are **descriptive** (not generic like `button-1`)
|
||||
|
||||
**Component Specification:**
|
||||
|
||||
- [ ] Each component has **minimum required fields**:
|
||||
- OBJECT ID (always)
|
||||
- Content or description
|
||||
- Behavior (if interactive)
|
||||
|
||||
- [ ] **Multilingual content** marked with language codes (EN:, SE:, etc.)
|
||||
- [ ] **Design system links** present where components exist
|
||||
- [ ] **Position** information provided
|
||||
- [ ] **Color variables** used (not hex codes directly)
|
||||
|
||||
**Completeness:**
|
||||
|
||||
- [ ] **All visible elements** in sketch have specs
|
||||
- [ ] **All interactive elements** have behavior defined
|
||||
- [ ] **All text content** is specified (not "lorem ipsum")
|
||||
- [ ] **All images** have source paths or descriptions
|
||||
|
||||
### Report Format
|
||||
|
||||
<output>
|
||||
**Page Sections Quality Report**
|
||||
|
||||
**Status:** ✅ PASS / ❌ FAIL
|
||||
|
||||
**Structure Issues:**
|
||||
- [Missing "Page Sections" header?]
|
||||
- [Wrong heading levels?]
|
||||
- [Missing Purpose statements?]
|
||||
|
||||
**Object ID Issues:**
|
||||
- [List any components without Object IDs]
|
||||
- [List duplicate Object IDs]
|
||||
- [List incorrectly formatted Object IDs]
|
||||
|
||||
**Specification Gaps:**
|
||||
- [Components missing behavior specs]
|
||||
- [Missing multilingual content]
|
||||
- [Missing position information]
|
||||
|
||||
**Sketch Coverage:**
|
||||
- [List visible elements in sketch not specified]
|
||||
|
||||
**Recommendations:**
|
||||
- [Specific fixes needed]
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Common Errors to Avoid
|
||||
|
||||
**❌ Don't:**
|
||||
- Skip Object IDs ("we'll add them later")
|
||||
- Use generic Object IDs (`button-1`, `text-2`)
|
||||
- Mix heading levels incorrectly
|
||||
- Forget the "Object" suffix on section headers
|
||||
- Leave content as placeholders ("TBD", "Lorem ipsum")
|
||||
- Use absolute URLs for design system links
|
||||
|
||||
**✅ Do:**
|
||||
- Give every interactive element an Object ID
|
||||
- Use descriptive, semantic Object IDs
|
||||
- Maintain consistent hierarchy (H3 → H4)
|
||||
- Write clear, one-sentence Purpose statements
|
||||
- Specify actual content (even if it might change)
|
||||
- Use relative paths for all internal links
|
||||
|
||||
---
|
||||
|
||||
## Example Fixes
|
||||
|
||||
### ❌ Incorrect: Missing Object IDs, wrong hierarchy
|
||||
|
||||
```markdown
|
||||
## Header
|
||||
|
||||
### Logo
|
||||
- Component: Logo
|
||||
- Content: TaskFlow
|
||||
|
||||
### Button
|
||||
- Content: Sign in
|
||||
- Behavior: Go to sign-in page
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- No "Page Sections" header
|
||||
- "Header" should be H3, components H4
|
||||
- Missing "Object" suffix
|
||||
- No Purpose statement
|
||||
- No Object IDs
|
||||
- Vague component names
|
||||
|
||||
### ✅ Correct: Proper hierarchy and Object IDs
|
||||
|
||||
```markdown
|
||||
## Page Sections
|
||||
|
||||
### Header Object
|
||||
**Purpose**: Navigation and user access
|
||||
|
||||
#### Company Logo
|
||||
**OBJECT ID**: `home-header-logo`
|
||||
- **Component**: [Logo Component](/docs/design-system/components/Logo.md)
|
||||
- **Content**: "TaskFlow" logotype
|
||||
- **Behavior**: Links to home page
|
||||
- **Position**: Left-aligned
|
||||
|
||||
#### Sign In Button
|
||||
**OBJECT ID**: `home-header-signin`
|
||||
- **Component**: [Button Secondary](/docs/design-system/components/Buttons/Button-Secondary.md)
|
||||
- **Content**: "Sign in"
|
||||
- **Behavior**: Navigate to sign-in page
|
||||
- **Position**: Right side
|
||||
```
|
||||
|
||||
**Strengths:**
|
||||
- Clear hierarchy (H2 → H3 → H4)
|
||||
- Purpose statement at section level
|
||||
- Unique, descriptive Object IDs
|
||||
- Design system links
|
||||
- Multilingual content
|
||||
- Position information
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
<action>Load and execute: step-05-object-registry.md</action>
|
||||
|
||||
|
|
@ -0,0 +1,327 @@
|
|||
# Step 5: Object Registry
|
||||
|
||||
**Purpose:** Create a master reference table of all page objects for quick lookup and traceability.
|
||||
|
||||
---
|
||||
|
||||
## What Object Registry Provides
|
||||
|
||||
**For Designers:**
|
||||
- Quick reference of all page elements
|
||||
- Easy communication ("update object start-hero-cta")
|
||||
- Complete page inventory
|
||||
|
||||
**For Developers:**
|
||||
- Testing targets (selenium, playwright)
|
||||
- Element reference for implementation
|
||||
- Content management system mapping
|
||||
|
||||
**For Content Teams:**
|
||||
- Translation targets
|
||||
- Content update references
|
||||
- CMS field mapping
|
||||
|
||||
**For QA/Testing:**
|
||||
- Systematic test coverage
|
||||
- Element identification
|
||||
- Regression testing targets
|
||||
|
||||
---
|
||||
|
||||
## Standard Format
|
||||
|
||||
### Required Structure
|
||||
|
||||
```markdown
|
||||
## Object Registry
|
||||
|
||||
This page uses a systematic Object ID system for precise element identification across specifications, HTML demos, and production code.
|
||||
|
||||
### Master Object List - [Section Name]
|
||||
|
||||
| Object ID | Object | Content Type | Description | Interactions |
|
||||
|-----------|--------|--------------|-------------|--------------|
|
||||
| `object-id` | Section | Type | Brief description | User actions |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Format Example (Fictional Project)
|
||||
|
||||
```markdown
|
||||
## Object Registry
|
||||
|
||||
This page uses a systematic Object ID system for precise element identification across specifications, HTML demos, and production code.
|
||||
|
||||
### Master Object List - Header & Hero
|
||||
|
||||
| Object ID | Object | Content Type | Description | Interactions |
|
||||
|-----------|--------|--------------|-------------|--------------|
|
||||
| `home-header-logo` | Header | Brand logo | TaskFlow logotype | onClick → home |
|
||||
| `home-header-signin` | Header | Navigation button | Sign in button | onClick → sign-in |
|
||||
| `home-hero-headline` | Hero | Primary headline | Value proposition | Static text |
|
||||
| `home-hero-cta` | Hero | Primary CTA button | Main call-to-action | onClick → registration |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Creation Instructions
|
||||
|
||||
<if condition="Creating new specification">
|
||||
|
||||
### Extract All Objects
|
||||
|
||||
1. **Review all Page Sections** created in Step 3
|
||||
2. **List every Object ID** found in the specifications
|
||||
3. **Group objects by section** (Header, Hero, Features, Footer, etc.)
|
||||
4. **Determine content type** for each object
|
||||
5. **Summarize interaction** in one phrase
|
||||
|
||||
### Content Type Classification
|
||||
|
||||
**Common Content Types:**
|
||||
- Brand logo
|
||||
- Navigation button
|
||||
- Primary headline
|
||||
- Secondary headline
|
||||
- Body paragraph
|
||||
- CTA button
|
||||
- Text input
|
||||
- Image/Illustration
|
||||
- Icon
|
||||
- Link
|
||||
- Trust indicator
|
||||
- Feature card
|
||||
- Testimonial card
|
||||
- FAQ item
|
||||
|
||||
### Interaction Classification
|
||||
|
||||
**Common Interactions:**
|
||||
- `onClick → [destination]`
|
||||
- `onChange → [action]`
|
||||
- `onSubmit → [action]`
|
||||
- `onHover → [effect]`
|
||||
- `Static display`
|
||||
- `Static text, language-aware`
|
||||
|
||||
### Generate Registry Tables
|
||||
|
||||
<output>
|
||||
Generate complete Object Registry following the standard format.
|
||||
|
||||
**Structure:**
|
||||
1. Registry introduction paragraph (copy exactly as shown)
|
||||
2. One table per logical section grouping
|
||||
3. All objects from Page Sections included
|
||||
|
||||
**Table Format:**
|
||||
```markdown
|
||||
### Master Object List - [Section Group Name]
|
||||
|
||||
| Object ID | Object | Content Type | Description | Interactions |
|
||||
|-----------|--------|--------------|-------------|--------------|
|
||||
| `object-id` | Section | Type | Brief description | User action |
|
||||
```
|
||||
|
||||
**Grouping Guidelines:**
|
||||
- Combine small related sections (Header & Hero)
|
||||
- Keep large sections separate (Features, FAQ, Footer)
|
||||
- Aim for 4-8 objects per table
|
||||
- Maximum 12 objects per table
|
||||
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Quality Check Instructions
|
||||
|
||||
<if condition="Analyzing existing specification">
|
||||
|
||||
### Registry Checklist
|
||||
|
||||
**Structure Validation:**
|
||||
|
||||
- [ ] **"## Object Registry"** heading present
|
||||
- [ ] **Introduction paragraph** present (explaining Object ID system)
|
||||
- [ ] At least one **Master Object List** table exists
|
||||
- [ ] Tables use correct markdown format (pipes and hyphens)
|
||||
- [ ] Column headers are: **Object ID | Object | Content Type | Description | Interactions**
|
||||
|
||||
**Completeness:**
|
||||
|
||||
- [ ] **All Object IDs** from Page Sections appear in registry
|
||||
- [ ] **No duplicate Object IDs** in registry
|
||||
- [ ] **No orphan Object IDs** (in registry but not in Page Sections)
|
||||
- [ ] Objects are **grouped logically** by section
|
||||
|
||||
**Content Quality:**
|
||||
|
||||
- [ ] Object IDs use **backtick formatting** (`` `object-id` ``)
|
||||
- [ ] Content Types are **descriptive and consistent**
|
||||
- [ ] Descriptions are **brief** (3-8 words)
|
||||
- [ ] Interactions use **standard format** (`onClick →`, `onChange →`, etc.)
|
||||
- [ ] **No empty cells** in table
|
||||
|
||||
**Cross-Reference Validation:**
|
||||
|
||||
Run a comparison between Page Sections and Object Registry:
|
||||
|
||||
1. **List all Object IDs from Page Sections**
|
||||
2. **List all Object IDs from Object Registry**
|
||||
3. **Compare lists:**
|
||||
- Missing in Registry = ❌ Add to registry
|
||||
- Missing in Sections = ❌ Remove from registry or add to sections
|
||||
- Mismatched = ❌ Fix typo
|
||||
|
||||
### Report Format
|
||||
|
||||
<output>
|
||||
**Object Registry Quality Report**
|
||||
|
||||
**Status:** ✅ PASS / ❌ FAIL
|
||||
|
||||
**Structure Issues:**
|
||||
- [Missing registry section?]
|
||||
- [Missing introduction paragraph?]
|
||||
- [Table formatting errors?]
|
||||
|
||||
**Completeness:**
|
||||
- **Total Object IDs in Sections:** X
|
||||
- **Total Object IDs in Registry:** Y
|
||||
- **Match:** ✅ / ❌
|
||||
|
||||
**Missing from Registry:**
|
||||
- [List Object IDs in sections but not in registry]
|
||||
|
||||
**Orphan Object IDs:**
|
||||
- [List Object IDs in registry but not in sections]
|
||||
|
||||
**Content Issues:**
|
||||
- [Vague descriptions]
|
||||
- [Inconsistent content types]
|
||||
- [Missing interaction specifications]
|
||||
|
||||
**Recommendations:**
|
||||
- [Specific fixes needed]
|
||||
</output>
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Common Errors to Avoid
|
||||
|
||||
**❌ Don't:**
|
||||
- Skip the registry ("it's just a duplicate")
|
||||
- Use inconsistent content type names
|
||||
- Leave cells empty (use "N/A" or "Static" if truly non-interactive)
|
||||
- Forget backticks around Object IDs
|
||||
- Create registry before Page Sections (order matters)
|
||||
- Use vague descriptions ("button", "text")
|
||||
|
||||
**✅ Do:**
|
||||
- Include every single Object ID from Page Sections
|
||||
- Use consistent content type terminology
|
||||
- Keep descriptions brief but specific
|
||||
- Format Object IDs with backticks
|
||||
- Group objects logically by section
|
||||
- Cross-reference to ensure 100% match
|
||||
|
||||
---
|
||||
|
||||
## Example Fixes
|
||||
|
||||
### ❌ Incorrect: Incomplete and poorly formatted
|
||||
|
||||
```markdown
|
||||
## Objects
|
||||
|
||||
| ID | Type | Description |
|
||||
|----|------|-------------|
|
||||
| start-logo | Logo | Logo |
|
||||
| start-button | Button | Button to sign in |
|
||||
```
|
||||
|
||||
**Issues:**
|
||||
- Wrong section title ("Objects" not "Object Registry")
|
||||
- Missing introduction paragraph
|
||||
- Wrong table headers
|
||||
- Object IDs not in backticks
|
||||
- Missing "Object" and "Interactions" columns
|
||||
- Vague descriptions
|
||||
- Incomplete (missing objects)
|
||||
|
||||
### ✅ Correct: Complete and properly formatted
|
||||
|
||||
```markdown
|
||||
## Object Registry
|
||||
|
||||
This page uses a systematic Object ID system for precise element identification across specifications, HTML demos, and production code.
|
||||
|
||||
### Master Object List - Header & Hero
|
||||
|
||||
| Object ID | Object | Content Type | Description | Interactions |
|
||||
|-----------|--------|--------------|-------------|--------------|
|
||||
| `home-header-logo` | Header | Brand logo | TaskFlow logotype | onClick → home |
|
||||
| `home-header-signin` | Header | Navigation button | Sign in button | onClick → sign-in |
|
||||
| `home-hero-headline` | Hero | Primary headline | Value proposition | Static text |
|
||||
| `home-hero-cta` | Hero | Primary CTA button | Main call-to-action | onClick → registration |
|
||||
```
|
||||
|
||||
**Strengths:**
|
||||
- Correct section title
|
||||
- Introduction paragraph present
|
||||
- All five columns present
|
||||
- Object IDs in backticks
|
||||
- Descriptive content types
|
||||
- Clear, brief descriptions
|
||||
- Specific interaction specs
|
||||
- Logical grouping
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes Section
|
||||
|
||||
### Optional Addition
|
||||
|
||||
After the registry tables, you may include an "Implementation Notes" section:
|
||||
|
||||
```markdown
|
||||
### Implementation Notes
|
||||
|
||||
**HTML Demo Integration:**
|
||||
- Each object includes `id="object-id"` and `data-object-id="object-id"` attributes
|
||||
- JavaScript uses Object IDs for content updates and event handling
|
||||
- Translation system maps content directly to Object IDs
|
||||
|
||||
**Production Code Mapping:**
|
||||
- Object IDs become component props or data attributes
|
||||
- Content management systems can reference Object IDs for updates
|
||||
- Testing frameworks can target elements by Object ID for reliable automation
|
||||
|
||||
**Designer-Developer Workflow:**
|
||||
- Designer uses Object IDs as component names in Figma
|
||||
- Specifications provide structure, designer modifies as needed
|
||||
- Developer updates specs based on design iterations
|
||||
- GitHub specifications remain single source of truth
|
||||
|
||||
**Content Traceability:**
|
||||
- Every interactive element has a unique Object ID
|
||||
- Changes to specifications automatically propagate to HTML demos and production code
|
||||
- Clear communication: "Update the CTA in start-hero-cta"
|
||||
```
|
||||
|
||||
**Include this section if:**
|
||||
- Project has interactive prototypes
|
||||
- Project uses CMS or translation system
|
||||
- Team wants implementation guidance
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
<action>Load and execute: step-06-final-validation.md</action>
|
||||
|
||||
|
|
@ -0,0 +1,420 @@
|
|||
# Step 6: Final Validation
|
||||
|
||||
**Purpose:** Run comprehensive quality checks and generate final report.
|
||||
|
||||
---
|
||||
|
||||
## What Final Validation Provides
|
||||
|
||||
**Quality Assurance:**
|
||||
- Catches missing elements before handoff
|
||||
- Ensures consistency across specification
|
||||
- Validates against WDS standards
|
||||
|
||||
**Confidence:**
|
||||
- Designer knows spec is complete
|
||||
- Developer can trust the specification
|
||||
- Team has single source of truth
|
||||
|
||||
**Traceability:**
|
||||
- All elements accounted for
|
||||
- Clear audit trail
|
||||
- Easy to identify gaps
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
Run through all items systematically.
|
||||
|
||||
### 1. Navigation Validation
|
||||
|
||||
- [ ] H3 header with page number present
|
||||
- [ ] First "Next Step" link present and correct
|
||||
- [ ] Sketch image embedded with correct path
|
||||
- [ ] Second "Next Step" link present and correct
|
||||
- [ ] H1 header matches H3 header exactly
|
||||
|
||||
### 2. Page Overview Validation
|
||||
|
||||
- [ ] Page description (1-2 paragraphs) present
|
||||
- [ ] User Situation section present
|
||||
- [ ] Page Purpose section present
|
||||
- [ ] Content is specific, not generic
|
||||
- [ ] Emotional context included
|
||||
|
||||
### 3. Page Sections Validation
|
||||
|
||||
- [ ] "## Page Sections" header present
|
||||
- [ ] All sections use H3 with "Object" suffix
|
||||
- [ ] Every section has Purpose statement
|
||||
- [ ] All components use H4
|
||||
- [ ] Every interactive element has Object ID
|
||||
- [ ] Object IDs follow naming convention
|
||||
- [ ] All Object IDs are unique
|
||||
- [ ] Content specified (not placeholder)
|
||||
- [ ] Multilingual content marked
|
||||
|
||||
### 4. Object Registry Validation
|
||||
|
||||
- [ ] "## Object Registry" header present
|
||||
- [ ] Introduction paragraph present
|
||||
- [ ] At least one Master Object List table
|
||||
- [ ] All Page Section Object IDs in registry
|
||||
- [ ] No orphan Object IDs in registry
|
||||
- [ ] Table formatting correct
|
||||
- [ ] Object IDs use backticks
|
||||
- [ ] All table cells populated
|
||||
|
||||
### 5. Sketch Coverage Validation
|
||||
|
||||
**Process:**
|
||||
1. Open the sketch image
|
||||
2. Identify all visible elements top to bottom
|
||||
3. Check each element has specification in Page Sections
|
||||
4. Mark missing elements
|
||||
|
||||
**Common Missing Elements:**
|
||||
- Background patterns or decorations
|
||||
- Icons within buttons or cards
|
||||
- Subtle UI elements (dividers, borders)
|
||||
- Error states or empty states
|
||||
- Loading indicators
|
||||
- Hover states
|
||||
|
||||
- [ ] All visible elements in sketch are specified
|
||||
- [ ] All interactive states documented
|
||||
- [ ] All content elements captured
|
||||
|
||||
### 6. Design System Linking
|
||||
|
||||
- [ ] Component links present where system exists
|
||||
- [ ] Component links use relative paths
|
||||
- [ ] Component links point to correct locations
|
||||
- [ ] Missing components marked as "TBD" with creation task
|
||||
|
||||
### 7. Cross-Reference Validation
|
||||
|
||||
**Object ID Audit:**
|
||||
|
||||
Create two lists:
|
||||
1. All Object IDs from Page Sections
|
||||
2. All Object IDs from Object Registry
|
||||
|
||||
**Compare:**
|
||||
- [ ] Lists are identical (no missing, no extra)
|
||||
- [ ] No duplicates within either list
|
||||
- [ ] All follow naming convention
|
||||
|
||||
**Path Audit:**
|
||||
|
||||
- [ ] Navigation "Next Step" paths exist
|
||||
- [ ] Sketch image path exists
|
||||
- [ ] Design system component paths exist (where applicable)
|
||||
- [ ] All paths use relative format
|
||||
|
||||
---
|
||||
|
||||
## Generate Quality Report
|
||||
|
||||
<output>
|
||||
# Page Specification Quality Report
|
||||
|
||||
**Page:** {page_number} {page_name}
|
||||
**Date:** {current_date}
|
||||
**Status:** ✅ READY FOR HANDOFF / ⚠️ NEEDS REVISION / ❌ INCOMPLETE
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
**Total Object IDs:** {count}
|
||||
**Sections:** {count}
|
||||
**Components:** {count}
|
||||
|
||||
**Critical Issues:** {count}
|
||||
**Warnings:** {count}
|
||||
**Recommendations:** {count}
|
||||
|
||||
---
|
||||
|
||||
## Section-by-Section Results
|
||||
|
||||
### ✅ Navigation Structure
|
||||
- Status: PASS / FAIL
|
||||
- Issues: [List if any]
|
||||
|
||||
### ✅ Page Overview
|
||||
- Status: PASS / FAIL
|
||||
- Issues: [List if any]
|
||||
|
||||
### ✅ Page Sections
|
||||
- Status: PASS / FAIL
|
||||
- Missing Object IDs: [Count]
|
||||
- Duplicate Object IDs: [Count]
|
||||
- Issues: [List if any]
|
||||
|
||||
### ✅ Object Registry
|
||||
- Status: PASS / FAIL
|
||||
- Objects in Sections: {count}
|
||||
- Objects in Registry: {count}
|
||||
- Match: YES / NO
|
||||
- Issues: [List if any]
|
||||
|
||||
### ✅ Sketch Coverage
|
||||
- Status: PASS / FAIL
|
||||
- Unspecified elements: [List]
|
||||
|
||||
### ✅ Design System Links
|
||||
- Status: PASS / FAIL
|
||||
- Broken links: [Count]
|
||||
- Missing links: [Count]
|
||||
|
||||
---
|
||||
|
||||
## Detailed Findings
|
||||
|
||||
### 🔴 Critical Issues (Must Fix)
|
||||
|
||||
1. [Issue description]
|
||||
- **Location:** [Where in spec]
|
||||
- **Impact:** [Why this matters]
|
||||
- **Fix:** [Specific action needed]
|
||||
|
||||
### ⚠️ Warnings (Should Fix)
|
||||
|
||||
1. [Issue description]
|
||||
- **Location:** [Where in spec]
|
||||
- **Impact:** [Why this matters]
|
||||
- **Fix:** [Specific action needed]
|
||||
|
||||
### 💡 Recommendations (Nice to Have)
|
||||
|
||||
1. [Suggestion]
|
||||
- **Rationale:** [Why this would help]
|
||||
|
||||
---
|
||||
|
||||
## Object ID Audit
|
||||
|
||||
**Total Object IDs:** {count}
|
||||
|
||||
**In Page Sections but not in Registry:**
|
||||
- [List Object IDs]
|
||||
|
||||
**In Registry but not in Page Sections:**
|
||||
- [List Object IDs]
|
||||
|
||||
**Duplicate Object IDs:**
|
||||
- [List duplicates]
|
||||
|
||||
**Naming Convention Violations:**
|
||||
- [List Object IDs not following pattern]
|
||||
|
||||
---
|
||||
|
||||
## Missing Elements from Sketch
|
||||
|
||||
Elements visible in sketch but not specified:
|
||||
|
||||
1. [Element description]
|
||||
- **Location in sketch:** [Where]
|
||||
- **Suggested Object ID:** [Proposed ID]
|
||||
|
||||
---
|
||||
|
||||
## Broken Links Audit
|
||||
|
||||
**Navigation Links:**
|
||||
- [List any broken "Next Step" links]
|
||||
|
||||
**Sketch Image:**
|
||||
- [Report if sketch image path broken]
|
||||
|
||||
**Design System Links:**
|
||||
- [List any broken component links]
|
||||
|
||||
---
|
||||
|
||||
## Next Actions
|
||||
|
||||
**Before Handoff:**
|
||||
1. [Required action]
|
||||
2. [Required action]
|
||||
|
||||
**For Future Iteration:**
|
||||
1. [Optional improvement]
|
||||
2. [Optional improvement]
|
||||
|
||||
---
|
||||
|
||||
## Approval
|
||||
|
||||
**Status:** ✅ APPROVED / ⚠️ CONDITIONAL / ❌ REJECTED
|
||||
|
||||
**Approved by:** [Role - Designer/Lead/PM]
|
||||
**Date:** [Approval date]
|
||||
**Notes:** [Any comments]
|
||||
|
||||
</output>
|
||||
|
||||
---
|
||||
|
||||
## Pass/Fail Criteria
|
||||
|
||||
### ✅ READY FOR HANDOFF
|
||||
|
||||
**All of these must be true:**
|
||||
- [ ] Zero critical issues
|
||||
- [ ] Navigation complete and correct
|
||||
- [ ] Page overview complete
|
||||
- [ ] All Object IDs present and unique
|
||||
- [ ] Object Registry matches Page Sections 100%
|
||||
- [ ] All sketch elements specified
|
||||
- [ ] All paths valid
|
||||
|
||||
**Warnings and recommendations are acceptable** for handoff but should be tracked.
|
||||
|
||||
### ⚠️ NEEDS REVISION
|
||||
|
||||
**If any of these are true:**
|
||||
- 1-3 critical issues present
|
||||
- Object Registry incomplete (<90% match)
|
||||
- Some sketch elements missing (<5)
|
||||
- Some broken links present
|
||||
|
||||
**Action:** Fix critical issues before handoff.
|
||||
|
||||
### ❌ INCOMPLETE
|
||||
|
||||
**If any of these are true:**
|
||||
- 4+ critical issues
|
||||
- Major sections missing
|
||||
- Object Registry severely incomplete (<70% match)
|
||||
- Many sketch elements unspecified (5+)
|
||||
- Multiple broken links
|
||||
|
||||
**Action:** Complete specification before validation.
|
||||
|
||||
---
|
||||
|
||||
## Common Critical Issues
|
||||
|
||||
**These always block handoff:**
|
||||
|
||||
1. **Missing Object IDs on interactive elements**
|
||||
- Developer cannot implement without IDs
|
||||
- Testing impossible without target IDs
|
||||
|
||||
2. **Duplicate Object IDs**
|
||||
- Creates implementation conflicts
|
||||
- Breaks element targeting
|
||||
|
||||
3. **Missing navigation structure**
|
||||
- Developer doesn't know flow
|
||||
- Routing cannot be implemented
|
||||
|
||||
4. **Placeholder content in interactive elements**
|
||||
- Cannot implement button with "TBD" text
|
||||
- Cannot create form with undefined fields
|
||||
|
||||
5. **Object Registry mismatch >10%**
|
||||
- Indicates specification chaos
|
||||
- High risk of missed elements
|
||||
|
||||
---
|
||||
|
||||
## Automated Checks (Future)
|
||||
|
||||
**These checks can be automated:**
|
||||
|
||||
- Object ID uniqueness
|
||||
- Object ID naming convention
|
||||
- Object Registry vs Page Sections matching
|
||||
- Markdown formatting
|
||||
- Path validation
|
||||
- Required section presence
|
||||
|
||||
**Manual checks still needed:**
|
||||
|
||||
- Sketch coverage
|
||||
- Content quality
|
||||
- Purpose statement clarity
|
||||
- Design system appropriateness
|
||||
|
||||
---
|
||||
|
||||
## After Validation
|
||||
|
||||
<if condition="Status is READY FOR HANDOFF">
|
||||
|
||||
### Next Steps
|
||||
|
||||
1. **Save quality report** to spec folder
|
||||
2. **Update scenario tracking** (mark page as complete)
|
||||
3. **Notify team** spec is ready for review
|
||||
4. **Proceed to prototype generation** (if applicable)
|
||||
5. **Hand off to developer** with confidence
|
||||
|
||||
</if>
|
||||
|
||||
<if condition="Status is NEEDS REVISION or INCOMPLETE">
|
||||
|
||||
### Next Steps
|
||||
|
||||
1. **Share quality report** with page owner
|
||||
2. **Prioritize critical issues** from report
|
||||
3. **Fix issues** and re-run validation
|
||||
4. **Track progress** in scenario tracking file
|
||||
5. **Re-validate** when fixes complete
|
||||
|
||||
</if>
|
||||
|
||||
---
|
||||
|
||||
## Quality Metrics Tracking
|
||||
|
||||
**Track these over time to improve process:**
|
||||
|
||||
- Average Object IDs per page
|
||||
- Common missing elements
|
||||
- Most frequent critical issues
|
||||
- Time to fix issues
|
||||
- Pass rate on first validation
|
||||
|
||||
---
|
||||
|
||||
## Completion
|
||||
|
||||
<output>
|
||||
**Page Specification Quality Validation Complete**
|
||||
|
||||
**Final Status:** [✅ READY / ⚠️ NEEDS REVISION / ❌ INCOMPLETE]
|
||||
|
||||
**Summary:**
|
||||
- Validated: {date}
|
||||
- Critical Issues: {count}
|
||||
- Warnings: {count}
|
||||
- Object IDs: {count}
|
||||
|
||||
{if READY}
|
||||
✅ This specification is ready for handoff to development or prototype generation.
|
||||
{endif}
|
||||
|
||||
{if NEEDS REVISION}
|
||||
⚠️ Please address {count} critical issues before proceeding.
|
||||
{endif}
|
||||
|
||||
{if INCOMPLETE}
|
||||
❌ This specification requires substantial work before validation.
|
||||
{endif}
|
||||
|
||||
**Quality Report saved to:** `{path}/quality-report-{date}.md`
|
||||
</output>
|
||||
|
||||
---
|
||||
|
||||
**Workflow Complete** ✅
|
||||
|
||||
Return to: [Page Specification Quality Workflow](instructions.md)
|
||||
|
||||
|
|
@ -4,7 +4,44 @@
|
|||
|
||||
## YOUR TASK
|
||||
|
||||
Initialize the UX Design workflow by welcoming the user and understanding what they want to design.
|
||||
Initialize the UX Design workflow by:
|
||||
1. Loading project structure metadata from project config
|
||||
2. Understanding folder organization requirements
|
||||
3. Welcoming the user and determining what to design
|
||||
|
||||
---
|
||||
|
||||
## CRITICAL: LOAD PROJECT STRUCTURE
|
||||
|
||||
**Before greeting the user**, read the project config to understand project structure:
|
||||
|
||||
<action>
|
||||
Read `{project_root}/config.yaml` (or `{project_root}/wds-workflow-status.yaml`) and extract:
|
||||
|
||||
- `project.structure.type` (landing_page | simple_website | web_application)
|
||||
- `project.structure.scenarios` (single | multiple)
|
||||
- `project.structure.pages` (single | multiple)
|
||||
|
||||
Store this in memory for the entire session.
|
||||
</action>
|
||||
|
||||
**Folder Structure Rules Based on Project Type:**
|
||||
|
||||
- **Landing Page** (`scenarios: single`, `pages: single`):
|
||||
- Place pages directly in `4-scenarios/`
|
||||
- Use page variants if needed: `1.1-start-page/`, `1.1-variant-a/`, `1.1-variant-b/`
|
||||
|
||||
- **Simple Website** (`scenarios: single`, `pages: multiple`):
|
||||
- Place pages directly in `4-scenarios/`
|
||||
- Number pages sequentially: `1.1-home/`, `1.2-about/`, `1.3-contact/`
|
||||
|
||||
- **Web Application** (`scenarios: multiple`, `pages: multiple`):
|
||||
- Create scenario subfolders: `4-scenarios/1-onboarding/`, `4-scenarios/2-dashboard/`
|
||||
- Number pages within each scenario: `1.1-signup/`, `1.2-verify-email/`, `2.1-dashboard/`
|
||||
|
||||
<reminder>
|
||||
This structure was defined during workflow-init. Follow it exactly. Do not create unnecessary subfolders.
|
||||
</reminder>
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -51,8 +88,8 @@ Choice [1/2/3]:</ask>
|
|||
|
||||
### Choice 1: New Scenario
|
||||
|
||||
- Proceed to Step 2 (Scenario Definition)
|
||||
- Load `steps/step-02-define-scenario.md`
|
||||
- Proceed to Step 2 (Scenario Structure Setup)
|
||||
- Load `steps/step-02-setup-scenario-structure.md`
|
||||
|
||||
### Choice 2: Continue Existing
|
||||
|
||||
|
|
@ -72,7 +109,7 @@ Choice [1/2/3]:</ask>
|
|||
|
||||
## NEXT STEP
|
||||
|
||||
After user selects [1] for new scenario, load `steps/step-02-define-scenario.md` to begin scenario definition.
|
||||
After user selects [1] for new scenario, load `steps/step-02-setup-scenario-structure.md` to begin scenario structure setup.
|
||||
|
||||
If user selects [2], determine current state and load appropriate step.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,93 +0,0 @@
|
|||
# Step 2: Define Scenario and Pages
|
||||
|
||||
**Progress: Step 2 of 5** - Next: Page Design
|
||||
|
||||
## YOUR TASK
|
||||
|
||||
Work with the user to define the scenario (user journey) and identify all pages within it.
|
||||
|
||||
---
|
||||
|
||||
## GOAL
|
||||
|
||||
Create clear scenario structure with numbered pages ready for design.
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
<output>**Let's define your scenario.**
|
||||
|
||||
A scenario is a cohesive user journey containing multiple related pages.</output>
|
||||
|
||||
<ask>**What scenario are we designing?**
|
||||
|
||||
Examples:
|
||||
|
||||
- "User Onboarding" (sign up through profile setup)
|
||||
- "Booking Flow" (search through confirmation)
|
||||
- "Dashboard Experience" (home screen with navigation)
|
||||
|
||||
Scenario name:</ask>
|
||||
|
||||
<action>Store scenario_name</action>
|
||||
<action>Determine scenario number (count existing scenarios, add 1)</action>
|
||||
<action>Generate scenario folder: {output_folder}/C-Scenarios/{nn}-{scenario-name}/</action>
|
||||
|
||||
<ask>**What pages are in this scenario?**
|
||||
|
||||
List the main screens/pages in order.
|
||||
|
||||
Example:
|
||||
|
||||
1. Start Page
|
||||
2. Sign Up
|
||||
3. Profile Setup
|
||||
4. Welcome Dashboard</ask>
|
||||
|
||||
<action>Store pages list</action>
|
||||
<action>Create folder structure for each page:
|
||||
|
||||
- {nn}.1-{page-name}/
|
||||
- {nn}.2-{page-name}/
|
||||
- etc.
|
||||
</action>
|
||||
|
||||
<output>✅ **Scenario structure created:**
|
||||
|
||||
`C-Scenarios/{nn}-{scenario-name}/`
|
||||
{{#each page}}
|
||||
|
||||
- `{nn}.{n}-{page-name}/`
|
||||
{{/each}}
|
||||
|
||||
We'll design each page using the 4A-4E process:
|
||||
|
||||
- **4A: Exploration** (optional - think through concept)
|
||||
- **4B: Sketch Analysis** (analyze your sketches)
|
||||
- **4C: Specification** (document everything systematically)
|
||||
- **4D: Prototype** (create interactive HTML)
|
||||
- **4E: PRD Update** (extract functional requirements)
|
||||
|
||||
Ready to design the first page? 🎨</output>
|
||||
|
||||
---
|
||||
|
||||
## MENU
|
||||
|
||||
<ask>[C] Continue to Step 3 (Page Design)</ask>
|
||||
|
||||
---
|
||||
|
||||
## STATE MANAGEMENT
|
||||
|
||||
Before proceeding:
|
||||
|
||||
- Save scenario structure to `C-Scenarios/{nn}-{scenario-name}/scenario-info.yaml`
|
||||
- Include: scenario_name, scenario_number, pages_list, current_page_index (0)
|
||||
|
||||
---
|
||||
|
||||
## NEXT STEP
|
||||
|
||||
When user selects [C], load `steps/step-03-design-page.md` to begin designing the first page.
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
# Step 2: Set Up Scenario Structure
|
||||
|
||||
**Progress: Step 2 of 5** - Next: Page Design
|
||||
|
||||
## YOUR TASK
|
||||
|
||||
Route to the appropriate initialization workshop based on project structure.
|
||||
|
||||
---
|
||||
|
||||
## CRITICAL: READ PROJECT STRUCTURE
|
||||
|
||||
<action>
|
||||
Read `wds-workflow-status.yaml` and extract:
|
||||
- `project_structure.scenarios` (single | multiple)
|
||||
- `project_structure.pages` (single | multiple)
|
||||
|
||||
Determine project structure type:
|
||||
- pages == "single" → SEPARATE_PAGES (individual pages/variants)
|
||||
- scenarios == "single" AND pages == "multiple" → SINGLE_FLOW (one scenario, multiple pages)
|
||||
- scenarios == "multiple" → MULTIPLE_FLOWS (multiple scenarios)
|
||||
|
||||
Store structure_type in memory for this session.
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## ROUTING LOGIC
|
||||
|
||||
### Separate Pages (No Scenarios)
|
||||
<check if="structure_type == SEPARATE_PAGES">
|
||||
<output>**Project Structure:** Separate pages or variants
|
||||
|
||||
You're creating individual pages (like landing pages, dashboards, or page variants). Let's define the first page.</output>
|
||||
|
||||
<action>Skip scenario-init (no scenarios needed)</action>
|
||||
<action>Load and execute: `step-02-substeps/page-init/step-01-page-context.md`</action>
|
||||
</check>
|
||||
|
||||
### Single User Flow (One Scenario)
|
||||
<check if="structure_type == SINGLE_FLOW">
|
||||
<output>**Project Structure:** Single user flow (multiple pages)
|
||||
|
||||
You're creating one continuous user journey across multiple pages. Let's first define the scenario, then the first page.</output>
|
||||
|
||||
<action>Load and execute: `step-02-substeps/scenario-init/step-01-core-feature.md`</action>
|
||||
<output>(After scenario-init completes, it will automatically route to page-init)</output>
|
||||
</check>
|
||||
|
||||
### Multiple User Flows (Multiple Scenarios)
|
||||
<check if="structure_type == MULTIPLE_FLOWS">
|
||||
<output>**Project Structure:** Multiple user flows (scenarios)
|
||||
|
||||
You're creating multiple distinct user journeys, each with their own pages. Let's define the first scenario, then its first page.</output>
|
||||
|
||||
<action>Load and execute: `step-02-substeps/scenario-init/step-01-core-feature.md`</action>
|
||||
<output>(After scenario-init completes, it will automatically route to page-init)</output>
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## CRITICAL RULES
|
||||
|
||||
- 🛑 **NEVER** skip the routing logic
|
||||
- 📖 **ALWAYS** read the full substep file before executing
|
||||
- 🚫 **NEVER** execute multiple flows
|
||||
- ⚠️ **ONLY ONE FLOW** executes based on project structure type
|
||||
|
|
@ -0,0 +1,110 @@
|
|||
# Step 02 Substeps: Reusable Workshops
|
||||
|
||||
This folder contains reusable workshop micro-instructions for scenario and page initialization.
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
### scenario-init/
|
||||
**Reusable scenario definition workshop** (7 micro-steps)
|
||||
|
||||
Used to define a scenario (user flow context):
|
||||
- Core feature/experience
|
||||
- User entry point
|
||||
- Mental state at entry
|
||||
- Mutual success goals (business + user)
|
||||
- Shortest path (page sequence)
|
||||
- Scenario name
|
||||
- Create scenario folder structure
|
||||
|
||||
**Usage:**
|
||||
- **Single page projects:** NOT USED (no scenarios)
|
||||
- **Single scenario projects:** Used ONCE (defines the one scenario)
|
||||
- **Multiple scenarios projects:** Used MULTIPLE TIMES (scenario 1, 2, 3...)
|
||||
|
||||
After completion, automatically routes to `page-init/`.
|
||||
|
||||
---
|
||||
|
||||
### page-init/
|
||||
**Reusable page definition workshop** (8 micro-steps)
|
||||
|
||||
Used to define an individual page:
|
||||
- Page context (determine scenario, page number)
|
||||
- Page name
|
||||
- Page purpose/goal
|
||||
- Entry point(s)
|
||||
- User mental state at entry
|
||||
- Desired outcome (business + user goals)
|
||||
- Page variants (if any)
|
||||
- Create page folder and initial specification document
|
||||
|
||||
**Usage:**
|
||||
- **Single page projects:** Used MULTIPLE TIMES (separate pages or variants)
|
||||
- **Single scenario projects:** Used MULTIPLE TIMES (page 1.1, 1.2, 1.3...)
|
||||
- **Multiple scenarios projects:** Used MULTIPLE TIMES (page 1.1, 1.2, 2.1, 2.2...)
|
||||
|
||||
The page-init workshop is the fundamental reusable building block for ALL page definitions.
|
||||
|
||||
---
|
||||
|
||||
## Flow
|
||||
|
||||
### Single Page Projects
|
||||
```
|
||||
step-02-setup-scenario-structure.md
|
||||
↓
|
||||
page-init/ (page 1)
|
||||
↓
|
||||
[User can add more pages]
|
||||
↓
|
||||
page-init/ (page 2)
|
||||
```
|
||||
|
||||
### Single Scenario Projects
|
||||
```
|
||||
step-02-setup-scenario-structure.md
|
||||
↓
|
||||
scenario-init/ (define scenario)
|
||||
↓
|
||||
page-init/ (page 1.1)
|
||||
↓
|
||||
[User can add more pages]
|
||||
↓
|
||||
page-init/ (page 1.2)
|
||||
```
|
||||
|
||||
### Multiple Scenarios Projects
|
||||
```
|
||||
step-02-setup-scenario-structure.md
|
||||
↓
|
||||
scenario-init/ (scenario 1)
|
||||
↓
|
||||
page-init/ (page 1.1)
|
||||
↓
|
||||
[User can add more pages to scenario 1]
|
||||
↓
|
||||
page-init/ (page 1.2)
|
||||
↓
|
||||
[User can add more scenarios]
|
||||
↓
|
||||
scenario-init/ (scenario 2)
|
||||
↓
|
||||
page-init/ (page 2.1)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Design Principles
|
||||
|
||||
1. **One question per file** - Prevents agent from skipping steps
|
||||
2. **Strict sequential flow** - Each step explicitly loads the next
|
||||
3. **Reusable workshops** - Can be called multiple times as project grows
|
||||
4. **Clear separation** - Scenario definition vs. page definition
|
||||
5. **Context-aware** - Workshops adapt based on project structure
|
||||
|
||||
---
|
||||
|
||||
**Last Updated:** 2025-12-27
|
||||
|
||||
|
|
@ -0,0 +1,327 @@
|
|||
# Page Init (Lightweight)
|
||||
|
||||
**Purpose:** Quick page setup - establish context, create structure, ready for iteration
|
||||
|
||||
---
|
||||
|
||||
## CONTEXT
|
||||
|
||||
**This workflow activates when:** User wants quick page setup without full specification yet.
|
||||
|
||||
**Creates:** Minimal structure (name, purpose, navigation, folders) ready for iteration.
|
||||
|
||||
**Critical:** Navigation links must be established for page comprehension.
|
||||
|
||||
---
|
||||
|
||||
## STEP 1: PAGE BASICS
|
||||
|
||||
<ask>**What's the name of this page?**
|
||||
|
||||
Examples:
|
||||
- "Start Page"
|
||||
- "Sign In"
|
||||
- "Dashboard"
|
||||
- "User Profile"
|
||||
|
||||
Page name:</ask>
|
||||
|
||||
<action>
|
||||
Store page_name
|
||||
Generate page_slug from page_name (lowercase, hyphenated)
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## STEP 2: PURPOSE & SITUATION
|
||||
|
||||
<ask>**What's the PURPOSE of this page?**
|
||||
|
||||
What should this page accomplish?
|
||||
|
||||
Purpose:</ask>
|
||||
|
||||
<action>Store page_purpose</action>
|
||||
|
||||
<ask>**What's the USER'S SITUATION when they arrive?**
|
||||
|
||||
What just happened? What are they trying to do?
|
||||
|
||||
User situation:</ask>
|
||||
|
||||
<action>Store user_situation</action>
|
||||
|
||||
---
|
||||
|
||||
## STEP 3: SCENARIO CONTEXT
|
||||
|
||||
<action>
|
||||
**Determine scenario context:**
|
||||
- Read project structure from wds-workflow-status.yaml
|
||||
- Check existing scenarios
|
||||
- Determine page placement
|
||||
</action>
|
||||
|
||||
<check if="multiple_scenarios_exist">
|
||||
<ask>**Which scenario does this page belong to?**
|
||||
|
||||
Existing scenarios:
|
||||
{{#each scenario in existing_scenarios}}
|
||||
- {{scenario.number}}: {{scenario.name}}
|
||||
{{/each}}
|
||||
|
||||
Choose scenario [number] or "new" for a new scenario:</ask>
|
||||
|
||||
<action>Store scenario_number</action>
|
||||
</check>
|
||||
|
||||
<check if="single_scenario or no_scenarios">
|
||||
<output>This page will be in your main user flow.</output>
|
||||
<action>Set scenario_number = 1</action>
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## STEP 4: NAVIGATION FLOW (CRITICAL!)
|
||||
|
||||
<output>**Now let's establish navigation - this is crucial for comprehension!**</output>
|
||||
|
||||
<action>
|
||||
**Determine page number:**
|
||||
- Count existing pages in scenario
|
||||
- Calculate next page number
|
||||
- Store page_number (e.g., "1.1", "1.2", "2.1")
|
||||
</action>
|
||||
|
||||
<ask>**What page comes BEFORE this one?**
|
||||
|
||||
{{#if existing_pages_in_scenario.length > 0}}
|
||||
Existing pages:
|
||||
{{#each page in existing_pages_in_scenario}}
|
||||
- {{page.number}}: {{page.name}}
|
||||
{{/each}}
|
||||
|
||||
Type page number, or "none" if this is the first page:
|
||||
{{else}}
|
||||
This is the first page in the scenario. Type "none":
|
||||
{{/if}}
|
||||
|
||||
Previous page:</ask>
|
||||
|
||||
<action>Store previous_page</action>
|
||||
|
||||
<ask>**What page comes AFTER this one?**
|
||||
|
||||
- If you know: Type the page name (we'll create it next)
|
||||
- If unsure: Type "TBD"
|
||||
- If last page: Type "none"
|
||||
|
||||
Next page:</ask>
|
||||
|
||||
<action>Store next_page</action>
|
||||
|
||||
---
|
||||
|
||||
## STEP 5: CREATE STRUCTURE
|
||||
|
||||
<output>**Creating page structure...**</output>
|
||||
|
||||
<action>
|
||||
**Create folder structure:**
|
||||
|
||||
Path: `4-scenarios/{{scenario_path}}/{{page_number}}-{{page_slug}}/`
|
||||
|
||||
Create:
|
||||
1. Page folder: `{{page_number}}-{{page_slug}}/`
|
||||
2. Sketches folder: `{{page_number}}-{{page_slug}}/sketches/`
|
||||
3. Placeholder document: `{{page_number}}-{{page_slug}}.md`
|
||||
</action>
|
||||
|
||||
<action>
|
||||
**Generate placeholder document:**
|
||||
|
||||
File: `4-scenarios/{{scenario_path}}/{{page_number}}-{{page_slug}}/{{page_number}}-{{page_slug}}.md`
|
||||
|
||||
Content:
|
||||
```markdown
|
||||
{{#if previous_page != "none"}}
|
||||
← [{{previous_page}}](../{{previous_page_slug}}/{{previous_page_slug}}.md)
|
||||
{{/if}}
|
||||
{{#if next_page != "none" and next_page != "TBD"}}
|
||||
| [{{next_page}}](../{{next_page_slug}}/{{next_page_slug}}.md) →
|
||||
{{/if}}
|
||||
{{#if next_page == "TBD"}}
|
||||
| Next: TBD
|
||||
{{/if}}
|
||||
|
||||
|
||||
|
||||
{{#if previous_page != "none"}}
|
||||
← [{{previous_page}}](../{{previous_page_slug}}/{{previous_page_slug}}.md)
|
||||
{{/if}}
|
||||
{{#if next_page != "none" and next_page != "TBD"}}
|
||||
| [{{next_page}}](../{{next_page_slug}}/{{next_page_slug}}.md) →
|
||||
{{/if}}
|
||||
|
||||
# {{page_number}} {{page_name}}
|
||||
|
||||
**User Situation:** {{user_situation}}
|
||||
|
||||
**Page Purpose:** {{page_purpose}}
|
||||
|
||||
---
|
||||
|
||||
## Status
|
||||
|
||||
⚠️ **PLACEHOLDER** - This page needs:
|
||||
- [ ] Sketch or screenshot
|
||||
- [ ] Section breakdown
|
||||
- [ ] Object specifications
|
||||
- [ ] Component links
|
||||
- [ ] Interaction definitions
|
||||
- [ ] States and variants
|
||||
|
||||
---
|
||||
|
||||
## Navigation Context
|
||||
|
||||
{{#if previous_page != "none"}}
|
||||
**Previous:** {{previous_page}}
|
||||
{{else}}
|
||||
**This is the first page in the scenario**
|
||||
{{/if}}
|
||||
|
||||
{{#if next_page == "TBD"}}
|
||||
**Next:** TBD (to be defined)
|
||||
{{else if next_page != "none"}}
|
||||
**Next:** {{next_page}}
|
||||
{{else}}
|
||||
**This is the last page in the scenario**
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
To complete this page specification:
|
||||
|
||||
1. **Add a sketch**: Place your sketch in `sketches/` folder
|
||||
2. **Run Page Process Workshop**: Analyze your sketch
|
||||
3. **Specify sections**: Define all page sections
|
||||
4. **Specify objects**: Define all interactive elements with Object IDs
|
||||
5. **Link components**: Connect to design system components
|
||||
6. **Document states**: Define loading, error, success, empty states
|
||||
7. **Generate prototype**: Create interactive HTML preview
|
||||
|
||||
---
|
||||
|
||||
{{#if previous_page != "none"}}
|
||||
**Previous Step**: ← [{{previous_page}}](../{{previous_page_slug}}/{{previous_page_slug}}.md)
|
||||
{{/if}}
|
||||
{{#if next_page != "none" and next_page != "TBD"}}
|
||||
**Next Step**: → [{{next_page}}](../{{next_page_slug}}/{{next_page_slug}}.md)
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
_Placeholder created using Whiteport Design Studio (WDS) methodology_
|
||||
```
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## STEP 6: UPDATE NAVIGATION
|
||||
|
||||
<check if="previous_page != 'none'">
|
||||
<action>
|
||||
**Update previous page document:**
|
||||
- Open previous page .md file
|
||||
- Update "Next" link to point to this page
|
||||
- Save
|
||||
</action>
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## STEP 7: COMPLETION
|
||||
|
||||
<output>✅ **Page initialized!**
|
||||
|
||||
**Created:**
|
||||
- Folder: `{{page_number}}-{{page_slug}}/`
|
||||
- Document: `{{page_number}}-{{page_slug}}.md`
|
||||
- Sketches folder: `sketches/`
|
||||
|
||||
**Page details:**
|
||||
- **Number:** {{page_number}}
|
||||
- **Name:** {{page_name}}
|
||||
- **Purpose:** {{page_purpose}}
|
||||
|
||||
**Navigation:**
|
||||
{{#if previous_page != "none"}}
|
||||
- Previous: {{previous_page}} ✅ linked
|
||||
{{else}}
|
||||
- First page in scenario
|
||||
{{/if}}
|
||||
{{#if next_page != "none" and next_page != "TBD"}}
|
||||
- Next: {{next_page}} ✅ linked
|
||||
{{else if next_page == "TBD"}}
|
||||
- Next: TBD
|
||||
{{else}}
|
||||
- Last page in scenario
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
**Next steps:**
|
||||
|
||||
1. **Add your sketch** to `sketches/` folder
|
||||
2. **Run Page Process Workshop** to analyze it
|
||||
|
||||
Or:
|
||||
|
||||
[A] Add sketch now and analyze
|
||||
[B] Create another page first
|
||||
[C] Back to scenario overview
|
||||
|
||||
Choice:</output>
|
||||
|
||||
---
|
||||
|
||||
## ROUTING
|
||||
|
||||
<action>
|
||||
Based on user choice:
|
||||
- [A] → workshop-page-process.md (with this page context)
|
||||
- [B] → Repeat page-init for next page
|
||||
- [C] → Return to scenario overview / main menu
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## KEY PRINCIPLES
|
||||
|
||||
### ✅ **Navigation is Critical**
|
||||
- Appears twice (top & after sketch)
|
||||
- Links to previous/next pages
|
||||
- Creates navigable flow
|
||||
- Essential for comprehension
|
||||
|
||||
### ✅ **Lightweight Setup**
|
||||
- Quick to create
|
||||
- No detailed specs yet
|
||||
- Just enough to get started
|
||||
- Ready for iteration
|
||||
|
||||
### ✅ **Context Captured**
|
||||
- Name, purpose, situation
|
||||
- Scenario placement
|
||||
- Page number assigned
|
||||
- Flow established
|
||||
|
||||
---
|
||||
|
||||
**Created:** December 28, 2025
|
||||
**Purpose:** Quick page initialization with navigation
|
||||
**Status:** Ready for WDS Presentation page
|
||||
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
# Page Init - Entry Point
|
||||
|
||||
**Purpose:** Route user to appropriate page creation workflow
|
||||
|
||||
---
|
||||
|
||||
## ROUTING
|
||||
|
||||
<action>
|
||||
**Understand from conversation context:**
|
||||
|
||||
Check what user has said:
|
||||
- Did they mention having a sketch/wireframe/visualization?
|
||||
- Did they upload an image file?
|
||||
- Are they describing a page concept without visual?
|
||||
- Are they asking about creating/defining a page?
|
||||
|
||||
**Route based on understanding:**
|
||||
|
||||
IF user has sketch/visualization ready:
|
||||
→ Load and execute: `step-02-substeps/page-init/workshop-page-process.md`
|
||||
└─> Intelligent context detection
|
||||
└─> New page: Full analysis
|
||||
└─> Updated page: Change detection & incremental update
|
||||
|
||||
IF user is describing concept without visualization:
|
||||
→ Load and execute: `step-02-substeps/page-init/workshop-page-creation.md`
|
||||
└─> Define page purpose and concept
|
||||
└─> Choose visualization method naturally
|
||||
└─> Create conceptual specification
|
||||
|
||||
IF unclear what user wants:
|
||||
→ Ask natural clarifying question based on context
|
||||
Example: "Do you have a sketch or wireframe I should look at, or should we define the page concept together?"
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## PHILOSOPHY
|
||||
|
||||
**The page is the conceptual entity.**
|
||||
|
||||
It has:
|
||||
- A purpose (what it accomplishes)
|
||||
- A user (who it serves)
|
||||
- Sections (what areas exist)
|
||||
- Objects (what interactions happen)
|
||||
- A place in the flow (navigation)
|
||||
|
||||
**Visualization is how we represent the page.**
|
||||
|
||||
Methods include:
|
||||
- Sketch (hand-drawn or digital)
|
||||
- Wireframe (tool-based)
|
||||
- ASCII layout (text-based)
|
||||
- Verbal description (discussion)
|
||||
- Reference (based on existing page)
|
||||
|
||||
**Page first. Visualization second.**
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Step 2: Page Name
|
||||
|
||||
---
|
||||
|
||||
<ask>**What's the name of this page?**
|
||||
|
||||
Examples:
|
||||
- Start Page / Home
|
||||
- About
|
||||
- Contact
|
||||
- Dashboard
|
||||
- User Profile
|
||||
- Checkout
|
||||
- Confirmation
|
||||
|
||||
Page name:</ask>
|
||||
|
||||
<action>Store page_name</action>
|
||||
<action>Generate page_slug from page_name (lowercase, hyphenated)</action>
|
||||
<template-output>page_name, page_slug</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/page-init/step-03-page-purpose.md`</action>
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# Step 3: Page Purpose
|
||||
|
||||
---
|
||||
|
||||
<ask>**What's the purpose of this page?**
|
||||
|
||||
What should this page accomplish?
|
||||
|
||||
Examples:
|
||||
- Capture user's attention and explain core value
|
||||
- Collect contact information for lead generation
|
||||
- Guide user through account setup
|
||||
- Display personalized dashboard with key metrics
|
||||
- Allow user to update their profile settings
|
||||
|
||||
Purpose:</ask>
|
||||
|
||||
<action>Store page_purpose</action>
|
||||
<template-output>page_purpose</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/page-init/step-04-entry-point.md`</action>
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
# Step 4: Entry Point
|
||||
|
||||
---
|
||||
|
||||
<ask>**Where do users arrive from?**
|
||||
|
||||
How do users get to this page?
|
||||
|
||||
Examples:
|
||||
- Google search (external)
|
||||
- Social media ad (external)
|
||||
- Email link (external)
|
||||
- QR code (external)
|
||||
- Navigation menu (internal)
|
||||
- Previous page in flow (internal)
|
||||
- Direct URL (bookmark)
|
||||
|
||||
Entry point(s):</ask>
|
||||
|
||||
<action>Store entry_point</action>
|
||||
<template-output>entry_point</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/page-init/step-05-mental-state.md`</action>
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
# Step 5: Mental State
|
||||
|
||||
---
|
||||
|
||||
<ask>**What's the user's mental state when arriving?**
|
||||
|
||||
Consider:
|
||||
- What just happened? (trigger)
|
||||
- What are they hoping for?
|
||||
- What are they worried about?
|
||||
- What questions do they have?
|
||||
|
||||
Mental state:</ask>
|
||||
|
||||
<action>Store mental_state</action>
|
||||
<template-output>mental_state</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/page-init/step-06-desired-outcome.md`</action>
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
# Step 6: Desired Outcome
|
||||
|
||||
---
|
||||
|
||||
<ask>**What's the desired outcome?**
|
||||
|
||||
What should happen on this page?
|
||||
|
||||
**Business Goal:**
|
||||
(What does the business want to achieve?)
|
||||
|
||||
**User Goal:**
|
||||
(What does the user want to accomplish?)</ask>
|
||||
|
||||
<action>Store business_goal and user_goal</action>
|
||||
<template-output>business_goal, user_goal</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/page-init/step-07-variants.md`</action>
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# Step 7: Page Variants
|
||||
|
||||
---
|
||||
|
||||
<ask>**Will you have page variants?**
|
||||
|
||||
For A/B testing, different audiences, or localization? (y/n)</ask>
|
||||
|
||||
<action>Store has_variants</action>
|
||||
|
||||
<check if="has_variants == 'y' or has_variants == 'yes'">
|
||||
<ask>**How many variants?**
|
||||
|
||||
Number of variants:</ask>
|
||||
|
||||
<action>Store variant_count</action>
|
||||
<template-output>has_variants, variant_count</template-output>
|
||||
</check>
|
||||
|
||||
<check if="has_variants == 'n' or has_variants == 'no'">
|
||||
<action>Store variant_count = 1</action>
|
||||
<template-output>has_variants, variant_count</template-output>
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/page-init/step-08-create-page-structure.md`</action>
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
# Step 8: Create Page Structure
|
||||
|
||||
---
|
||||
|
||||
<action>
|
||||
**Determine page folder path:**
|
||||
|
||||
**For single page projects (no scenarios):**
|
||||
- Page path: `4-scenarios/{{page_slug}}/`
|
||||
|
||||
**For scenario-based projects:**
|
||||
- Read scenario_number from context
|
||||
- Read current_page_index from `scenario-tracking.yaml`
|
||||
- Calculate page_number: `{{scenario_number}}.{{current_page_index + 1}}`
|
||||
- Page path: `4-scenarios/{{scenario_number}}-{{scenario-slug}}/{{page_number}}-{{page_slug}}/`
|
||||
|
||||
Store page_path and page_number
|
||||
</action>
|
||||
|
||||
<action>
|
||||
**Create physical folder structure:**
|
||||
|
||||
1. Create page directory: `{{page_path}}`
|
||||
2. Create sketches subdirectory: `{{page_path}}sketches/`
|
||||
3. If has_variants and variant_count > 1:
|
||||
- Create variant subdirectories:
|
||||
- `{{page_path}}variant-a/sketches/`
|
||||
- `{{page_path}}variant-b/sketches/`
|
||||
- (etc. for each variant)
|
||||
|
||||
**Generate page specification document:**
|
||||
|
||||
File: `{{page_path}}{{page_number}}-{{page_slug}}.md`
|
||||
|
||||
Content:
|
||||
```markdown
|
||||
# {{page_number}} {{page_name}}
|
||||
|
||||
{{#if scenario_name}}
|
||||
**Scenario:** {{scenario_name}}
|
||||
{{/if}}
|
||||
**Page Number:** {{page_number}}
|
||||
**Created:** {{date}}
|
||||
**Method:** Whiteport Design Studio (WDS)
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**Page Purpose:** {{page_purpose}}
|
||||
|
||||
**Entry Points:**
|
||||
- {{entry_point}}
|
||||
|
||||
**User Mental State:**
|
||||
{{mental_state}}
|
||||
|
||||
**Main User Goal:** {{user_goal}}
|
||||
|
||||
**Business Goal:** {{business_goal}}
|
||||
|
||||
**URL/Route:** [To be determined]
|
||||
|
||||
---
|
||||
|
||||
{{#if scenario_name}}
|
||||
## Journey Context
|
||||
|
||||
{{#if total_pages}}
|
||||
This is **page {{current_page_index + 1}} of {{total_pages}}** in the "{{scenario_name}}" scenario.
|
||||
{{/if}}
|
||||
|
||||
{{#if next_page}}
|
||||
**Next Page:** {{next_page}}
|
||||
{{/if}}
|
||||
|
||||
{{#if scenario_goal}}
|
||||
**Scenario Goal:** {{scenario_goal}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
{{/if}}
|
||||
|
||||
## Design Sections
|
||||
|
||||
[To be filled during sketch analysis and specification]
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. Add sketches to `sketches/` folder
|
||||
2. Run substep 4B (Sketch Analysis) to analyze sketches
|
||||
3. Continue with substep 4C (Specification) to complete full details
|
||||
4. Generate prototype (substep 4D)
|
||||
5. Extract requirements (substep 4E)
|
||||
|
||||
---
|
||||
|
||||
_This starter document was generated from the page initialization workshop. Complete the full specification using the 4A-4E design process._
|
||||
```
|
||||
|
||||
**Update scenario-tracking.yaml (if applicable):**
|
||||
|
||||
If this is a scenario-based project:
|
||||
- Update current_page_index: increment by 1
|
||||
- Update page status in pages_list
|
||||
</action>
|
||||
|
||||
<output>✅ **Page structure created:**
|
||||
|
||||
**Page:** {{page_number}} {{page_name}}
|
||||
|
||||
**Folder:**
|
||||
- `{{page_path}}`
|
||||
|
||||
**Purpose:** {{page_purpose}}
|
||||
|
||||
{{#if has_variants}}
|
||||
**Variants:** {{variant_count}}
|
||||
{{/if}}
|
||||
|
||||
**Next Steps:**
|
||||
- Add sketches to the sketches folder
|
||||
- Continue with page design (Step 3)
|
||||
|
||||
Ready to design! 🎨</output>
|
||||
|
||||
---
|
||||
|
||||
<output>[C] Continue to Step 3 (Page Design)
|
||||
[A] Add Another Page
|
||||
[S] Add Another Scenario (if multi-scenario project)</output>
|
||||
|
||||
<action>
|
||||
- If user selects [C], load `steps/step-03-design-page.md`
|
||||
- If user selects [A], reload `step-02-substeps/page-init/step-01-page-context.md`
|
||||
- If user selects [S], load `step-02-substeps/scenario-init/step-01-core-feature.md`
|
||||
</action>
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,406 @@
|
|||
# Workshop C: Placeholder Pages
|
||||
|
||||
**Trigger:** User wants to quickly map out a scenario structure without full specifications
|
||||
|
||||
---
|
||||
|
||||
## WORKSHOP GOAL
|
||||
|
||||
Rapidly create placeholder page documents with:
|
||||
- Navigation structure
|
||||
- Page names
|
||||
- Page purposes
|
||||
- Scenario context
|
||||
|
||||
This gives clarity to the overall flow before diving into detailed specifications.
|
||||
|
||||
---
|
||||
|
||||
## PHASE 1: TRIGGER DETECTION
|
||||
|
||||
<output>**Let's map out your scenario structure!**
|
||||
|
||||
Sometimes it helps to create placeholder pages first - just the names, purposes, and navigation - before diving into detailed specifications. This gives you a clear roadmap.
|
||||
|
||||
Would you like to:
|
||||
- Create placeholders for a whole scenario flow
|
||||
- Add individual placeholder pages as you plan
|
||||
|
||||
Let's start! 📋</output>
|
||||
|
||||
---
|
||||
|
||||
## PHASE 2: SCENARIO CONTEXT
|
||||
|
||||
<action>
|
||||
**Determine scenario context:**
|
||||
- Read project structure from wds-workflow-status.yaml
|
||||
- Check existing scenarios
|
||||
- Determine if working with existing or new scenario
|
||||
</action>
|
||||
|
||||
<ask>**Which scenario are we mapping out?**
|
||||
|
||||
{{#if existing_scenarios}}
|
||||
Existing scenarios:
|
||||
{{#each scenario in existing_scenarios}}
|
||||
- {{scenario.number}}: {{scenario.name}}
|
||||
{{/each}}
|
||||
|
||||
Type scenario number or "new" for a new scenario:
|
||||
{{else}}
|
||||
This will be your first scenario. What should we call it?
|
||||
|
||||
Scenario name:
|
||||
{{/if}}</ask>
|
||||
|
||||
<action>
|
||||
Store scenario_number and scenario_name
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## PHASE 3: FLOW MAPPING
|
||||
|
||||
<output>**Great! Let's map out the pages in this flow.**
|
||||
|
||||
Think about the user journey through "{{scenario_name}}"</output>
|
||||
|
||||
<ask>**How many pages will be in this scenario?**
|
||||
|
||||
Think about the steps a user goes through:
|
||||
- Entry point / first page
|
||||
- Middle steps (actions, decisions, inputs)
|
||||
- Completion / exit page
|
||||
|
||||
Number of pages:</ask>
|
||||
|
||||
<action>Store pages_count</action>
|
||||
|
||||
---
|
||||
|
||||
## PHASE 4: PAGE ENUMERATION
|
||||
|
||||
<output>**Perfect! Let's name and define each page.**
|
||||
|
||||
I'll guide you through {{pages_count}} pages...</output>
|
||||
|
||||
<action>For page_index from 1 to pages_count, run this loop:</action>
|
||||
|
||||
<output>---
|
||||
|
||||
### Page {{page_index}} of {{pages_count}}
|
||||
|
||||
</output>
|
||||
|
||||
<ask>**What should we call this page?**
|
||||
|
||||
Examples:
|
||||
- "Start Page" / "Home"
|
||||
- "Sign In"
|
||||
- "User Profile"
|
||||
- "Checkout"
|
||||
- "Confirmation"
|
||||
|
||||
Page name:</ask>
|
||||
|
||||
<action>
|
||||
Store page_name
|
||||
Generate page_slug
|
||||
Calculate page_number (scenario.page_index)
|
||||
</action>
|
||||
|
||||
<ask>**What's the PURPOSE of "{{page_name}}"?**
|
||||
|
||||
In 1-2 sentences:
|
||||
- What does the user accomplish here?
|
||||
- What happens on this page?
|
||||
|
||||
Purpose:</ask>
|
||||
|
||||
<action>Store page_purpose</action>
|
||||
|
||||
<ask>**What's the USER'S SITUATION when they arrive?**
|
||||
|
||||
What just happened? What are they trying to do?
|
||||
|
||||
User situation:</ask>
|
||||
|
||||
<action>Store user_situation</action>
|
||||
|
||||
<output>✓ **Page {{page_index}} defined:**
|
||||
|
||||
{{page_number}}-{{page_slug}}: {{page_name}}
|
||||
- Purpose: {{page_purpose}}
|
||||
- Situation: {{user_situation}}</output>
|
||||
|
||||
<action>Continue to next page</action>
|
||||
|
||||
---
|
||||
|
||||
## PHASE 5: FLOW REVIEW
|
||||
|
||||
<output>**Here's your complete scenario flow:**
|
||||
|
||||
**Scenario {{scenario_number}}: {{scenario_name}}**
|
||||
|
||||
{{#each page in pages_list}}
|
||||
{{@index + 1}}. **{{page.number}}-{{page.slug}}** - {{page.name}}
|
||||
Purpose: {{page.purpose}}
|
||||
User: {{page.situation}}
|
||||
|
||||
{{/each}}
|
||||
|
||||
Does this flow make sense? Any pages missing or in wrong order?</output>
|
||||
|
||||
<ask>**Review the flow:**
|
||||
|
||||
- Type "good" to proceed
|
||||
- Type "add" to insert a page
|
||||
- Type "remove N" to remove page N
|
||||
- Type "move N to M" to reorder
|
||||
|
||||
Action:</ask>
|
||||
|
||||
<action>
|
||||
Process user adjustments:
|
||||
- Add pages if needed
|
||||
- Remove pages if requested
|
||||
- Renumber pages after changes
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## PHASE 6: GENERATE PLACEHOLDER DOCUMENTS
|
||||
|
||||
<output>**Perfect! Creating your placeholder pages now...**
|
||||
|
||||
Generating {{pages_list.length}} page documents...</output>
|
||||
|
||||
<action>
|
||||
For each page in pages_list:
|
||||
|
||||
**Create folder structure:**
|
||||
`4-scenarios/{{scenario_path}}/{{page.number}}-{{page.slug}}/`
|
||||
`4-scenarios/{{scenario_path}}/{{page.number}}-{{page.slug}}/sketches/`
|
||||
|
||||
**Generate placeholder document:**
|
||||
|
||||
File: `4-scenarios/{{scenario_path}}/{{page.number}}-{{page.slug}}/{{page.number}}-{{page.slug}}.md`
|
||||
|
||||
Content:
|
||||
```markdown
|
||||
{{#if @index > 0}}
|
||||
← [{{pages_list[@index - 1].number}}-{{pages_list[@index - 1].slug}}](../{{pages_list[@index - 1].number}}-{{pages_list[@index - 1].slug}}/{{pages_list[@index - 1].number}}-{{pages_list[@index - 1].slug}}.md)
|
||||
{{/if}}
|
||||
{{#if @index < pages_list.length - 1}}
|
||||
| [{{pages_list[@index + 1].number}}-{{pages_list[@index + 1].slug}}](../{{pages_list[@index + 1].number}}-{{pages_list[@index + 1].slug}}/{{pages_list[@index + 1].number}}-{{pages_list[@index + 1].slug}}.md) →
|
||||
{{/if}}
|
||||
|
||||
# {{page.number}} {{page.name}}
|
||||
|
||||
**User Situation:** {{page.situation}}
|
||||
|
||||
**Page Purpose:** {{page.purpose}}
|
||||
|
||||
---
|
||||
|
||||
## Status
|
||||
|
||||
⚠️ **PLACEHOLDER** - This page needs:
|
||||
- [ ] Sketch or screenshot
|
||||
- [ ] Section breakdown
|
||||
- [ ] Object specifications
|
||||
- [ ] Component links
|
||||
- [ ] Interaction definitions
|
||||
- [ ] States and variants
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
To complete this page specification:
|
||||
|
||||
1. **Add a sketch**: Place sketch in `sketches/` folder
|
||||
2. **Run Workshop A**: Sketch Analysis Workshop to break down the visual
|
||||
3. **Specify objects**: Define all interactive elements with Object IDs
|
||||
4. **Link components**: Connect to design system components
|
||||
5. **Document states**: Define loading, error, success, empty states
|
||||
|
||||
---
|
||||
|
||||
{{#if @index > 0}}
|
||||
**Previous Step**: ← [{{pages_list[@index - 1].number}}-{{pages_list[@index - 1].slug}}](../{{pages_list[@index - 1].number}}-{{pages_list[@index - 1].slug}}/{{pages_list[@index - 1].number}}-{{pages_list[@index - 1].slug}}.md)
|
||||
{{/if}}
|
||||
{{#if @index < pages_list.length - 1}}
|
||||
**Next Step**: → [{{pages_list[@index + 1].number}}-{{pages_list[@index + 1].slug}}](../{{pages_list[@index + 1].number}}-{{pages_list[@index + 1].slug}}/{{pages_list[@index + 1].number}}-{{pages_list[@index + 1].slug}}.md)
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
_Placeholder created using Whiteport Design Studio (WDS) methodology_
|
||||
```
|
||||
</action>
|
||||
|
||||
<action>
|
||||
**Create scenario overview document:**
|
||||
|
||||
File: `4-scenarios/{{scenario_path}}/00-{{scenario_slug}}-scenario.md`
|
||||
|
||||
Content:
|
||||
```markdown
|
||||
# {{scenario_number}} {{scenario_name}} - Scenario Overview
|
||||
|
||||
**Project**: {{project_name}}
|
||||
**Date Created**: {{date}}
|
||||
**Last Updated**: {{date}}
|
||||
|
||||
## Scenario Overview
|
||||
|
||||
[Brief description of this scenario - to be filled in]
|
||||
|
||||
## Scenario Steps
|
||||
|
||||
{{#each page in pages_list}}
|
||||
### **{{page.number}} {{page.name}}**
|
||||
**Purpose**: {{page.purpose}}
|
||||
**Status**: ⚠️ Placeholder
|
||||
**Files**: [{{page.number}}-{{page.slug}}.md]({{page.number}}-{{page.slug}}/{{page.number}}-{{page.slug}}.md)
|
||||
|
||||
{{/each}}
|
||||
|
||||
## User Journey Flow
|
||||
|
||||
```
|
||||
{{#each page in pages_list}}
|
||||
{{page.number}}-{{page.slug}}{{#unless @last}} → {{/unless}}
|
||||
{{/each}}
|
||||
```
|
||||
|
||||
## Status
|
||||
|
||||
{{pages_list.length}} placeholder pages created. Each page needs:
|
||||
- Sketch or visual concept
|
||||
- Detailed specifications
|
||||
- Object definitions
|
||||
- Component links
|
||||
|
||||
---
|
||||
|
||||
_Created using Whiteport Design Studio (WDS) methodology_
|
||||
```
|
||||
</action>
|
||||
|
||||
<action>
|
||||
**Create scenario tracking file:**
|
||||
|
||||
File: `4-scenarios/{{scenario_path}}/scenario-tracking.yaml`
|
||||
|
||||
Content:
|
||||
```yaml
|
||||
scenario_number: {{scenario_number}}
|
||||
scenario_name: "{{scenario_name}}"
|
||||
pages_list:
|
||||
{{#each page in pages_list}}
|
||||
- name: "{{page.name}}"
|
||||
slug: "{{page.slug}}"
|
||||
page_number: "{{page.number}}"
|
||||
purpose: "{{page.purpose}}"
|
||||
status: "placeholder"
|
||||
{{/each}}
|
||||
current_page_index: 0
|
||||
total_pages: {{pages_list.length}}
|
||||
created_date: "{{date}}"
|
||||
```
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## PHASE 7: COMPLETION SUMMARY
|
||||
|
||||
<output>✅ **Placeholder pages created!**
|
||||
|
||||
**Scenario:** {{scenario_number}} - {{scenario_name}}
|
||||
|
||||
**Created:**
|
||||
- {{pages_list.length}} page folders with navigation
|
||||
- {{pages_list.length}} placeholder documents
|
||||
- 1 scenario overview document
|
||||
- 1 scenario tracking file
|
||||
|
||||
**File structure:**
|
||||
```
|
||||
4-scenarios/
|
||||
{{scenario_path}}/
|
||||
00-{{scenario_slug}}-scenario.md
|
||||
scenario-tracking.yaml
|
||||
{{#each page in pages_list}}
|
||||
{{page.number}}-{{page.slug}}/
|
||||
{{page.number}}-{{page.slug}}.md ⚠️ PLACEHOLDER
|
||||
sketches/
|
||||
{{/each}}
|
||||
```
|
||||
|
||||
**Your scenario flow:**
|
||||
```
|
||||
{{#each page in pages_list}}
|
||||
{{page.number}}-{{page.slug}}: {{page.name}}
|
||||
{{/each}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
You can now:
|
||||
|
||||
1. **Add sketches** - Upload visuals for each page
|
||||
2. **Complete specifications** - Run Workshop A (Sketch Analysis) for each page
|
||||
3. **Add more pages** - Come back and add pages to this scenario
|
||||
4. **Create another scenario** - Start a new user journey
|
||||
|
||||
**Ready to work on a specific page?**
|
||||
|
||||
Pick a page to work on:
|
||||
{{#each page in pages_list}}
|
||||
[{{@index + 1}}] {{page.name}}
|
||||
{{/each}}
|
||||
[N] Add another scenario
|
||||
[D] Done for now
|
||||
|
||||
Choice:</output>
|
||||
|
||||
---
|
||||
|
||||
## ROUTING
|
||||
|
||||
<action>
|
||||
**Based on user choice:**
|
||||
- If user picks a page number → Route to Workshop B (Sketch Creation) for that page
|
||||
- If user selects [N] → Route to scenario-init workshop
|
||||
- If user selects [D] → Return to main UX design menu
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## NOTES FOR IMPLEMENTATION
|
||||
|
||||
**Advantages of placeholders:**
|
||||
- Quick mapping of entire flow
|
||||
- Clear navigation before details
|
||||
- Easy to see gaps or redundancies
|
||||
- Can be reviewed by stakeholders early
|
||||
- Team can work on different pages in parallel
|
||||
|
||||
**When to use:**
|
||||
- New projects starting from scratch
|
||||
- Complex multi-page scenarios
|
||||
- When need for early stakeholder review
|
||||
- Before diving into visual design
|
||||
|
||||
**When NOT to use:**
|
||||
- Single page projects
|
||||
- When sketch already exists (use Workshop A)
|
||||
- Small modifications to existing flow
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,578 @@
|
|||
# Workshop: Page Creation (Discussion-Based)
|
||||
|
||||
**Purpose:** Define a page concept through conversation, create visualization method based on need
|
||||
|
||||
---
|
||||
|
||||
## CONTEXT
|
||||
|
||||
**This workflow activates when:** User needs to define a page concept but doesn't have a visualization yet.
|
||||
|
||||
**Goal:** Define what the page IS, then choose how to visualize it.
|
||||
|
||||
**Philosophy:** The page (concept) comes first. Visualization (method) follows.
|
||||
|
||||
---
|
||||
|
||||
## STEP 1: PAGE CONCEPT
|
||||
|
||||
<ask>**What is this page about?**
|
||||
|
||||
Tell me in your own words:
|
||||
- What is this page called?
|
||||
- What should it accomplish?
|
||||
- Who uses it and why?
|
||||
|
||||
Describe the page concept:</ask>
|
||||
|
||||
<action>Store page_concept</action>
|
||||
|
||||
---
|
||||
|
||||
## STEP 2: VISUALIZATION PREFERENCE
|
||||
|
||||
<ask>**How would you like to visualize this page?**
|
||||
|
||||
[A] I'll draw a sketch (physical/digital) and upload it
|
||||
[B] Let's describe it verbally - I'll specify sections through discussion
|
||||
[C] Create a simple ASCII layout together
|
||||
[D] It's similar to another page I can reference
|
||||
[E] Generate HTML prototype - I'll screenshot it for documentation
|
||||
|
||||
Choice:</ask>
|
||||
|
||||
<action>Store visualization_method</action>
|
||||
|
||||
---
|
||||
|
||||
## NOTE ON OPTION E (HTML Prototype)
|
||||
|
||||
**This is the bridge method:**
|
||||
```
|
||||
Concept → HTML Code → Render → Screenshot → Documentation
|
||||
```
|
||||
|
||||
**Benefits:**
|
||||
- ✅ Professional, pixel-perfect visualization
|
||||
- ✅ Tests actual layout behavior
|
||||
- ✅ Responsive/mobile preview available
|
||||
- ✅ Can iterate quickly
|
||||
- ✅ Screenshot becomes the "sketch"
|
||||
- ✅ Prototype is already built!
|
||||
|
||||
**Perfect for:**
|
||||
- Users who can describe but can't draw
|
||||
- Testing responsive layouts
|
||||
- Quick professional mockups
|
||||
- When prototype comes before final design
|
||||
|
||||
---
|
||||
|
||||
## FLOW A: SKETCH PATH
|
||||
|
||||
<check if="visualization_method == 'A'">
|
||||
|
||||
<output>**Perfect! Let's set up for your sketch.**
|
||||
|
||||
I'll create:
|
||||
1. Page placeholder with navigation
|
||||
2. Sketches folder ready for upload
|
||||
3. Basic page structure
|
||||
|
||||
When you're ready, upload your sketch and we'll analyze it together using the Page Process Workshop.</output>
|
||||
|
||||
<action>
|
||||
1. Run page-init-lightweight.md to create structure
|
||||
2. User uploads sketch when ready
|
||||
3. Return to workshop-page-process.md for analysis
|
||||
</action>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## FLOW B: VERBAL SPECIFICATION
|
||||
|
||||
<check if="visualization_method == 'B'">
|
||||
|
||||
<output>**Great! Let's build the page concept through conversation.**
|
||||
|
||||
We'll define:
|
||||
- Page sections (what areas exist?)
|
||||
- Section purposes (why does each section exist?)
|
||||
- Key objects (what interactive elements?)
|
||||
- User flow (how do they move through the page?)
|
||||
|
||||
This creates a conceptual specification - the page where concept meets description.</output>
|
||||
|
||||
### SUBSTEP B1: IDENTIFY SECTIONS
|
||||
|
||||
<ask>**What are the main SECTIONS of this page?**
|
||||
|
||||
Think about areas/blocks, like:
|
||||
- Header/Navigation
|
||||
- Hero/Banner
|
||||
- Content areas
|
||||
- Forms
|
||||
- Footer
|
||||
|
||||
List the sections from top to bottom:</ask>
|
||||
|
||||
<action>Store sections_list</action>
|
||||
|
||||
### SUBSTEP B2: SECTION PURPOSES
|
||||
|
||||
<output>**Now let's define each section's purpose:**</output>
|
||||
|
||||
<action>
|
||||
For each section in sections_list:
|
||||
<ask>
|
||||
**{{section.name}}**
|
||||
|
||||
What is the PURPOSE of this section?
|
||||
- What should the user understand/do here?
|
||||
- Why does this section exist?
|
||||
|
||||
Purpose:
|
||||
</ask>
|
||||
|
||||
Store section.purpose
|
||||
End
|
||||
</action>
|
||||
|
||||
### SUBSTEP B3: KEY OBJECTS
|
||||
|
||||
<ask>**What are the KEY INTERACTIVE OBJECTS on this page?**
|
||||
|
||||
Think about:
|
||||
- Buttons (CTAs, actions)
|
||||
- Forms (inputs, selectors)
|
||||
- Links (navigation, external)
|
||||
- Media (images, videos)
|
||||
|
||||
List the most important interactive elements:</ask>
|
||||
|
||||
<action>Store key_objects</action>
|
||||
|
||||
### SUBSTEP B4: USER FLOW
|
||||
|
||||
<ask>**How does the user move through this page?**
|
||||
|
||||
- Where do they enter?
|
||||
- What's their first action?
|
||||
- What's the desired outcome?
|
||||
- Where do they go next?
|
||||
|
||||
Describe the flow:</ask>
|
||||
|
||||
<action>Store user_flow</action>
|
||||
|
||||
### SUBSTEP B5: GENERATE SPECIFICATION
|
||||
|
||||
<output>**Creating conceptual specification...**</output>
|
||||
|
||||
<action>
|
||||
Generate page specification document:
|
||||
- Page name and purpose
|
||||
- Navigation (prev/next)
|
||||
- For each section:
|
||||
- Section name
|
||||
- Section purpose
|
||||
- Status: "CONCEPTUAL - Needs visualization"
|
||||
- For each key object:
|
||||
- Object name
|
||||
- Object type
|
||||
- Object purpose
|
||||
- Status: "CONCEPTUAL - Needs specification"
|
||||
- User flow description
|
||||
- Next steps: "Create visualization (sketch/wireframe)"
|
||||
|
||||
Save to: 4-scenarios/{{scenario_path}}/{{page_number}}-{{page_slug}}/{{page_number}}-{{page_slug}}.md
|
||||
</action>
|
||||
|
||||
<output>✅ **Conceptual page specification created!**
|
||||
|
||||
**What we defined:**
|
||||
- {{sections_list.length}} sections with purposes
|
||||
- {{key_objects.length}} key interactive objects
|
||||
- Complete user flow
|
||||
|
||||
**Status:** CONCEPTUAL - Ready for visualization
|
||||
|
||||
**Next steps:**
|
||||
1. Create sketch/wireframe based on this concept
|
||||
2. Upload visualization
|
||||
3. Run Page Process Workshop to enhance specification
|
||||
|
||||
Or:
|
||||
|
||||
[A] Create ASCII layout now (quick visual)
|
||||
[B] Done - I'll create sketch later
|
||||
[C] Actually, let's refine the concept more
|
||||
|
||||
Choice:</output>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## FLOW E: GENERATE HTML PROTOTYPE
|
||||
|
||||
<check if="visualization_method == 'E'">
|
||||
|
||||
<output>**Perfect! Let's generate an HTML prototype based on your concept.**
|
||||
|
||||
This creates a working page that you can:
|
||||
- View in browser
|
||||
- Screenshot for documentation
|
||||
- Test responsive behavior
|
||||
- Use as starting point for development
|
||||
|
||||
The screenshot becomes your "sketch" for the specification.</output>
|
||||
|
||||
### SUBSTEP E1: DEFINE BASIC STRUCTURE
|
||||
|
||||
<output>**Based on your page concept:**
|
||||
|
||||
**Page:** {{page_name}}
|
||||
**Sections:** {{sections_list}}
|
||||
**Key Objects:** {{key_objects}}
|
||||
|
||||
I'll generate a clean HTML prototype with:
|
||||
- Semantic HTML structure
|
||||
- Basic Tailwind CSS styling (or vanilla CSS)
|
||||
- Placeholder content based on your descriptions
|
||||
- Responsive layout
|
||||
- Interactive elements (buttons, forms, etc.)</output>
|
||||
|
||||
<ask>**Any specific styling preferences?**
|
||||
|
||||
[A] Clean, minimal (default)
|
||||
[B] Modern SaaS style
|
||||
[C] Professional/corporate
|
||||
[D] Creative/bold
|
||||
[E] Match an existing site (describe)
|
||||
|
||||
Styling:</ask>
|
||||
|
||||
<action>Store styling_preference</action>
|
||||
|
||||
### SUBSTEP E2: GENERATE HTML
|
||||
|
||||
<action>
|
||||
**Generate HTML prototype:**
|
||||
|
||||
1. Create semantic HTML structure for each section
|
||||
2. Add Tailwind CSS classes (or vanilla CSS)
|
||||
3. Include placeholder content from user's descriptions
|
||||
4. Add interactive elements with proper attributes
|
||||
5. Make responsive (mobile-first)
|
||||
6. Include basic states (hover, focus, etc.)
|
||||
|
||||
File: `prototypes/{{page_slug}}-prototype.html`
|
||||
|
||||
Template structure:
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>{{page_name}} - Prototype</title>
|
||||
<script src="https://cdn.tailwindcss.com"></script>
|
||||
</head>
|
||||
<body class="bg-gray-50">
|
||||
<!-- Generated sections based on concept -->
|
||||
{{#each section in sections_list}}
|
||||
<section id="{{section.slug}}" class="...">
|
||||
<!-- Section content -->
|
||||
</section>
|
||||
{{/each}}
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
Save to: `4-scenarios/{{scenario_path}}/{{page_number}}-{{page_slug}}/prototypes/`
|
||||
</action>
|
||||
|
||||
### SUBSTEP E3: VIEW AND CAPTURE
|
||||
|
||||
<output>**Prototype generated!** 🎉
|
||||
|
||||
**File location:**
|
||||
`4-scenarios/{{scenario_path}}/{{page_number}}-{{page_slug}}/prototypes/{{page_slug}}-prototype.html`
|
||||
|
||||
**Next steps:**
|
||||
|
||||
1. **Open in browser** - Double-click the HTML file
|
||||
2. **Review the layout** - Does it match your vision?
|
||||
3. **Test responsive** - Resize browser window
|
||||
4. **Take screenshots:**
|
||||
- Desktop view (full page)
|
||||
- Mobile view (if needed)
|
||||
- Key sections (close-ups)
|
||||
5. **Save screenshots** to `sketches/` folder
|
||||
|
||||
**Screenshot naming:**
|
||||
- `{{page_slug}}-desktop.jpg` - Full desktop view
|
||||
- `{{page_slug}}-mobile.jpg` - Mobile view
|
||||
- `{{page_slug}}-section-name.jpg` - Section close-ups</output>
|
||||
|
||||
<ask>**Ready to capture screenshots?**
|
||||
|
||||
Once you've saved the screenshots, type "done" and I'll analyze them:
|
||||
|
||||
Status:</ask>
|
||||
|
||||
<action>Wait for user confirmation</action>
|
||||
|
||||
### SUBSTEP E4: ITERATE IF NEEDED
|
||||
|
||||
<ask>**How does the prototype look?**
|
||||
|
||||
[A] Perfect - I've captured screenshots
|
||||
[B] Need adjustments - let me describe changes
|
||||
[C] Completely different direction - let's revise
|
||||
|
||||
Choice:</ask>
|
||||
|
||||
<check if="choice == 'A'">
|
||||
<action>
|
||||
User should have screenshots in sketches/ folder
|
||||
Route to: workshop-page-process.md for analysis
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<check if="choice == 'B'">
|
||||
<ask>What changes are needed?</ask>
|
||||
<action>
|
||||
Update HTML prototype based on feedback
|
||||
Regenerate sections as needed
|
||||
Return to SUBSTEP E3 (view and capture)
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<check if="choice == 'C'">
|
||||
<action>Return to STEP 1: PAGE CONCEPT to redefine</action>
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
<check if="visualization_method == 'C'">
|
||||
|
||||
<output>**Let's create a simple ASCII layout together.**
|
||||
|
||||
⚠️ **Note:** ASCII is a last resort - sketches are much better for capturing design intent!
|
||||
|
||||
We'll create a basic box-and-text layout to show structure.</output>
|
||||
|
||||
<ask>**What are the main sections from top to bottom?**
|
||||
|
||||
Example:
|
||||
- Header
|
||||
- Hero
|
||||
- Features (3 columns)
|
||||
- CTA
|
||||
- Footer
|
||||
|
||||
List sections:</ask>
|
||||
|
||||
<action>Store sections_for_ascii</action>
|
||||
|
||||
<action>
|
||||
Generate ASCII layout:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ [HEADER] │
|
||||
│ Logo | Nav | Contact │
|
||||
└─────────────────────────────────────────┘
|
||||
|
||||
┌─────────────────────────────────────────┐
|
||||
│ │
|
||||
│ [HERO SECTION] │
|
||||
│ │
|
||||
│ Headline Goes Here │
|
||||
│ Subheadline text here │
|
||||
│ │
|
||||
│ [CTA Button] │
|
||||
│ │
|
||||
└─────────────────────────────────────────┘
|
||||
|
||||
┌───────────┬───────────┬───────────┐
|
||||
│ │ │ │
|
||||
│ [Feature] │ [Feature] │ [Feature] │
|
||||
│ 1 │ 2 │ 3 │
|
||||
│ │ │ │
|
||||
│ Icon │ Icon │ Icon │
|
||||
│ Text │ Text │ Text │
|
||||
│ │ │ │
|
||||
└───────────┴───────────┴───────────┘
|
||||
|
||||
... (for each section)
|
||||
```
|
||||
|
||||
Save as conceptual specification with ASCII visualization
|
||||
</action>
|
||||
|
||||
<output>✅ **ASCII layout created!**
|
||||
|
||||
⚠️ **Remember:** This is a rough structural guide.
|
||||
|
||||
**Recommended next steps:**
|
||||
1. Use this ASCII as a reference
|
||||
2. Create a proper sketch/wireframe
|
||||
3. Upload and run Page Process Workshop
|
||||
|
||||
**ASCII is helpful for structure, but lacks:**
|
||||
- Visual hierarchy
|
||||
- Spacing and proportions
|
||||
- Typography details
|
||||
- Color and visual design
|
||||
- Actual content flow
|
||||
|
||||
Ready to move forward?</output>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## FLOW D: REFERENCE PAGE
|
||||
|
||||
<check if="visualization_method == 'D'">
|
||||
|
||||
<ask>**Which page is this similar to?**
|
||||
|
||||
Provide:
|
||||
- Page name or URL
|
||||
- What file path (if internal project)
|
||||
- Or description of reference page
|
||||
|
||||
Reference:</ask>
|
||||
|
||||
<action>Store reference_page</action>
|
||||
|
||||
<ask>**What are the KEY DIFFERENCES from the reference?**
|
||||
|
||||
What changes from the reference page?
|
||||
|
||||
Differences:</ask>
|
||||
|
||||
<action>Store differences</action>
|
||||
|
||||
<output>**Creating page based on reference...**</output>
|
||||
|
||||
<action>
|
||||
If internal reference exists:
|
||||
1. Copy reference specification structure
|
||||
2. Update with differences
|
||||
3. Mark sections that need updates
|
||||
4. Preserve navigation pattern
|
||||
|
||||
If external reference:
|
||||
1. Describe reference structure
|
||||
2. Note differences
|
||||
3. Create conceptual specification
|
||||
4. Recommend creating sketch showing changes
|
||||
|
||||
Generate specification document
|
||||
</action>
|
||||
|
||||
<output>✅ **Reference-based page specification created!**
|
||||
|
||||
**Based on:** {{reference_page}}
|
||||
|
||||
**Key differences noted:** {{differences}}
|
||||
|
||||
**Next steps:**
|
||||
- Review generated specification
|
||||
- Create sketch showing unique elements
|
||||
- Run Page Process Workshop to refine
|
||||
|
||||
Ready?</output>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## COMPLETION
|
||||
|
||||
<output>**Page concept defined!** 🎯
|
||||
|
||||
**Page:** {{page_name}}
|
||||
**Method:** {{visualization_method_description}}
|
||||
**Status:**
|
||||
{{#if has_visualization}}
|
||||
- ✅ Conceptual specification complete
|
||||
- ⏳ Visualization pending
|
||||
{{else}}
|
||||
- ✅ Conceptual specification complete
|
||||
- ✅ Visualization method defined
|
||||
{{/if}}
|
||||
|
||||
**The page is the place where visualization meets specification.**
|
||||
|
||||
**What would you like to do next?**
|
||||
|
||||
[A] Create/upload sketch for this page
|
||||
[B] Create another page
|
||||
[C] Review what we've created
|
||||
[D] Back to scenario overview
|
||||
|
||||
Choice:</output>
|
||||
|
||||
---
|
||||
|
||||
## KEY PHILOSOPHY
|
||||
|
||||
### ✅ **Page-Centric Thinking**
|
||||
|
||||
The **page** is the conceptual entity:
|
||||
- Has a purpose
|
||||
- Serves users
|
||||
- Contains sections
|
||||
- Has interactive objects
|
||||
- Exists in a flow
|
||||
|
||||
The **visualization** is one representation:
|
||||
- Sketch (preferred)
|
||||
- Wireframe
|
||||
- ASCII (last resort)
|
||||
- Verbal description
|
||||
- Reference to similar page
|
||||
|
||||
**The page comes first. Visualization follows.**
|
||||
|
||||
### ✅ **Flexible Methods**
|
||||
|
||||
Different projects need different approaches:
|
||||
- Early concept → Verbal/ASCII → Sketch later
|
||||
- Clear vision → Sketch directly
|
||||
- Existing patterns → Reference + differences
|
||||
- Iterative → Mix of methods
|
||||
|
||||
**The workshop adapts to YOUR process.**
|
||||
|
||||
---
|
||||
|
||||
## INTEGRATION
|
||||
|
||||
This workshop creates:
|
||||
1. **Conceptual page specification** (always)
|
||||
2. **Placeholder for visualization** (always)
|
||||
3. **Guidance for next steps** (always)
|
||||
|
||||
Next workshops use:
|
||||
- **workshop-page-process.md** - When sketch is ready
|
||||
- **page-init-lightweight.md** - For quick structure
|
||||
- **4b-sketch-analysis.md** - For detailed analysis
|
||||
|
||||
---
|
||||
|
||||
**Created:** December 28, 2025
|
||||
**Purpose:** Define page concept, choose visualization method
|
||||
**Philosophy:** Page first, visualization second
|
||||
**Status:** Ready for use
|
||||
|
||||
|
|
@ -0,0 +1,333 @@
|
|||
# Page Process Workshop
|
||||
|
||||
**Purpose:** Intelligent sketch analysis with context detection - handles both new and updated sketches
|
||||
|
||||
---
|
||||
|
||||
## CONTEXT
|
||||
|
||||
**This workflow activates when:** User has a sketch/visualization ready to analyze.
|
||||
|
||||
**Intelligence:** Detects if this is a new page or update to existing specification.
|
||||
|
||||
**Behavior:**
|
||||
- New page → Full analysis
|
||||
- Updated page → Change detection, incremental update
|
||||
- Partial completion → Specify ready sections, mark TBD
|
||||
|
||||
---
|
||||
|
||||
## STEP 1: CONTEXT DETECTION
|
||||
|
||||
<action>
|
||||
**Determine page context:**
|
||||
|
||||
1. Read current page specification (if exists)
|
||||
2. Check for existing sketch versions
|
||||
3. Identify project structure (scenarios, pages)
|
||||
4. Store context information
|
||||
</action>
|
||||
|
||||
<check if="!page_spec_exists">
|
||||
<output>**This is the first sketch for this page!**
|
||||
|
||||
Let me analyze what you've drawn and create the initial specification.</output>
|
||||
|
||||
<action>Route to: `substeps/4b-sketch-analysis.md` (existing workflow)</action>
|
||||
</check>
|
||||
|
||||
<check if="page_spec_exists">
|
||||
<output>**I see we already have specifications for this page.**
|
||||
|
||||
Let me compare this sketch to what we have...</output>
|
||||
|
||||
<action>Proceed to STEP 2: Change Detection</action>
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## STEP 2: CHANGE DETECTION (For Existing Pages)
|
||||
|
||||
<action>
|
||||
**Compare new sketch to existing specifications:**
|
||||
|
||||
1. Load existing specification document
|
||||
2. Identify which sections are already specified
|
||||
3. Analyze new sketch for:
|
||||
- Unchanged sections
|
||||
- Modified sections
|
||||
- New sections added
|
||||
- Removed sections
|
||||
- TBD sections now complete
|
||||
- Complete sections now TBD
|
||||
|
||||
4. Calculate confidence for each comparison
|
||||
</action>
|
||||
|
||||
<output>**Comparison Results:**
|
||||
|
||||
{{#if has_changes}}
|
||||
🔍 **Changes detected:**
|
||||
|
||||
{{#if unchanged_sections.length > 0}}
|
||||
✅ **Unchanged sections** ({{unchanged_sections.length}}):
|
||||
{{#each section in unchanged_sections}}
|
||||
- {{section.name}}
|
||||
{{/each}}
|
||||
{{/if}}
|
||||
|
||||
{{#if modified_sections.length > 0}}
|
||||
✏️ **Modified sections** ({{modified_sections.length}}):
|
||||
{{#each section in modified_sections}}
|
||||
- {{section.name}}: {{section.change_description}}
|
||||
{{/each}}
|
||||
{{/if}}
|
||||
|
||||
{{#if new_sections.length > 0}}
|
||||
➕ **New sections added** ({{new_sections.length}}):
|
||||
{{#each section in new_sections}}
|
||||
- {{section.name}}: {{section.description}}
|
||||
{{/each}}
|
||||
{{/if}}
|
||||
|
||||
{{#if completed_sections.length > 0}}
|
||||
✨ **TBD sections now complete** ({{completed_sections.length}}):
|
||||
{{#each section in completed_sections}}
|
||||
- {{section.name}}: Ready to specify
|
||||
{{/each}}
|
||||
{{/if}}
|
||||
|
||||
{{#if removed_sections.length > 0}}
|
||||
⚠️ **Sections removed** ({{removed_sections.length}}):
|
||||
{{#each section in removed_sections}}
|
||||
- {{section.name}}
|
||||
{{/each}}
|
||||
{{/if}}
|
||||
|
||||
{{else}}
|
||||
✅ **No changes detected**
|
||||
|
||||
This sketch appears identical to the existing specification. Are you sure you wanted to upload a new version?
|
||||
{{/if}}
|
||||
|
||||
</output>
|
||||
|
||||
---
|
||||
|
||||
## STEP 3: UPDATE STRATEGY
|
||||
|
||||
<check if="has_changes">
|
||||
|
||||
<ask>**How would you like to proceed?**
|
||||
|
||||
{{#if modified_sections.length > 0 or new_sections.length > 0 or completed_sections.length > 0}}
|
||||
[A] Update all changed/new/completed sections
|
||||
[B] Pick specific sections to update
|
||||
[C] Show me detailed comparison first
|
||||
[D] Actually, this is the same - cancel
|
||||
{{else if removed_sections.length > 0}}
|
||||
[A] Remove deleted sections from spec
|
||||
[B] Keep them marked as "removed from design"
|
||||
[C] Cancel - I'll fix the sketch
|
||||
{{/if}}
|
||||
|
||||
Choice:</ask>
|
||||
|
||||
<action>Store user_choice</action>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## STEP 4A: UPDATE ALL (If user chose A)
|
||||
|
||||
<check if="user_choice == 'A'">
|
||||
|
||||
<output>**Updating all changed sections:**
|
||||
|
||||
I'll process:
|
||||
{{#if modified_sections.length > 0}}
|
||||
- {{modified_sections.length}} modified sections
|
||||
{{/if}}
|
||||
{{#if new_sections.length > 0}}
|
||||
- {{new_sections.length}} new sections
|
||||
{{/if}}
|
||||
{{#if completed_sections.length > 0}}
|
||||
- {{completed_sections.length}} completed sections
|
||||
{{/if}}
|
||||
{{#if removed_sections.length > 0}}
|
||||
- {{removed_sections.length}} removed sections
|
||||
{{/if}}
|
||||
|
||||
**Preserving:**
|
||||
{{#each section in unchanged_sections}}
|
||||
- {{section.name}}
|
||||
{{/each}}
|
||||
|
||||
Ready to analyze sections?</output>
|
||||
|
||||
<action>
|
||||
For each section in (modified_sections + new_sections + completed_sections):
|
||||
Run 4b-sketch-analysis.md workflow for that section only
|
||||
Update specification document
|
||||
Preserve unchanged sections
|
||||
End
|
||||
</action>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## STEP 4B: SELECTIVE UPDATE (If user chose B)
|
||||
|
||||
<check if="user_choice == 'B'">
|
||||
|
||||
<ask>**Which sections should I update?**
|
||||
|
||||
{{#each section in (modified_sections + new_sections + completed_sections)}}
|
||||
[{{@index + 1}}] {{section.name}} - {{section.change_type}}
|
||||
{{/each}}
|
||||
|
||||
Enter numbers separated by commas (e.g., 1,3,5):</ask>
|
||||
|
||||
<action>
|
||||
Parse selected_sections
|
||||
For each selected section:
|
||||
Run 4b-sketch-analysis.md workflow for that section
|
||||
Update specification document
|
||||
End
|
||||
</action>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## STEP 4C: DETAILED COMPARISON (If user chose C)
|
||||
|
||||
<check if="user_choice == 'C'">
|
||||
|
||||
<output>**Detailed Section-by-Section Comparison:**
|
||||
|
||||
{{#each section in modified_sections}}
|
||||
|
||||
---
|
||||
|
||||
### {{section.name}}
|
||||
|
||||
**Current specification:**
|
||||
{{section.current_spec_summary}}
|
||||
|
||||
**New sketch shows:**
|
||||
{{section.new_sketch_summary}}
|
||||
|
||||
**Detected changes:**
|
||||
{{#each change in section.changes}}
|
||||
- {{change.description}}
|
||||
{{/each}}
|
||||
|
||||
**Confidence:** {{section.confidence}}%
|
||||
|
||||
---
|
||||
{{/each}}
|
||||
|
||||
After reviewing, what would you like to do?
|
||||
|
||||
[A] Update all
|
||||
[B] Pick specific sections
|
||||
[C] Cancel</output>
|
||||
|
||||
<action>Return to STEP 3 with user's choice</action>
|
||||
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## STEP 5: COMPLETION
|
||||
|
||||
<output>✅ **Page specification updated!**
|
||||
|
||||
**Summary:**
|
||||
{{#if updated_count > 0}}
|
||||
- {{updated_count}} sections updated
|
||||
{{/if}}
|
||||
{{#if added_count > 0}}
|
||||
- {{added_count}} sections added
|
||||
{{/if}}
|
||||
{{#if preserved_count > 0}}
|
||||
- {{preserved_count}} sections preserved (unchanged)
|
||||
{{/if}}
|
||||
{{#if removed_count > 0}}
|
||||
- {{removed_count}} sections removed
|
||||
{{/if}}
|
||||
|
||||
**Updated file:** `{{page_spec_path}}`
|
||||
|
||||
**Sketch saved to:** `{{sketch_path}}`
|
||||
|
||||
**Next steps:**
|
||||
- Review the updated specification
|
||||
- Generate updated prototype (if needed)
|
||||
- Continue to next page or scenario
|
||||
|
||||
Would you like to:
|
||||
[A] Generate HTML prototype
|
||||
[B] Add another page
|
||||
[C] Update another section
|
||||
[D] Done with this page
|
||||
|
||||
Choice:</output>
|
||||
|
||||
---
|
||||
|
||||
## ROUTING
|
||||
|
||||
<action>
|
||||
Based on user choice:
|
||||
- [A] → Load prototype generation workflow
|
||||
- [B] → Return to page-init/step-01-page-context.md
|
||||
- [C] → Return to STEP 3 (pick sections)
|
||||
- [D] → Return to main UX design menu
|
||||
</action>
|
||||
|
||||
---
|
||||
|
||||
## KEY FEATURES
|
||||
|
||||
### ✅ **Intelligent Context Detection**
|
||||
- Automatically knows if new or update
|
||||
- Compares sketches to existing specs
|
||||
- Identifies unchanged sections
|
||||
|
||||
### ✅ **Incremental Updates**
|
||||
- Only updates what changed
|
||||
- Preserves existing work
|
||||
- No data loss
|
||||
|
||||
### ✅ **Change Confidence**
|
||||
- Shows confidence level per change
|
||||
- Lets user verify before processing
|
||||
- Reduces errors
|
||||
|
||||
### ✅ **Flexible Control**
|
||||
- Update all or select specific
|
||||
- See detailed comparison
|
||||
- Cancel anytime
|
||||
|
||||
---
|
||||
|
||||
## INTEGRATION WITH EXISTING SYSTEM
|
||||
|
||||
This workshop uses:
|
||||
- **4b-sketch-analysis.md** - For actual section analysis
|
||||
- **SKETCH-TEXT-ANALYSIS-GUIDE.md** - For reading text markers
|
||||
- **page-specification.template.md** - For document structure
|
||||
- **object-types/*.md** - For component specifications
|
||||
|
||||
**It's a smart router that preserves your existing workflows!**
|
||||
|
||||
---
|
||||
|
||||
**Created:** December 28, 2025
|
||||
**For:** Iterative page specification workflow
|
||||
**Status:** Ready to test with WDS Presentation page
|
||||
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Step 1: Core Feature
|
||||
|
||||
**Scenario Discovery - Question 1 of 5**
|
||||
|
||||
---
|
||||
|
||||
<output>**Let's find the natural starting point for this scenario.**
|
||||
|
||||
Looking at your Trigger Map and project goals, we need to identify what to design.</output>
|
||||
|
||||
<ask>**What feature or experience should this scenario cover?**
|
||||
|
||||
Think about:
|
||||
- Which feature delivers the most value to your primary target group?
|
||||
- What's the core experience that serves your business goals?
|
||||
- What's the "happy path" users need?
|
||||
|
||||
Feature/Experience:</ask>
|
||||
|
||||
<action>Store core_feature</action>
|
||||
<template-output>core_feature</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/flow-c-multiple-scenarios/step-02-entry-point.md`</action>
|
||||
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Step 2: Entry Point
|
||||
|
||||
**Scenario Discovery - Question 2 of 5**
|
||||
|
||||
---
|
||||
|
||||
<ask>**Where does the user first encounter this?**
|
||||
|
||||
What's their entry point?
|
||||
- Google search?
|
||||
- Friend recommendation?
|
||||
- App store?
|
||||
- Direct navigation (logged in)?
|
||||
- Internal link from another feature?
|
||||
- Email/push notification?
|
||||
- External integration?
|
||||
|
||||
Entry point:</ask>
|
||||
|
||||
<action>Store entry_point</action>
|
||||
<template-output>entry_point</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/flow-c-multiple-scenarios/step-03-mental-state.md`</action>
|
||||
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
# Step 3: Mental State
|
||||
|
||||
**Scenario Discovery - Question 3 of 5**
|
||||
|
||||
---
|
||||
|
||||
<ask>**What's their mental state at this moment?**
|
||||
|
||||
When they arrive, how are they feeling?
|
||||
|
||||
Consider:
|
||||
- **What just happened?** (trigger moment that brings them here)
|
||||
- **What are they hoping for?** (desired outcome)
|
||||
- **What are they worried about?** (fears, concerns, obstacles)
|
||||
|
||||
Mental state:</ask>
|
||||
|
||||
<action>Store mental_state</action>
|
||||
<template-output>mental_state</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/flow-c-multiple-scenarios/step-04-mutual-success.md`</action>
|
||||
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
# Step 4: Mutual Success
|
||||
|
||||
**Scenario Discovery - Question 4 of 5**
|
||||
|
||||
---
|
||||
|
||||
<ask>**What does mutual success look like?**
|
||||
|
||||
Define success for both sides:
|
||||
|
||||
**For the business:** [what outcome/action/metric]
|
||||
Examples: subscription purchased, task completed, data submitted
|
||||
|
||||
**For the user:** [what state/feeling/outcome they achieve]
|
||||
Examples: problem solved, goal achieved, confidence gained
|
||||
|
||||
Success definition:</ask>
|
||||
|
||||
<action>Store business_success</action>
|
||||
<action>Store user_success</action>
|
||||
<template-output>business_success</template-output>
|
||||
<template-output>user_success</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/flow-c-multiple-scenarios/step-05-shortest-path.md`</action>
|
||||
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Step 5: Shortest Path
|
||||
|
||||
**Scenario Discovery - Question 5 of 5**
|
||||
|
||||
---
|
||||
|
||||
<output>**Now let's map the shortest possible journey** from:
|
||||
|
||||
**START:** {{entry_point}} ({{mental_state}})
|
||||
**END:** {{business_success}} + {{user_success}}
|
||||
|
||||
What's the absolute minimum path? No extra steps, just the essentials that move the user toward mutual success.</output>
|
||||
|
||||
<ask>**List the critical pages/steps in order:**
|
||||
|
||||
Example for SaaS onboarding:
|
||||
1. Landing page - understand solution
|
||||
2. Sign up - commit to trying
|
||||
3. Welcome setup - quick configuration
|
||||
4. First success moment - proof it works
|
||||
5. Dashboard - ongoing use
|
||||
|
||||
Example for mobile app:
|
||||
1. App store page - decide to install
|
||||
2. Welcome screen - understand purpose
|
||||
3. Permission requests - enable features
|
||||
4. Quick tutorial - learn basics
|
||||
5. First action - achieve something
|
||||
|
||||
Your path:</ask>
|
||||
|
||||
<action>Parse pages from user input</action>
|
||||
<action>Store pages_list</action>
|
||||
<template-output>pages_list</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/flow-c-multiple-scenarios/step-06-scenario-name.md`</action>
|
||||
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
# Step 6: Scenario Name
|
||||
|
||||
---
|
||||
|
||||
<ask>**What should we call this scenario?**
|
||||
|
||||
Make it descriptive and outcome-focused:
|
||||
|
||||
Examples:
|
||||
- "User Onboarding to First Success"
|
||||
- "Purchase Journey"
|
||||
- "Problem Resolution Flow"
|
||||
- "Content Creation Workflow"
|
||||
- "Admin Setup Process"
|
||||
|
||||
Scenario name:</ask>
|
||||
|
||||
<action>Store scenario_name</action>
|
||||
<template-output>scenario_name</template-output>
|
||||
|
||||
---
|
||||
|
||||
<action>Load and execute: `step-02-substeps/flow-c-multiple-scenarios/step-07-create-structure.md`</action>
|
||||
|
||||
|
|
@ -0,0 +1,145 @@
|
|||
# Step 7: Create Structure
|
||||
|
||||
---
|
||||
|
||||
<action>
|
||||
**Determine scenario number:**
|
||||
- Count existing scenario folders in `4-scenarios/`
|
||||
- If none exist, scenario_num = 1
|
||||
- Otherwise, scenario_num = (highest number + 1)
|
||||
- Store scenario_num
|
||||
</action>
|
||||
|
||||
<action>
|
||||
**Create physical folder structure:**
|
||||
|
||||
1. Create `4-scenarios/{{scenario_num}}-{{scenario-slug}}/` directory
|
||||
|
||||
**Generate 00-scenario-overview.md:**
|
||||
|
||||
File: `4-scenarios/{{scenario_num}}-{{scenario-slug}}/00-scenario-overview.md`
|
||||
|
||||
Content:
|
||||
```markdown
|
||||
# Scenario {{scenario_num}}: {{scenario_name}}
|
||||
|
||||
**Project Structure:** Multiple scenarios
|
||||
|
||||
---
|
||||
|
||||
## Core Feature
|
||||
|
||||
{{core_feature}}
|
||||
|
||||
---
|
||||
|
||||
## User Journey
|
||||
|
||||
### Entry Point
|
||||
|
||||
{{entry_point}}
|
||||
|
||||
### Mental State
|
||||
|
||||
{{mental_state}}
|
||||
|
||||
When users arrive, they are feeling:
|
||||
- **Trigger:** [what just happened]
|
||||
- **Hope:** [what they're hoping for]
|
||||
- **Worry:** [what they're worried about]
|
||||
|
||||
---
|
||||
|
||||
## Success Goals
|
||||
|
||||
### Business Success
|
||||
|
||||
{{business_success}}
|
||||
|
||||
### User Success
|
||||
|
||||
{{user_success}}
|
||||
|
||||
---
|
||||
|
||||
## Shortest Path
|
||||
|
||||
{{#each page in pages_list}}
|
||||
{{@index + 1}}. **{{page.name}}** - {{page.description}}
|
||||
{{/each}}
|
||||
|
||||
---
|
||||
|
||||
## Pages in This Scenario
|
||||
|
||||
{{#each page in pages_list}}
|
||||
- `{{scenario_num}}.{{@index + 1}}-{{page.slug}}/`
|
||||
{{/each}}
|
||||
|
||||
---
|
||||
|
||||
## Trigger Map Connections
|
||||
|
||||
[Link to relevant personas and driving forces from Trigger Map]
|
||||
|
||||
---
|
||||
|
||||
**Created:** {{date}}
|
||||
**Status:** Ready for design
|
||||
```
|
||||
|
||||
**Generate scenario-tracking.yaml:**
|
||||
|
||||
File: `4-scenarios/{{scenario_num}}-{{scenario-slug}}/scenario-tracking.yaml`
|
||||
|
||||
Content:
|
||||
```yaml
|
||||
scenario_number: {{scenario_num}}
|
||||
scenario_name: "{{scenario_name}}"
|
||||
core_feature: "{{core_feature}}"
|
||||
entry_point: "{{entry_point}}"
|
||||
mental_state: "{{mental_state}}"
|
||||
business_success: "{{business_success}}"
|
||||
user_success: "{{user_success}}"
|
||||
pages_list:
|
||||
{{#each page in pages_list}}
|
||||
- name: "{{page.name}}"
|
||||
slug: "{{page.slug}}"
|
||||
page_number: "{{scenario_num}}.{{@index + 1}}"
|
||||
description: "{{page.description}}"
|
||||
status: "not_started"
|
||||
{{/each}}
|
||||
current_page_index: 0
|
||||
total_pages: {{pages_list.length}}
|
||||
```
|
||||
|
||||
**Note:** Individual page folders and documents will be created when you run the page-init workshop for each page.
|
||||
</action>
|
||||
|
||||
<output>✅ **Scenario structure created:**
|
||||
|
||||
**Scenario {{scenario_num}}:** {{scenario_name}}
|
||||
|
||||
**Folder:**
|
||||
- `4-scenarios/{{scenario_num}}-{{scenario-slug}}/`
|
||||
|
||||
**Documents:**
|
||||
- `00-scenario-overview.md` (detailed scenario metadata)
|
||||
- `scenario-tracking.yaml` (progress tracking)
|
||||
|
||||
**Journey Overview:**
|
||||
- **Start:** {{entry_point}} ({{mental_state}})
|
||||
- **End:** {{business_success}} + {{user_success}}
|
||||
- **Pages planned:** {{pages_list.length}}
|
||||
|
||||
**Next Step:**
|
||||
- Run the page-init workshop to define and create the first page in this scenario
|
||||
|
||||
The scenario container is ready! 🎨</output>
|
||||
|
||||
---
|
||||
|
||||
<output>[C] Continue to Page Initialization Workshop</output>
|
||||
|
||||
<action>When user selects [C], load `step-02-substeps/page-init/step-01-page-context.md`</action>
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ Choice [1/2/3/4/5]:</ask>
|
|||
### Choice 1: Design Another Scenario
|
||||
|
||||
<action>Return to Step 2 (Define Scenario)</action>
|
||||
<action>Load `steps/step-02-define-scenario.md`</action>
|
||||
<action>Load `steps/step-02-setup-scenario-structure.md`</action>
|
||||
|
||||
### Choice 2: Phase 5 (Design System)
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,226 @@
|
|||
# Project Structure System
|
||||
|
||||
## Overview
|
||||
|
||||
WDS includes a centralized project initialization system that collects project structure metadata and makes it available to all agents throughout the workflow. This ensures proper folder organization from the start and eliminates confusion.
|
||||
|
||||
## The Central Project Details File
|
||||
|
||||
All project configuration is stored in **one central file**:
|
||||
|
||||
📄 **`wds-workflow-status.yaml`** (in project docs root)
|
||||
|
||||
This file contains:
|
||||
- Project metadata (name, type, creation date)
|
||||
- **Project structure** (landing page, website, or application)
|
||||
- **Delivery configuration** (format, target platform, PRD requirements)
|
||||
- Language configuration
|
||||
- Folder naming preferences
|
||||
- Design system settings
|
||||
- Workflow progress tracking
|
||||
|
||||
**All WDS agents read this file** to understand project context and structure.
|
||||
|
||||
---
|
||||
|
||||
## How It Works
|
||||
|
||||
### Step 1: Workflow Init (Collection)
|
||||
|
||||
During **initial project setup** (`workflow-init`), the system asks:
|
||||
|
||||
**"What are you designing?"**
|
||||
|
||||
1. **Separate pages** - Individual pages or page variants
|
||||
2. **Single user flow** - Multiple pages, single user journey
|
||||
3. **Multiple user flows** - Multiple scenarios/journeys, interactive features
|
||||
|
||||
### Step 2: Storage (Central Config)
|
||||
|
||||
This information is written to `wds-workflow-status.yaml`:
|
||||
|
||||
```yaml
|
||||
# Project information
|
||||
project: "WDS Presentation Page"
|
||||
project_type: "landing-page"
|
||||
|
||||
# Project structure (defines folder organization)
|
||||
project_structure:
|
||||
type: "separate_pages"
|
||||
scenarios: "single"
|
||||
pages: "single"
|
||||
|
||||
# Delivery configuration (what gets handed off)
|
||||
delivery:
|
||||
format: "wordpress"
|
||||
target_platform: "wordpress"
|
||||
requires_prd: false
|
||||
description: "WordPress page editor code with markup and content sections"
|
||||
```
|
||||
|
||||
**Key benefit:** Since `requires_prd: false`, the system knows **not to include PRD phases** (Phase 3 Platform Requirements, Phase 6 PRD Finalization). The workflow focuses only on design specifications that translate directly to WordPress implementation.
|
||||
|
||||
### Step 3: Application (All Agents)
|
||||
|
||||
When any agent starts work, they:
|
||||
1. **Read** `wds-workflow-status.yaml`
|
||||
2. **Extract** `project_structure` section
|
||||
3. **Apply** appropriate folder organization rules
|
||||
|
||||
**Example - Freyja (UX Designer):**
|
||||
- Reads config file before greeting user
|
||||
- Understands this is "separate pages"
|
||||
- Places pages directly in `4-scenarios/` (no scenario subfolders)
|
||||
- Numbers pages with individual identifiers
|
||||
|
||||
---
|
||||
|
||||
## Information Flow
|
||||
|
||||
```
|
||||
User Input → Workflow Init → wds-workflow-status.yaml → All Agents → Correct Structure
|
||||
(Step 2b) (Central Storage) (Read Config) (Applied)
|
||||
```
|
||||
|
||||
**Key Principle:** Define once, use everywhere.
|
||||
|
||||
---
|
||||
|
||||
### Separate Pages
|
||||
- **Structure:** `4-scenarios/start-page/` or variants
|
||||
- **Pattern:** Pages directly in `4-scenarios/`
|
||||
- **Variants:** `start-page-variant-a/`, `start-page-variant-b/` (if A/B testing)
|
||||
- **Use case:** Landing pages, standalone pages, page variants
|
||||
|
||||
```
|
||||
4-scenarios/
|
||||
start-page/
|
||||
start-page.md
|
||||
sketches/
|
||||
prototypes/
|
||||
start-page-variant-a/ (optional)
|
||||
start-page-variant-a.md
|
||||
sketches/
|
||||
```
|
||||
|
||||
### Single User Flow
|
||||
- **Structure:** `4-scenarios/1.1-home/`, `4-scenarios/1.2-about/`
|
||||
- **Pattern:** Pages directly in `4-scenarios/`
|
||||
- **Numbering:** Sequential pages `1.1`, `1.2`, `1.3`, etc.
|
||||
- **No Scenario Subfolders:** All pages at the same level
|
||||
- **Use case:** Simple websites, wizard flows, single-screen apps
|
||||
|
||||
```
|
||||
4-scenarios/
|
||||
1.1-home/
|
||||
1.1-home.md
|
||||
sketches/
|
||||
prototypes/
|
||||
1.2-about/
|
||||
1.2-about.md
|
||||
sketches/
|
||||
1.3-contact/
|
||||
1.3-contact.md
|
||||
sketches/
|
||||
```
|
||||
|
||||
### Multiple User Flows
|
||||
- **Structure:** `4-scenarios/1-onboarding/`, `4-scenarios/2-dashboard/`
|
||||
- **Pattern:** Scenario subfolders, pages within scenarios
|
||||
- **Numbering:**
|
||||
- Scenarios: `1-scenario-name`, `2-scenario-name`
|
||||
- Pages within: `1.1-page`, `1.2-page`, `2.1-page`, `2.2-page`
|
||||
- **Use case:** Web applications, mobile apps, admin systems
|
||||
|
||||
```
|
||||
4-scenarios/
|
||||
1-onboarding/
|
||||
00-scenario.md
|
||||
1.1-signup/
|
||||
1.1-signup.md
|
||||
sketches/
|
||||
1.2-verify-email/
|
||||
1.2-verify-email.md
|
||||
sketches/
|
||||
2-dashboard/
|
||||
00-scenario.md
|
||||
2.1-overview/
|
||||
2.1-overview.md
|
||||
sketches/
|
||||
2.2-settings/
|
||||
2.2-settings.md
|
||||
sketches/
|
||||
```
|
||||
|
||||
## Benefits
|
||||
|
||||
### For Users
|
||||
- **No confusion** about folder structure
|
||||
- **Consistent organization** across projects
|
||||
- **Correct setup from the start** - no reorganization needed
|
||||
|
||||
### For Agents
|
||||
- **Clear instructions** based on project type
|
||||
- **No guesswork** about where to place files
|
||||
- **Proper structure** enables smooth handoffs between phases
|
||||
|
||||
## Implementation Files
|
||||
|
||||
### 1. Collection Phase
|
||||
- **File:** `workflows/workflow-init/instructions.md`
|
||||
- **Step:** Step 2 - "Project Structure"
|
||||
- **When:** During initial project setup
|
||||
- **Action:** Asks user to classify project structure
|
||||
|
||||
### 2. Central Storage
|
||||
- **File:** `wds-workflow-status.yaml` (project root)
|
||||
- **Template:** `workflows/00-system/wds-workflow-status-template.yaml`
|
||||
- **Section:** `project_structure:`
|
||||
- **Fields:**
|
||||
- `type` - separate_pages | single_flow | multiple_flows
|
||||
- `scenarios` - single | multiple
|
||||
- `pages` - single | multiple
|
||||
|
||||
### 3. Application - All Phases
|
||||
Every agent that needs structure information reads from `wds-workflow-status.yaml`:
|
||||
|
||||
**Freyja (UX Designer):**
|
||||
- **File:** `workflows/4-ux-design/steps/step-01-init.md`
|
||||
- **When:** Before greeting user (initialization)
|
||||
- **Action:** Reads config, applies folder rules
|
||||
|
||||
**Future agents can access the same information** by reading the central config file.
|
||||
|
||||
## Migration for Existing Projects
|
||||
|
||||
If a project was created before this system:
|
||||
|
||||
1. **Add structure section to config** (`config.yaml` or `wds-workflow-status.yaml`)
|
||||
2. **Identify the project type** based on actual content
|
||||
3. **Reorganize folders** if needed to match the standard
|
||||
4. **Update all internal references** to reflect new structure
|
||||
|
||||
Example addition to config:
|
||||
|
||||
```yaml
|
||||
project:
|
||||
structure:
|
||||
type: "single_flow"
|
||||
scenarios: "single"
|
||||
pages: "multiple"
|
||||
```
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
Potential additions to this system:
|
||||
|
||||
- **Multi-language variants** (e.g., `/en/`, `/sv/` folders)
|
||||
- **Platform variants** (e.g., `/web/`, `/mobile/` folders)
|
||||
- **Custom structure templates** for specific industries
|
||||
- **Validation tools** to ensure structure compliance
|
||||
|
||||
---
|
||||
|
||||
**Created:** December 27, 2025
|
||||
**Status:** Implemented in WDS v6
|
||||
|
||||
|
|
@ -9,6 +9,36 @@
|
|||
|
||||
---
|
||||
|
||||
## Receiving Handoffs from Other Agents
|
||||
|
||||
**I am activated when:**
|
||||
- User shares interface design (sketch, wireframe, screenshot)
|
||||
- User describes page/screen/component design needs
|
||||
- Another agent recognizes UX design task and refers to me
|
||||
|
||||
**How I receive handoffs:**
|
||||
|
||||
```
|
||||
Other Agent: "@freyja User has [context about interface/design need]"
|
||||
|
||||
Me: "Thanks [Agent Name]! I can see [what user shared].
|
||||
[Natural question to continue conversation]"
|
||||
|
||||
→ Route to appropriate workflow based on context
|
||||
```
|
||||
|
||||
**Context I need from referring agent:**
|
||||
- What did user share? (sketch, description, goal)
|
||||
- What project is this for? (if known)
|
||||
- Any relevant background (from Product Brief, Trigger Map, etc.)
|
||||
|
||||
**I respond naturally:**
|
||||
- Acknowledge the referring agent briefly
|
||||
- Pick up the conversation seamlessly
|
||||
- Focus on helping user, not the handoff mechanics
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: UX Design (Scenarios)
|
||||
|
||||
**What I do**:
|
||||
|
|
|
|||
|
|
@ -9,6 +9,19 @@
|
|||
|
||||
---
|
||||
|
||||
## Interface Recognition & Freyja Handoff
|
||||
|
||||
**When user shares interface design with me:**
|
||||
- Recognize: "I see you've shared an interface design/sketch"
|
||||
- Explain: "Freyja handles UX design and page specifications"
|
||||
- Offer: "Should I activate Freyja to help with this?"
|
||||
- Handoff: Provide context to Freyja and step back
|
||||
|
||||
**I focus on:** Technical architecture, infrastructure (HOW it's built)
|
||||
**Freyja focuses on:** User interface, page design (WHAT users see)
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: PRD Platform (Technical Foundation)
|
||||
|
||||
**What I do**:
|
||||
|
|
|
|||
|
|
@ -9,6 +9,19 @@
|
|||
|
||||
---
|
||||
|
||||
## Interface Recognition & Freyja Handoff
|
||||
|
||||
**When user shares interface design with me:**
|
||||
- Recognize: "I see you've shared an interface design/sketch/wireframe"
|
||||
- Explain: "Freyja is our UX Designer who handles page specifications"
|
||||
- Offer: "Should I activate Freyja to help with this?"
|
||||
- Handoff: Provide context to Freyja and step back
|
||||
|
||||
**I focus on:** Strategy, vision, positioning (WHY)
|
||||
**Freyja focuses on:** Interface, pages, specifications (WHAT/HOW)
|
||||
|
||||
---
|
||||
|
||||
## Pre-Phase 1: Alignment & Signoff
|
||||
|
||||
**What I do**:
|
||||
|
|
|
|||
|
|
@ -6,352 +6,17 @@
|
|||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Welcome and understand project">
|
||||
<step n="1" goal="Welcome and project name">
|
||||
<output>Welcome to Whiteport Design Studio, {user_name}! 🎨
|
||||
|
||||
I'm here to help you set up your design project. WDS provides a structured approach to design - from strategic vision through detailed specifications.
|
||||
I'll help you set up your design project with the right structure and phases.</output>
|
||||
|
||||
Let's figure out which phases you need.</output>
|
||||
<ask>What's your project called?</ask>
|
||||
|
||||
<ask>Tell me about your project in a few sentences. What are you designing?</ask>
|
||||
<action>Store user_description</action>
|
||||
<action>Analyze description for project indicators:
|
||||
<action>Store project_name</action>
|
||||
<template-output>project_name</template-output>
|
||||
|
||||
- "landing page", "single page", "simple" → landing-page path
|
||||
- "product", "platform", "app", "system", "full" → full-product path
|
||||
- "strategy", "research", "discovery", "planning" → digital-strategy path
|
||||
- "design system", "components", "library" → design-system path
|
||||
- "feature", "enhancement", "addition" → feature-enhancement path
|
||||
- "quick", "prototype", "poc", "test" → quick-prototype path
|
||||
</action>
|
||||
<template-output>user_description</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Confirm project type">
|
||||
<output>Based on what you shared, this sounds like a **{{detected_project_type}}** project.</output>
|
||||
|
||||
<ask>Does that sound right?
|
||||
|
||||
1. Yes, that's correct
|
||||
2. No, let me explain more
|
||||
3. Show me all the options
|
||||
|
||||
Choice [1/2/3]:</ask>
|
||||
|
||||
<check if="choice == 2">
|
||||
<ask>Tell me more - what's the scope and complexity?</ask>
|
||||
<action>Re-analyze and update detected_project_type</action>
|
||||
<action>Return to step 2</action>
|
||||
</check>
|
||||
|
||||
<check if="choice == 3">
|
||||
<output>WDS supports these project types:
|
||||
|
||||
**1. Full Product** 🚀
|
||||
All 6 phases - complete design journey from vision to handoff
|
||||
Best for: New products, platforms, complex applications
|
||||
|
||||
**2. Landing Page** 📄
|
||||
Phases 1 (Brief), 4 (Design), optional 5 (Design System)
|
||||
Best for: Marketing sites, single-page apps, simple projects
|
||||
|
||||
**3. Feature Enhancement** ✨
|
||||
Phases 2 (Trigger Map), 4 (Design), 6 (PRD Finalization)
|
||||
Best for: Adding features to existing products
|
||||
|
||||
**4. Digital Strategy** 🧭
|
||||
Phases 1 (Brief), 2 (Trigger Map) only
|
||||
Best for: Discovery, research, product strategy
|
||||
|
||||
**5. Design System Only** 🎨
|
||||
Phases 4 (Design), 5 (Design System)
|
||||
Best for: Building component libraries
|
||||
|
||||
**6. Quick Prototype** ⚡
|
||||
Phase 4 only
|
||||
Best for: Rapid prototyping, proof of concepts</output>
|
||||
|
||||
<ask>Which fits your project?
|
||||
|
||||
1. Full Product
|
||||
2. Landing Page
|
||||
3. Feature Enhancement
|
||||
4. Digital Strategy
|
||||
5. Design System Only
|
||||
6. Quick Prototype
|
||||
|
||||
Choice [1-6]:</ask>
|
||||
<action>Map choice to project_type</action>
|
||||
</check>
|
||||
|
||||
<template-output>project_type</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Project Brief level">
|
||||
<output>Every WDS project starts with a Project Brief - so agents understand what you're building and why.</output>
|
||||
|
||||
<check if="project_type in [full-product, digital-strategy]">
|
||||
<output>For **{{project_type}}** projects, a **Complete Project Brief** is included.
|
||||
|
||||
This covers:
|
||||
|
||||
- Vision & positioning
|
||||
- Target users (ICP)
|
||||
- Success criteria
|
||||
- Competitive landscape
|
||||
- Strategic constraints</output>
|
||||
<action>Set brief_level = "complete"</action>
|
||||
</check>
|
||||
|
||||
<check if="project_type in [quick-prototype, landing-page]">
|
||||
<output>For **{{project_type}}** projects, a **Simplified Project Brief** keeps things fast.
|
||||
|
||||
This covers:
|
||||
|
||||
- Scope & challenge
|
||||
- Opportunity
|
||||
- Design goals</output>
|
||||
<action>Set brief_level = "simplified"</action>
|
||||
</check>
|
||||
|
||||
<check if="project_type in [feature-enhancement, design-system-only]">
|
||||
<ask>Project Brief depth:
|
||||
|
||||
1. **Simplified** (5-10 min)
|
||||
- Scope & challenge
|
||||
- Opportunity
|
||||
- Design goals
|
||||
Best for: Quick features, time-pressured work
|
||||
2. **Complete** (30-60 min)
|
||||
- Vision & positioning
|
||||
- Target users (ICP)
|
||||
- Success criteria
|
||||
- Competitive landscape
|
||||
Best for: When you want strategic clarity
|
||||
|
||||
Choice [1/2]:</ask>
|
||||
|
||||
<check if="choice == 1">
|
||||
<action>Set brief_level = "simplified"</action>
|
||||
</check>
|
||||
|
||||
<check if="choice == 2">
|
||||
<action>Set brief_level = "complete"</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<template-output>brief_level</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Configure languages">
|
||||
<output>WDS needs to know what language to write specifications in and what languages your product will support.</output>
|
||||
|
||||
<ask>**Specification Language** - What language should WDS write the design specifications in?
|
||||
|
||||
Common choices:
|
||||
|
||||
1. **English** (EN) - Default, widely used
|
||||
2. **Swedish** (SE)
|
||||
3. **Norwegian** (NO)
|
||||
4. **Danish** (DK)
|
||||
5. **Other** - I'll specify
|
||||
|
||||
Choice [1-5]:</ask>
|
||||
<action>Store specification_language</action>
|
||||
<template-output>specification_language</template-output>
|
||||
|
||||
<ask>**Product Languages** - What languages will the final product support?
|
||||
|
||||
List them separated by commas (e.g., "EN, SE" or "EN, SE, NO, DK"):
|
||||
|
||||
Common language codes:
|
||||
|
||||
- EN = English
|
||||
- SE = Swedish
|
||||
- NO = Norwegian
|
||||
- DK = Danish
|
||||
- FI = Finnish
|
||||
- DE = German
|
||||
- FR = French
|
||||
- ES = Spanish
|
||||
|
||||
Product languages:</ask>
|
||||
<action>Store product_languages (parse as array)</action>
|
||||
<action>Validate language codes</action>
|
||||
<template-output>product_languages</template-output>
|
||||
|
||||
<output>✅ **Language Configuration:**
|
||||
|
||||
- **Specifications written in:** {{specification_language}}
|
||||
- **Product supports:** {{product_languages_list}}
|
||||
|
||||
All text specifications will include translations for: {{product_languages_list}}</output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Configure folder naming">
|
||||
<output>WDS creates folders in your project's `docs/` directory. Let's configure how they're named.</output>
|
||||
|
||||
<ask>Folder prefix style:
|
||||
|
||||
1. **Letters** (A-Product-Brief, B-Trigger-Map, C-...)
|
||||
- Distinctive WDS branding
|
||||
- Easy visual grouping
|
||||
2. **Numbers** (01-Product-Brief, 02-Trigger-Map, 03-...)
|
||||
- Traditional sequential numbering
|
||||
- Familiar format
|
||||
|
||||
Choice [1/2]:</ask>
|
||||
<action>Set folder_prefix based on choice (letters/numbers)</action>
|
||||
<template-output>folder_prefix</template-output>
|
||||
|
||||
<ask>Folder capitalization:
|
||||
|
||||
1. **Title-Case** (A-Product-Brief, B-Trigger-Map)
|
||||
- Easier to read for non-technical stakeholders
|
||||
2. **lowercase** (a-product-brief, b-trigger-map)
|
||||
- Developer-friendly convention
|
||||
|
||||
Choice [1/2]:</ask>
|
||||
<action>Set folder_case based on choice (title/lowercase)</action>
|
||||
<template-output>folder_case</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Design System decision">
|
||||
<check if="project_type in [full-product, landing-page, feature-enhancement]">
|
||||
<output>The **Design System** phase is optional but valuable for building reusable components.</output>
|
||||
|
||||
<ask>Include Design System phase?
|
||||
|
||||
1. **Yes** - Build a component library alongside design work
|
||||
2. **No** - Keep it simple, focus on page designs only
|
||||
3. **Help me decide**
|
||||
|
||||
Choice [1/2/3]:</ask>
|
||||
|
||||
<check if="choice == 3">
|
||||
<output>Include Design System if:
|
||||
- You have multiple pages with shared patterns
|
||||
- You want consistent components across the product
|
||||
- You're building for a team that needs a component library
|
||||
- You plan to hand off to developers who need component docs
|
||||
|
||||
Skip Design System if:
|
||||
|
||||
- It's a simple, one-off project
|
||||
- You're using an existing design system (Material, Chakra, etc.)
|
||||
- You need to move fast without component documentation</output>
|
||||
<ask>Based on this, include Design System? (y/n)</ask>
|
||||
<action>Set include_design_system based on answer</action>
|
||||
</check>
|
||||
|
||||
<check if="choice == 1">
|
||||
<action>Set include_design_system = true</action>
|
||||
</check>
|
||||
|
||||
<check if="choice == 2">
|
||||
<action>Set include_design_system = false</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="project_type == design-system-only">
|
||||
<action>Set include_design_system = true</action>
|
||||
</check>
|
||||
|
||||
<template-output>include_design_system</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Component library selection">
|
||||
<check if="include_design_system == true">
|
||||
<output>For the Design System, you can build custom components or use an existing library.</output>
|
||||
|
||||
<ask>Component library approach:
|
||||
|
||||
1. **Custom** - Build your own from scratch
|
||||
2. **Shadcn/ui** - Copy-paste React components (recommended for flexibility)
|
||||
3. **Chakra UI** - Comprehensive React library
|
||||
4. **Radix UI** - Headless accessible primitives
|
||||
5. **Material UI** - Material Design components
|
||||
6. **Tailwind CSS** - Utility-first styling (combine with headless)
|
||||
7. **Other** - I'll specify later
|
||||
8. **Undecided** - I'll choose during the project
|
||||
|
||||
Choice [1-8]:</ask>
|
||||
<action>Set component_library based on choice</action>
|
||||
<template-output>component_library</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Generate workflow path">
|
||||
<action>Load path file: {path_files}/{{project_type}}.yaml</action>
|
||||
<action>Build workflow_items from path file</action>
|
||||
<action>Apply brief_level setting (simplified or complete)</action>
|
||||
<action>Apply include_design_system setting</action>
|
||||
<action>Generate folder names based on folder_prefix and folder_case</action>
|
||||
<action>Set generated date</action>
|
||||
|
||||
<template-output>generated</template-output>
|
||||
<template-output>workflow_path_file</template-output>
|
||||
<template-output>workflow_items</template-output>
|
||||
<template-output>folder_names</template-output>
|
||||
<template-output>brief_level</template-output>
|
||||
<template-output>specification_language</template-output>
|
||||
<template-output>product_languages</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Review and create">
|
||||
<output>Your WDS project setup:
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Type:** {{project_type}}
|
||||
**Project Brief:** {{#if brief_level == 'complete'}}Complete{{else}}Simplified{{/if}}
|
||||
**Specification Language:** {{specification_language}}
|
||||
**Product Languages:** {{product_languages_list}}
|
||||
**Design System:** {{include_design_system}}
|
||||
{{#if component_library}}**Component Library:** {{component_library}}{{/if}}
|
||||
|
||||
**Phases enabled:**
|
||||
{{#each enabled_phases}}
|
||||
|
||||
- Phase {{this.number}}: {{this.name}} → `{{this.folder}}/`
|
||||
{{/each}}
|
||||
|
||||
**Folder naming:** {{folder_prefix}} + {{folder_case}}
|
||||
Example: `{{example_folder_name}}`
|
||||
</output>
|
||||
|
||||
<ask>Create WDS workflow tracking file? (y/n)</ask>
|
||||
|
||||
<check if="y">
|
||||
<action>Generate YAML from template with all variables</action>
|
||||
<action>Save to {output_folder}/wds-workflow-status.yaml</action>
|
||||
<action>Identify first workflow and agent</action>
|
||||
|
||||
<output>✅ **Created:** {output_folder}/wds-workflow-status.yaml
|
||||
|
||||
**Your WDS journey begins!**
|
||||
|
||||
**First Phase:** {{first_phase_name}}
|
||||
**Agent:** {{first_agent}}
|
||||
**Folder:** {{first_folder}}
|
||||
|
||||
To start, activate **{{first_agent}}** and begin {{first_phase_name}}.
|
||||
|
||||
To check progress anytime: `/bmad:wds:workflows:workflow-status`
|
||||
|
||||
Happy designing! 🎨</output>
|
||||
</check>
|
||||
|
||||
<check if="n">
|
||||
<output>No problem! Run this workflow again when you're ready.
|
||||
|
||||
You can also manually create your project structure:
|
||||
{{#each enabled_phases}}
|
||||
|
||||
- Create `docs/{{this.folder}}/` for {{this.name}}
|
||||
{{/each}}
|
||||
|
||||
Happy designing! 🎨</output>
|
||||
</check>
|
||||
<action>Load and execute: `workflow-init/steps/step-02-project-structure.md`</action>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
|
|||
|
|
@ -6,6 +6,17 @@ project:
|
|||
description: "{{PROJECT_DESCRIPTION}}"
|
||||
wds_version: "6.0"
|
||||
created: "{{DATE}}"
|
||||
|
||||
# Project Structure - defines folder organization
|
||||
structure:
|
||||
type: "{{STRUCTURE_TYPE}}" # "landing_page" | "simple_website" | "web_application"
|
||||
scenarios: "{{STRUCTURE_SCENARIOS}}" # "single" | "multiple"
|
||||
pages: "{{STRUCTURE_PAGES}}" # "single" | "multiple"
|
||||
|
||||
# Folder organization pattern
|
||||
# landing_page: 4-scenarios/1.1-page-name/
|
||||
# simple_website: 4-scenarios/1.1-page/, 4-scenarios/1.2-page/
|
||||
# web_application: 4-scenarios/1-scenario-name/1.1-page/, 4-scenarios/2-scenario-name/2.1-page/
|
||||
|
||||
# Design System Configuration
|
||||
design_system:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,54 @@
|
|||
# Step 2: Project Structure
|
||||
|
||||
**Goal:** Determine the project structure to set up the correct folder organization.
|
||||
|
||||
---
|
||||
|
||||
## YOUR TASK
|
||||
|
||||
Ask the user about their project structure.
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
<output>**Let's determine your project structure.**
|
||||
|
||||
This defines how we'll organize your scenarios and pages.</output>
|
||||
|
||||
<ask>**What are you designing?**
|
||||
|
||||
1. **Separate pages** - Individual pages, landing pages, or page variants
|
||||
2. **Single user flow** - Multiple pages in one continuous journey (website, wizard, single app flow)
|
||||
3. **Multiple user flows** - Application with different user journeys (web app, mobile app, admin system)
|
||||
|
||||
Choice [1/2/3]:</ask>
|
||||
|
||||
<action>Map choice to structure:
|
||||
- 1 → structure_type: "separate_pages", scenarios: "single", pages: "single"
|
||||
- 2 → structure_type: "single_flow", scenarios: "single", pages: "multiple"
|
||||
- 3 → structure_type: "multiple_flows", scenarios: "multiple", pages: "multiple"
|
||||
</action>
|
||||
|
||||
<output>✅ **Project Structure Set**
|
||||
|
||||
{{#if choice == 1}}
|
||||
**Separate pages** - We'll create individual page folders (with optional variants).
|
||||
{{else if choice == 2}}
|
||||
**Single user flow** - We'll create numbered pages in one flow (1.1, 1.2, 1.3...).
|
||||
{{else if choice == 3}}
|
||||
**Multiple user flows** - We'll create scenario folders with pages inside each (1-scenario/1.1, 1.2...).
|
||||
{{/if}}
|
||||
|
||||
This structure will be used when you start designing in Phase 4 (UX Design).</output>
|
||||
|
||||
<template-output>structure_type</template-output>
|
||||
<template-output>structure_scenarios</template-output>
|
||||
<template-output>structure_pages</template-output>
|
||||
|
||||
---
|
||||
|
||||
## NEXT STEP
|
||||
|
||||
<action>Load and execute: `workflow-init/steps/step-03-delivery-config.md`</action>
|
||||
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
# Step 3: Delivery Configuration
|
||||
|
||||
**Goal:** Define what format you'll be delivering at the end of the design process.
|
||||
|
||||
---
|
||||
|
||||
## YOUR TASK
|
||||
|
||||
Determine the delivery format and whether PRD phases are needed.
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
<output>**What will you deliver at the end of the design process?**</output>
|
||||
|
||||
<ask>**Delivery format:**
|
||||
|
||||
1. **WordPress Markup** - Ready-to-paste WordPress editor code
|
||||
2. **Complete PRD** - Product Requirements Document for development team
|
||||
3. **Interactive Prototype** - HTML/Figma prototype for testing
|
||||
4. **Direct to Code** - Specifications ready for AI code generation
|
||||
5. **Figma Designs** - Visual designs in Figma with handoff
|
||||
6. **Custom/Other** - I'll specify
|
||||
|
||||
Choice [1-6]:</ask>
|
||||
|
||||
<action>Map choice to delivery configuration:
|
||||
- 1 → format: "wordpress", target_platform: "wordpress", requires_prd: false
|
||||
- 2 → format: "prd", target_platform: "custom", requires_prd: true
|
||||
- 3 → format: "prototype", target_platform: "html", requires_prd: false
|
||||
- 4 → format: "direct-code", target_platform: "custom", requires_prd: false
|
||||
- 5 → format: "figma", target_platform: "figma", requires_prd: false
|
||||
- 6 → format: "other", ask for details
|
||||
</action>
|
||||
|
||||
<check if="choice == 6">
|
||||
<ask>Please describe your delivery format and target platform:</ask>
|
||||
<action>Store custom delivery_description</action>
|
||||
<ask>Will this project need PRD phases (Platform Requirements + PRD Finalization)? (y/n)</ask>
|
||||
<action>Set requires_prd based on answer</action>
|
||||
</check>
|
||||
|
||||
<output>✅ **Delivery Configuration Set**
|
||||
|
||||
{{#if delivery_format == wordpress}}
|
||||
**WordPress Markup** - Design specifications will be WordPress-ready.
|
||||
PRD phases will be skipped (direct implementation).
|
||||
{{else if delivery_format == prd}}
|
||||
**Complete PRD** - You'll create a full Product Requirements Document.
|
||||
PRD phases are required (Phase 3 + Phase 6).
|
||||
{{else if delivery_format == prototype}}
|
||||
**Interactive Prototype** - Focus on testable prototypes.
|
||||
PRD phases are optional.
|
||||
{{else if delivery_format == direct-code}}
|
||||
**Direct to Code** - Specifications for AI code generation.
|
||||
PRD phases are optional.
|
||||
{{else if delivery_format == figma}}
|
||||
**Figma Designs** - Visual designs with developer handoff.
|
||||
PRD phases are optional.
|
||||
{{else}}
|
||||
**Custom Format** - {{delivery_description}}
|
||||
PRD phases: {{#if requires_prd}}Required{{else}}Not needed{{/if}}
|
||||
{{/if}}</output>
|
||||
|
||||
<template-output>delivery_format</template-output>
|
||||
<template-output>target_platform</template-output>
|
||||
<template-output>requires_prd</template-output>
|
||||
<template-output>delivery_description</template-output>
|
||||
|
||||
---
|
||||
|
||||
## NEXT STEP
|
||||
|
||||
<action>Load and execute: `workflow-init/steps/step-04-phases-selection.md`</action>
|
||||
|
||||
|
|
@ -0,0 +1,180 @@
|
|||
# Step 4: Project Phases Selection
|
||||
|
||||
**Goal:** Select which WDS phases you need for this project.
|
||||
|
||||
---
|
||||
|
||||
## YOUR TASK
|
||||
|
||||
Guide the user through selecting appropriate project phases.
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
<output>**Which WDS phases do you need?**
|
||||
|
||||
WDS offers 6 design phases. Let's figure out which ones serve your project.</output>
|
||||
|
||||
<ask>**Project phase approach:**
|
||||
|
||||
1. **Guided Selection** - I'll recommend phases based on your answers
|
||||
2. **Express Selection** - I know exactly which phases I need
|
||||
3. **Show All Phases** - Let me see what's available
|
||||
|
||||
Choice [1/2/3]:</ask>
|
||||
|
||||
<check if="choice == 3">
|
||||
<output>**WDS Phases Overview:**
|
||||
|
||||
**Phase 1: Product Brief** 📋
|
||||
- Define vision, positioning, target users
|
||||
- SMART success criteria
|
||||
- When: New projects, strategic clarity needed
|
||||
|
||||
**Phase 2: Trigger Mapping** 🎯
|
||||
- Connect business goals to user psychology
|
||||
- Prioritize features
|
||||
- Define personas
|
||||
- When: Understanding user needs deeply
|
||||
|
||||
**Phase 3: Platform Requirements** 🏗️
|
||||
- Technical architecture
|
||||
- Data models
|
||||
- Platform decisions
|
||||
- When: Building applications (requires_prd: true)
|
||||
|
||||
**Phase 4: UX Design** 🎨
|
||||
- Scenario-driven page design
|
||||
- Conceptual specifications
|
||||
- Interactive prototypes
|
||||
- When: Always (core design phase)
|
||||
|
||||
**Phase 5: Design System** 🧩
|
||||
- Component library
|
||||
- Design tokens
|
||||
- Reusable patterns
|
||||
- When: Multiple pages, consistency needed
|
||||
|
||||
**Phase 6: PRD Finalization** 📦
|
||||
- Complete PRD compilation
|
||||
- Development roadmap
|
||||
- Implementation handoff
|
||||
- When: Formal development handoff (requires_prd: true)</output>
|
||||
|
||||
<ask>Now, which approach?
|
||||
1. Guided Selection
|
||||
2. Express Selection
|
||||
|
||||
Choice [1/2]:</ask>
|
||||
</check>
|
||||
|
||||
<check if="choice == 1">
|
||||
<output>**Guided Phase Selection**
|
||||
|
||||
Based on your project, I'll recommend the right phases.</output>
|
||||
|
||||
<ask>**What's your starting point?**
|
||||
|
||||
1. **Brand new idea** - Starting from scratch
|
||||
2. **Clear vision** - I know what I want to build
|
||||
3. **Existing product** - Adding features or redesigning
|
||||
|
||||
Choice [1/2/3]:</ask>
|
||||
|
||||
<check if="starting_point == 1">
|
||||
<output>**Recommendation: Full Discovery**
|
||||
|
||||
For brand new ideas:
|
||||
- Phase 1: Product Brief (define the vision)
|
||||
- Phase 2: Trigger Mapping (understand users)
|
||||
- Phase 4: UX Design (design the experience)
|
||||
- Phase 5: Design System (optional, if multiple pages)
|
||||
{{#if requires_prd}}
|
||||
- Phase 3: Platform Requirements
|
||||
- Phase 6: PRD Finalization
|
||||
{{/if}}</output>
|
||||
<action>Set recommended_phases: [1, 2, 4] + (requires_prd ? [3, 6] : [])</action>
|
||||
</check>
|
||||
|
||||
<check if="starting_point == 2">
|
||||
<output>**Recommendation: Design-Focused**
|
||||
|
||||
For clear visions:
|
||||
- Phase 2: Trigger Mapping (optional, validate assumptions)
|
||||
- Phase 4: UX Design (design the experience)
|
||||
- Phase 5: Design System (optional, if multiple pages)
|
||||
{{#if requires_prd}}
|
||||
- Phase 3: Platform Requirements
|
||||
- Phase 6: PRD Finalization
|
||||
{{/if}}</output>
|
||||
<action>Set recommended_phases: [4] + (requires_prd ? [3, 6] : [])</action>
|
||||
</check>
|
||||
|
||||
<check if="starting_point == 3">
|
||||
<output>**Recommendation: Enhancement Flow**
|
||||
|
||||
For existing products:
|
||||
- Phase 2: Trigger Mapping (optional, understand impact)
|
||||
- Phase 4: UX Design (design the changes)
|
||||
{{#if requires_prd}}
|
||||
- Phase 6: PRD Finalization (document changes)
|
||||
{{/if}}</output>
|
||||
<action>Set recommended_phases: [4] + (requires_prd ? [6] : [])</action>
|
||||
</check>
|
||||
|
||||
<ask>Include these phases? {{recommended_phases_list}}
|
||||
|
||||
1. Yes, these are perfect
|
||||
2. Let me customize
|
||||
|
||||
Choice [1/2]:</ask>
|
||||
|
||||
<check if="customize == 2">
|
||||
<action>Continue to express selection</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="choice == 2 OR customize == 2">
|
||||
<output>**Express Phase Selection**</output>
|
||||
|
||||
<ask>Select the phases you need (comma-separated):
|
||||
|
||||
1. Product Brief
|
||||
2. Trigger Mapping
|
||||
3. Platform Requirements
|
||||
4. UX Design
|
||||
5. Design System
|
||||
6. PRD Finalization
|
||||
|
||||
Example: "1,2,4,5" or "4" or "2,4,6"
|
||||
|
||||
Your phases:</ask>
|
||||
|
||||
<action>Parse selected phases</action>
|
||||
<action>Store selected_phases array</action>
|
||||
</check>
|
||||
|
||||
<output>✅ **Project Phases Configured**
|
||||
|
||||
**Phases Included:**
|
||||
{{#each selected_phase}}
|
||||
- Phase {{this.number}}: {{this.name}}
|
||||
{{/each}}
|
||||
|
||||
{{#if not_selected_phases}}
|
||||
**Phases Skipped:**
|
||||
{{#each not_selected_phase}}
|
||||
- Phase {{this.number}}: {{this.name}}
|
||||
{{/each}}
|
||||
{{/if}}</output>
|
||||
|
||||
<template-output>selected_phases</template-output>
|
||||
<template-output>workflow_path</template-output>
|
||||
|
||||
---
|
||||
|
||||
## NEXT STEP
|
||||
|
||||
<action>Load and execute: `workflow-init/steps/step-05-languages.md`</action>
|
||||
|
||||
Loading…
Reference in New Issue