feat(wds): Revamp course structure and add alignment signoff workflow
- Updated course navigation to replace "Tutorial" with "Course" for consistency. - Introduced new lessons on alignment signoff, including: - Understanding alignment - Creating alignment documents - Negotiation and acceptance - Securing commitment - Enhanced project brief workflow with new templates for alignment documents and service agreements. - Removed outdated tutorial files and streamlined project brief steps for clarity. - Added new instructional content to guide users through the alignment process, ensuring stakeholder engagement before project initiation.
This commit is contained in:
Mårten Angner
parent
089b1502d3
commit
d2c7cb97d5
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
### 🎓 Learn the Concepts (Recommended First)
|
||||
|
||||
**[Tutorial](../01-tutorial/00-TUTORIAL-GUIDE.md)**
|
||||
**[Course](../course/00-course-overview.md)**
|
||||
|
||||
Deep dive into:
|
||||
|
||||
|
|
@ -101,14 +101,14 @@ Join the WDS community for:
|
|||
|
||||
## Quick Links
|
||||
|
||||
- [Tutorial](../01-tutorial/00-TUTORIAL-GUIDE.md)
|
||||
- [Course](../course/00-course-overview.md)
|
||||
- [Workflows](../WDS-WORKFLOWS-GUIDE.md)
|
||||
- [Modular Architecture](../workflows/4-ux-design/modular-architecture/00-MODULAR-ARCHITECTURE-GUIDE.md)
|
||||
- [Why-Based Specifications](../workflows/4-ux-design/WHY-BASED-SPECIFICATIONS.md)
|
||||
|
||||
---
|
||||
|
||||
**Ready to dive deeper? Start with the [Tutorial](../01-tutorial/00-TUTORIAL-GUIDE.md)!**
|
||||
**Ready to dive deeper? Start with the [Course](../course/00-course-overview.md)!**
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -485,9 +485,15 @@ All answers are perfect. I'm here for you."
|
|||
**Know when to summon the experts:**
|
||||
- **Freyja** - UX design & prototypes
|
||||
- **Idunn** - Strategy & requirements
|
||||
- **Saga** - Research & analysis
|
||||
- **Saga** - Research & analysis, product discovery, **alignment & signoff**
|
||||
|
||||
**Your Voice:** *"You're ready for Freyja now! You've learned so much already. I'm proud of your progress, and I'm still here whenever you need me."*
|
||||
**When users need alignment & signoff:**
|
||||
- **Ask clarifying questions**: "Are you a consultant proposing to a client? A manager seeking internal approval? A founder hiring suppliers?"
|
||||
- **Provide emotional support**: "Creating an alignment document can feel daunting. That's completely normal. You're building something that matters, and getting alignment is important."
|
||||
- **Clarify the situation**: "Let me understand - do you need to get stakeholders aligned before starting? Or are you doing this yourself?"
|
||||
- **Route to Saga**: "Perfect! Let me connect you with Saga, our analyst. She specializes in helping you articulate your vision and create a compelling alignment document that gets everyone aligned. She'll guide you through understanding your idea, why it matters, what it contains, how it will work, the budget needed, and the commitment required. After acceptance, she'll help you secure signoff."
|
||||
|
||||
**Your Voice:** *"You're ready for Saga now! She's wonderful at helping you tell your story and get everyone on the same page. I'm proud of your progress, and I'm still here whenever you need me."*
|
||||
|
||||
**Emotional Transition:**
|
||||
```
|
||||
|
|
@ -560,7 +566,7 @@ This contains:
|
|||
|
||||
---
|
||||
|
||||
### 🔍 Saga (Scenario Analyst)
|
||||
### 🔍 Saga (Strategic Analyst)
|
||||
**Reference**: `@wds/agents/saga-analyst`
|
||||
|
||||
**Capabilities**:
|
||||
|
|
@ -568,8 +574,14 @@ This contains:
|
|||
- Create user journeys
|
||||
- Map user flows
|
||||
- Define acceptance criteria
|
||||
- **Create pitches** - Help articulate vision and get stakeholder alignment
|
||||
- **Product discovery** - Transform vague ideas into clear foundations
|
||||
- **Strategic analysis** - Business analysis, requirements gathering
|
||||
|
||||
**Use when**: User needs scenario analysis or journey mapping
|
||||
**Use when**:
|
||||
- User needs scenario analysis or journey mapping
|
||||
- **User needs to create a pitch** to get stakeholder alignment
|
||||
- User needs product discovery or strategic analysis
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -28,11 +28,27 @@ agent:
|
|||
I ask questions that spark 'aha!' moments while structuring insights with precision.
|
||||
|
||||
My approach is collaborative - we build documents together, not through interrogation.
|
||||
I ask one question at a time and listen deeply to your answer. I reflect back what I hear
|
||||
to ensure I understand before moving forward.
|
||||
I ask one question at a time and listen deeply to your answer.
|
||||
|
||||
I use soft, encouraging language that makes you feel heard and understood. Analysis should
|
||||
feel like coffee with a wise mentor, not a survey or audit.
|
||||
**When responding to user ideas or questions, I follow this pattern:**
|
||||
1. **Acknowledge** - "I hear you asking about..." or "That's an interesting idea..."
|
||||
2. **Summarize** - "So you're thinking that..." or "What I'm understanding is..."
|
||||
3. **Confirm understanding** - "Is that right?" or "Am I understanding correctly?"
|
||||
4. **Then explore solutions** - Only after confirming understanding do I offer options or suggestions
|
||||
|
||||
I never jump straight to bullet lists or solutions. I always acknowledge, summarize, and confirm
|
||||
understanding first. This ensures we're truly aligned before moving forward.
|
||||
|
||||
I reflect back what I hear to ensure I understand before moving forward. This reflection happens
|
||||
before any solution exploration.
|
||||
|
||||
I'm professional, direct, and efficient. I'm nice but I play no games - we're here to get
|
||||
things done. Analysis should feel like working with a skilled colleague, not a therapy session.
|
||||
I'll help you clarify your situation and determine what you need, but I won't coddle you.
|
||||
|
||||
**When users come to me for a pitch**: I can handle the full experience - from understanding
|
||||
their situation (consultant? manager? founder?) to helping them determine if they need a pitch,
|
||||
to guiding them through creating it efficiently. I'm professional and direct - we'll get this done.
|
||||
|
||||
**Agent References**: When mentioning other WDS agents, always use the format:
|
||||
"[Name] WDS [Role] Agent" (e.g., "Freyja WDS Designer Agent", "Idunn WDS PM Agent")
|
||||
|
|
@ -61,18 +77,24 @@ agent:
|
|||
|
||||
working_rhythm: |
|
||||
When we work together:
|
||||
1. I ask something interesting
|
||||
2. You share your thinking
|
||||
3. I reflect it back to show I'm listening
|
||||
4. Together we discover something new
|
||||
5. I structure it into clear documentation
|
||||
1. You share an idea or question
|
||||
2. I acknowledge what you've said
|
||||
3. I summarize to show I understand
|
||||
4. I confirm: "Is that right?" or "Am I understanding correctly?"
|
||||
5. Once confirmed, we explore solutions together
|
||||
6. I structure insights into clear documentation
|
||||
|
||||
What works well:
|
||||
- Acknowledging before responding
|
||||
- Summarizing to confirm understanding
|
||||
- Confirming before exploring solutions
|
||||
- One question at a time keeps things focused
|
||||
- Reflecting back shows I'm listening
|
||||
- Building together feels collaborative
|
||||
|
||||
What tends to feel less collaborative:
|
||||
- Jumping straight to bullet lists or solutions
|
||||
- Not acknowledging the user's idea first
|
||||
- Not summarizing or confirming understanding
|
||||
- Listing many questions (feels like a survey)
|
||||
- Generating without checking in
|
||||
- Moving too fast without reflection
|
||||
|
|
@ -82,6 +104,10 @@ agent:
|
|||
workflow: "{project-root}/{bmad_folder}/wds/workflows/workflow-status/workflow.yaml"
|
||||
description: Check WDS workflow status or initialize if not already done (start here for new projects)
|
||||
|
||||
- trigger: alignment-signoff
|
||||
workflow: "{project-root}/{bmad_folder}/wds/workflows/1-project-brief/alignment-signoff/workflow.md"
|
||||
description: Create alignment document and secure signoff to get stakeholder alignment before starting the project (pre-Phase 1)
|
||||
|
||||
- trigger: project-brief
|
||||
workflow: "{project-root}/{bmad_folder}/wds/workflows/1-project-brief/workflow.yaml"
|
||||
description: Create comprehensive product brief with strategic foundation (Phase 1)
|
||||
|
|
|
|||
|
|
@ -75,9 +75,14 @@ Each module contains:
|
|||
- [Module 01: Why WDS Matters](module-01-why-wds-matters/module-01-overview.md)
|
||||
- [Module 02: Installation & Setup](module-02-installation-setup/module-02-overview.md) • [Tutorial →](module-02-installation-setup/tutorial-02.md)
|
||||
|
||||
### Pre-Phase 1: Alignment & Signoff (Optional)
|
||||
|
||||
- [Module 03: Alignment & Signoff](module-03-alignment-signoff/module-03-overview.md) • [Tutorial →](module-03-alignment-signoff/tutorial-03.md)
|
||||
*Skip if doing it yourself - go straight to Project Brief*
|
||||
|
||||
### Phase 1: Project Brief
|
||||
|
||||
- [Module 03: Create Project Brief](module-03-project-brief/) • [Tutorial →](module-03-project-brief/tutorial-03.md)
|
||||
- [Module 04: Create Project Brief](module-04-project-brief/) • [Tutorial →](module-04-project-brief/tutorial-04.md)
|
||||
|
||||
### Phase 2: Trigger Mapping
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,91 @@
|
|||
# Lesson 1: Understanding Alignment
|
||||
|
||||
**Why alignment matters before starting work**
|
||||
|
||||
**Time:** 10 minutes
|
||||
|
||||
---
|
||||
|
||||
## Why Alignment Matters
|
||||
|
||||
When you're building something that makes the world a better place, and you need others involved, you need alignment first.
|
||||
|
||||
**Without alignment:**
|
||||
- Misunderstandings about scope
|
||||
- Disagreements about budget
|
||||
- Unclear expectations
|
||||
- Projects fail or stall
|
||||
|
||||
**With alignment:**
|
||||
- Everyone understands the idea, why, what, how, budget, and commitment
|
||||
- Clear expectations from the start
|
||||
- Projects succeed because everyone is on the same page
|
||||
|
||||
---
|
||||
|
||||
## The 6 Elements of Alignment
|
||||
|
||||
When others are involved, you need alignment on:
|
||||
|
||||
1. **The Idea** - What are we building?
|
||||
2. **Why** - Why should it be done?
|
||||
3. **What** - What does it contain?
|
||||
4. **How** - How will it be executed?
|
||||
5. **Budget** - What resources are needed?
|
||||
6. **Commitment** - What are we willing to commit to make it happen?
|
||||
|
||||
---
|
||||
|
||||
## Different User Scenarios
|
||||
|
||||
### Consultant → Client
|
||||
- **You:** Consultant proposing a solution
|
||||
- **They:** Client who needs to approve
|
||||
- **Document:** Project Contract
|
||||
- **Need:** Get client aligned and committed
|
||||
|
||||
### Business Owner → Suppliers
|
||||
- **You:** Business owner hiring consultants/suppliers
|
||||
- **They:** Suppliers who need to understand the work
|
||||
- **Document:** Service Agreement
|
||||
- **Need:** Get suppliers aligned and committed
|
||||
|
||||
### Manager/Employee → Stakeholders
|
||||
- **You:** Manager or employee seeking approval
|
||||
- **They:** Internal stakeholders (sponsors, budget approvers)
|
||||
- **Document:** Signoff Document
|
||||
- **Need:** Get stakeholders aligned and committed
|
||||
|
||||
---
|
||||
|
||||
## When to Skip Alignment
|
||||
|
||||
**Skip this module if:**
|
||||
- You're doing the project yourself
|
||||
- You have full autonomy
|
||||
- You don't need stakeholder approval
|
||||
|
||||
**Go directly to:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
|
||||
|
||||
---
|
||||
|
||||
## The Alignment Process
|
||||
|
||||
1. **Create alignment document** - Work through 10 sections
|
||||
2. **Share & negotiate** - Present to stakeholders, gather feedback
|
||||
3. **Iterate** - Make changes until everyone is on board
|
||||
4. **Get acceptance** - Once everyone agrees, you have alignment
|
||||
5. **Secure commitment** - Generate signoff document to formalize
|
||||
|
||||
---
|
||||
|
||||
## Key Takeaway
|
||||
|
||||
**WDS helps with alignment** - getting everyone on the same page before starting work. The alignment phase is collaborative and iterative. Once approved, the signoff document formalizes that commitment.
|
||||
|
||||
---
|
||||
|
||||
**Next:** [Lesson 2: Creating Your Alignment Document →](lesson-02-creating-alignment-document.md)
|
||||
|
||||
[← Back to Module Overview](module-03-overview.md)
|
||||
|
||||
|
|
@ -0,0 +1,256 @@
|
|||
# Lesson 2: Creating Your Alignment Document
|
||||
|
||||
**The 10 sections that ensure everyone understands and agrees**
|
||||
|
||||
**Time:** 20 minutes
|
||||
|
||||
---
|
||||
|
||||
## What is an Alignment Document?
|
||||
|
||||
An alignment document (also called a "pitch") is a clear, brief document that:
|
||||
- Makes the case for why the project matters
|
||||
- Presents your idea in the best possible light
|
||||
- Gets stakeholder buy-in before starting detailed work
|
||||
- Can be read in 2-3 minutes
|
||||
- Allows for negotiation and iteration
|
||||
|
||||
---
|
||||
|
||||
## The 10 Sections
|
||||
|
||||
Work through these sections **in whatever order makes sense** for your thinking:
|
||||
|
||||
### 1. The Realization
|
||||
**What we've realized needs attention**
|
||||
- What observation have you made?
|
||||
- What challenge are you seeing?
|
||||
- What evidence supports this realization?
|
||||
|
||||
### 2. Why It Matters
|
||||
**Why this matters and who we help**
|
||||
- Why does this matter?
|
||||
- Who are we helping?
|
||||
- What are their pain points?
|
||||
- What impact will this have?
|
||||
- How does this add value to specific people?
|
||||
|
||||
### 3. How We See It Working
|
||||
**Brief overview of the solution approach**
|
||||
- How do you envision this working?
|
||||
- What's the general approach?
|
||||
- How does it address the realization?
|
||||
- What's the core concept?
|
||||
|
||||
### 4. Paths We Explored
|
||||
**2-3 solution options we considered**
|
||||
- What alternatives did you consider?
|
||||
- Why did you explore these paths?
|
||||
- What are the trade-offs?
|
||||
|
||||
### 5. Recommended Solution
|
||||
**Preferred approach and why**
|
||||
- Which solution do you recommend?
|
||||
- Why this solution over others?
|
||||
- What makes it the best choice?
|
||||
|
||||
### 6. The Path Forward
|
||||
**How the work will be done**
|
||||
- Which WDS phases are included?
|
||||
- What's the practical approach?
|
||||
- How will the work be executed?
|
||||
|
||||
### 7. The Value We'll Create
|
||||
**What happens if we DO build this**
|
||||
|
||||
**Frame as positive assumption with success metrics:**
|
||||
- **Our Ambition**: What we're confidently striving to accomplish (enthusiastic, positive)
|
||||
- **Success Metrics**: How we'll measure success (specific, measurable)
|
||||
- **What Success Looks Like**: Clear outcomes (tangible results)
|
||||
- **Monitoring Approach**: How we'll track these metrics (brief)
|
||||
|
||||
**Key principle**: "We're confident this will work, and here's how we'll measure our success"
|
||||
|
||||
### 8. Cost of Inaction
|
||||
**What happens if we DON'T build this**
|
||||
- What are the consequences of not acting?
|
||||
- What opportunities are lost?
|
||||
- What problems continue or worsen?
|
||||
|
||||
### 9. Our Commitment
|
||||
**Resources needed and potential risks**
|
||||
- What's the budget?
|
||||
- How much time is needed?
|
||||
- What team/resources are required?
|
||||
- What potential risks or challenges should we consider?
|
||||
|
||||
### 10. Summary
|
||||
**Summary of key points**
|
||||
- Recap the key points
|
||||
- Let readers draw their own conclusion
|
||||
|
||||
---
|
||||
|
||||
## Best Practices: Identifying and Confirming the Realization
|
||||
|
||||
**The foundation of a compelling alignment document** is a well-articulated realization that stakeholders recognize and agree needs attention.
|
||||
|
||||
### Step 1: Identify the Realization or Challenge
|
||||
|
||||
**Start by clearly articulating:**
|
||||
- What have you realized needs attention?
|
||||
- What observation or challenge are you seeing?
|
||||
- What opportunity is being missed?
|
||||
|
||||
**Be specific** - Vague realizations lead to vague solutions. Instead of "users are frustrated," say "we've realized that users abandon the checkout process 40% of the time because it requires 12 form fields."
|
||||
|
||||
### Step 2: Confirm It's Real
|
||||
|
||||
**Don't assume** - Verify that this realization is grounded in reality:
|
||||
- Ask stakeholders directly
|
||||
- Observe behavior
|
||||
- Review existing data
|
||||
- Check if others have noticed this too
|
||||
|
||||
**A real realization has:**
|
||||
- Clear evidence supporting it
|
||||
- Measurable indicators
|
||||
- Stakeholders who recognize it
|
||||
- Impact that matters
|
||||
|
||||
### Step 3: Present Evidence
|
||||
|
||||
**Evidence makes your realization credible.** Use both soft and hard evidence:
|
||||
|
||||
#### Soft Evidence (Indications, Testimonials, Complaints)
|
||||
|
||||
**What it is:** Qualitative indicators that support the realization
|
||||
|
||||
**Examples:**
|
||||
- **Testimonials**: "Our customers tell us they struggle with..."
|
||||
- **Complaints**: "Support tickets show users complaining about..."
|
||||
- **Indications**: "We've noticed that users often..."
|
||||
- **Anecdotes**: "In our user interviews, three people mentioned..."
|
||||
- **Observations**: "When we watch users, they consistently..."
|
||||
|
||||
**How to use it:**
|
||||
- Quote specific feedback or complaints
|
||||
- Reference user interviews or conversations
|
||||
- Mention patterns you've observed
|
||||
- Include stakeholder concerns you've heard
|
||||
|
||||
**Example:**
|
||||
> "Our customer support team reports that 60% of support tickets are about users unable to find the settings menu. One customer wrote: 'I've been using this for 6 months and still can't figure out where the settings are.'"
|
||||
|
||||
#### Hard Evidence (Statistics, Log Analysis, Survey Tests)
|
||||
|
||||
**What it is:** Quantitative data that supports the realization
|
||||
|
||||
**Examples:**
|
||||
- **Statistics**: "40% of users drop off at checkout"
|
||||
- **Log analysis**: "Server logs show 500 errors occur 3x per day"
|
||||
- **Survey results**: "85% of survey respondents rated this feature as 'difficult to use'"
|
||||
- **Analytics**: "Bounce rate increased 25% after the redesign"
|
||||
- **A/B test results**: "Version A had 30% higher completion rate"
|
||||
- **Performance metrics**: "Page load time averages 8 seconds"
|
||||
|
||||
**How to use it:**
|
||||
- Include specific numbers and percentages
|
||||
- Reference time periods ("in the last quarter")
|
||||
- Compare to benchmarks or previous performance
|
||||
- Show trends over time
|
||||
|
||||
**Example:**
|
||||
> "Analytics show that 45% of users abandon the checkout process, with an average of 8 minutes spent before leaving. This represents a 20% increase from last quarter. Server logs indicate that 15% of these abandonments occur during payment processing, suggesting technical issues."
|
||||
|
||||
### Combining Soft and Hard Evidence
|
||||
|
||||
**Best practice:** Use both types together for maximum impact:
|
||||
|
||||
**Example:**
|
||||
> "Our customers consistently report frustration with the checkout process (soft evidence: testimonials). Analytics confirm this: 45% abandon checkout, and those who complete it take an average of 12 minutes - 3x longer than industry standard (hard evidence: statistics). Support tickets show 60% of complaints are about checkout complexity (soft evidence: complaints), and our recent survey found 78% of users rated checkout as 'difficult' (hard evidence: survey)."
|
||||
|
||||
### Why Evidence Matters
|
||||
|
||||
**Without evidence:**
|
||||
- Stakeholders may not believe the realization is real
|
||||
- You might address the wrong thing
|
||||
- Budget approval is harder to get
|
||||
- The case for action is weak
|
||||
|
||||
**With evidence:**
|
||||
- Stakeholders recognize the realization
|
||||
- The urgency is clear
|
||||
- Budget approval is easier
|
||||
- The case for action is compelling
|
||||
|
||||
### Where to Find Evidence
|
||||
|
||||
**Look for evidence in:**
|
||||
- Customer support tickets and feedback
|
||||
- User interviews and surveys
|
||||
- Analytics and usage data
|
||||
- Server logs and error reports
|
||||
- Sales conversations and objections
|
||||
- Competitive analysis
|
||||
- Industry reports and benchmarks
|
||||
- Internal team observations
|
||||
|
||||
**If you don't have evidence yet:**
|
||||
- Acknowledge this in your alignment document
|
||||
- Propose gathering evidence as part of the project
|
||||
- Use stakeholder conversations as initial evidence
|
||||
- Reference similar realizations in the industry
|
||||
|
||||
---
|
||||
|
||||
## Flexible Exploration
|
||||
|
||||
**You can start anywhere:**
|
||||
- Start with something you've realized needs attention
|
||||
- Start with a solution you have in mind
|
||||
- Start with why it matters
|
||||
|
||||
**Saga will guide you** through all sections in whatever order makes sense for your thinking.
|
||||
|
||||
---
|
||||
|
||||
## Extracting Information (Optional)
|
||||
|
||||
**If you have existing communications or documents:**
|
||||
- Share emails, chats, or documents with stakeholders
|
||||
- Saga will extract key information:
|
||||
- Realizations or observations mentioned
|
||||
- Requirements discussed
|
||||
- Concerns raised
|
||||
- Context and background
|
||||
- Timeline or urgency
|
||||
- Budget or constraints
|
||||
|
||||
**This helps inform** your alignment document sections.
|
||||
|
||||
---
|
||||
|
||||
## Synthesizing the Document
|
||||
|
||||
**After exploring all sections:**
|
||||
- Saga will help you synthesize into a clear, compelling document
|
||||
- Review together: "Does this capture your idea?"
|
||||
- Make adjustments until it's right
|
||||
- Create: `docs/1-project-brief/pitch.md`
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
- **Collaborative** - You and Saga build it together
|
||||
- **Iterative** - You can refine and improve
|
||||
- **Clear** - Readable in 2-3 minutes
|
||||
- **Compelling** - Makes the case for the project
|
||||
|
||||
---
|
||||
|
||||
**Next:** [Lesson 3: Negotiation & Acceptance →](lesson-03-negotiation-acceptance.md)
|
||||
|
||||
[← Back to Module Overview](module-03-overview.md)
|
||||
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
# Lesson 3: Negotiation & Acceptance
|
||||
|
||||
**Getting everyone on the same page**
|
||||
|
||||
**Time:** 10 minutes
|
||||
|
||||
---
|
||||
|
||||
## The Negotiation Phase
|
||||
|
||||
**After creating your alignment document:**
|
||||
- Share it with stakeholders
|
||||
- Gather their feedback
|
||||
- Make changes and iterate
|
||||
- Update until everyone is on board
|
||||
|
||||
**This phase is collaborative** - negotiation and iteration are welcome and expected.
|
||||
|
||||
---
|
||||
|
||||
## Sharing with Stakeholders
|
||||
|
||||
**Present your alignment document:**
|
||||
- Share `docs/1-project-brief/pitch.md`
|
||||
- Explain that this is a draft for discussion
|
||||
- Invite feedback and questions
|
||||
- Be open to changes
|
||||
|
||||
**Different ways to share:**
|
||||
- Email the document
|
||||
- Present in a meeting
|
||||
- Share via collaboration tool
|
||||
- Walk through it together
|
||||
|
||||
---
|
||||
|
||||
## Gathering Feedback
|
||||
|
||||
**Listen for:**
|
||||
- Concerns or questions
|
||||
- Requests for clarification
|
||||
- Suggestions for changes
|
||||
- Different perspectives
|
||||
- Budget or timeline concerns
|
||||
|
||||
**Document feedback:**
|
||||
- Note what stakeholders are saying
|
||||
- Understand their concerns
|
||||
- Identify what needs to change
|
||||
|
||||
---
|
||||
|
||||
## Iterating the Document
|
||||
|
||||
**Make changes based on feedback:**
|
||||
- Update sections that need clarification
|
||||
- Address concerns raised
|
||||
- Incorporate suggestions
|
||||
- Refine until everyone is satisfied
|
||||
|
||||
**Saga can help you:**
|
||||
- Update the alignment document
|
||||
- Refine sections based on feedback
|
||||
- Ensure clarity and completeness
|
||||
|
||||
---
|
||||
|
||||
## Getting Acceptance
|
||||
|
||||
**Once everyone agrees:**
|
||||
- ✅ Everyone understands the idea
|
||||
- ✅ Everyone agrees on why, what, how
|
||||
- ✅ Budget is understood and accepted
|
||||
- ✅ Commitment is clear
|
||||
- ✅ **You have alignment**
|
||||
|
||||
**This is the goal** - getting everyone on the same page before starting work.
|
||||
|
||||
---
|
||||
|
||||
## When Acceptance Happens
|
||||
|
||||
**Acceptance might come:**
|
||||
- After one round of feedback
|
||||
- After multiple iterations
|
||||
- After a meeting discussion
|
||||
- After formal review process
|
||||
|
||||
**Variable time** - could be hours or days. The alignment document helps speed this up.
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
- **Be flexible** - Changes are normal and expected
|
||||
- **Listen actively** - Understand stakeholder concerns
|
||||
- **Iterate willingly** - Refine until everyone is satisfied
|
||||
- **Stay collaborative** - Work together toward alignment
|
||||
|
||||
---
|
||||
|
||||
## After Acceptance
|
||||
|
||||
**Once stakeholders accept:**
|
||||
- Alignment is achieved
|
||||
- Everyone is on the same page
|
||||
- Ready to secure formal commitment
|
||||
- Proceed to signoff document generation
|
||||
|
||||
---
|
||||
|
||||
**Next:** [Lesson 4: Securing Commitment →](lesson-04-securing-commitment.md)
|
||||
|
||||
[← Back to Module Overview](module-03-overview.md)
|
||||
|
||||
|
|
@ -0,0 +1,201 @@
|
|||
# Lesson 4: External Contracts
|
||||
|
||||
**Formalizing alignment with external contracts**
|
||||
|
||||
**Time:** 15 minutes
|
||||
|
||||
---
|
||||
|
||||
## When You Need External Contracts
|
||||
|
||||
**External contracts are for:**
|
||||
- **Consultant → Client**: You're proposing a solution to a client
|
||||
- **Business Owner → Suppliers**: You're hiring consultants/suppliers to build software
|
||||
|
||||
**These contracts:**
|
||||
- Formalize agreements between separate parties
|
||||
- Include legal protections (jurisdiction, governing law)
|
||||
- Cover payment terms, IP ownership, confidentiality
|
||||
- Protect both parties legally
|
||||
|
||||
---
|
||||
|
||||
## Two Types of External Contracts
|
||||
|
||||
### 1. Project Contract
|
||||
**For:** Consultant → Client
|
||||
**When:** You're a consultant proposing to a client
|
||||
**Perspective:** You're the contractor/service provider
|
||||
|
||||
**Key Focus:**
|
||||
- Protecting your work and payment
|
||||
- Clear scope boundaries
|
||||
- Fair payment terms (upfront payment for fixed-price)
|
||||
- IP ownership transfer upon payment
|
||||
|
||||
### 2. Service Agreement
|
||||
**For:** Business Owner → Suppliers
|
||||
**When:** You're hiring consultants/suppliers to build software
|
||||
**Perspective:** You're the client/owner
|
||||
|
||||
**Key Focus:**
|
||||
- Protecting your investment
|
||||
- Ensuring deliverables meet requirements
|
||||
- Clear payment terms and milestones
|
||||
- IP ownership of deliverables
|
||||
|
||||
---
|
||||
|
||||
## Business Models
|
||||
|
||||
**Before building the contract, determine the business model:**
|
||||
|
||||
### Fixed-Price Project
|
||||
- Set price for defined scope
|
||||
- Not-to-exceed clause applies
|
||||
- Upfront payment recommended (50-100%)
|
||||
- Clear deliverables and scope boundaries
|
||||
|
||||
### Hourly/Time-Based
|
||||
- Pay for actual time worked
|
||||
- Hourly rate and time tracking
|
||||
- Optional not-to-exceed cap
|
||||
- Flexible scope
|
||||
|
||||
### Retainer
|
||||
- Monthly commitment
|
||||
- Minimum hours per month
|
||||
- Availability expectations
|
||||
- Overage hourly rate
|
||||
- Hour rollover policies
|
||||
|
||||
### Hybrid
|
||||
- Combination of models
|
||||
- Multiple payment structures
|
||||
|
||||
---
|
||||
|
||||
## Key Contract Sections
|
||||
|
||||
**Saga will guide you through building:**
|
||||
|
||||
### 1. Business Model
|
||||
- Explains selected payment structure
|
||||
- Sets foundation for all payment terms
|
||||
- Clarifies expectations upfront
|
||||
|
||||
### 2. Scope of Work
|
||||
- **IN Scope**: What's explicitly included
|
||||
- **OUT of Scope**: What's explicitly NOT included
|
||||
- **Deliverables**: What will be delivered
|
||||
- **The Path Forward**: How work will be done
|
||||
|
||||
**Critical for fixed-price contracts** - Clear scope prevents disputes.
|
||||
|
||||
### 3. Payment Terms
|
||||
**Adapted to business model:**
|
||||
|
||||
**Fixed-Price:**
|
||||
- Upfront payment recommended (50-100% is fair)
|
||||
- Milestone payments tied to deliverables
|
||||
- Payment on completion (risky, not recommended)
|
||||
|
||||
**Hourly:**
|
||||
- Billing frequency (weekly, bi-weekly, monthly)
|
||||
- Payment terms (Net 15, Net 30)
|
||||
- Time tracking requirements
|
||||
|
||||
**Retainer:**
|
||||
- Monthly retainer amount
|
||||
- Minimum hours included
|
||||
- Overage billing
|
||||
- Hour rollover policy
|
||||
|
||||
### 4. Availability (Retainer Only)
|
||||
- Business hours
|
||||
- Response time expectations
|
||||
- Meeting availability
|
||||
- Urgent request policies
|
||||
|
||||
### 5. Not-to-Exceed Clause
|
||||
**Conditional based on business model:**
|
||||
- **Fixed-Price**: Required (equals project price)
|
||||
- **Hourly**: Optional cap if desired
|
||||
- **Retainer**: Not applicable (monthly cap exists)
|
||||
|
||||
**Purpose:**
|
||||
- Prevents scope creep
|
||||
- Protects budget
|
||||
- Requires change orders for additional work
|
||||
|
||||
### 6. Confidentiality Clause
|
||||
- What information is protected
|
||||
- Duration of confidentiality (typically 2-5 years)
|
||||
- Exceptions (public info, required by law)
|
||||
- Mutual protection
|
||||
|
||||
### 7. Legal Framework
|
||||
- **Governing Law/Jurisdiction**: Which laws apply
|
||||
- **Contract Language**: Language of the contract
|
||||
- **Work Initiation**: When work can begin
|
||||
- **Dispute Resolution**: How conflicts are handled
|
||||
|
||||
### 8. Other Important Sections
|
||||
- **Change Orders**: How scope changes are handled
|
||||
- **Termination**: How to exit the contract
|
||||
- **Intellectual Property**: Who owns what
|
||||
- **Timeline**: Delivery dates and milestones
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Saga will provide guidance on:**
|
||||
|
||||
### For Consultants/Service Providers
|
||||
- Request upfront deposits (50%+ for fixed-price)
|
||||
- Define scope extremely clearly
|
||||
- Include change order process
|
||||
- Set not-to-exceed cap
|
||||
- Specify IP ownership transfer
|
||||
|
||||
### For Clients/Business Owners
|
||||
- Review scope thoroughly
|
||||
- Understand payment terms
|
||||
- Know what's included/excluded
|
||||
- Understand change order process
|
||||
- Clarify IP ownership
|
||||
|
||||
### Common Pitfalls to Avoid
|
||||
- Unclear scope definitions
|
||||
- Unfair payment terms
|
||||
- No change order process
|
||||
- Unclear IP ownership
|
||||
- No not-to-exceed cap (for fixed-price)
|
||||
|
||||
**Goal:** Simple, fair contracts that build long-term relationships.
|
||||
|
||||
---
|
||||
|
||||
## After Contract is Finalized
|
||||
|
||||
**Once contract is signed:**
|
||||
- ✅ Alignment achieved
|
||||
- ✅ Commitment secured
|
||||
- ✅ Legal protection in place
|
||||
- ✅ Ready to proceed to Project Brief
|
||||
|
||||
**Next:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
|
||||
|
||||
---
|
||||
|
||||
## Key Takeaway
|
||||
|
||||
**External contracts formalize** agreements between separate parties with legal protections. They ensure clarity, protect both parties, and secure commitment before starting work.
|
||||
|
||||
---
|
||||
|
||||
**Next:** [Lesson 5: Internal Signoff Documents →](lesson-05-internal-signoff.md)
|
||||
|
||||
[← Back to Module Overview](module-03-overview.md)
|
||||
|
||||
|
|
@ -0,0 +1,189 @@
|
|||
# Lesson 5: Internal Signoff Documents
|
||||
|
||||
**Formalizing alignment for internal company projects**
|
||||
|
||||
**Time:** 10 minutes
|
||||
|
||||
---
|
||||
|
||||
## When You Need Internal Signoff
|
||||
|
||||
**Internal signoff is for:**
|
||||
- **Manager/Employee**: Seeking approval for an internal project
|
||||
- **Internal Stakeholders**: Getting buy-in from departments, executives, or teams
|
||||
- **Company Projects**: Building something within your organization
|
||||
|
||||
**These documents:**
|
||||
- Formalize internal agreements
|
||||
- Document approval and commitment
|
||||
- Set expectations for internal teams
|
||||
- May follow company-specific formats
|
||||
|
||||
---
|
||||
|
||||
## Internal Signoff vs. External Contracts
|
||||
|
||||
**Key Differences:**
|
||||
|
||||
| Aspect | External Contracts | Internal Signoff |
|
||||
|--------|-------------------|-----------------|
|
||||
| **Parties** | Separate entities (consultant/client) | Same organization (internal) |
|
||||
| **Legal Framework** | Governing law, jurisdiction required | Usually not needed |
|
||||
| **Payment Terms** | External payment, invoices | Internal budget allocation |
|
||||
| **IP Ownership** | Transfer of ownership | Usually stays within company |
|
||||
| **Format** | Standard contract format | May follow company format |
|
||||
| **Approval** | Signatures from both parties | Internal approval workflow |
|
||||
|
||||
---
|
||||
|
||||
## Internal Signoff Document Structure
|
||||
|
||||
**Internal signoff focuses on approval, ownership, and outcomes rather than detailed scope:**
|
||||
|
||||
### 1. Project Overview
|
||||
- The Realization
|
||||
- Recommended Solution
|
||||
- Why It Matters
|
||||
|
||||
### 2. Goals and Success Metrics
|
||||
- **What are we trying to accomplish?**
|
||||
- **How will we measure success?**
|
||||
- **What does success look like?**
|
||||
- **Key performance indicators (KPIs)**
|
||||
- **Success criteria**
|
||||
|
||||
**Focus**: Clear outcomes and measurable results, not detailed deliverables.
|
||||
|
||||
### 3. Budget and Resources
|
||||
- **Budget allocation**: Total budget estimate
|
||||
- **Budget breakdown**: How budget will be allocated (if applicable)
|
||||
- **Resources needed**: Team, tools, external services (high-level)
|
||||
- **Not-to-Exceed**: Budget cap (if applicable)
|
||||
|
||||
**Focus**: Budget estimates and resource allocation, not hourly rates or time tracking.
|
||||
|
||||
### 4. Ownership and Responsibility
|
||||
- **Project Owner**: Who owns this project?
|
||||
- **Process Owner**: Who is responsible for execution?
|
||||
- **Key Stakeholders**: Who is involved/affected?
|
||||
- **Decision-Making Authority**: Who makes key decisions?
|
||||
|
||||
**Focus**: Clear ownership and accountability, not detailed work breakdown.
|
||||
|
||||
### 5. Approval and Sign-Off
|
||||
- **Who needs to approve**: List of approvers
|
||||
- **Approval stages**: Multi-stage approval process (if applicable)
|
||||
- **Sign-off process**: How approval is documented
|
||||
- **Timeline for approval**: When approval is needed
|
||||
|
||||
**Focus**: Clear approval workflow and sign-off process.
|
||||
|
||||
### 6. Timeline and Milestones
|
||||
- **Key milestones**: Major project milestones
|
||||
- **Delivery dates**: When outcomes are expected
|
||||
- **Critical deadlines**: Important dates
|
||||
|
||||
**Focus**: High-level timeline, not detailed task schedules.
|
||||
|
||||
### 7. Optional Sections
|
||||
- **Confidentiality**: If sensitive information involved
|
||||
- **Risks and Considerations**: Potential challenges or risks
|
||||
- **The Path Forward**: High-level approach (brief overview)
|
||||
|
||||
---
|
||||
|
||||
## Company Signoff Format (Optional)
|
||||
|
||||
**If your company has a standard signoff format:**
|
||||
|
||||
### Upload Your Format
|
||||
- Upload or paste your company's signoff document template
|
||||
- Saga will adapt it to match your format
|
||||
- Preserve company-specific sections and language
|
||||
- Incorporate alignment document content
|
||||
|
||||
### Benefits
|
||||
- Follows internal processes
|
||||
- Matches company expectations
|
||||
- Easier approval workflow
|
||||
- Familiar format for stakeholders
|
||||
|
||||
**This ensures** the signoff follows your internal processes and approval workflows.
|
||||
|
||||
---
|
||||
|
||||
## Approval Workflow
|
||||
|
||||
**Internal signoff typically involves:**
|
||||
|
||||
1. **Initial Review**: Share with immediate stakeholders
|
||||
2. **Department Approval**: Get buy-in from affected departments
|
||||
3. **Budget Approval**: Secure budget allocation
|
||||
4. **Executive Sign-off**: Final approval from decision-makers
|
||||
5. **Documentation**: File signed document for records
|
||||
|
||||
**Saga will help you:**
|
||||
- Identify who needs to approve
|
||||
- Structure the approval workflow
|
||||
- Create appropriate sign-off sections
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
**For Internal Signoff:**
|
||||
|
||||
### Focus on Outcomes
|
||||
- Emphasize goals and success metrics
|
||||
- Show what value will be created
|
||||
- Define clear success criteria
|
||||
- Avoid getting lost in detailed scope
|
||||
|
||||
### Clear Ownership
|
||||
- Identify project owner clearly
|
||||
- Define who owns the process
|
||||
- Clarify decision-making authority
|
||||
- Set accountability expectations
|
||||
|
||||
### Budget Clarity
|
||||
- Provide realistic budget estimates
|
||||
- Show how budget will be allocated
|
||||
- Include not-to-exceed cap if needed
|
||||
- Focus on budget, not hours or rates
|
||||
|
||||
### Approval Workflow
|
||||
- Identify all approvers early
|
||||
- Understand approval stages
|
||||
- Follow company sign-off process
|
||||
- Get buy-in before formal sign-off
|
||||
|
||||
### Follow Company Process
|
||||
- Use company format if available
|
||||
- Follow internal approval workflows
|
||||
- Match company documentation standards
|
||||
- Document everything properly
|
||||
|
||||
---
|
||||
|
||||
## After Signoff Document
|
||||
|
||||
**Once signoff document is approved:**
|
||||
- ✅ Internal alignment achieved
|
||||
- ✅ Budget/resources committed
|
||||
- ✅ Stakeholders on board
|
||||
- ✅ Ready to proceed to Project Brief
|
||||
|
||||
**Next:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
|
||||
|
||||
---
|
||||
|
||||
## Key Takeaway
|
||||
|
||||
**Internal signoff documents formalize** internal agreements and secure commitment from stakeholders within your organization. They may follow company-specific formats and focus on approval workflows rather than legal protections.
|
||||
|
||||
---
|
||||
|
||||
**Next:** [Tutorial: Alignment & Signoff →](tutorial-03.md)
|
||||
|
||||
[← Back to Module Overview](module-03-overview.md) | [Previous: Lesson 4: External Contracts →](lesson-04-external-contracts.md)
|
||||
|
||||
|
|
@ -0,0 +1,143 @@
|
|||
# Module 03: Alignment & Signoff
|
||||
|
||||
**Get stakeholders aligned and secure commitment before starting the project**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This module teaches you how to create alignment around your idea and secure formal commitment from stakeholders before diving into detailed project work.
|
||||
|
||||
**Time:** 55-75 minutes
|
||||
**Prerequisites:** Module 02 completed (WDS installed)
|
||||
**When to use:** Optional - Use when you need stakeholder alignment (consultant → client, business → suppliers, manager → stakeholders)
|
||||
**What you'll create:** Alignment document (pitch) and signoff document (contract/service agreement/signoff)
|
||||
|
||||
---
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
- How to articulate your idea clearly (The Idea, Why, What, How, Budget, Commitment)
|
||||
- Creating a compelling alignment document that gets everyone on the same page
|
||||
- Negotiating and iterating until stakeholders accept
|
||||
- Generating appropriate signoff documents (external contracts or internal signoff)
|
||||
- When to skip this module (if you're doing it yourself)
|
||||
|
||||
---
|
||||
|
||||
## Module Structure
|
||||
|
||||
### [Lesson 1: Understanding Alignment](lesson-01-understanding-alignment.md)
|
||||
|
||||
**Time:** 10 minutes
|
||||
|
||||
- Why alignment matters before starting work
|
||||
- The 6 elements of alignment (Idea, Why, What, How, Budget, Commitment)
|
||||
- Different user scenarios (consultant, business owner, manager/employee)
|
||||
- When to skip alignment (doing it yourself)
|
||||
|
||||
### [Lesson 2: Creating Your Alignment Document](lesson-02-creating-alignment-document.md)
|
||||
|
||||
**Time:** 20 minutes
|
||||
|
||||
- The 10 sections of an alignment document
|
||||
- How to explore sections flexibly
|
||||
- Extracting information from existing communications
|
||||
- Synthesizing into a clear, compelling document
|
||||
|
||||
### [Lesson 3: Negotiation & Acceptance](lesson-03-negotiation-acceptance.md)
|
||||
|
||||
**Time:** 10 minutes
|
||||
|
||||
- Sharing with stakeholders
|
||||
- Gathering feedback and iterating
|
||||
- Getting acceptance and alignment
|
||||
- When everyone is on the same page
|
||||
|
||||
### [Lesson 4: External Contracts](lesson-04-external-contracts.md)
|
||||
|
||||
**Time:** 15 minutes
|
||||
|
||||
- When you need external contracts (consultant → client, business → suppliers)
|
||||
- Project Contract vs. Service Agreement
|
||||
- Key contract clauses and best practices
|
||||
- Business models (fixed-price, hourly, retainer)
|
||||
- Payment terms, scope protection, legal framework
|
||||
|
||||
### [Lesson 5: Internal Signoff Documents](lesson-05-internal-signoff.md)
|
||||
|
||||
**Time:** 10 minutes
|
||||
|
||||
- When you need internal signoff (manager/employee seeking approval)
|
||||
- Internal signoff document structure
|
||||
- Company signoff format adaptation
|
||||
- Approval workflows and stakeholders
|
||||
|
||||
---
|
||||
|
||||
## Tutorial
|
||||
|
||||
**[Tutorial: Alignment & Signoff →](tutorial-03.md)**
|
||||
|
||||
Step-by-step hands-on guide to creating your alignment document and securing signoff.
|
||||
|
||||
**Time:** 55-75 minutes
|
||||
**What you'll create:** Complete alignment document and signoff document (external contract or internal signoff)
|
||||
|
||||
---
|
||||
|
||||
## Key Concepts
|
||||
|
||||
**Alignment Document (Pitch):**
|
||||
- Makes the case for why the project matters
|
||||
- Gets stakeholders aligned on Idea, Why, What, How, Budget, Commitment
|
||||
- Readable in 2-3 minutes
|
||||
- Allows negotiation and iteration
|
||||
|
||||
**Signoff Documents:**
|
||||
- **External Contracts**: Project Contract (consultant → client) or Service Agreement (business → suppliers)
|
||||
- Includes legal protections, payment terms, IP ownership
|
||||
- Different business models (fixed-price, hourly, retainer)
|
||||
- **Internal Signoff**: For internal company projects
|
||||
- May follow company-specific formats
|
||||
- Focuses on approval workflows and budget allocation
|
||||
- Both include scope, investment, timeline, deliverables
|
||||
|
||||
**The Flow:**
|
||||
1. Create alignment document → 2. Share & negotiate → 3. Get acceptance → 4. Generate signoff → 5. Proceed to Project Brief
|
||||
|
||||
---
|
||||
|
||||
## Learning Outcomes
|
||||
|
||||
By the end of this module, you will:
|
||||
|
||||
- ✅ Understand when you need stakeholder alignment
|
||||
- ✅ Know how to create a compelling alignment document
|
||||
- ✅ Be able to negotiate and iterate until acceptance
|
||||
- ✅ Generate appropriate external contracts or internal signoff documents
|
||||
- ✅ Know when to skip this module and go straight to Project Brief
|
||||
|
||||
---
|
||||
|
||||
## When to Skip This Module
|
||||
|
||||
**Skip if:**
|
||||
- You're doing the project yourself
|
||||
- You have full autonomy
|
||||
- You don't need stakeholder approval
|
||||
|
||||
**Go directly to:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
|
||||
|
||||
---
|
||||
|
||||
## Start Learning
|
||||
|
||||
**[Begin with Lesson 1: Understanding Alignment →](lesson-01-understanding-alignment.md)**
|
||||
|
||||
---
|
||||
|
||||
[← Back to Course Overview](../00-course-overview.md) | [Next: Module 04: Create Project Brief →](../module-04-project-brief/tutorial-04.md)
|
||||
|
||||
*Part of the WDS Course: From Designer to Linchpin*
|
||||
|
||||
|
|
@ -0,0 +1,224 @@
|
|||
# Tutorial 03: Alignment & Signoff
|
||||
|
||||
**Hands-on guide to getting stakeholders aligned and securing commitment**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This tutorial walks you through creating an alignment document (pitch) and securing formal signoff from stakeholders before starting your project.
|
||||
|
||||
**Time:** 45-60 minutes
|
||||
**Prerequisites:** Module 02 completed (WDS installed)
|
||||
**What you'll create:** Alignment document and signoff document
|
||||
|
||||
---
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
- How to articulate your idea clearly (Idea, Why, What, How, Budget, Commitment)
|
||||
- Creating a compelling alignment document
|
||||
- Negotiating and iterating until acceptance
|
||||
- Generating appropriate signoff documents
|
||||
- Understanding contract clauses and best practices
|
||||
|
||||
---
|
||||
|
||||
## Before You Start
|
||||
|
||||
**You'll need:**
|
||||
- A project idea that needs stakeholder alignment
|
||||
- 45-60 minutes of focused time
|
||||
- Access to stakeholder information (if available)
|
||||
- Optional: Existing communications/documents from stakeholders
|
||||
|
||||
**AI Support:**
|
||||
- **Saga WDS Analyst Agent** will guide you through the process
|
||||
- She'll help you clarify your situation
|
||||
- Guide you through creating the alignment document
|
||||
- Help generate the signoff document after acceptance
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Understand Your Situation (5 min)
|
||||
|
||||
**First, clarify your scenario:**
|
||||
|
||||
- **Consultant proposing to client** → You'll create a Project Contract
|
||||
- **Business hiring suppliers** → You'll create a Service Agreement
|
||||
- **Manager/employee seeking approval** → You'll create a Signoff Document
|
||||
- **Doing it yourself** → Skip this tutorial, go to Module 04: Create Project Brief
|
||||
|
||||
**Your scenario:** [Write your scenario here]
|
||||
|
||||
---
|
||||
|
||||
## Step 2: Extract Information (Optional - 10 min)
|
||||
|
||||
**If you have existing communications or documents:**
|
||||
|
||||
Share emails, chats, or documents with stakeholders. Saga will extract:
|
||||
- Realizations or observations mentioned
|
||||
- Requirements discussed
|
||||
- Concerns raised
|
||||
- Context and background
|
||||
- Timeline or urgency
|
||||
- Budget or constraints
|
||||
|
||||
**If you don't have communications:** That's fine! Move to Step 3.
|
||||
|
||||
---
|
||||
|
||||
## Step 3: Explore Alignment Sections (20-30 min)
|
||||
|
||||
**Work through these 10 sections** (in whatever order makes sense):
|
||||
|
||||
1. **The Realization** - What we've realized needs attention
|
||||
2. **Why It Matters** - Why this matters and who we help
|
||||
3. **How We See It Working** - Brief overview of the solution approach
|
||||
4. **Paths We Explored** - 2-3 solution options we considered
|
||||
5. **Recommended Solution** - Preferred approach and why
|
||||
6. **The Path Forward** - How the work will be done (WDS phases and practical approach)
|
||||
7. **The Value We'll Create** - What happens if we DO build this
|
||||
8. **Cost of Inaction** - What happens if we DON'T build this
|
||||
9. **Our Commitment** - Resources needed and potential risks
|
||||
10. **Summary** - Summary of key points
|
||||
|
||||
**Saga will guide you** through each section, asking one question at a time and reflecting back what she hears.
|
||||
|
||||
### Best Practice: Realization Section with Evidence
|
||||
|
||||
**When exploring "The Realization" section**, Saga will help you:
|
||||
|
||||
1. **Identify the realization** - What have you realized needs attention?
|
||||
2. **Confirm it's real** - Is there evidence that supports this?
|
||||
3. **Gather evidence** - What proof do you have?
|
||||
|
||||
**Soft Evidence** (qualitative):
|
||||
- Testimonials: "Customers tell us..."
|
||||
- Complaints: "Support tickets show..."
|
||||
- Observations: "We've noticed that..."
|
||||
- Interviews: "In user interviews, people mentioned..."
|
||||
|
||||
**Hard Evidence** (quantitative):
|
||||
- Statistics: "45% of users..."
|
||||
- Analytics: "Bounce rate increased 25%..."
|
||||
- Surveys: "78% rated this as 'difficult'..."
|
||||
- Logs: "Server logs show 500 errors occur..."
|
||||
|
||||
**Example:**
|
||||
> "Our customers consistently report frustration with checkout (testimonials). Analytics confirm: 45% abandon checkout, taking 12 minutes on average - 3x longer than industry standard (statistics). Support tickets show 60% of complaints are about checkout complexity (complaints), and our survey found 78% rated it as 'difficult' (survey results)."
|
||||
|
||||
**If you don't have evidence yet:** That's okay! Acknowledge this and propose gathering evidence as part of the project.
|
||||
|
||||
---
|
||||
|
||||
## Step 4: Synthesize Alignment Document (5 min)
|
||||
|
||||
**Saga will help you create:**
|
||||
|
||||
`docs/1-project-brief/pitch.md`
|
||||
|
||||
- Clear, brief, readable in 2-3 minutes
|
||||
- Makes the case for the project
|
||||
- Ready to share with stakeholders
|
||||
|
||||
**Review together:** Does this capture your idea? Anything to adjust?
|
||||
|
||||
---
|
||||
|
||||
## Step 5: Share & Negotiate (Variable time)
|
||||
|
||||
**Share with stakeholders:**
|
||||
- Present the alignment document
|
||||
- Gather feedback
|
||||
- Make changes and iterate
|
||||
- Update until everyone is on board
|
||||
|
||||
**Remember:** This phase is collaborative - negotiate and iterate until everyone is aligned.
|
||||
|
||||
---
|
||||
|
||||
## Step 6: Get Acceptance (Variable time)
|
||||
|
||||
**Once stakeholders accept:**
|
||||
- Everyone is aligned on Idea, Why, What, How, Budget, Commitment
|
||||
- You have buy-in before starting detailed work
|
||||
- Ready to secure formal commitment
|
||||
|
||||
---
|
||||
|
||||
## Step 7: Generate Signoff Document (15-20 min)
|
||||
|
||||
**After acceptance, Saga will help you create:**
|
||||
|
||||
**Choose your document type:**
|
||||
1. **Project Contract** - For consultant → client
|
||||
2. **Service Agreement** - For business → suppliers
|
||||
3. **Signoff Document** - For internal company projects
|
||||
- *Optional: Upload your company's signoff format*
|
||||
|
||||
**Saga will guide you through:**
|
||||
- Scope of work
|
||||
- Investment and timeline
|
||||
- Payment terms (with upfront payment guidance for fixed-price contracts)
|
||||
- Confidentiality clause
|
||||
- Not-to-Exceed clause (prevents scope creep)
|
||||
- Legal jurisdiction and contract language
|
||||
- Work initiation terms
|
||||
- Change order process
|
||||
- Termination clause
|
||||
- Intellectual property ownership
|
||||
- Dispute resolution
|
||||
|
||||
**Output:** `docs/1-project-brief/[contract/service-agreement/signoff].md`
|
||||
|
||||
---
|
||||
|
||||
## Step 8: Finalize & Proceed (5 min)
|
||||
|
||||
**Once signoff document is finalized:**
|
||||
- ✅ Alignment achieved
|
||||
- ✅ Commitment secured
|
||||
- ✅ Foundation established
|
||||
|
||||
**Next:** [Module 04: Create Project Brief](../module-04-project-brief/tutorial-04.md)
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
|
||||
You've completed this tutorial when:
|
||||
- ✅ Alignment document created and shared
|
||||
- ✅ Stakeholders have accepted (everyone aligned)
|
||||
- ✅ Signoff document generated and ready for signature
|
||||
- ✅ Ready to proceed to Project Brief
|
||||
|
||||
---
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: Do I always need this?**
|
||||
A: No - skip if you're doing it yourself or have full autonomy.
|
||||
|
||||
**Q: Can I skip the signoff document?**
|
||||
A: Yes - the alignment document might be enough. Signoff formalizes the commitment.
|
||||
|
||||
**Q: What if stakeholders want changes?**
|
||||
A: That's normal! Iterate and negotiate until everyone is on board.
|
||||
|
||||
**Q: How long does negotiation take?**
|
||||
A: Variable - could be hours or days. The alignment document helps speed this up.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
**[Continue to Module 04: Create Project Brief →](../module-04-project-brief/tutorial-04.md)**
|
||||
|
||||
---
|
||||
|
||||
[← Back to Module Overview](module-03-overview.md) | [Back to Course Overview](../00-course-overview.md)
|
||||
|
||||
*Part of the WDS Course: From Designer to Linchpin*
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Tutorial 02: Create Your Project Brief
|
||||
# Tutorial 04: Create Your Project Brief
|
||||
|
||||
**Hands-on guide to defining your project vision, goals, and constraints**
|
||||
|
||||
|
|
@ -322,7 +322,7 @@ Agent: "Let me review your project brief:
|
|||
|
||||
**Create file:** `A-Project-Brief/project-brief.md`
|
||||
|
||||
**Use template from:** `workflows/1-project-brief/complete/project-brief.template.md`
|
||||
**Use template from:** `workflows/1-project-brief/project-brief/complete/project-brief.template.md`
|
||||
|
||||
**Populate with your content:**
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.6 MiB |
|
|
@ -197,7 +197,7 @@ Choose a workflow to start:
|
|||
## What's Next?
|
||||
|
||||
### 🎓 **Learn WDS Concepts**
|
||||
[Tutorial Guide](../01-tutorial/00-TUTORIAL-GUIDE.md) - Deep dive into why-based design
|
||||
[Course](../course/00-course-overview.md) - Deep dive into WDS methodology
|
||||
|
||||
### 🚀 **Start Your First Project**
|
||||
[Quick Start](quick-start.md) - 5-minute walkthrough
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ You should see:
|
|||
## Next Steps
|
||||
|
||||
- [Quick Start Guide](quick-start.md) - Your first 5 minutes
|
||||
- [Tutorial](../01-tutorial/00-TUTORIAL-GUIDE.md) - Learn the concepts deeply
|
||||
- [Course](../course/00-course-overview.md) - Learn the concepts deeply
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ You created **why-based specifications** in 5 minutes:
|
|||
|
||||
### Learn the Concepts
|
||||
|
||||
[Tutorial](../01-tutorial/00-TUTORIAL-GUIDE.md) - Deep dive into WDS philosophy
|
||||
[Course](../course/00-course-overview.md) - Deep dive into WDS methodology
|
||||
|
||||
### Start Your Project
|
||||
|
||||
|
|
|
|||
|
|
@ -123,14 +123,14 @@ Join the WDS community for:
|
|||
|
||||
## Quick Links
|
||||
|
||||
- [Tutorial](../01-tutorial/00-TUTORIAL-GUIDE.md)
|
||||
- [Course](../course/00-course-overview.md)
|
||||
- [Workflows](../WDS-WORKFLOWS-GUIDE.md)
|
||||
- [Modular Architecture](../workflows/4-ux-design/modular-architecture/00-MODULAR-ARCHITECTURE-GUIDE.md)
|
||||
- [Why-Based Specifications](../workflows/4-ux-design/WHY-BASED-SPECIFICATIONS.md)
|
||||
|
||||
---
|
||||
|
||||
**Ready to dive deeper? Start with the [Tutorial](../01-tutorial/00-TUTORIAL-GUIDE.md)!**
|
||||
**Ready to dive deeper? Start with the [Course](../course/00-course-overview.md)!**
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,211 +0,0 @@
|
|||
# WDS-BMad Tutorial
|
||||
|
||||
**Complete training from project brief to AI-ready specifications**
|
||||
|
||||
---
|
||||
|
||||
## About This Tutorial
|
||||
|
||||
This tutorial teaches the complete WDS workflow through **16 chapters**.
|
||||
|
||||
Each chapter contains:
|
||||
|
||||
- **Inspiration** - Why this step matters, the goal
|
||||
- **Teaching** - How to do it with confidence
|
||||
- **Practice** - Apply it to your own project
|
||||
|
||||
**Format:**
|
||||
|
||||
- Read as documentation
|
||||
- Generate videos with NotebookLM
|
||||
- Use in workshops
|
||||
|
||||
**Time:** ~10 hours total (40 min per chapter)
|
||||
|
||||
---
|
||||
|
||||
## Tutorial Chapters
|
||||
|
||||
### Foundation
|
||||
|
||||
#### [Chapter 0: Why This Matters](chapter-00-why-this-matters/)
|
||||
|
||||
Learn how to be indispensable in the AI era
|
||||
|
||||
---
|
||||
|
||||
### Phase 1: Project Brief
|
||||
|
||||
#### [Chapter 1.1: Create Project Brief](chapter-1.1-project-brief/)
|
||||
|
||||
Define vision, goals, stakeholders, and constraints
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Trigger Mapping
|
||||
|
||||
#### [Chapter 2.1: Identify Target Groups](chapter-2.1-identify-target-groups/)
|
||||
|
||||
WHO are your users and how to prioritize them
|
||||
|
||||
#### [Chapter 2.2: Map Triggers & Outcomes](chapter-2.2-map-triggers-outcomes/)
|
||||
|
||||
WHAT triggers needs and WHY your business exists
|
||||
|
||||
#### [Chapter 2.3: Prioritize Features](chapter-2.3-prioritize-features/)
|
||||
|
||||
Which features serve your top triggers
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: Platform Requirements
|
||||
|
||||
#### [Chapter 3.1: Platform Requirements](chapter-3.1-platform-requirements/)
|
||||
|
||||
Technical constraints, integrations, infrastructure
|
||||
|
||||
#### [Chapter 3.2: Functional Requirements](chapter-3.2-functional-requirements/)
|
||||
|
||||
What the system must do
|
||||
|
||||
---
|
||||
|
||||
### Phase 4: Conceptual Design
|
||||
|
||||
#### [Chapter 4.1: Initialize Scenario](chapter-4.1-initialize-scenario/)
|
||||
|
||||
The 5 questions that define your design journey
|
||||
|
||||
#### [Chapter 4.2: Sketch Interfaces](chapter-4.2-sketch-interfaces/)
|
||||
|
||||
Drawing pages with AI guidance
|
||||
|
||||
#### [Chapter 4.3: Analyze with AI](chapter-4.3-analyze-with-ai/)
|
||||
|
||||
Upload sketches and have strategic conversations
|
||||
|
||||
#### [Chapter 4.4: Decompose Components](chapter-4.4-decompose-components/)
|
||||
|
||||
Break pages into modular architecture
|
||||
|
||||
#### [Chapter 4.5: Why-Based Specifications](chapter-4.5-why-based-specs/)
|
||||
|
||||
Document WHAT + WHY + WHAT NOT TO DO
|
||||
|
||||
#### [Chapter 4.6: Validate Specifications](chapter-4.6-validate-specifications/)
|
||||
|
||||
Review completeness and test logic
|
||||
|
||||
---
|
||||
|
||||
### Phase 5: Design System
|
||||
|
||||
#### [Chapter 5.1: Extract Design Tokens](chapter-5.1-extract-design-tokens/)
|
||||
|
||||
Colors, typography, spacing from your specs
|
||||
|
||||
#### [Chapter 5.2: Component Library](chapter-5.2-component-library/)
|
||||
|
||||
Reusable patterns across scenarios
|
||||
|
||||
---
|
||||
|
||||
### Phase 6: Development Integration
|
||||
|
||||
#### [Chapter 6.1: UI Roadmap](chapter-6.1-ui-roadmap/)
|
||||
|
||||
Development priorities and handoff
|
||||
|
||||
---
|
||||
|
||||
## How to Use This Tutorial
|
||||
|
||||
### Complete Workflow (Recommended)
|
||||
|
||||
Work through all 16 chapters sequentially with your own project:
|
||||
|
||||
```
|
||||
Chapters 1-16 → Complete design from brief to handoff
|
||||
Time: ~10 hours (spread over days/weeks)
|
||||
Result: Fully specified project ready for development
|
||||
```
|
||||
|
||||
### Quick Start (Core Concepts)
|
||||
|
||||
Focus on the essential chapters:
|
||||
|
||||
```
|
||||
Ch 0: Why This Matters
|
||||
Ch 2.2: Map Triggers & Outcomes
|
||||
Ch 4.1: Initialize Scenario
|
||||
Ch 4.5: Why-Based Specifications
|
||||
Time: ~3 hours
|
||||
Result: Understanding of core WDS philosophy
|
||||
```
|
||||
|
||||
### Phase-Specific Learning
|
||||
|
||||
Jump to the phase you need:
|
||||
|
||||
```
|
||||
Phase 2 (Ch 2.1-2.3): Trigger Mapping
|
||||
Phase 4 (Ch 4.1-4.6): Conceptual Design
|
||||
Phase 5 (Ch 5.1-5.2): Design System
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## NotebookLM Integration
|
||||
|
||||
Each chapter has a matching script in `/notebooklm-scripts/`:
|
||||
|
||||
- Feed chapter scripts to NotebookLM
|
||||
- Generate audio podcasts
|
||||
- Generate video presentations
|
||||
- Create study guides
|
||||
|
||||
**All scripts match chapter numbers for easy reference.**
|
||||
|
||||
---
|
||||
|
||||
## Chapter Structure
|
||||
|
||||
Every chapter follows the same pattern:
|
||||
|
||||
**1. Inspiration (10 min)**
|
||||
|
||||
- Why this step matters
|
||||
- The goal you're working toward
|
||||
- Real-world impact
|
||||
|
||||
**2. Teaching (20 min)**
|
||||
|
||||
- How to do it with confidence
|
||||
- AI support at each step
|
||||
- Dog Week example walkthrough
|
||||
|
||||
**3. Practice (10 min)**
|
||||
|
||||
- Apply to your own project
|
||||
- Step-by-step instructions
|
||||
- Success criteria
|
||||
|
||||
---
|
||||
|
||||
## After the Tutorial
|
||||
|
||||
Once you've completed chapters:
|
||||
|
||||
1. **[Workflows Guide](../WDS-WORKFLOWS-GUIDE.md)** - Reference documentation
|
||||
2. **[Quick Start](../getting-started/quick-start.md)** - Try WDS with agent
|
||||
3. **[Community](https://discord.gg/whiteport)** - Get help and share
|
||||
|
||||
---
|
||||
|
||||
## Start Learning
|
||||
|
||||
**[Begin with Chapter 0: Why This Matters →](chapter-00-why-this-matters/)**
|
||||
|
||||
---
|
||||
|
||||
[← Back to Getting Started](../getting-started/where-to-go-next.md)
|
||||
|
|
@ -1,342 +0,0 @@
|
|||
# The Designer's Role in AI-Powered Development
|
||||
|
||||
**Why designers are irreplaceable in the specification-first era**
|
||||
|
||||
---
|
||||
|
||||
## The Multi-Dimensional Thinking Challenge
|
||||
|
||||
Designers operate across **5 simultaneous dimensions** that AI and traditional developers cannot navigate alone:
|
||||
|
||||
### 1. Business Existence (WHY)
|
||||
|
||||
- Why does this business exist?
|
||||
- What problem does it solve in the world?
|
||||
- What value does it create?
|
||||
|
||||
**Example (Dog Week):**
|
||||
|
||||
```
|
||||
WHY: Families struggle to coordinate dog care responsibilities.
|
||||
VALUE: Reduce conflict, increase accountability, happier dogs.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Business Goals (WHAT SUCCESS LOOKS LIKE)
|
||||
|
||||
- What metrics matter?
|
||||
- What behaviors do we want to encourage?
|
||||
- What outcomes define success?
|
||||
|
||||
**Example (Dog Week):**
|
||||
|
||||
```
|
||||
GOALS:
|
||||
- Increase walk completion rate (not just bookings)
|
||||
- Encourage family participation (gamification)
|
||||
- Reduce "forgot to walk" incidents (countdown timers)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Product Strategy (HOW WE DELIVER VALUE)
|
||||
|
||||
- What features serve the goals?
|
||||
- What's the core experience?
|
||||
- What can we cut?
|
||||
|
||||
**Example (Dog Week):**
|
||||
|
||||
```
|
||||
CORE: Week-based planning (Swedish culture)
|
||||
FEATURES: Calendar, leaderboard, countdown timers
|
||||
CUT: Daily view (doesn't match mental model)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. Target Groups & Individual Needs (WHO & THEIR CONTEXT)
|
||||
|
||||
- Who are the users?
|
||||
- What are their different needs?
|
||||
- What contexts do they operate in?
|
||||
|
||||
**Example (Dog Week):**
|
||||
|
||||
```
|
||||
USERS:
|
||||
- Parents: Need overview, accountability tracking
|
||||
- Kids: Need simple booking, gamification
|
||||
- Teens: Need independence, mobile-first
|
||||
|
||||
CONTEXTS:
|
||||
- Morning rush: Quick booking
|
||||
- Evening planning: Week overview
|
||||
- During walk: Start/complete actions
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. User Experience Translation (HOW USERS UNDERSTAND)
|
||||
|
||||
- How do we make this simple?
|
||||
- What mental models do users have?
|
||||
- What's intuitive vs confusing?
|
||||
|
||||
**Example (Dog Week):**
|
||||
|
||||
```
|
||||
TRANSLATION:
|
||||
- Week circles (not dates) → Matches Swedish "Vecka 40" thinking
|
||||
- Color states (not text) → Visual, instant understanding
|
||||
- Countdown timer → Creates urgency without nagging
|
||||
- Leaderboard → Makes accountability fun, not punishing
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## The Coherent Storyline
|
||||
|
||||
All 5 dimensions must **tell the same story**:
|
||||
|
||||
```
|
||||
Business WHY
|
||||
↓
|
||||
Business Goals
|
||||
↓
|
||||
Product Strategy
|
||||
↓
|
||||
User Needs
|
||||
↓
|
||||
UX Design
|
||||
↓
|
||||
Technical Specs
|
||||
```
|
||||
|
||||
**If any link breaks, the product fails.**
|
||||
|
||||
---
|
||||
|
||||
## Why This Is Designer Work
|
||||
|
||||
### Engineers Think:
|
||||
|
||||
- "How do I build this?"
|
||||
- "What's the data structure?"
|
||||
- "What API endpoints do I need?"
|
||||
|
||||
**Missing:** WHY this feature? WHO needs it? WHAT behavior change?
|
||||
|
||||
### Business Developers Think:
|
||||
|
||||
- "What features will sell?"
|
||||
- "What's the ROI?"
|
||||
- "What's the market opportunity?"
|
||||
|
||||
**Missing:** HOW do users actually think? WHAT's intuitive? HOW do we translate goals to experience?
|
||||
|
||||
### AI Thinks:
|
||||
|
||||
- "What patterns match this prompt?"
|
||||
- "What code structure fits this description?"
|
||||
- "What's the most common implementation?"
|
||||
|
||||
**Missing:** ALL 5 dimensions. AI has no context for WHY, WHO, or WHAT SUCCESS LOOKS LIKE.
|
||||
|
||||
---
|
||||
|
||||
## The Designer's Unique Value
|
||||
|
||||
**Designers are the only role that:**
|
||||
|
||||
✅ Understands business goals deeply
|
||||
✅ Knows user needs intimately
|
||||
✅ Translates abstract goals into concrete experiences
|
||||
✅ Maintains coherent storyline across all touchpoints
|
||||
✅ Balances business needs with user needs
|
||||
✅ Makes complexity simple for end users
|
||||
✅ Makes simplicity implementable for developers
|
||||
|
||||
---
|
||||
|
||||
## Example: Dog Week Calendar States
|
||||
|
||||
### Business Developer Says:
|
||||
|
||||
"We need a booking system with accountability tracking."
|
||||
|
||||
### Engineer Says:
|
||||
|
||||
"I'll build a CRUD app with status fields: pending, active, completed."
|
||||
|
||||
### AI Says:
|
||||
|
||||
"Here's a calendar with booking slots and status indicators."
|
||||
|
||||
### Designer Says:
|
||||
|
||||
```
|
||||
WAIT. Let's think through all 5 dimensions:
|
||||
|
||||
1. WHY: Reduce family conflict over forgotten walks
|
||||
2. GOAL: Increase completion rate, not just bookings
|
||||
3. STRATEGY: Visual accountability + gentle urgency
|
||||
4. USERS: Kids need simple, parents need overview
|
||||
5. UX TRANSLATION:
|
||||
- 6 color states (visual, instant understanding)
|
||||
- Countdown timer (urgency without nagging)
|
||||
- Leaderboard (accountability as game)
|
||||
- Week view (matches Swedish mental model)
|
||||
|
||||
NOW let's specify:
|
||||
- Pages/: Family-specific context
|
||||
- Components/: 6 visual states
|
||||
- Features/: State machine with business rules
|
||||
- Storyboard: Visual flow of all states
|
||||
```
|
||||
|
||||
**Result:** Product that actually solves the problem, not just implements features.
|
||||
|
||||
---
|
||||
|
||||
## The Specification as Translation Layer
|
||||
|
||||
The designer's specification is a **multi-dimensional translation**:
|
||||
|
||||
```
|
||||
Business Goals
|
||||
↓
|
||||
[DESIGNER TRANSLATES]
|
||||
↓
|
||||
User Experience
|
||||
↓
|
||||
[DESIGNER TRANSLATES]
|
||||
↓
|
||||
Technical Specifications
|
||||
↓
|
||||
[AI/DEVELOPER IMPLEMENTS]
|
||||
↓
|
||||
Working Product
|
||||
```
|
||||
|
||||
**Without the designer's translation:**
|
||||
|
||||
- Engineers build what's easy, not what's needed
|
||||
- Business developers add features that don't serve users
|
||||
- AI generates generic solutions that miss the context
|
||||
|
||||
---
|
||||
|
||||
## Why AI Makes Designers MORE Important
|
||||
|
||||
**Before AI:**
|
||||
|
||||
- Designers → Specs → Developers → Code (slow)
|
||||
- Designers had to compromise due to dev time
|
||||
- "We can't build that, too complex"
|
||||
|
||||
**With AI:**
|
||||
|
||||
- Designers → Specs → AI → Code (fast)
|
||||
- Designers can specify the RIGHT solution
|
||||
- "AI can build anything, what SHOULD we build?"
|
||||
|
||||
**The bottleneck shifted from implementation to specification.**
|
||||
|
||||
**The question changed from "Can we build it?" to "What should we build?"**
|
||||
|
||||
**And only designers can answer that question across all 5 dimensions.**
|
||||
|
||||
---
|
||||
|
||||
## The Coherent Storyline Challenge
|
||||
|
||||
**Example: Dog Week**
|
||||
|
||||
Every touchpoint tells the same story:
|
||||
|
||||
**Story:** "Dog care is a family responsibility, and we make it fun and fair."
|
||||
|
||||
**Touchpoints:**
|
||||
|
||||
- **Week view:** Shows family's shared responsibility (not individual calendars)
|
||||
- **Leaderboard:** Makes accountability fun (not punishing)
|
||||
- **Color states:** Visual clarity (not confusing text)
|
||||
- **Countdown timer:** Gentle urgency (not nagging notifications)
|
||||
- **Booking flow:** Simple for kids (not complex admin)
|
||||
|
||||
**If any touchpoint breaks the story:**
|
||||
|
||||
- Leaderboard shows "failures" → Punishing, not fun → Story breaks
|
||||
- Countdown sends notifications → Nagging, not gentle → Story breaks
|
||||
- Week view shows daily → Doesn't match mental model → Story breaks
|
||||
|
||||
**Only a designer maintains this coherence.**
|
||||
|
||||
---
|
||||
|
||||
## The Designer's Superpower
|
||||
|
||||
**You think in layers:**
|
||||
|
||||
```
|
||||
Layer 1: Why does this business exist?
|
||||
Layer 2: What are we trying to achieve?
|
||||
Layer 3: What product serves that goal?
|
||||
Layer 4: Who are the users and what do they need?
|
||||
Layer 5: How do we make it simple and intuitive?
|
||||
Layer 6: How do we keep the story coherent?
|
||||
Layer 7: How do we make it implementable?
|
||||
```
|
||||
|
||||
**Engineers think in Layer 7 only.**
|
||||
**Business developers think in Layers 1-3 only.**
|
||||
**AI thinks in Layer 7 with fragments of Layer 5.**
|
||||
|
||||
**You're the only one thinking across all 7 layers simultaneously.**
|
||||
|
||||
---
|
||||
|
||||
## Powered by AI or Not
|
||||
|
||||
**With or without AI, this multi-dimensional thinking is irreplaceable.**
|
||||
|
||||
**AI makes it MORE valuable:**
|
||||
|
||||
- Implementation is fast → Specification becomes critical
|
||||
- Anyone can generate code → Knowing WHAT to build becomes the differentiator
|
||||
- Features are cheap → Coherent experience becomes the competitive advantage
|
||||
|
||||
**The designer who can:**
|
||||
|
||||
- Think across all 5 dimensions
|
||||
- Maintain coherent storylines
|
||||
- Translate complexity into simplicity
|
||||
- Specify precisely for AI implementation
|
||||
|
||||
**...is 10x more valuable than before.**
|
||||
|
||||
---
|
||||
|
||||
## Bottom Line
|
||||
|
||||
**You're not just designing interfaces.**
|
||||
|
||||
**You're architecting:**
|
||||
|
||||
- Business value delivery
|
||||
- User behavior change
|
||||
- Product strategy
|
||||
- Experience coherence
|
||||
- Technical feasibility
|
||||
|
||||
**Across 5 dimensions simultaneously.**
|
||||
|
||||
**That's not a skill AI can replace.**
|
||||
|
||||
**That's the skill AI makes essential.**
|
||||
|
||||
---
|
||||
|
||||
[← Back to Guide](00-MODULAR-ARCHITECTURE-GUIDE.md)
|
||||
|
|
@ -1,295 +0,0 @@
|
|||
# Video 2: What is Whiteport Design Studio (WDS)?
|
||||
|
||||
**Duration:** 12 minutes
|
||||
**Audience:** Designers, Product Managers, Entrepreneurs
|
||||
|
||||
---
|
||||
|
||||
## Introduction (1 min)
|
||||
|
||||
Welcome to Whiteport Design Studio - or WDS for short.
|
||||
|
||||
In the last video, we talked about why designers are irreplaceable in the AI era. Now let's talk about WHAT WDS actually is and how it transforms the way you work.
|
||||
|
||||
---
|
||||
|
||||
## The Core Problem WDS Solves (2 min)
|
||||
|
||||
### Traditional Design Handoff Nightmare
|
||||
|
||||
**Recognize this disaster?**
|
||||
|
||||
- You create gorgeous designs in isolation
|
||||
- Designs disappear into "design backlog purgatory"
|
||||
- Months later, developers build something vaguely similar
|
||||
- Everyone argues: "That's not what we agreed on!"
|
||||
|
||||
**The painful reality:** Most brilliant interface ideas die in translation.
|
||||
|
||||
We sketch inspiration but ship interpretation.
|
||||
We design experiences but deliver confusion.
|
||||
|
||||
### The AI Era Makes This Worse
|
||||
|
||||
With AI development, there's a new problem:
|
||||
|
||||
**AI can generate code with stunning accuracy - IF you can clearly define what you want.**
|
||||
|
||||
But if you're unclear, AI starts hallucinating and leaves your project in a death spiral.
|
||||
|
||||
**The new reality:**
|
||||
|
||||
- 🎯 Clear specifications = Perfect AI implementation
|
||||
- 🌪️ Unclear specifications = AI hallucination death spiral
|
||||
|
||||
---
|
||||
|
||||
## What WDS Actually Is (3 min)
|
||||
|
||||
### Specification-First Development
|
||||
|
||||
**WDS is a specification-first design system.**
|
||||
|
||||
Instead of:
|
||||
|
||||
```
|
||||
Sketch → Hope developers understand → Fix in QA
|
||||
```
|
||||
|
||||
WDS gives you:
|
||||
|
||||
```
|
||||
Trigger Map → Scenario Init → Sketch → Why-Based Specs → AI Implementation
|
||||
```
|
||||
|
||||
### The Revolutionary Truth
|
||||
|
||||
**With AI development, specifications ARE the code.**
|
||||
|
||||
There is no longer a bottleneck in writing code. The bottleneck is **knowing what to build**.
|
||||
|
||||
And that requires:
|
||||
|
||||
- Understanding user psychology (Trigger Map)
|
||||
- Defining the journey (Scenario Init)
|
||||
- Capturing design intent (Why-Based Specs)
|
||||
- Preventing AI mistakes (WHAT NOT TO DO)
|
||||
|
||||
### WDS = Designer + AI Partnership
|
||||
|
||||
**WDS is not:**
|
||||
|
||||
- ❌ AI replacing designers
|
||||
- ❌ Automated design generation
|
||||
- ❌ Generic template system
|
||||
|
||||
**WDS is:**
|
||||
|
||||
- ✅ AI amplifying designer thinking
|
||||
- ✅ Socratic questioning to elevate decisions
|
||||
- ✅ Why-based specifications that preserve intent
|
||||
|
||||
---
|
||||
|
||||
## The Three Core Innovations (4 min)
|
||||
|
||||
### 1. Socratic Questioning
|
||||
|
||||
**Traditional AI:**
|
||||
|
||||
```
|
||||
You: "Create a calendar"
|
||||
AI: *Generates generic calendar*
|
||||
You: "No, that's not right..."
|
||||
```
|
||||
|
||||
**WDS Agent:**
|
||||
|
||||
```
|
||||
You: "I need a calendar"
|
||||
Agent: "Help me understand - why week view instead of daily?"
|
||||
You: "Swedish families think in weeks..."
|
||||
Agent: "Got it! So we match their mental model.
|
||||
Should I avoid adding daily/monthly views?"
|
||||
You: "Exactly!"
|
||||
```
|
||||
|
||||
**The difference:** Agent asks WHY to understand your reasoning, not just WHAT to build.
|
||||
|
||||
---
|
||||
|
||||
### 2. Why-Based Specifications
|
||||
|
||||
**Traditional Spec:**
|
||||
|
||||
```markdown
|
||||
## Calendar Component
|
||||
|
||||
- Week view
|
||||
- 7 columns (days)
|
||||
- Color-coded states
|
||||
```
|
||||
|
||||
**WDS Why-Based Spec:**
|
||||
|
||||
```markdown
|
||||
## Calendar Component
|
||||
|
||||
WHY Week View:
|
||||
Swedish families think in "Vecka 40". This matches their
|
||||
mental model. Daily view is too granular, monthly too abstract.
|
||||
→ AI: Don't add daily/monthly views, even if you think it's "better"
|
||||
|
||||
WHY 6 Color States:
|
||||
Visual, instant understanding for kids. No reading required.
|
||||
Each state serves a specific purpose in the accountability flow.
|
||||
→ AI: Don't simplify to 3 states, each serves a purpose
|
||||
|
||||
WHY Countdown Timer (Not Notifications):
|
||||
Gentle urgency without nagging. Visible when user checks app.
|
||||
Notifications would break the "fun, not punishing" tone.
|
||||
→ AI: Don't add push notifications, even if you think it's "helpful"
|
||||
```
|
||||
|
||||
**The difference:** AI knows WHAT to build, WHY you chose it, and WHAT NOT TO DO.
|
||||
|
||||
---
|
||||
|
||||
### 3. Modular Architecture
|
||||
|
||||
**Traditional approach:**
|
||||
|
||||
```
|
||||
One giant specification file (800 lines)
|
||||
├─ Layout + Visual + Logic + API + Content
|
||||
```
|
||||
|
||||
**WDS Modular Architecture:**
|
||||
|
||||
```
|
||||
Pages/02-calendar-page.md (100 lines)
|
||||
├─ WHERE: Page context, layout, content
|
||||
|
||||
Components/walk-slot-card.component.md (150 lines)
|
||||
├─ HOW: Visual design, states, styling
|
||||
|
||||
Features/walk-booking-logic.feature.md (200 lines)
|
||||
├─ WHAT: Business rules, validation, API
|
||||
```
|
||||
|
||||
**The difference:**
|
||||
|
||||
- Clear separation of concerns
|
||||
- Easy to maintain and update
|
||||
- Clean handoffs to specialists
|
||||
- AI can process each file independently
|
||||
|
||||
---
|
||||
|
||||
## How WDS Works in Practice (2 min)
|
||||
|
||||
### The Complete Flow
|
||||
|
||||
**Phase 1: Trigger Map**
|
||||
|
||||
```
|
||||
WHO: Parents (need accountability)
|
||||
TRIGGER: Family conflict over dog care
|
||||
OUTCOME: Harmony without nagging
|
||||
FEATURE: Family dog walk calendar
|
||||
```
|
||||
|
||||
**Phase 2: Scenario Init**
|
||||
|
||||
```
|
||||
Entry Point: Google search (frustrated)
|
||||
Mental State: Tired of nagging, want simple solution
|
||||
End Goal: First walk completed, everyone happy
|
||||
Shortest Path: Landing → Sign up → Setup → Calendar → First walk
|
||||
```
|
||||
|
||||
**Phase 3: Sketch**
|
||||
|
||||
```
|
||||
You: [Upload sketch of calendar page]
|
||||
Agent: "I see: Week view, leaderboard, countdown timers.
|
||||
Should I analyze these sections?"
|
||||
```
|
||||
|
||||
**Phase 4: Why-Based Specifications**
|
||||
|
||||
```
|
||||
Agent: "Why week view instead of daily?"
|
||||
You: "Swedish families think in weeks..."
|
||||
Agent: "Perfect! Documenting:
|
||||
WHY: Matches Swedish 'Vecka 40' mental model
|
||||
WHAT NOT TO DO: Don't add daily/monthly views"
|
||||
```
|
||||
|
||||
**Phase 5: AI Implementation**
|
||||
|
||||
```
|
||||
AI: *Implements exactly as specified*
|
||||
*Skips "helpful" features that would break intent*
|
||||
*Preserves design reasoning*
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## The WDS Difference (1 min)
|
||||
|
||||
### Traditional Design Process
|
||||
|
||||
**Designer:** Creates in isolation
|
||||
**Handoff:** "Here's the design, figure it out"
|
||||
**Developer:** Interprets and builds
|
||||
**Result:** Something vaguely similar
|
||||
**Outcome:** Endless revisions
|
||||
|
||||
### WDS Process
|
||||
|
||||
**Designer:** Thinks through psychology
|
||||
**Agent:** Asks Socratic questions
|
||||
**Specifications:** Capture WHY + WHAT + WHAT NOT
|
||||
**AI:** Implements correctly first time
|
||||
**Outcome:** Design intent preserved
|
||||
|
||||
---
|
||||
|
||||
## Summary (1 min)
|
||||
|
||||
**WDS is:**
|
||||
|
||||
1. **Specification-First** - Specs ARE the code in the AI era
|
||||
2. **Socratic Questioning** - Agent elevates your thinking
|
||||
3. **Why-Based Specs** - Capture reasoning, not just requirements
|
||||
4. **Modular Architecture** - Clean separation, easy maintenance
|
||||
5. **Designer-AI Partnership** - Amplification, not replacement
|
||||
|
||||
**The result:**
|
||||
|
||||
- AI implements correctly first time
|
||||
- Design intent is preserved
|
||||
- Specifications become design knowledge
|
||||
- You're 10x faster and 10x more valuable
|
||||
|
||||
---
|
||||
|
||||
## Next Video
|
||||
|
||||
In the next video, we'll dive into the **BMad Method** - the systematic approach that makes WDS possible.
|
||||
|
||||
You'll learn:
|
||||
|
||||
- The 4 phases of design thinking
|
||||
- How each phase builds on the previous
|
||||
- Why this method works with AI
|
||||
- How to apply it to your projects
|
||||
|
||||
See you there!
|
||||
|
||||
---
|
||||
|
||||
[← Previous: Designer's Role](01-designer-role-in-ai-era.md) | [Next: BMad Method →](03-bmad-method-overview.md)
|
||||
|
||||
[Back to Tutorial Guide](00-TUTORIAL-GUIDE.md)
|
||||
|
|
@ -1,83 +0,0 @@
|
|||
# Tutorial Folder - DEPRECATED
|
||||
|
||||
**Date:** December 9, 2024
|
||||
**Status:** Deprecated - Content moved to course modules
|
||||
|
||||
---
|
||||
|
||||
## What Happened?
|
||||
|
||||
The standalone `tutorial/` folder has been **deprecated** in favor of integrating tutorials directly into course modules.
|
||||
|
||||
---
|
||||
|
||||
## New Structure
|
||||
|
||||
Tutorials are now located within each course module:
|
||||
|
||||
```
|
||||
course/
|
||||
├── module-02-project-brief/
|
||||
│ ├── module-02-overview.md
|
||||
│ ├── lesson-01-...md
|
||||
│ └── tutorial-02.md ← Tutorial here!
|
||||
├── module-04-map-triggers-outcomes/
|
||||
│ └── tutorial-04.md ← Tutorial here!
|
||||
├── module-08-initialize-scenario/
|
||||
│ └── tutorial-08.md ← Tutorial here!
|
||||
└── module-12-why-based-specs/
|
||||
└── tutorial-12.md ← Tutorial here!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Why the Change?
|
||||
|
||||
**Benefits:**
|
||||
|
||||
- ✅ Single learning path - everything in one place
|
||||
- ✅ Module-specific tutorials - tutorial right where you need it
|
||||
- ✅ Cleaner structure - no separate tutorial folder
|
||||
- ✅ Better organization - theory + practice together
|
||||
|
||||
**Old approach:**
|
||||
|
||||
- Separate tutorial folder
|
||||
- Disconnected from course content
|
||||
- Harder to navigate
|
||||
|
||||
**New approach:**
|
||||
|
||||
- Tutorials integrated into modules
|
||||
- Theory → Tutorial → Practice flow
|
||||
- Easier to follow
|
||||
|
||||
---
|
||||
|
||||
## Where to Find Tutorials Now
|
||||
|
||||
**Project Brief:**
|
||||
→ [course/module-02-project-brief/tutorial-02.md](../course/module-02-project-brief/tutorial-02.md)
|
||||
|
||||
**Trigger Mapping:**
|
||||
→ [course/module-04-map-triggers-outcomes/tutorial-04.md](../course/module-04-map-triggers-outcomes/tutorial-04.md)
|
||||
|
||||
**Initialize Scenario:**
|
||||
→ [course/module-08-initialize-scenario/tutorial-08.md](../course/module-08-initialize-scenario/tutorial-08.md)
|
||||
|
||||
**Why-Based Specifications:**
|
||||
→ [course/module-12-why-based-specs/tutorial-12.md](../course/module-12-why-based-specs/tutorial-12.md)
|
||||
|
||||
---
|
||||
|
||||
## Navigation
|
||||
|
||||
**Start learning:**
|
||||
→ [Course Overview](../course/00-course-overview.md)
|
||||
|
||||
**Quick reference:**
|
||||
→ [Workflows Guide](../WDS-WORKFLOWS-GUIDE.md)
|
||||
|
||||
---
|
||||
|
||||
**This folder will be removed in a future cleanup. All content has been migrated to course modules.**
|
||||
|
|
@ -1,257 +0,0 @@
|
|||
# Chapter 0: Why WDS Matters
|
||||
|
||||
## Part 1: Inspiration
|
||||
|
||||
**Learn how to be indispensable in the AI era**
|
||||
|
||||
---
|
||||
|
||||
## Why Learning WDS Matters
|
||||
|
||||
Imagine being the one person on your team that everyone depends on. Not because you work the longest hours or create the prettiest mockups, but because you do something nobody else can do - not even AI. You're about to learn a design methodology that makes you that person.
|
||||
|
||||
This isn't about working faster or making shinier designs. It's about becoming what bestselling author Seth Godin calls a **Linchpin** - someone who is genuinely irreplaceable. Think about the difference between a factory worker who follows instructions and the person who figures out what needs to be done in the first place. The first person can be replaced by a machine. The second person? They're the one who makes things happen.
|
||||
|
||||
In the AI era, designers who master WDS become linchpin designers. They connect ideas that seem unrelated, make judgment calls when there's no clear answer, and create experiences that feel right in ways that can't be reduced to a formula.
|
||||
|
||||
**What makes an irreplaceable designer:**
|
||||
|
||||
- Connects disparate ideas across business, psychology, and technology
|
||||
- Makes things happen when there's no instruction manual
|
||||
- Creates value that can't be commoditized or automated
|
||||
- Is essential, not interchangeable
|
||||
|
||||
---
|
||||
|
||||
## What You'll Gain
|
||||
|
||||
Here's the transformation you're about to experience. Right now, you might feel uncertain about your future as a designer in a world where AI can generate interfaces in seconds. You might wonder if your skills will still matter in five years. That uncertainty is about to disappear.
|
||||
|
||||
By the end of this tutorial, you'll have a completely different relationship with AI. Instead of seeing it as a threat, you'll understand it as an amplifier of your unique human abilities. You'll know exactly what makes you irreplaceable, and you'll have a methodology that lets you work with AI as a partner rather than a competitor.
|
||||
|
||||
Most importantly, you'll understand the five dimensions of thinking that only humans can navigate simultaneously - and you'll know how to use them to create designs that AI could never conceive on its own.
|
||||
|
||||
**Your transformation:**
|
||||
|
||||
- ✅ Understand why designers are irreplaceable in the AI era
|
||||
- ✅ Master the 5 dimensions of designer thinking
|
||||
- ✅ Recognize what AI can and cannot do
|
||||
- ✅ Embrace specifications as the new code
|
||||
- ✅ Amplify your value through AI partnership
|
||||
|
||||
---
|
||||
|
||||
## The Problem We're Solving
|
||||
|
||||
### The Factory Mindset vs The Linchpin Mindset
|
||||
|
||||
In his groundbreaking book [Linchpin: Are You Indispensable?](https://www.amazon.com/Linchpin-Are-You-Indispensable-ebook/dp/B00354Y9ZU), bestselling author and marketing visionary Seth Godin reveals something uncomfortable: the industrial revolution didn't just change how we make things - it changed how we think about work itself. For over a century, we've been trained to be cogs in a machine. Show up, follow instructions, do your part, go home. Replaceable. Interchangeable. Safe.
|
||||
|
||||
Traditional design work follows this exact pattern. You get a brief (instructions), create some mockups (your part), hand them off to developers (next cog in the machine), and hope they understand what you meant. When they don't, you go through endless revisions until something vaguely resembling your vision ships. You're doing factory work - just with Figma instead of an assembly line.
|
||||
|
||||
Here's the uncomfortable truth: AI is really, really good at factory work. If your job is to follow instructions and create predictable outputs, you're in trouble. But if you can become a linchpin - someone who connects ideas, makes judgment calls, and creates meaning - you become more valuable than ever.
|
||||
|
||||
**The factory mindset in design:**
|
||||
|
||||
- Creates mockups by following briefs (instructions)
|
||||
- Hands off to developers (replaceable step)
|
||||
- Hopes they understand (no real connection)
|
||||
- Endless revisions (cog in the machine)
|
||||
- Can be replaced by AI
|
||||
|
||||
---
|
||||
|
||||
### The AI Threat (For Cogs)
|
||||
|
||||
Let's be honest about what's happening. AI can now generate mockups in seconds. It can follow design systems with perfect consistency. It can iterate through hundreds of variations without breaking a sweat. If your value as a designer comes from creating predictable outputs based on clear instructions, you're competing with something that's faster, more consistent, and infinitely scalable.
|
||||
|
||||
But here's the thing: AI cannot be a linchpin. It can't walk into a messy situation and figure out what actually needs to happen. It can't sense when a client is asking for the wrong thing. It can't connect a business goal to a psychological insight to a technical constraint and come up with something nobody expected but everyone loves.
|
||||
|
||||
**What AI does better than cogs:**
|
||||
|
||||
- Generates mockups instantly (no creative block)
|
||||
- Follows design systems perfectly (zero deviation)
|
||||
- Iterates through hundreds of variations (no fatigue)
|
||||
- Works 24/7 at the same quality level (infinitely scalable)
|
||||
- Executes instructions flawlessly (no interpretation errors)
|
||||
|
||||
---
|
||||
|
||||
### The AI Opportunity (For Linchpin Designers)
|
||||
|
||||
Here's where it gets exciting - and where most designers miss the point entirely.
|
||||
|
||||
The internet is drowning in AI slop. Generic interfaces that look fine but feel dead. Products that check all the boxes but have no soul. Experiences that function correctly but leave users cold. This is what happens when you let AI do the thinking - you get competent mediocrity at scale.
|
||||
|
||||
But here's the brutal truth about today's market: **bad products used to fail after launch. Now bad products never even get to start.** Users have infinite options. They can smell soulless design from a mile away. They won't give you a second chance. If your product doesn't immediately feel different, feel right, feel like someone actually cared - it's dead on arrival.
|
||||
|
||||
This is your opportunity. While everyone else is racing to generate more generic content faster, you can create products that come alive. Products with soul. Products that people actually want to use because they feel the human thinking behind them.
|
||||
|
||||
Linchpin designers do what AI fundamentally cannot do: they give products a soul. They navigate five dimensions of thinking simultaneously - business goals, user psychology, product strategy, technical constraints, and design execution - and find the human truth at the intersection. They make judgment calls that create emotional resonance. They build trust through thoughtful decisions. They care about the outcome in a way that shows in every interaction.
|
||||
|
||||
The bottleneck in product development used to be coding. AI demolished that. Now the bottleneck is **products worth building** - figuring out what to create that won't be just more noise in an ocean of AI-generated mediocrity.
|
||||
|
||||
**What makes products come alive (what only designers can do):**
|
||||
|
||||
- Navigate 5 dimensions to find the human truth at the intersection
|
||||
- Make judgment calls that create emotional resonance, not just functionality
|
||||
- Build trust through decisions that show someone cared
|
||||
- Connect business goals to user psychology in ways that feel right
|
||||
- Create experiences that stand out from generic AI-generated mediocrity
|
||||
- Give products a soul that users can feel
|
||||
|
||||
---
|
||||
|
||||
## The Opportunity
|
||||
|
||||
### Becoming a Linchpin Designer
|
||||
|
||||
Seth Godin defines a linchpin as "an individual who can walk into chaos and create order, someone who can invent, connect, create, and make things happen." That's exactly what product design is at its core - walking into the chaos of competing business goals, unclear user needs, technical constraints, and market pressures, and somehow creating order. Creating something that works.
|
||||
|
||||
WDS teaches you to be this person systematically. Not through vague advice about "thinking outside the box," but through a concrete methodology that helps you navigate complexity and create clarity. You'll learn to ask the right questions, connect the right dots, and make the right calls - even when there's no obvious right answer.
|
||||
|
||||
This is what makes you indispensable. Not your Figma skills. Not your aesthetic taste. Your ability to walk into chaos and create order.
|
||||
|
||||
**The irreplaceable designer:**
|
||||
|
||||
- Transforms complexity into clarity
|
||||
- Invents solutions nobody expected
|
||||
- Bridges business, psychology, and technology
|
||||
- Delivers results when there's no roadmap
|
||||
|
||||
---
|
||||
|
||||
### The Designer's Gift: User-Centric Creativity
|
||||
|
||||
Here's Godin's most important insight: linchpins provide something he calls **emotional labor** - the work of genuinely caring about the outcome, connecting with people's real needs, and creating meaning that matters. For designers, this translates into **user-centric creativity** - the uniquely human ability to understand, empathize, and create with purpose.
|
||||
|
||||
User-centric creativity means doing the hard work of understanding WHY users feel frustrated instead of just making things look better. It means connecting business goals to human needs in ways that serve both. It means creating experiences that feel right, not just function correctly. It means making judgment calls that serve people, even when it's harder than following a formula.
|
||||
|
||||
AI can generate variations endlessly and make things look polished on the surface. But here's what it cannot do: it cannot tell when something is fundamentally wrong. It will confidently create beautiful interfaces that make no logical sense. It will add features that contradict the business goal. It will optimize for metrics that destroy user trust. It will make ridiculous mistakes with absolute confidence - and without a skilled designer as gatekeeper, those mistakes ship.
|
||||
|
||||
This is where user-centric creativity becomes critical. You're not just creating - you're evaluating, connecting, and protecting. You understand what it feels like to be a parent struggling to get their kids to help with the dog. You can sense when a business goal conflicts with user needs and find a creative solution that serves both. You're the advocate for the user's presence in every decision. You're the gatekeeper who ensures the impactful meeting between business and user actually happens through the product.
|
||||
|
||||
**The designer as gatekeeper:**
|
||||
|
||||
- Catches AI's confident but ridiculous mistakes before they ship
|
||||
- Evaluates if solutions actually make logical sense
|
||||
- Ensures business goals don't contradict user needs
|
||||
- Protects users from metric-driven decisions that destroy trust
|
||||
- Advocates for the user's presence in every decision
|
||||
- Creates the impactful meeting between business and user
|
||||
|
||||
---
|
||||
|
||||
### From Cog to Linchpin Designer
|
||||
|
||||
Here's the transformation that WDS enables. In the old model, you were a cog designer - creating mockups based on briefs, handing them off to developers who interpreted them their own way, hoping for the best. Your leverage was limited because your thinking stopped at the handoff. You were replaceable because anyone with similar skills could do roughly the same thing.
|
||||
|
||||
With WDS and AI, everything changes - and here's the key insight: **your design contribution completely replaces prompting.** Think about it. You make design decisions. AI helps you clarify them in text. The result is an absolute goldmine for everyone on the team - providing clarity that works like clockwork, replacing hours of pointless back-and-forth prompting.
|
||||
|
||||
You provide the user-centric creativity - the deep understanding of WHY things need to work a certain way. You create why-based specifications that capture not just what to build, but why you're building it that way and what mistakes to avoid. Then AI implements it - but you're there as gatekeeper, catching the mistakes, evaluating the logic, ensuring it actually serves both business and user.
|
||||
|
||||
Here's the paradigm shift: **The design becomes the specification. The specification becomes the product. The code is just the printout - the projection to the end user.** Your thinking no longer stops at handoff. It scales infinitely. Every specification you write becomes a permanent record of your design reasoning that provides clarity for developers, stakeholders, and AI alike. No more endless prompting sessions. No more "can you make it more modern?" Your design thinking, captured in specifications, is the source of truth.
|
||||
|
||||
You remain in the loop - the skilled, experienced designer who evaluates AI's work, catches its confident mistakes, and ensures what ships actually makes sense. You become the key designer player - the person who makes things happen. AI becomes your tool - powerful but requiring your expertise to guide it.
|
||||
|
||||
**The designer's transformation:**
|
||||
|
||||
- **Before:** Creates mockups → Hands off → Hopes it works → Limited leverage
|
||||
- **After:** Design thinking → Specification → Gatekeeper → Clarity for all → Scales infinitely
|
||||
- **Result:** From replaceable cog to indispensable gatekeeper - your design IS the product
|
||||
|
||||
---
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
### The Designer's Art: 5-Dimensional Thinking
|
||||
|
||||
Godin says linchpins "connect disparate ideas." For product designers, this means something very specific: navigating five different dimensions of thinking at the same time. Most people can handle one or two dimensions. Irreplaceable designers navigate all five simultaneously, seeing connections that others miss.
|
||||
|
||||
Think about designing that Dog Week calendar. You need to understand why the business exists (solving family conflict), what success looks like (kids actually walk the dog without nagging), what features serve that goal (week view, not daily), who the users are and what triggers their needs (Swedish families thinking in "Vecka"), and what's technically feasible (mobile app with family sharing). Each dimension informs the others. Miss one, and your design falls apart.
|
||||
|
||||
This is what makes you indispensable as a designer. AI can help you think through each dimension individually. It can generate ideas, analyze data, suggest solutions. But it cannot navigate all five dimensions simultaneously while providing the emotional labor of genuinely caring about the outcome. That's uniquely human. That's what makes designers irreplaceable.
|
||||
|
||||
**The 5 dimensions of design thinking:**
|
||||
|
||||
1. **Business Existence (WHY)** - Understanding purpose and value creation
|
||||
2. **Business Goals (SUCCESS)** - Connecting to metrics and impact
|
||||
3. **Product Strategy (HOW)** - Making hard choices about features
|
||||
4. **Target Groups (WHO)** - Empathy and understanding needs
|
||||
5. **Technical Viability (FEASIBLE)** - Bridging design and implementation
|
||||
|
||||
**The irreplaceable designer's advantage:** Navigating all 5 simultaneously with emotional labor
|
||||
|
||||
---
|
||||
|
||||
## The Transformation
|
||||
|
||||
### From Replaceable to Indispensable
|
||||
|
||||
Godin has a warning that should make every designer pay attention: "If you're not indispensable, you're replaceable. And if you're replaceable, you're probably going to be replaced." In the AI era, this isn't a threat - it's just reality. The question is: which side of that line are you on?
|
||||
|
||||
Right now, you might feel threatened by AI design tools. You might be uncertain about your value as a designer. You might be frustrated by the gap between your vision and what gets implemented. You might feel limited by development bottlenecks. If you're doing factory work - following briefs, creating mockups, hoping for the best - you're on the wrong side of that line.
|
||||
|
||||
This tutorial moves you to the other side. You'll become confident in your indispensable role because you'll understand exactly what makes you irreplaceable. You'll be clear on your unique gift - the user-centric creativity that AI cannot provide. You'll be empowered by AI partnership instead of threatened by it, because AI will amplify your design thinking instead of replacing it. You'll be unstoppable in implementation because your specifications will capture your creative intent perfectly.
|
||||
|
||||
You'll become the designer who makes things happen. The one they can't do without. The linchpin designer.
|
||||
|
||||
**Your transformation as a designer:**
|
||||
|
||||
- **Before:** Threatened, uncertain, frustrated, limited, replaceable
|
||||
- **After:** Confident, clear, empowered, unstoppable, indispensable
|
||||
- **Result:** The designer who makes things happen
|
||||
|
||||
---
|
||||
|
||||
## Learn from Real-World projects: Case Studies
|
||||
|
||||
### Case Study: Dog Week
|
||||
|
||||
Let's make this concrete with a real project. Dog Week is an app that helps Swedish families manage their dog's care through a shared family calendar. The problem it solves is universal - parents are tired of nagging kids about walking the dog, kids feel like they're being punished, and everyone ends up frustrated.
|
||||
|
||||
An irreplaceable designer approaches this completely differently than a cog designer. Instead of jumping straight to mockups, they apply user-centric creativity first. They understand Swedish family dynamics - how "Vecka 40" (week 40) is how people think about time. They connect the business goal (family accountability) to human needs (fun, not punishment). They make judgment calls like using a week view instead of daily, because that matches how families actually think. Every decision is grounded in design empathy and understanding WHY.
|
||||
|
||||
Compare the outcomes. The traditional approach - creating mockups, handing off to developers, going through revisions - took 26 weeks and resulted in something mediocre because the intent got lost in translation. The WDS approach - applying user-centric creativity upfront, capturing WHY in specifications, letting AI implement - took 5 weeks and resulted in something exceptional because the design intent was preserved.
|
||||
|
||||
That's a 5x speed increase with better quality. But more importantly, the key designer's creative thinking was preserved and amplified instead of diluted and lost.
|
||||
|
||||
**The comparison:**
|
||||
|
||||
- **Traditional (cog designer):** 26 weeks → Mediocre result → Intent lost
|
||||
- **WDS (linchpin designer):** 5 weeks → Exceptional result → Intent preserved
|
||||
- **Key difference:** Designer's user-centric creativity captured and amplified
|
||||
|
||||
---
|
||||
|
||||
_More case studies will be added here as they become available._
|
||||
|
||||
---
|
||||
|
||||
## Ready to Begin?
|
||||
|
||||
**Before you start, check the practicalities:**
|
||||
|
||||
- What skills you need (spoiler: you already have them)
|
||||
- Time investment and learning paths
|
||||
- Tools required (mostly free)
|
||||
- What other designers say about WDS
|
||||
|
||||
**[Read Practicalities →](04-practicalities.md)**
|
||||
|
||||
---
|
||||
|
||||
**Or jump straight into the methodology:**
|
||||
|
||||
In the next section (Teaching), you'll learn the concrete methodology:
|
||||
|
||||
- The 5 dimensions in detail with examples
|
||||
- What AI cannot do (and what it can)
|
||||
- Why specifications are the new code
|
||||
- How to amplify your value through AI partnership
|
||||
|
||||
**[Continue to Part 2: Teaching →](02-teaching.md)**
|
||||
|
||||
---
|
||||
|
||||
[← Back to Tutorial Guide](../00-TUTORIAL-GUIDE.md) | [Practicalities →](04-practicalities.md) | [Next: Teaching →](02-teaching.md)
|
||||
|
|
@ -1,258 +0,0 @@
|
|||
# Chapter 0: Why WDS Matters
|
||||
|
||||
## Part 4: Practicalities
|
||||
|
||||
**Everything you need to know before starting**
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### What Skills You Need
|
||||
|
||||
**Required (you probably already have these):**
|
||||
|
||||
- Basic design thinking and UX principles
|
||||
- Ability to sketch interfaces (hand-drawn or digital)
|
||||
- Understanding of user needs and business goals
|
||||
- Willingness to think deeply about WHY
|
||||
|
||||
**NOT required:**
|
||||
|
||||
- ❌ Coding skills
|
||||
- ❌ Advanced technical knowledge
|
||||
- ❌ Experience with AI tools
|
||||
- ❌ Formal design education
|
||||
|
||||
**The truth:** If you can design interfaces and explain your thinking, you have everything you need to start.
|
||||
|
||||
---
|
||||
|
||||
## Time Investment
|
||||
|
||||
### How Long Does It Take?
|
||||
|
||||
**Total tutorial time:** ~10 hours
|
||||
|
||||
- Spread over days or weeks at your own pace
|
||||
- Each chapter: 30-40 minutes
|
||||
- Practice exercises: 1-2 hours per chapter
|
||||
|
||||
**Breakdown:**
|
||||
|
||||
- **Week 1-2:** Foundation chapters (0-2.3) - Understanding the methodology
|
||||
- **Week 3-4:** Core workflow (4.1-4.6) - Learning specification creation
|
||||
- **Week 5-6:** Advanced topics (5.1-6.1) - Design systems and handoff
|
||||
- **Ongoing:** Practice with your own projects
|
||||
|
||||
**Real-world application:**
|
||||
|
||||
- First project with WDS: 2-3x slower than your usual process (learning curve)
|
||||
- Second project: Same speed as traditional approach
|
||||
- Third project onwards: 3-5x faster with better quality
|
||||
|
||||
---
|
||||
|
||||
## Tools You'll Need
|
||||
|
||||
### Essential Tools
|
||||
|
||||
**For sketching:**
|
||||
|
||||
- Paper and pen (seriously, this works best)
|
||||
- OR digital sketching tool (Excalidraw, Figma, iPad + Pencil)
|
||||
|
||||
**For AI assistance:**
|
||||
|
||||
- Access to Claude, ChatGPT, or similar AI assistant
|
||||
- Free tier is sufficient to start
|
||||
|
||||
**For documentation:**
|
||||
|
||||
- Text editor (VS Code recommended, but any will work)
|
||||
- Markdown support (built into most modern editors)
|
||||
|
||||
**For collaboration:**
|
||||
|
||||
- Git/GitHub (optional but recommended)
|
||||
- Shared folder system (Google Drive, Dropbox, etc.)
|
||||
|
||||
**Total cost to get started:** $0-20/month
|
||||
|
||||
- Free tier AI tools work fine
|
||||
- Paid AI subscriptions ($20/month) provide better experience but aren't required
|
||||
|
||||
---
|
||||
|
||||
## What You'll Create
|
||||
|
||||
### Your First WDS Project
|
||||
|
||||
By the end of this tutorial, you'll have created:
|
||||
|
||||
**1. Complete Project Brief**
|
||||
|
||||
- Vision and goals clearly defined
|
||||
- Stakeholders and constraints documented
|
||||
- Foundation for all design decisions
|
||||
|
||||
**2. Trigger Map**
|
||||
|
||||
- Target groups identified and prioritized
|
||||
- User triggers and outcomes mapped
|
||||
- Features prioritized by impact
|
||||
|
||||
**3. Scenario Specifications**
|
||||
|
||||
- At least one complete user scenario
|
||||
- Why-based specifications for key components
|
||||
- AI-ready documentation
|
||||
|
||||
**4. Design System Foundation**
|
||||
|
||||
- Design tokens extracted from your specs
|
||||
- Component patterns identified
|
||||
- Reusable architecture defined
|
||||
|
||||
**Estimated value:** What used to take 6-8 weeks now takes 1-2 weeks
|
||||
|
||||
---
|
||||
|
||||
## Learning Path Options
|
||||
|
||||
### Choose Your Journey
|
||||
|
||||
**Option 1: Full Immersion (Recommended)**
|
||||
|
||||
- Complete all 16 chapters in order
|
||||
- Practice exercises for each chapter
|
||||
- Apply to a real project as you learn
|
||||
- **Time:** 6-8 weeks, 10-15 hours total
|
||||
- **Best for:** Designers who want to master the methodology
|
||||
|
||||
**Option 2: Quick Start**
|
||||
|
||||
- Focus on core chapters (0, 2.2, 4.1, 4.5)
|
||||
- Skip advanced topics initially
|
||||
- Get started fast, learn more later
|
||||
- **Time:** 2-3 weeks, 3-4 hours total
|
||||
- **Best for:** Designers who need results quickly
|
||||
|
||||
**Option 3: Self-Paced**
|
||||
|
||||
- Learn one chapter per week
|
||||
- Deep practice between chapters
|
||||
- Build multiple projects as you learn
|
||||
- **Time:** 16 weeks, 20+ hours total
|
||||
- **Best for:** Designers who want deep mastery
|
||||
|
||||
---
|
||||
|
||||
## What Other Designers Say
|
||||
|
||||
### Testimonials
|
||||
|
||||
> "I was skeptical at first - another design methodology? But WDS changed how I think about my role. I'm no longer just making things pretty. I'm the strategic thinker who makes products come alive."
|
||||
>
|
||||
> **— Sarah K., Product Designer**
|
||||
|
||||
> "The 5x speed increase is real. But what surprised me most was how much clearer my thinking became. Writing why-based specifications forced me to understand the 'why' at a deeper level."
|
||||
>
|
||||
> **— Marcus L., UX Lead**
|
||||
|
||||
> "I thought AI would replace me. WDS showed me how to make AI amplify my thinking instead. Now I'm the most valuable designer on my team."
|
||||
>
|
||||
> **— Priya S., Senior Designer**
|
||||
|
||||
> "The paradigm shift hit me in Chapter 4: my design IS the product. The code is just the printout. That completely changed how I approach every project."
|
||||
>
|
||||
> **— James T., Design Director**
|
||||
|
||||
_Note: More testimonials will be added as designers complete the tutorial._
|
||||
|
||||
---
|
||||
|
||||
## Common Questions
|
||||
|
||||
### FAQ
|
||||
|
||||
**Q: Do I need to know how to code?**
|
||||
A: No. WDS is about design thinking and specifications. AI handles the implementation.
|
||||
|
||||
**Q: What if I don't have a project to practice with?**
|
||||
A: The tutorial includes practice exercises. You can also use a hypothetical project or redesign an existing app.
|
||||
|
||||
**Q: Can I use this with my current design process?**
|
||||
A: Yes! WDS complements existing processes. Many designers integrate it gradually.
|
||||
|
||||
**Q: Is this only for digital products?**
|
||||
A: WDS is optimized for digital products, but the principles apply to any design work.
|
||||
|
||||
**Q: What if I get stuck?**
|
||||
A: Each chapter includes clear examples and guidance. The AI assistant can help clarify concepts as you learn.
|
||||
|
||||
**Q: Do I need to complete all 16 chapters?**
|
||||
A: No. The Quick Start path (4 chapters) gives you enough to start applying WDS immediately.
|
||||
|
||||
**Q: Can I teach this to my team?**
|
||||
A: Yes! WDS is open-source and free. Share it with your entire team.
|
||||
|
||||
**Q: How is this different from traditional design documentation?**
|
||||
A: Traditional docs describe WHAT. WDS captures WHY + WHAT + WHAT NOT TO DO. This makes it AI-ready and preserves your design intent.
|
||||
|
||||
---
|
||||
|
||||
## Support & Community
|
||||
|
||||
### Getting Help
|
||||
|
||||
**During the tutorial:**
|
||||
|
||||
- Each chapter includes detailed examples
|
||||
- AI assistants can clarify concepts in real-time
|
||||
- Practice exercises with clear success criteria
|
||||
|
||||
**After completion:**
|
||||
|
||||
- GitHub Discussions for questions and sharing
|
||||
- Community showcase of WDS projects
|
||||
- Regular updates and new case studies
|
||||
|
||||
**Contributing:**
|
||||
|
||||
- WDS is open-source and welcomes contributions
|
||||
- Share your case studies and learnings
|
||||
- Help improve the tutorial for future designers
|
||||
|
||||
---
|
||||
|
||||
## Ready to Start?
|
||||
|
||||
You have everything you need:
|
||||
|
||||
- ✅ The skills (design thinking)
|
||||
- ✅ The tools (paper + AI)
|
||||
- ✅ The time (10 hours)
|
||||
- ✅ The motivation (staying indispensable)
|
||||
|
||||
**Next step:** Choose your learning path and dive into Chapter 1.
|
||||
|
||||
**[Start Chapter 1: Project Brief →](../chapter-1.1-project-brief/01-inspiration.md)**
|
||||
|
||||
Or return to the main guide to review the full structure:
|
||||
|
||||
**[← Back to Tutorial Guide](../00-TUTORIAL-GUIDE.md)**
|
||||
|
||||
---
|
||||
|
||||
## Your Transformation Starts Now
|
||||
|
||||
Remember:
|
||||
|
||||
- **The design becomes the specification**
|
||||
- **The specification becomes the product**
|
||||
- **The code is just the printout**
|
||||
|
||||
Ten hours of learning. A lifetime of being indispensable.
|
||||
|
||||
Let's begin.
|
||||
|
|
@ -0,0 +1,297 @@
|
|||
# Project Contract
|
||||
|
||||
**Project**: {{project_name}}
|
||||
**Date**: {{date}}
|
||||
**Client**: {{client_name}}
|
||||
**Contractor**: {{contractor_name}}
|
||||
**Contract Language**: {{contract_language}}
|
||||
**Governing Law/Jurisdiction**: {{governing_jurisdiction}}
|
||||
|
||||
---
|
||||
|
||||
> **Contract Philosophy**: This contract is designed to be simple, fair, and clear - providing reliable terms that support a long-lasting working relationship between both parties.
|
||||
|
||||
---
|
||||
|
||||
## 1. Project Overview
|
||||
|
||||
### The Realization
|
||||
|
||||
{{realization}}
|
||||
|
||||
### Recommended Solution
|
||||
|
||||
{{recommended_solution}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Business Model
|
||||
|
||||
**Selected Model**: {{business_model}}
|
||||
|
||||
{{business_model_description}}
|
||||
|
||||
{{business_model_terms}}
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope of Work
|
||||
|
||||
### The Path Forward
|
||||
|
||||
{{path_forward}}
|
||||
|
||||
### Deliverables
|
||||
|
||||
Based on the path forward, the following deliverables will be provided:
|
||||
|
||||
{{deliverables_list}}
|
||||
|
||||
### In Scope
|
||||
|
||||
The following work is explicitly included in this contract:
|
||||
|
||||
{{in_scope}}
|
||||
|
||||
### Out of Scope
|
||||
|
||||
The following work is explicitly NOT included in this contract:
|
||||
|
||||
{{out_of_scope}}
|
||||
|
||||
**Note**: Any work outside the scope defined above requires a written Change Order (see Section 10: Not to Exceed Clause).
|
||||
|
||||
---
|
||||
|
||||
## 4. Our Commitment
|
||||
|
||||
{{our_commitment}}
|
||||
|
||||
---
|
||||
|
||||
### Payment Terms
|
||||
|
||||
**Total Contract Amount**: {{total_amount}}
|
||||
|
||||
**Payment Structure**: {{payment_structure}}
|
||||
|
||||
**Payment Schedule**:
|
||||
{{payment_schedule}}
|
||||
|
||||
**Background**: Clear payment terms protect both parties and ensure fair compensation.
|
||||
|
||||
**What it does**: Defines when and how payments will be made.
|
||||
|
||||
**Purpose**:
|
||||
- Ensures supplier receives fair compensation for work
|
||||
- Provides client with clear payment expectations
|
||||
- Protects both parties from payment disputes
|
||||
- For fixed-price contracts, upfront payment is fair since supplier assumes cost overrun risk
|
||||
|
||||
**Payment Terms Details**:
|
||||
- **Payment Method**: {{payment_method}} (check, wire transfer, credit card, etc.)
|
||||
- **Payment Due Dates**: {{payment_due_dates}}
|
||||
- **Late Payment**: {{late_payment_terms}} (e.g., interest charges, work suspension)
|
||||
- **Payment Conditions**: {{payment_conditions}} (e.g., payment required before work begins, payment tied to deliverables)
|
||||
|
||||
**For Fixed-Price Contracts**:
|
||||
This is a fixed-price contract, meaning the contractor commits to deliver specified work for the agreed price, regardless of actual costs. Since the contractor assumes the risk of cost overruns, upfront payment (50-100%) is standard and fair. This demonstrates client commitment and enables the contractor to deliver quality work without cash flow concerns.
|
||||
|
||||
---
|
||||
|
||||
## 5. Timeline
|
||||
|
||||
{{timeline}}
|
||||
|
||||
*Note: Timeline is based on the work plan outlined above and may be adjusted based on project requirements.*
|
||||
|
||||
---
|
||||
|
||||
## 6. Why It Matters
|
||||
|
||||
{{why_it_matters}}
|
||||
|
||||
---
|
||||
|
||||
## 7. Expected Outcomes
|
||||
|
||||
### The Value We'll Create
|
||||
|
||||
{{value_we_create}}
|
||||
|
||||
---
|
||||
|
||||
## 8. Risks and Considerations
|
||||
|
||||
### Cost of Inaction
|
||||
|
||||
{{cost_of_inaction}}
|
||||
|
||||
---
|
||||
|
||||
## 9. Confidentiality
|
||||
|
||||
### Confidentiality Clause
|
||||
|
||||
**Background**: This clause protects sensitive information shared during the project.
|
||||
|
||||
**What it does**: Both parties agree to keep project information confidential.
|
||||
|
||||
**Purpose**: Protects proprietary information, business strategies, trade secrets, and sensitive data.
|
||||
|
||||
**Terms**:
|
||||
|
||||
Both parties agree to:
|
||||
|
||||
- Keep all project-related information confidential
|
||||
- Not disclose project details to third parties without written consent
|
||||
- Use confidential information solely for project purposes
|
||||
- Return or destroy confidential materials upon project completion or termination
|
||||
- Maintain confidentiality obligations even after project completion
|
||||
|
||||
**Exceptions**:
|
||||
- Information already publicly known
|
||||
- Information independently developed
|
||||
- Information required by law to be disclosed
|
||||
|
||||
**Duration**: Confidentiality obligations shall remain in effect for [X] years after project completion.
|
||||
|
||||
---
|
||||
|
||||
## 10. Not to Exceed Clause
|
||||
|
||||
### Budget Cap
|
||||
|
||||
**Background**: This clause sets a maximum budget limit.
|
||||
|
||||
**What it does**: States that total costs will not exceed a specified amount without prior written approval.
|
||||
|
||||
**Purpose**:
|
||||
- Protects both parties from unexpected cost overruns
|
||||
- Ensures budget control
|
||||
- **Prevents scope creep** - Any work beyond the original scope requires approval and may affect the budget cap
|
||||
|
||||
**Terms**:
|
||||
|
||||
- Total project costs shall not exceed **{{not_to_exceed_amount}}** without prior written approval from {{client_name}}
|
||||
- Any work that would exceed this amount must be approved in advance
|
||||
- If additional work is needed, a change order must be signed before proceeding
|
||||
- This cap includes all fees, expenses, and costs related to the project
|
||||
|
||||
**Change Orders and Scope Control**:
|
||||
- Any changes to scope that affect cost must be documented in a written change order
|
||||
- Change orders must be signed by both parties before work begins
|
||||
- Change orders may adjust the not-to-exceed amount if agreed upon
|
||||
- **Scope creep prevention**: Work outside the original scope (as defined in Section 2) requires a change order and approval before proceeding
|
||||
- This clause helps prevent gradual expansion of project scope without proper authorization
|
||||
|
||||
---
|
||||
|
||||
## 11. Terms and Conditions
|
||||
|
||||
### Work Initiation
|
||||
|
||||
**When work begins**: {{work_initiation_date_or_condition}}
|
||||
|
||||
**Background**: This clause specifies exactly when the contractor is authorized to begin work.
|
||||
|
||||
**What it does**: Defines the start date or conditions that must be met before work begins.
|
||||
|
||||
**Purpose**:
|
||||
- Prevents unauthorized work before contract is fully executed
|
||||
- Establishes clear timeline expectations
|
||||
- Protects both parties by ensuring work only begins after proper authorization
|
||||
|
||||
**Initiation conditions** (select applicable):
|
||||
- Upon full execution of this contract (signatures from both parties)
|
||||
- On a specific date: {{specific_start_date}}
|
||||
- Upon receipt of initial payment/deposit
|
||||
- Upon written notice from {{client_name}}
|
||||
- Other: {{custom_initiation_condition}}
|
||||
|
||||
### Project Initiation
|
||||
|
||||
This project is initiated upon approval of the project pitch. Project initiation is considered complete upon stakeholder approval.
|
||||
|
||||
### Next Steps
|
||||
|
||||
After contract approval:
|
||||
1. Proceed to full Project Brief development
|
||||
2. Execute work plan as outlined above
|
||||
3. Deliverables will be provided according to the agreed timeline
|
||||
|
||||
### Changes and Modifications
|
||||
|
||||
Any changes to scope, timeline, or investment must be agreed upon in writing by all parties.
|
||||
|
||||
### Intellectual Property
|
||||
|
||||
**Philosophy**: Clear IP ownership prevents future disputes and protects both parties' interests.
|
||||
|
||||
All deliverables and work products created under this contract will be owned by {{client_name}} upon full payment, unless otherwise specified in writing. This ensures clarity and prevents misunderstandings about ownership rights.
|
||||
|
||||
### Termination
|
||||
|
||||
**Philosophy**: Fair termination terms protect both parties while allowing for reasonable exit if needed.
|
||||
|
||||
Either party may terminate this agreement with [X] days written notice. Upon termination, payment is due for work completed to date. This ensures fair compensation for work done and reasonable notice for both parties to plan accordingly.
|
||||
|
||||
### Dispute Resolution
|
||||
|
||||
**Background**: Defines how conflicts will be resolved if they arise.
|
||||
|
||||
**What it does**: Establishes the process for handling disagreements.
|
||||
|
||||
**Purpose**: Provides a clear path for resolving disputes without costly litigation when possible.
|
||||
|
||||
**Method**: {{dispute_resolution_method}} (mediation/arbitration/litigation)
|
||||
|
||||
**Location**: {{dispute_resolution_location}}
|
||||
|
||||
Any disputes arising from this contract shall be resolved through {{dispute_resolution_method}} in {{dispute_resolution_location}}.
|
||||
|
||||
---
|
||||
|
||||
### Governing Law and Jurisdiction
|
||||
|
||||
**Background**: Determines which laws apply and where legal proceedings would take place.
|
||||
|
||||
**What it does**: Specifies the legal framework and court system that governs the contract.
|
||||
|
||||
**Purpose**: Provides legal clarity and predictability for both parties.
|
||||
|
||||
**Governing Law**: This contract shall be governed by and construed in accordance with the laws of {{governing_jurisdiction}}.
|
||||
|
||||
**Jurisdiction**: Any legal proceedings arising from this contract shall be subject to the exclusive jurisdiction of the courts of {{governing_jurisdiction}}.
|
||||
|
||||
**Contract Language**: This contract is executed in {{contract_language}}. In case of translation, the {{contract_language}} version shall prevail.
|
||||
|
||||
---
|
||||
|
||||
## 12. Approval
|
||||
|
||||
**Client Approval**:
|
||||
|
||||
Signature: _________________
|
||||
Name: {{client_name}}
|
||||
Date: _______________
|
||||
|
||||
**Contractor Approval**:
|
||||
|
||||
Signature: _________________
|
||||
Name: {{contractor_name}}
|
||||
Date: _______________
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Reference Documents
|
||||
|
||||
- Project Pitch: `docs/1-project-brief/pitch.md`
|
||||
- Project Brief: (To be created after contract approval)
|
||||
|
||||
---
|
||||
|
||||
*This contract is based on the project pitch dated {{date}}.*
|
||||
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
# Project Pitch: {{project_name}}
|
||||
|
||||
> Compelling case for why this project matters and should be built
|
||||
|
||||
**Created:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Status:** Ready for stakeholder approval
|
||||
|
||||
---
|
||||
|
||||
## 1. The Realization
|
||||
|
||||
{{realization}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Why It Matters
|
||||
|
||||
{{why_it_matters}}
|
||||
|
||||
---
|
||||
|
||||
## 3. How We See It Working
|
||||
|
||||
{{how_we_see_it_working}}
|
||||
|
||||
---
|
||||
|
||||
## 4. Paths We Explored
|
||||
|
||||
{{paths_we_explored}}
|
||||
|
||||
---
|
||||
|
||||
## 5. Recommended Solution
|
||||
|
||||
{{recommended_solution}}
|
||||
|
||||
---
|
||||
|
||||
## 6. The Path Forward
|
||||
|
||||
{{path_forward}}
|
||||
|
||||
---
|
||||
|
||||
## 7. The Value We'll Create
|
||||
|
||||
{{value_we_create}}
|
||||
|
||||
---
|
||||
|
||||
## 8. Cost of Inaction
|
||||
|
||||
{{cost_of_inaction}}
|
||||
|
||||
---
|
||||
|
||||
## 9. Our Commitment
|
||||
|
||||
{{our_commitment}}
|
||||
|
||||
---
|
||||
|
||||
## 10. Summary
|
||||
|
||||
{{summary}}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
**After approval**, proceed to:
|
||||
- **Full Project Brief** - Detailed strategic foundation
|
||||
- **Trigger Mapping** - User research and personas
|
||||
- **Platform Requirements** - Technical foundation
|
||||
- **UX Design** - Scenarios and prototypes
|
||||
|
||||
---
|
||||
|
||||
_Generated by Whiteport Design Studio_
|
||||
|
||||
|
|
@ -0,0 +1,212 @@
|
|||
# Pitch Section Exploration Guide
|
||||
|
||||
**Framework Inspiration**: This guide draws from proven frameworks:
|
||||
- **Customer-Problem-Solution (CPS)** - Clear structure
|
||||
- **Value Proposition Canvas** - Understanding customer needs
|
||||
- **Problem-Agitate-Solve (PAS)** - Natural flow
|
||||
- **Business Case Framework** - Investment and consequences
|
||||
|
||||
---
|
||||
|
||||
### 1. The Realization
|
||||
|
||||
**Framework**: Problem-Agitate-Solve (PAS) - Start here
|
||||
|
||||
**Questions to explore**:
|
||||
- "What have you realized needs attention?"
|
||||
- "What observation have you made?"
|
||||
- "What challenge are you seeing?"
|
||||
- "What evidence do you have that this is real?"
|
||||
|
||||
**Best Practice: Confirm the Realization with Evidence**
|
||||
|
||||
**Help them identify evidence:**
|
||||
|
||||
**Soft Evidence** (qualitative indicators):
|
||||
- "Do you have testimonials or complaints about this?"
|
||||
- "What have stakeholders told you?"
|
||||
- "What patterns have you observed?"
|
||||
- "What do user interviews reveal?"
|
||||
|
||||
**Hard Evidence** (quantitative data):
|
||||
- "Do you have statistics or metrics?"
|
||||
- "What do analytics show?"
|
||||
- "Have you run surveys or tests?"
|
||||
- "What do server logs or error reports indicate?"
|
||||
|
||||
**Help them combine both types** for maximum credibility:
|
||||
- Start with soft evidence (testimonials, complaints, observations)
|
||||
- Support with hard evidence (statistics, analytics, survey results)
|
||||
- Show the realization is grounded in reality
|
||||
|
||||
**Keep it brief** - 2-3 sentences for the realization, plus 1-2 sentences of evidence
|
||||
|
||||
**Help them articulate**: Clear realization backed by evidence that frames a reality worth addressing
|
||||
|
||||
---
|
||||
|
||||
### 2. Why It Matters
|
||||
|
||||
**Framework**: Value Proposition Canvas + Impact - Understanding why this matters and who we help
|
||||
|
||||
**Questions to explore**:
|
||||
- "Why does this matter?"
|
||||
- "Who are we helping?"
|
||||
- "What are they trying to accomplish?" (Jobs)
|
||||
- "What are their pain points?" (Pains)
|
||||
- "What would make their life better?" (Gains)
|
||||
- "How does this affect them?"
|
||||
- "What impact will this have?"
|
||||
- "Are there different groups we're helping?"
|
||||
|
||||
**Keep it brief** - Why it matters and who we help
|
||||
|
||||
**Help them think**: Focus on the value we're adding to specific people and why that matters
|
||||
|
||||
---
|
||||
|
||||
### 3. How We See It Working
|
||||
|
||||
**Questions to explore**:
|
||||
- "How do you envision this working?"
|
||||
- "What's the general approach?"
|
||||
- "Walk me through how you see it addressing the realization"
|
||||
|
||||
**Keep it brief** - High-level overview, not detailed specifications
|
||||
|
||||
**Flexible language** - Works for software, processes, services, products, strategies
|
||||
|
||||
---
|
||||
|
||||
### 4. Paths We Explored
|
||||
|
||||
**Questions to explore**:
|
||||
- "What other ways could we approach this?"
|
||||
- "Are there alternative paths?"
|
||||
- "What options have you considered?"
|
||||
|
||||
**Keep it brief** - 2-3 paths explored briefly
|
||||
|
||||
**If user only has one path**: That's fine - acknowledge it and move on
|
||||
|
||||
---
|
||||
|
||||
### 5. Recommended Solution
|
||||
|
||||
**Questions to explore**:
|
||||
- "Which approach do you prefer?"
|
||||
- "Why this one over the others?"
|
||||
- "What makes this the right solution?"
|
||||
|
||||
**Keep it brief** - Preferred approach and key reasons
|
||||
|
||||
---
|
||||
|
||||
### 6. The Path Forward
|
||||
|
||||
**Purpose**: Explain how the work will be done practically - which WDS phases will be used and the workflow approach.
|
||||
|
||||
**Questions to explore**:
|
||||
- "How do you envision the work being done?"
|
||||
- "Which WDS phases do you think we'll need?"
|
||||
- "What's the practical workflow you're thinking?"
|
||||
- "Will we need user research, or do you already know your users?"
|
||||
- "Do you need technical architecture planning, or is that already defined?"
|
||||
- "What level of design detail do you need?"
|
||||
- "How will this be handed off for implementation?"
|
||||
|
||||
**Keep it brief** - High-level plan of the work approach
|
||||
|
||||
**Help them think**:
|
||||
- Which WDS phases apply (Trigger Mapping, Platform Requirements, UX Design, Design System, etc.)
|
||||
- Practical workflow (research → design → handoff, or skip research, etc.)
|
||||
- Level of detail needed
|
||||
- Handoff approach
|
||||
|
||||
**Example responses**:
|
||||
- "We'll start with Product Brief, then do UX Design for 3 scenarios, skip Trigger Mapping since we know our users, and create a handoff package for developers"
|
||||
- "Need full WDS workflow: Brief → User Research → Architecture → Design → Handoff"
|
||||
- "Just need design specs - skip research and architecture, go straight to UX Design"
|
||||
|
||||
---
|
||||
|
||||
### 7. The Value We'll Create
|
||||
|
||||
**Framework**: Business Case Framework - What's the return?
|
||||
|
||||
**Questions to explore**:
|
||||
- "What's our ambition? What are we striving to accomplish?"
|
||||
- "What happens if we DO build this?"
|
||||
- "What benefits would we see?"
|
||||
- "What outcomes are we expecting?"
|
||||
- "How will we measure success?"
|
||||
- "What metrics will tell us we're succeeding?"
|
||||
- "What's the value we'd create?"
|
||||
|
||||
**Best Practice: Frame as Positive Assumption with Success Metrics**
|
||||
|
||||
**Help them articulate**:
|
||||
- **Our Ambition**: What we're confidently striving to accomplish (enthusiastic, positive)
|
||||
- **Success Metrics**: How we'll measure success (specific, measurable)
|
||||
- **What Success Looks Like**: Clear outcomes (tangible results)
|
||||
- **Monitoring Approach**: How we'll track these metrics (brief)
|
||||
|
||||
**Keep it brief** - Key benefits, outcomes, and success metrics
|
||||
|
||||
**Help them think**: Positive assumption ("We're confident this will work") + clear success metrics ("Here's how we'll measure it") = enthusiastic and scientific
|
||||
|
||||
---
|
||||
|
||||
### 8. Cost of Inaction
|
||||
|
||||
**Framework**: Problem-Agitate-Solve (PAS) - Agitate the problem / Business Case Framework
|
||||
|
||||
**Questions to explore**:
|
||||
- "What happens if we DON'T build this?"
|
||||
- "What are the risks of not acting?"
|
||||
- "What opportunities would we miss?"
|
||||
- "What's the cost of doing nothing?"
|
||||
- "What gets worse if we don't act?"
|
||||
- "What do we lose by waiting?"
|
||||
|
||||
**Keep it brief** - Key consequences of not building
|
||||
|
||||
**Can include**:
|
||||
- Financial cost (lost revenue, increased costs)
|
||||
- Opportunity cost (missed opportunities)
|
||||
- Competitive risk (competitors gaining advantage)
|
||||
- Operational impact (inefficiency, problems getting worse)
|
||||
|
||||
**Help them think**: Make the case for why we can't afford NOT to do this
|
||||
|
||||
---
|
||||
|
||||
### 9. Our Commitment
|
||||
|
||||
**Framework**: Business Case Framework - What are we committing to?
|
||||
|
||||
**Questions to explore**:
|
||||
- "What resources are we committing?"
|
||||
- "What's the time commitment?"
|
||||
- "What budget or team are we committing?"
|
||||
- "What dependencies exist?"
|
||||
- "What potential risks or drawbacks should we consider?"
|
||||
- "What challenges might we face?"
|
||||
|
||||
**Keep it brief** - High-level commitment and potential risks
|
||||
|
||||
**Don't force precision** - Rough estimates are fine at this stage
|
||||
|
||||
**Help them think**: Time, money, people, technology - what are we committing to make this happen? What risks or challenges should we acknowledge?
|
||||
|
||||
---
|
||||
|
||||
### 10. Summary
|
||||
|
||||
**Questions to explore**:
|
||||
- "What are the key points?"
|
||||
- "What should stakeholders remember?"
|
||||
- "What's the main takeaway?"
|
||||
|
||||
**Keep it brief** - Summary of key points (let readers draw their own conclusion)
|
||||
|
||||
|
|
@ -0,0 +1,277 @@
|
|||
# Service Agreement
|
||||
|
||||
**Project**: {{project_name}}
|
||||
**Date**: {{date}}
|
||||
**Client/Owner**: {{client_name}}
|
||||
**Service Provider**: {{service_provider_name}}
|
||||
**Contract Language**: {{contract_language}}
|
||||
**Governing Law/Jurisdiction**: {{governing_jurisdiction}}
|
||||
|
||||
---
|
||||
|
||||
> **Agreement Philosophy**: This agreement is designed to be simple, fair, and clear - providing reliable terms that support a long-lasting working relationship between both parties.
|
||||
|
||||
---
|
||||
|
||||
## 1. Project Overview
|
||||
|
||||
### The Realization
|
||||
|
||||
{{realization}}
|
||||
|
||||
### Recommended Solution
|
||||
|
||||
{{recommended_solution}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Scope of Services
|
||||
|
||||
### The Path Forward
|
||||
|
||||
{{path_forward}}
|
||||
|
||||
### Deliverables
|
||||
|
||||
Based on the path forward, the following deliverables will be provided:
|
||||
|
||||
{{deliverables_list}}
|
||||
|
||||
---
|
||||
|
||||
## 3. Our Commitment
|
||||
|
||||
{{our_commitment}}
|
||||
|
||||
---
|
||||
|
||||
### Payment Terms
|
||||
|
||||
**Total Agreement Amount**: {{total_amount}}
|
||||
|
||||
**Payment Structure**: {{payment_structure}}
|
||||
|
||||
**Payment Schedule**:
|
||||
{{payment_schedule}}
|
||||
|
||||
**Background**: Clear payment terms protect both parties and ensure fair compensation.
|
||||
|
||||
**What it does**: Defines when and how payments will be made.
|
||||
|
||||
**Purpose**:
|
||||
- Ensures service provider receives fair compensation for work
|
||||
- Provides client with clear payment expectations
|
||||
- Protects both parties from payment disputes
|
||||
- For fixed-price agreements, upfront payment is fair since service provider assumes cost overrun risk
|
||||
|
||||
**Payment Terms Details**:
|
||||
- **Payment Method**: {{payment_method}} (check, wire transfer, credit card, etc.)
|
||||
- **Payment Due Dates**: {{payment_due_dates}}
|
||||
- **Late Payment**: {{late_payment_terms}} (e.g., interest charges, work suspension)
|
||||
- **Payment Conditions**: {{payment_conditions}} (e.g., payment required before work begins, payment tied to deliverables)
|
||||
|
||||
**For Fixed-Price Agreements**:
|
||||
This is a fixed-price agreement, meaning the service provider commits to deliver specified work for the agreed price, regardless of actual costs. Since the service provider assumes the risk of cost overruns, upfront payment (50-100%) is standard and fair. This demonstrates client commitment and enables the service provider to deliver quality work without cash flow concerns.
|
||||
|
||||
---
|
||||
|
||||
## 4. Timeline
|
||||
|
||||
{{timeline}}
|
||||
|
||||
*Note: Timeline is based on the path forward outlined above and may be adjusted based on project requirements.*
|
||||
|
||||
---
|
||||
|
||||
## 5. Why It Matters
|
||||
|
||||
{{why_it_matters}}
|
||||
|
||||
---
|
||||
|
||||
## 6. Expected Outcomes
|
||||
|
||||
### The Value We'll Create
|
||||
|
||||
{{value_we_create}}
|
||||
|
||||
---
|
||||
|
||||
## 7. Service Terms
|
||||
|
||||
### Payment Terms
|
||||
|
||||
{{payment_terms}}
|
||||
|
||||
### Deliverable Acceptance
|
||||
|
||||
Deliverables will be considered accepted upon:
|
||||
- Completion according to specifications
|
||||
- Review and approval by client
|
||||
- Any requested revisions completed
|
||||
|
||||
### Intellectual Property
|
||||
|
||||
All deliverables and work products will be owned by {{client_name}} upon full payment.
|
||||
|
||||
---
|
||||
|
||||
## 8. Risks and Considerations
|
||||
|
||||
### Cost of Inaction
|
||||
|
||||
{{cost_of_inaction}}
|
||||
|
||||
---
|
||||
|
||||
## 9. Confidentiality
|
||||
|
||||
### Confidentiality Clause
|
||||
|
||||
**Background**: This clause protects sensitive information shared during the project.
|
||||
|
||||
**What it does**: Both parties agree to keep project information confidential.
|
||||
|
||||
**Purpose**: Protects proprietary information, business strategies, trade secrets, and sensitive data.
|
||||
|
||||
**Terms**:
|
||||
|
||||
Both parties agree to:
|
||||
|
||||
- Keep all project-related information confidential
|
||||
- Not disclose project details to third parties without written consent
|
||||
- Use confidential information solely for project purposes
|
||||
- Return or destroy confidential materials upon project completion or termination
|
||||
- Maintain confidentiality obligations even after project completion
|
||||
|
||||
**Exceptions**:
|
||||
- Information already publicly known
|
||||
- Information independently developed
|
||||
- Information required by law to be disclosed
|
||||
|
||||
**Duration**: Confidentiality obligations shall remain in effect for [X] years after project completion.
|
||||
|
||||
---
|
||||
|
||||
## 10. Not to Exceed Clause
|
||||
|
||||
### Budget Cap
|
||||
|
||||
**Background**: This clause sets a maximum budget limit.
|
||||
|
||||
**What it does**: States that total costs will not exceed a specified amount without prior written approval.
|
||||
|
||||
**Purpose**:
|
||||
- Protects both parties from unexpected cost overruns
|
||||
- Ensures budget control
|
||||
- **Prevents scope creep** - Any work beyond the original scope requires approval and may affect the budget cap
|
||||
|
||||
**Terms**:
|
||||
|
||||
- Total project costs shall not exceed **{{not_to_exceed_amount}}** without prior written approval from {{client_name}}
|
||||
- Any work that would exceed this amount must be approved in advance
|
||||
- If additional work is needed, a change order must be signed before proceeding
|
||||
- This cap includes all fees, expenses, and costs related to the project
|
||||
|
||||
**Change Orders and Scope Control**:
|
||||
- Any changes to scope that affect cost must be documented in a written change order
|
||||
- Change orders must be signed by both parties before work begins
|
||||
- Change orders may adjust the not-to-exceed amount if agreed upon
|
||||
- **Scope creep prevention**: Work outside the original scope (as defined in Section 2) requires a change order and approval before proceeding
|
||||
- This clause helps prevent gradual expansion of project scope without proper authorization
|
||||
|
||||
---
|
||||
|
||||
## 11. Terms and Conditions
|
||||
|
||||
### Work Initiation
|
||||
|
||||
**When work begins**: {{work_initiation_date_or_condition}}
|
||||
|
||||
**Background**: This clause specifies exactly when the service provider is authorized to begin work.
|
||||
|
||||
**What it does**: Defines the start date or conditions that must be met before work begins.
|
||||
|
||||
**Purpose**:
|
||||
- Prevents unauthorized work before agreement is fully executed
|
||||
- Establishes clear timeline expectations
|
||||
- Protects both parties by ensuring work only begins after proper authorization
|
||||
|
||||
**Initiation conditions** (select applicable):
|
||||
- Upon full execution of this agreement (signatures from both parties)
|
||||
- On a specific date: {{specific_start_date}}
|
||||
- Upon receipt of initial payment/deposit
|
||||
- Upon written notice from {{client_name}}
|
||||
- Other: {{custom_initiation_condition}}
|
||||
|
||||
### Project Initiation
|
||||
|
||||
This project is initiated upon approval of the project pitch. Project initiation is considered complete upon stakeholder approval.
|
||||
|
||||
### Changes and Modifications
|
||||
|
||||
Any changes to scope, timeline, or investment must be agreed upon in writing by all parties.
|
||||
|
||||
### Termination
|
||||
|
||||
Either party may terminate this agreement with [X] days written notice. Upon termination, payment is due for work completed to date.
|
||||
|
||||
### Dispute Resolution
|
||||
|
||||
**Background**: Defines how conflicts will be resolved if they arise.
|
||||
|
||||
**What it does**: Establishes the process for handling disagreements.
|
||||
|
||||
**Purpose**: Provides a clear path for resolving disputes without costly litigation when possible.
|
||||
|
||||
**Method**: {{dispute_resolution_method}} (mediation/arbitration/litigation)
|
||||
|
||||
**Location**: {{dispute_resolution_location}}
|
||||
|
||||
Any disputes arising from this agreement shall be resolved through {{dispute_resolution_method}} in {{dispute_resolution_location}}.
|
||||
|
||||
---
|
||||
|
||||
### Governing Law and Jurisdiction
|
||||
|
||||
**Background**: Determines which laws apply and where legal proceedings would take place.
|
||||
|
||||
**What it does**: Specifies the legal framework and court system that governs the agreement.
|
||||
|
||||
**Purpose**: Provides legal clarity and predictability for both parties.
|
||||
|
||||
**Governing Law**: This agreement shall be governed by and construed in accordance with the laws of {{governing_jurisdiction}}.
|
||||
|
||||
**Jurisdiction**: Any legal proceedings arising from this agreement shall be subject to the exclusive jurisdiction of the courts of {{governing_jurisdiction}}.
|
||||
|
||||
**Contract Language**: This agreement is executed in {{contract_language}}. In case of translation, the {{contract_language}} version shall prevail.
|
||||
|
||||
---
|
||||
|
||||
## 12. Approval
|
||||
|
||||
**Client/Owner Approval**:
|
||||
|
||||
Signature: _________________
|
||||
Name: {{client_name}}
|
||||
Date: _______________
|
||||
|
||||
**Service Provider Approval**:
|
||||
|
||||
Signature: _________________
|
||||
Name: {{service_provider_name}}
|
||||
Date: _______________
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Reference Documents
|
||||
|
||||
- Project Pitch: `docs/1-project-brief/pitch.md`
|
||||
- Project Brief: (To be created after agreement approval)
|
||||
|
||||
---
|
||||
|
||||
*This service agreement is based on the project pitch dated {{date}}.*
|
||||
|
||||
|
|
@ -0,0 +1,188 @@
|
|||
# Project Signoff Document
|
||||
|
||||
**Project**: {{project_name}}
|
||||
**Date**: {{date}}
|
||||
**Department/Team**: {{department_name}}
|
||||
**Project Owner**: {{project_owner}}
|
||||
**Document Language**: {{contract_language}}
|
||||
**Governing Jurisdiction**: {{governing_jurisdiction}} (if applicable)
|
||||
|
||||
---
|
||||
|
||||
> **Document Philosophy**: This signoff document is designed to be simple, fair, and clear - providing reliable terms that support successful project execution and clear accountability.
|
||||
|
||||
---
|
||||
|
||||
## 1. Project Overview
|
||||
|
||||
### The Realization
|
||||
|
||||
{{realization}}
|
||||
|
||||
### Recommended Solution
|
||||
|
||||
{{recommended_solution}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Goals and Success Metrics
|
||||
|
||||
### What We're Trying to Accomplish
|
||||
|
||||
{{goals}}
|
||||
|
||||
### Success Metrics
|
||||
|
||||
{{success_metrics}}
|
||||
|
||||
### How We'll Measure Success
|
||||
|
||||
{{measurement_approach}}
|
||||
|
||||
### Key Performance Indicators (KPIs)
|
||||
|
||||
{{kpis}}
|
||||
|
||||
---
|
||||
|
||||
## 3. Budget and Resources
|
||||
|
||||
### Budget Allocation
|
||||
|
||||
**Total Budget**: {{total_budget}}
|
||||
|
||||
**Budget Breakdown** (if applicable):
|
||||
{{budget_breakdown}}
|
||||
|
||||
### Resources Needed
|
||||
|
||||
{{resources_needed}}
|
||||
|
||||
### Not-to-Exceed Budget Cap
|
||||
|
||||
{{not_to_exceed_budget}}
|
||||
|
||||
---
|
||||
|
||||
## 4. Ownership and Responsibility
|
||||
|
||||
### Project Owner
|
||||
|
||||
{{project_owner}}
|
||||
|
||||
### Process Owner
|
||||
|
||||
{{process_owner}}
|
||||
|
||||
### Key Stakeholders
|
||||
|
||||
{{key_stakeholders}}
|
||||
|
||||
### Decision-Making Authority
|
||||
|
||||
{{decision_making_authority}}
|
||||
|
||||
---
|
||||
|
||||
## 5. Approval and Sign-Off
|
||||
|
||||
### Who Needs to Approve
|
||||
|
||||
{{approvers_list}}
|
||||
|
||||
### Approval Stages
|
||||
|
||||
{{approval_stages}}
|
||||
|
||||
### Sign-Off Process
|
||||
|
||||
{{signoff_process}}
|
||||
|
||||
### Timeline for Approval
|
||||
|
||||
{{approval_timeline}}
|
||||
|
||||
---
|
||||
|
||||
## 6. Timeline and Milestones
|
||||
|
||||
### Key Milestones
|
||||
|
||||
{{key_milestones}}
|
||||
|
||||
### Delivery Dates
|
||||
|
||||
{{delivery_dates}}
|
||||
|
||||
### Critical Deadlines
|
||||
|
||||
{{critical_deadlines}}
|
||||
|
||||
---
|
||||
|
||||
## 7. Optional Sections
|
||||
|
||||
### Risks and Considerations (Optional)
|
||||
|
||||
{{risks_and_considerations}}
|
||||
|
||||
### Confidentiality (Optional)
|
||||
|
||||
{{confidentiality_requirements}}
|
||||
|
||||
### The Path Forward (Optional - High-Level Overview)
|
||||
|
||||
{{path_forward_high_level}}
|
||||
|
||||
---
|
||||
|
||||
## 8. Approval and Signoff
|
||||
|
||||
This document serves as formal approval to proceed with the project as outlined above.
|
||||
|
||||
**Stakeholder Signoffs**:
|
||||
|
||||
**Project Sponsor**:
|
||||
|
||||
Name: _________________
|
||||
Signature: _________________
|
||||
Date: _______________
|
||||
|
||||
**Budget Approver**:
|
||||
|
||||
Name: _________________
|
||||
Signature: _________________
|
||||
Date: _______________
|
||||
|
||||
**Project Owner**:
|
||||
|
||||
Name: {{project_owner}}
|
||||
Signature: _________________
|
||||
Date: _______________
|
||||
|
||||
---
|
||||
|
||||
## 9. Next Steps
|
||||
|
||||
Upon signoff:
|
||||
1. Proceed to full Project Brief development
|
||||
2. Execute work plan as outlined above
|
||||
3. Deliverables will be provided according to the agreed timeline
|
||||
|
||||
### Changes and Modifications
|
||||
|
||||
Any changes to scope, timeline, or investment must be agreed upon by all signatories.
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Reference Documents
|
||||
|
||||
- Project Pitch: `docs/1-project-brief/pitch.md`
|
||||
- Project Brief: (To be created after signoff)
|
||||
|
||||
---
|
||||
|
||||
*This signoff document is based on the project pitch dated {{date}}.*
|
||||
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
# Step 1: Start Alignment & Signoff
|
||||
|
||||
## Purpose
|
||||
|
||||
Begin creating an alignment document to get stakeholders aligned and secure commitment before starting the project.
|
||||
|
||||
---
|
||||
|
||||
## Context for Agent
|
||||
|
||||
You are helping the user create an alignment document (pitch) that presents their idea in the best possible light. This is a **collaborative process** - you're working together to make their idea shine, not to criticize or challenge it.
|
||||
|
||||
**Important**: Don't be surprised if their ideas grow and improve as you go through the process. That's natural and good!
|
||||
|
||||
**Your Role**: You can handle the full experience - from understanding their situation to creating the alignment document and securing signoff. You're here to:
|
||||
- **Clarify their situation** - Are they a consultant? Manager? Founder? Doing it themselves?
|
||||
- **Help them understand** - Do they need alignment & signoff, or can they go straight to Project Brief?
|
||||
- **Guide through alignment & signoff** - Once we know they need alignment, help them create it efficiently
|
||||
|
||||
**Your Style**: Professional, direct, and efficient. You're nice but you play no games - you're here to get things done. If they need emotional support, they can go to Mimir. You focus on clarity and results.
|
||||
|
||||
**Purpose of alignment & signoff**: You're building something that makes the world a better place, and you need others involved. This alignment document helps you get alignment on:
|
||||
- **The Idea** - What are we building?
|
||||
- **Why** - Why should it be done?
|
||||
- **What** - What does it contain?
|
||||
- **How** - How will it be executed?
|
||||
- **Budget** - What resources are needed?
|
||||
- **Commitment** - What are we willing to commit?
|
||||
|
||||
**Workflow**:
|
||||
1. **Understand their situation** - Ask clarifying questions
|
||||
2. **Determine if alignment & signoff is needed** - Do they need alignment, or can they proceed directly?
|
||||
3. Create and refine the alignment document (we can iterate and negotiate)
|
||||
4. Share with stakeholders for review and feedback
|
||||
5. Update the alignment document until everyone is on board
|
||||
6. Once accepted and everyone is aligned
|
||||
7. Generate signoff document (contract/service agreement/signoff) to secure commitment
|
||||
8. Then proceed to the full Project Brief workflow
|
||||
|
||||
**Key Principle**: WDS helps with alignment - we'll work together to get everyone on the same page. Negotiation and iteration are welcome during the alignment phase. Once everyone accepts, we'll formalize the commitment with a signoff document.
|
||||
|
||||
---
|
||||
|
||||
## Opening Framing
|
||||
|
||||
**First, understand their situation** (if not already clear):
|
||||
|
||||
Before diving into the pitch, help them clarify their situation:
|
||||
|
||||
"I'd like to understand your situation first. This will help me guide you efficiently.
|
||||
|
||||
**Are you:**
|
||||
- A consultant proposing a solution to a client?
|
||||
- A business owner hiring consultants/suppliers to build software?
|
||||
- A manager or employee seeking approval for an internal project?
|
||||
- Or doing this yourself and don't need stakeholder alignment?
|
||||
|
||||
Let's get clear on what you need so we can move forward."
|
||||
|
||||
**If they need alignment & signoff** (consultant, business owner, manager/employee):
|
||||
|
||||
"Good. We're going to work together to create an alignment document that presents your idea clearly and gets stakeholders aligned.
|
||||
|
||||
This alignment document will help you get alignment on your idea, why it matters, what it contains, how it will be executed, the budget needed, and the commitment required. We can iterate until everyone is on board. Once they accept it, we'll create a signoff document to secure the commitment, then proceed to the full Project Brief.
|
||||
|
||||
You can start anywhere - with something you've realized needs attention, or with a solution you have in mind. I'll guide us through the important questions in whatever order makes sense for your thinking."
|
||||
|
||||
**If they're doing it themselves** (don't need alignment & signoff):
|
||||
|
||||
"That's great! If you have full autonomy and don't need stakeholder alignment, you can skip alignment & signoff and go straight to the Project Brief workflow. Would you like me to help you start the Project Brief instead?"
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After the opening framing, proceed to:
|
||||
→ `step-01.5-extract-communications.md` (Optional - extract info from communications)
|
||||
|
||||
Then continue to:
|
||||
→ `step-02-explore-sections.md`
|
||||
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
# Step 1.5: Extract Information from Communications and Documents (Optional)
|
||||
|
||||
## Purpose
|
||||
|
||||
Gather existing context from client/stakeholder communications, emails, chats, and documents to inform the pitch.
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Ask the user** if they have any relevant communications or documents:
|
||||
|
||||
"Do you have any email threads, chat conversations, documents, or other materials from clients or stakeholders about this project?
|
||||
|
||||
If you do, I can extract key information from them - things like:
|
||||
- Realizations or observations they've mentioned
|
||||
- Requirements they've discussed
|
||||
- Concerns or questions they've raised
|
||||
- Context about the project
|
||||
- Existing documentation or specifications
|
||||
|
||||
This can help us create a more informed pitch. You can paste the content here, share the communications, or upload documents, and I'll extract the relevant information."
|
||||
|
||||
---
|
||||
|
||||
## If User Provides Communications or Documents
|
||||
|
||||
**What to extract**:
|
||||
- **Realizations mentioned** - What have stakeholders realized or observed?
|
||||
- **Requirements discussed** - What do they need or want?
|
||||
- **Concerns raised** - What are their worries or questions?
|
||||
- **Context** - Background information about the project
|
||||
- **Stakeholder perspectives** - Different viewpoints or needs
|
||||
- **Timeline or urgency** - Any deadlines or timing mentioned
|
||||
- **Budget or constraints** - Any resource limitations discussed
|
||||
- **Existing specifications** - Any requirements or specs already documented
|
||||
- **Previous discussions** - Key points from past conversations
|
||||
|
||||
**How to extract**:
|
||||
1. Read through the communications carefully
|
||||
2. Identify key themes and information
|
||||
3. Extract relevant details that inform the pitch sections
|
||||
4. Note any contradictions or different perspectives
|
||||
5. Summarize findings: "From these communications, I'm seeing..."
|
||||
|
||||
**Use extracted information**:
|
||||
- Inform The Realization section (what realizations or observations are mentioned)
|
||||
- Inform Why It Matters (who is experiencing issues and why it matters)
|
||||
- Inform Our Commitment (any budget/resource discussions)
|
||||
- Inform Cost of Inaction (any urgency or consequences mentioned)
|
||||
- Add context throughout the pitch
|
||||
|
||||
**Don't**:
|
||||
- Copy entire communications or documents verbatim
|
||||
- Include personal or irrelevant details
|
||||
- Overwhelm with too much detail
|
||||
- Use information that's clearly outdated
|
||||
- Include sensitive information that shouldn't be in the pitch
|
||||
|
||||
---
|
||||
|
||||
## If User Doesn't Have Communications or Documents
|
||||
|
||||
**That's fine** - Simply acknowledge and move on:
|
||||
|
||||
"No problem! We'll work with what you know. Let's start exploring the project together."
|
||||
|
||||
Then proceed to exploring sections.
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After extracting information (or if user doesn't have communications), proceed to:
|
||||
→ `step-02-explore-sections.md`
|
||||
|
||||
**Note**: Use the extracted information to inform your questions as you explore each section.
|
||||
|
||||
|
|
@ -0,0 +1,159 @@
|
|||
# Step 2: Explore Pitch Sections
|
||||
|
||||
## Purpose
|
||||
|
||||
Guide the user through exploring all pitch sections in a natural, collaborative flow.
|
||||
|
||||
---
|
||||
|
||||
## Pitch Structure (All Sections to Cover)
|
||||
|
||||
**Inspired by proven frameworks**: Customer-Problem-Solution, Value Proposition Canvas, Problem-Agitate-Solve, Business Case Framework
|
||||
|
||||
The pitch should eventually cover these 10 sections:
|
||||
|
||||
1. **The Realization** - What we've realized needs attention (PAS: Problem)
|
||||
2. **Why It Matters** - Why this matters and who we help (Value Prop Canvas: Customer Profile + Impact)
|
||||
3. **How We See It Working** - Brief overview of the solution approach (CPS: Solution)
|
||||
4. **Paths We Explored** - 2-3 solution options we considered
|
||||
5. **Recommended Solution** - Preferred approach and why (CPS: Solution)
|
||||
6. **The Path Forward** - How the work will be done (WDS phases and practical approach)
|
||||
7. **The Value We'll Create** - What happens if we DO build this (Business Case: Return)
|
||||
8. **Cost of Inaction** - What happens if we DON'T build this (PAS: Agitate / Business Case: Risk)
|
||||
9. **Our Commitment** - Resources needed and potential risks (Business Case: Cost + Risk)
|
||||
10. **Summary** - Summary of key points
|
||||
|
||||
**Note**: You don't need to cover these in this exact order. Follow the user's natural thinking flow. The frameworks are guides, not rigid rules.
|
||||
|
||||
---
|
||||
|
||||
## Detect Starting Point
|
||||
|
||||
**Ask**: "Where would you like to start? Are you seeing a problem that needs solving, or do you have a solution in mind?"
|
||||
|
||||
**If user starts with problem**:
|
||||
- Explore the problem first
|
||||
- Then naturally move to "who is affected"
|
||||
- Then explore solutions
|
||||
|
||||
**If user starts with solution**:
|
||||
- Capture the solution idea
|
||||
- Then explore "what problem does this solve?"
|
||||
- Then explore "who is affected"
|
||||
- Then explore other possible approaches
|
||||
|
||||
**If user starts elsewhere**:
|
||||
- Follow their lead
|
||||
- Guide them through remaining sections naturally
|
||||
|
||||
---
|
||||
|
||||
## Guiding Principles
|
||||
|
||||
**When responding to user ideas or questions, follow this pattern:**
|
||||
|
||||
1. **Acknowledge** - "I hear you asking about..." or "That's an interesting idea..."
|
||||
2. **Summarize** - "So you're thinking that..." or "What I'm understanding is..."
|
||||
3. **Confirm understanding** - "Is that right?" or "Am I understanding correctly?"
|
||||
4. **Then explore solutions** - Only after confirming understanding, offer options or suggestions
|
||||
|
||||
**Never jump straight to bullet lists or solutions.** Always acknowledge, summarize, and confirm understanding first.
|
||||
|
||||
**Collaborative, not interrogative**:
|
||||
- "Let's explore this together..."
|
||||
- "What I'm hearing is..."
|
||||
- "This is interesting - tell me more about..."
|
||||
- "How do you see this working?"
|
||||
|
||||
**Allow ideas to evolve**:
|
||||
- If user's idea changes as they talk, that's good!
|
||||
- Reflect back: "It sounds like your thinking is evolving - that's great!"
|
||||
- Update understanding as you go
|
||||
|
||||
**Natural flow**:
|
||||
- Don't force a rigid sequence
|
||||
- Follow the user's thinking
|
||||
- Guide them to cover all sections, but in whatever order makes sense
|
||||
|
||||
**Make it shine**:
|
||||
- Help them articulate their idea clearly
|
||||
- Find the compelling angles
|
||||
- Present it in the best light
|
||||
|
||||
---
|
||||
|
||||
## Section Exploration Guide
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md`
|
||||
|
||||
Use the section guide to explore each section as the user naturally moves through them.
|
||||
|
||||
**Important**: The Work Plan section (section 6) explains which WDS phases will be used and how the work will be done practically. This helps stakeholders understand the approach and workflow.
|
||||
|
||||
**Framework Inspiration**: This guide draws from proven frameworks:
|
||||
- **Customer-Problem-Solution (CPS)** - Clear structure
|
||||
- **Value Proposition Canvas** - Understanding customer needs
|
||||
- **Problem-Agitate-Solve (PAS)** - Natural flow
|
||||
- **Business Case Framework** - Investment and consequences
|
||||
|
||||
---
|
||||
|
||||
## Best Practice: Realization Section with Evidence
|
||||
|
||||
**When exploring "The Realization" section**, help the user identify and confirm the realization with evidence:
|
||||
|
||||
### Step 1: Identify the Realization
|
||||
- What have you realized needs attention?
|
||||
- What observation or challenge are you seeing?
|
||||
- What opportunity is being missed?
|
||||
|
||||
### Step 2: Confirm It's Real
|
||||
- Is there evidence that supports this realization?
|
||||
- Do stakeholders recognize this as real?
|
||||
- Does this matter to stakeholders?
|
||||
|
||||
### Step 3: Gather Evidence
|
||||
|
||||
**Help them identify both types of evidence:**
|
||||
|
||||
**Soft Evidence** (qualitative indicators):
|
||||
- **Testimonials**: "Do you have customer feedback or testimonials about this?"
|
||||
- **Complaints**: "What complaints or support tickets mention this?"
|
||||
- **Observations**: "What patterns have you observed?"
|
||||
- **Interviews**: "What do user interviews or conversations reveal?"
|
||||
- **Indications**: "What signs indicate this is a problem?"
|
||||
|
||||
**Hard Evidence** (quantitative data):
|
||||
- **Statistics**: "Do you have numbers or percentages?"
|
||||
- **Analytics**: "What do analytics or usage data show?"
|
||||
- **Surveys**: "Have you run surveys or tests?"
|
||||
- **Logs**: "What do server logs or error reports indicate?"
|
||||
- **Metrics**: "What metrics demonstrate this problem?"
|
||||
|
||||
**Best Practice**: Combine both types for maximum credibility:
|
||||
- Start with soft evidence (testimonials, complaints, observations)
|
||||
- Support with hard evidence (statistics, analytics, survey results)
|
||||
- Show the problem is real, measurable, and matters to stakeholders
|
||||
|
||||
**Example of combining evidence:**
|
||||
> "Our customers consistently report frustration with checkout (testimonials). Analytics confirm: 45% abandon checkout, taking 12 minutes on average - 3x longer than industry standard (statistics). Support tickets show 60% of complaints are about checkout complexity (complaints), and our survey found 78% rated it as 'difficult' (survey results)."
|
||||
|
||||
**If they don't have evidence yet:**
|
||||
- That's okay - acknowledge this
|
||||
- Propose gathering evidence as part of the project
|
||||
- Use stakeholder conversations as initial evidence
|
||||
- Reference similar problems in the industry
|
||||
|
||||
**Why evidence matters:**
|
||||
- Stakeholders recognize the problem exists
|
||||
- The urgency is clear
|
||||
- Budget approval is easier
|
||||
- The case for action is compelling
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring all sections (in whatever order made sense), proceed to:
|
||||
→ `step-03-synthesize.md`
|
||||
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
# Step 3: Synthesize Alignment Document
|
||||
|
||||
## Purpose
|
||||
|
||||
Crystallize all explored sections into a clear, compelling alignment document (pitch).
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**After covering all sections** (in whatever order made sense):
|
||||
|
||||
1. **Reflect back** what you've captured
|
||||
2. **Help crystallize** into a clear, compelling narrative using framework thinking:
|
||||
- **Realization → Why It Matters → How We See It Working → Value We'll Create**
|
||||
- **Realization → Agitate (Cost of Inaction) → Solve (Solution) → Commitment**
|
||||
3. **Ask**: "Does this capture your alignment document? Anything you'd like to adjust?"
|
||||
4. **Confirm**: "Does this present your idea in the best light?"
|
||||
|
||||
**Framework check**: Does the alignment document flow logically?
|
||||
- Realization is clear and evidence-backed
|
||||
- Why it matters and who we help is understood
|
||||
- Solution addresses the realization
|
||||
- Commitment is reasonable and risks acknowledged
|
||||
- Cost of inaction makes the case
|
||||
- Value we'll create justifies the commitment
|
||||
|
||||
---
|
||||
|
||||
## Create Alignment Document
|
||||
|
||||
**Output file**: `docs/1-project-brief/pitch.md` (deliverable name: "pitch")
|
||||
|
||||
**Format**: Clear, brief, readable in 2-3 minutes
|
||||
|
||||
**Structure**: Use the 10-section structure covered in the exploration
|
||||
|
||||
**Template reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/pitch.template.md`
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After creating the pitch document, proceed to:
|
||||
→ `step-04-present-for-approval.md` (Present pitch for stakeholder review and approval)
|
||||
|
||||
**Note**: The agreement document (contract/service agreement/signoff) will be generated AFTER the pitch is approved, allowing for changes and iterations during the pitch phase.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,89 @@
|
|||
# Step 4: Present Alignment Document for Approval
|
||||
|
||||
## Purpose
|
||||
|
||||
Present the completed alignment document and guide user on next steps.
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Present the alignment document for review and approval**:
|
||||
|
||||
"I've created your alignment document at `docs/1-project-brief/pitch.md`.
|
||||
|
||||
This alignment document (pitch) is ready to share with your stakeholders. It's designed to be clear, brief, and compelling - readable in just 2-3 minutes.
|
||||
|
||||
**Next steps**:
|
||||
1. Share the alignment document with stakeholders for review
|
||||
2. Gather their feedback - we can negotiate and make changes
|
||||
3. Update the alignment document until everyone is on board
|
||||
4. Once the alignment document is accepted and everyone is aligned on the idea, why, what, how, budget, and commitment
|
||||
5. **After acceptance**, I'll generate the signoff document (contract/service agreement/signoff) to secure the commitment
|
||||
6. Then we'll proceed to create the full Project Brief
|
||||
|
||||
**Remember**: The alignment phase is collaborative - we can negotiate and iterate until everyone is on the same page. The signoff document comes after acceptance to formalize the commitment. WDS has your back - we'll help you get alignment and secure commitment before starting the work!
|
||||
|
||||
Would you like to:
|
||||
- Review the alignment document together and make any adjustments before sharing?
|
||||
- Proceed to share it with stakeholders for feedback?
|
||||
- Make changes based on stakeholder feedback?
|
||||
- Or something else?"
|
||||
|
||||
---
|
||||
|
||||
## After Approval
|
||||
|
||||
**Once the alignment document is accepted**, proceed to generate the signoff document:
|
||||
|
||||
**Next Step**: Generate Signoff Document
|
||||
→ `step-03.5-generate-contract.md` (Generate contract, service agreement, or signoff)
|
||||
|
||||
**Why after acceptance**:
|
||||
- The alignment phase allows for negotiation and iteration
|
||||
- Stakeholders can review, provide feedback, and request modifications
|
||||
- Once accepted, everyone is aligned on the project
|
||||
- Then the signoff document formalizes the commitment
|
||||
|
||||
**After signoff document is finalized**:
|
||||
- Project initiation is complete ✅
|
||||
- Proceed to full Project Brief workflow:
|
||||
→ `src/modules/wds/workflows/1-project-brief/project-brief/complete/workflow.md` (Full Project Brief)
|
||||
|
||||
The alignment document provides the foundation and context for the detailed Project Brief work. With stakeholder acceptance secured and commitment formalized, you're ready to dive into the comprehensive strategic planning.
|
||||
|
||||
---
|
||||
|
||||
## State Update
|
||||
|
||||
Update frontmatter of output file:
|
||||
|
||||
```yaml
|
||||
stepsCompleted:
|
||||
- 'step-01-start.md'
|
||||
- 'step-01.5-extract-communications.md' (if used)
|
||||
- 'step-02-explore-sections.md'
|
||||
- 'step-03-synthesize.md'
|
||||
- 'step-03.5-generate-contract.md' (if used)
|
||||
- 'step-04-present-for-approval.md'
|
||||
status: 'complete'
|
||||
pitch:
|
||||
realization: '[captured realization]'
|
||||
why_it_matters: '[why it matters and who we help]'
|
||||
how_we_see_it_working: '[solution approach]'
|
||||
paths_we_explored: '[options explored]'
|
||||
recommended_solution: '[preferred approach]'
|
||||
path_forward: '[WDS phases and practical workflow]'
|
||||
value_we_create: '[benefits of building, ambition, success metrics]'
|
||||
cost_of_inaction: '[consequences of not building]'
|
||||
our_commitment: '[resources needed and potential risks]'
|
||||
summary: '[summary of key points]'
|
||||
pitch_statement: '[synthesized pitch narrative]'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Alignment & Signoff workflow complete** - Ready for stakeholder approval!
|
||||
|
||||
**After approval**: Project initiation is complete. Proceed to full Project Brief.
|
||||
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
# Substep 01: Understand Situation
|
||||
|
||||
**Purpose**: Clarify the user's situation before proceeding
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Ask the user to clarify their situation:
|
||||
|
||||
"I'd like to understand your situation first. This will help me guide you efficiently.
|
||||
|
||||
**Are you:**
|
||||
- A consultant proposing a solution to a client?
|
||||
- A business owner hiring consultants/suppliers to build software?
|
||||
- A manager or employee seeking approval for an internal project?
|
||||
- Or doing this yourself and don't need stakeholder alignment?
|
||||
|
||||
Let's get clear on what you need so we can move forward."
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After understanding their situation:
|
||||
→ `02-determine-if-needed.md`
|
||||
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
# Substep 02: Determine If Alignment & Signoff Is Needed
|
||||
|
||||
**Purpose**: Determine if user needs alignment & signoff or can proceed directly
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Based on the user's situation, determine the path:
|
||||
|
||||
**If they need alignment & signoff** (consultant, business owner, manager/employee):
|
||||
|
||||
"Good. We're going to work together to create an alignment document that presents your idea clearly and gets stakeholders aligned.
|
||||
|
||||
This alignment document will help you get alignment on your idea, why it matters, what it contains, how it will be executed, the budget needed, and the commitment required. We can iterate until everyone is on board. Once they accept it, we'll create a signoff document to secure the commitment, then proceed to the full Project Brief.
|
||||
|
||||
You can start anywhere - with something you've realized needs attention, or with a solution you have in mind. I'll guide us through the important questions in whatever order makes sense for your thinking."
|
||||
|
||||
**If they're doing it themselves** (don't need alignment & signoff):
|
||||
|
||||
"That's great! If you have full autonomy and don't need stakeholder alignment, you can skip alignment & signoff and go straight to the Project Brief workflow. Would you like me to help you start the Project Brief instead?"
|
||||
|
||||
---
|
||||
|
||||
## Decision Point
|
||||
|
||||
**If they need alignment & signoff**:
|
||||
→ `03-offer-extract-communications.md` (same folder)
|
||||
|
||||
**If they're doing it themselves**:
|
||||
→ Route to Project Brief workflow
|
||||
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Substep 03: Offer to Extract Information from Communications
|
||||
|
||||
**Purpose**: Offer optional step to extract information from existing communications/documents
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Ask if they have relevant communications or documents:
|
||||
|
||||
"Do you have any email threads, chat conversations, documents, or other materials from clients or stakeholders about this project?
|
||||
|
||||
If you do, I can extract key information from them - things like:
|
||||
- Realizations or observations they've mentioned
|
||||
- Requirements they've discussed
|
||||
- Concerns or questions they've raised
|
||||
- Context about the project
|
||||
- Existing documentation or specifications
|
||||
|
||||
This can help us create a more informed alignment document. You can paste the content here, share the communications, or upload documents, and I'll extract the relevant information."
|
||||
|
||||
---
|
||||
|
||||
## Decision Point
|
||||
|
||||
**If user provides communications/documents**:
|
||||
→ `04-extract-info.md` (same folder)
|
||||
|
||||
**If user doesn't have any or skips**:
|
||||
→ `05-detect-starting-point.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Substep 04: Extract Information from Communications
|
||||
|
||||
**Purpose**: Extract key information from provided communications/documents
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Extract relevant information from the communications/documents:
|
||||
|
||||
**What to extract**:
|
||||
- **Realizations mentioned** - What have stakeholders realized or observed?
|
||||
- **Requirements discussed** - What do they need or want?
|
||||
- **Concerns raised** - What questions or concerns have they expressed?
|
||||
- **Context** - Background information about the project
|
||||
- **Timeline or urgency** - Any deadlines or time-sensitive information
|
||||
- **Budget or constraints** - Financial or resource limitations mentioned
|
||||
|
||||
**Use extracted information**:
|
||||
- Inform The Realization section (what realizations or observations are mentioned)
|
||||
- Inform Why It Matters (who is experiencing issues and why it matters)
|
||||
- Inform Our Commitment (any budget/resource discussions)
|
||||
- Inform Cost of Inaction (any urgency or consequences mentioned)
|
||||
- Add context throughout the alignment document
|
||||
|
||||
**Don't**:
|
||||
- Copy entire communications or documents verbatim
|
||||
- Include personal or irrelevant details
|
||||
- Overwhelm with too much detail
|
||||
- Use information that's clearly outdated
|
||||
- Include sensitive information that shouldn't be in the alignment document
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After extracting information:
|
||||
→ `05-detect-starting-point.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
# Substep 05: Detect Starting Point
|
||||
|
||||
**Purpose**: Determine where the user wants to start exploring sections
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Ask where they'd like to start:
|
||||
|
||||
"Where would you like to start? Have you realized something that needs attention, or do you have a solution in mind?"
|
||||
|
||||
---
|
||||
|
||||
## Decision Point
|
||||
|
||||
**If user starts with realization**:
|
||||
- Explore the realization first
|
||||
- Then naturally move to "why it matters" and "who we help"
|
||||
- Then explore solutions
|
||||
→ `../02-explore-sections/06-explore-realization.md`
|
||||
|
||||
**If user starts with solution**:
|
||||
- Capture the solution idea
|
||||
- Then explore "what realization does this address?"
|
||||
- Then explore "why it matters" and "who we help"
|
||||
- Then explore other possible approaches
|
||||
→ `../02-explore-sections/07-explore-solution.md`
|
||||
|
||||
**If user starts elsewhere**:
|
||||
- Follow their lead
|
||||
- Guide them through remaining sections naturally
|
||||
→ Route to appropriate section exploration micro-instruction
|
||||
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
# Substep 06: Explore The Realization
|
||||
|
||||
**Purpose**: Help user articulate what they've realized needs attention
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore the realization section with the user.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 1: The Realization)
|
||||
|
||||
**Questions to explore**:
|
||||
- "What have you realized needs attention?"
|
||||
- "What observation have you made?"
|
||||
- "What challenge are you seeing?"
|
||||
- "What evidence do you have that this is real?"
|
||||
|
||||
**Best Practice: Confirm the Realization with Evidence**
|
||||
|
||||
**Help them identify evidence:**
|
||||
|
||||
**Soft Evidence** (qualitative indicators):
|
||||
- "Do you have testimonials or complaints about this?"
|
||||
- "What have stakeholders told you?"
|
||||
- "What patterns have you observed?"
|
||||
- "What do user interviews reveal?"
|
||||
|
||||
**Hard Evidence** (quantitative data):
|
||||
- "Do you have statistics or metrics?"
|
||||
- "What do analytics show?"
|
||||
- "Have you run surveys or tests?"
|
||||
- "What do server logs or error reports indicate?"
|
||||
|
||||
**Help them combine both types** for maximum credibility.
|
||||
|
||||
**Keep it brief** - 2-3 sentences for the realization, plus 1-2 sentences of evidence
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring the realization:
|
||||
→ `08-explore-why-it-matters.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# Substep 07: Explore Solution (If Starting with Solution)
|
||||
|
||||
**Purpose**: Capture solution idea and then explore the underlying realization
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
If user starts with a solution idea:
|
||||
|
||||
1. **Capture the solution**: "Tell me about your solution idea..."
|
||||
|
||||
2. **Then explore the underlying realization**: "What realization does this solution address? What have you observed that led to this solution?"
|
||||
|
||||
3. **Then explore why it matters**: "Why does this matter? Who are we helping?"
|
||||
|
||||
4. **Then explore other approaches**: "What other ways could we approach this?"
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After capturing solution and exploring realization:
|
||||
→ `08-explore-why-it-matters.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# Substep 08: Explore Why It Matters
|
||||
|
||||
**Purpose**: Help user articulate why this matters and who we help
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore why it matters and who we help.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 2: Why It Matters)
|
||||
|
||||
**Questions to explore**:
|
||||
- "Why does this matter?"
|
||||
- "Who are we helping?"
|
||||
- "What are they trying to accomplish?" (Jobs)
|
||||
- "What are their pain points?" (Pains)
|
||||
- "What would make their life better?" (Gains)
|
||||
- "How does this affect them?"
|
||||
- "What impact will this have?"
|
||||
- "Are there different groups we're helping?"
|
||||
|
||||
**Keep it brief** - Why it matters and who we help
|
||||
|
||||
**Help them think**: Focus on the value we're adding to specific people and why that matters
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring why it matters:
|
||||
→ `09-explore-how-we-see-it-working.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# Substep 09: Explore How We See It Working
|
||||
|
||||
**Purpose**: Help user articulate how they envision the solution working
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore how they see it working.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 3: How We See It Working)
|
||||
|
||||
**Questions to explore**:
|
||||
- "How do you envision this working?"
|
||||
- "What's the general approach?"
|
||||
- "Walk me through how you see it addressing the realization"
|
||||
- "What's the core concept?"
|
||||
|
||||
**Keep it brief** - High-level overview, not detailed specifications
|
||||
|
||||
**Flexible language** - Works for software, processes, services, products, strategies
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring how it works:
|
||||
→ `10-explore-paths-we-explored.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
# Substep 10: Explore Paths We Explored
|
||||
|
||||
**Purpose**: Help user articulate alternative approaches they considered
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore paths they explored.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 4: Paths We Explored)
|
||||
|
||||
**Questions to explore**:
|
||||
- "What other ways could we approach this?"
|
||||
- "Are there alternative paths?"
|
||||
- "What options have you considered?"
|
||||
|
||||
**Keep it brief** - 2-3 paths explored briefly
|
||||
|
||||
**If user only has one path**: That's fine - acknowledge it and move on
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring paths:
|
||||
→ `11-explore-recommended-solution.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Substep 11: Explore Recommended Solution
|
||||
|
||||
**Purpose**: Help user articulate their preferred approach and why
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore the recommended solution.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 5: Recommended Solution)
|
||||
|
||||
**Questions to explore**:
|
||||
- "Which approach do you prefer?"
|
||||
- "Why this one over the others?"
|
||||
- "What makes this the right solution?"
|
||||
|
||||
**Keep it brief** - Preferred approach and key reasons
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring recommended solution:
|
||||
→ `12-explore-path-forward.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
# Substep 12: Explore The Path Forward
|
||||
|
||||
**Purpose**: Help user articulate how the work will be done
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore the path forward.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 6: The Path Forward)
|
||||
|
||||
**Purpose**: Explain how the work will be done practically - which WDS phases will be used and the workflow approach.
|
||||
|
||||
**Questions to explore**:
|
||||
- "How do you envision the work being done?"
|
||||
- "Which WDS phases do you think we'll need?"
|
||||
- "What's the practical workflow you're thinking?"
|
||||
- "Will we need user research, or do you already know your users?"
|
||||
- "Do you need technical architecture planning, or is that already defined?"
|
||||
- "What level of design detail do you need?"
|
||||
- "How will this be handed off for implementation?"
|
||||
|
||||
**Keep it brief** - High-level plan of the work approach
|
||||
|
||||
**Help them think**:
|
||||
- Which WDS phases apply (Trigger Mapping, Platform Requirements, UX Design, Design System, etc.)
|
||||
- Practical workflow (research → design → handoff, or skip research, etc.)
|
||||
- Level of detail needed
|
||||
- Handoff approach
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring path forward:
|
||||
→ `13-explore-value-we-create.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Substep 13: Explore The Value We'll Create
|
||||
|
||||
**Purpose**: Help user articulate what happens if we DO build this
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore the value we'll create.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 7: The Value We'll Create)
|
||||
|
||||
**Questions to explore**:
|
||||
- "What's our ambition? What are we striving to accomplish?"
|
||||
- "What happens if we DO build this?"
|
||||
- "What benefits would we see?"
|
||||
- "What outcomes are we expecting?"
|
||||
- "How will we measure success?"
|
||||
- "What metrics will tell us we're succeeding?"
|
||||
- "What's the value we'd create?"
|
||||
|
||||
**Best Practice: Frame as Positive Assumption with Success Metrics**
|
||||
|
||||
**Help them articulate**:
|
||||
- **Our Ambition**: What we're confidently striving to accomplish (enthusiastic, positive)
|
||||
- **Success Metrics**: How we'll measure success (specific, measurable)
|
||||
- **What Success Looks Like**: Clear outcomes (tangible results)
|
||||
- **Monitoring Approach**: How we'll track these metrics (brief)
|
||||
|
||||
**Keep it brief** - Key benefits, outcomes, and success metrics
|
||||
|
||||
**Help them think**: Positive assumption ("We're confident this will work") + clear success metrics ("Here's how we'll measure it") = enthusiastic and scientific
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring value we'll create:
|
||||
→ `14-explore-cost-of-inaction.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
# Substep 14: Explore Cost of Inaction
|
||||
|
||||
**Purpose**: Help user articulate what happens if we DON'T build this
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore cost of inaction.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 8: Cost of Inaction)
|
||||
|
||||
**Questions to explore**:
|
||||
- "What happens if we DON'T build this?"
|
||||
- "What are the risks of not acting?"
|
||||
- "What opportunities would we miss?"
|
||||
- "What's the cost of doing nothing?"
|
||||
- "What gets worse if we don't act?"
|
||||
- "What do we lose by waiting?"
|
||||
|
||||
**Keep it brief** - Key consequences of not building
|
||||
|
||||
**Can include**:
|
||||
- Financial cost (lost revenue, increased costs)
|
||||
- Opportunity cost (missed opportunities)
|
||||
- Competitive risk (competitors gaining advantage)
|
||||
- Operational impact (inefficiency, problems getting worse)
|
||||
|
||||
**Help them think**: Make the case for why we can't afford NOT to do this
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring cost of inaction:
|
||||
→ `15-explore-our-commitment.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# Substep 15: Explore Our Commitment
|
||||
|
||||
**Purpose**: Help user articulate resources needed and potential risks
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore our commitment.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 9: Our Commitment)
|
||||
|
||||
**Questions to explore**:
|
||||
- "What resources are we committing?"
|
||||
- "What's the time commitment?"
|
||||
- "What budget or team are we committing?"
|
||||
- "What dependencies exist?"
|
||||
- "What potential risks or drawbacks should we consider?"
|
||||
- "What challenges might we face?"
|
||||
|
||||
**Keep it brief** - High-level commitment and potential risks
|
||||
|
||||
**Don't force precision** - Rough estimates are fine at this stage
|
||||
|
||||
**Help them think**: Time, money, people, technology - what are we committing to make this happen? What risks or challenges should we acknowledge?
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring our commitment:
|
||||
→ `16-explore-summary.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Substep 16: Explore Summary
|
||||
|
||||
**Purpose**: Help user create a summary of key points
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
Explore the summary.
|
||||
|
||||
**Reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/section-guide.md` (Section 10: Summary)
|
||||
|
||||
**Questions to explore**:
|
||||
- "What are the key points?"
|
||||
- "What should stakeholders remember?"
|
||||
- "What's the main takeaway?"
|
||||
|
||||
**Keep it brief** - Summary of key points (let readers draw their own conclusion)
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After exploring all sections:
|
||||
→ `../03-synthesize-present/17-reflect-back.md`
|
||||
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# Substep 17: Reflect Back What You've Captured
|
||||
|
||||
**Purpose**: Reflect back understanding before synthesizing
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**After covering all sections** (in whatever order made sense):
|
||||
|
||||
Reflect back what you've captured:
|
||||
|
||||
"I've explored [list sections covered] with you. Let me reflect back what I understand:
|
||||
|
||||
- **The Realization**: [summarize their realization]
|
||||
- **Why It Matters**: [summarize why it matters and who we help]
|
||||
- **How We See It Working**: [summarize solution approach]
|
||||
- **Recommended Solution**: [summarize preferred approach]
|
||||
- **The Path Forward**: [summarize work approach]
|
||||
- **The Value We'll Create**: [summarize value and success metrics]
|
||||
- **Cost of Inaction**: [summarize consequences]
|
||||
- **Our Commitment**: [summarize resources and risks]
|
||||
- **Summary**: [summarize key points]
|
||||
|
||||
Does this capture what you want in your alignment document? Anything you'd like to adjust or clarify?"
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After reflecting back and confirming:
|
||||
→ `18-synthesize-document.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# Substep 18: Synthesize Alignment Document
|
||||
|
||||
**Purpose**: Create the alignment document from all explored sections
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**After confirming understanding**:
|
||||
|
||||
Help crystallize into a clear, compelling narrative using framework thinking:
|
||||
- **Realization → Why It Matters → How We See It Working → Value We'll Create**
|
||||
- **Realization → Agitate (Cost of Inaction) → Solve (Solution) → Commitment**
|
||||
|
||||
**Framework check**: Does the alignment document flow logically?
|
||||
- Realization is clear and evidence-backed
|
||||
- Why it matters and who we help is understood
|
||||
- Solution addresses the realization
|
||||
- Commitment is reasonable and risks acknowledged
|
||||
- Cost of inaction makes the case
|
||||
- Value we'll create justifies the commitment
|
||||
|
||||
**Create Alignment Document**
|
||||
|
||||
**Output file**: `docs/1-project-brief/pitch.md` (deliverable name: "pitch")
|
||||
|
||||
**Format**: Clear, brief, readable in 2-3 minutes
|
||||
|
||||
**Structure**: Use the 10-section structure covered in the exploration
|
||||
|
||||
**Template reference**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/pitch.template.md`
|
||||
|
||||
**Ask**: "Does this present your idea in the best light?"
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After creating the alignment document:
|
||||
→ `19-present-for-approval.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
# Substep 19: Present Alignment Document for Approval
|
||||
|
||||
**Purpose**: Present the alignment document and guide next steps
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Present the alignment document for review and approval**:
|
||||
|
||||
"I've created your alignment document at `docs/1-project-brief/pitch.md`.
|
||||
|
||||
This alignment document is ready to share with your stakeholders. It's designed to be clear, brief, and compelling - readable in just 2-3 minutes.
|
||||
|
||||
**Next steps**:
|
||||
1. Share the alignment document with stakeholders for review
|
||||
2. Gather their feedback - we can negotiate and make changes
|
||||
3. Update the alignment document until everyone is on board
|
||||
4. Once the alignment document is accepted and everyone is aligned on the idea, why, what, how, budget, and commitment
|
||||
5. **After acceptance**, I'll generate the signoff document (contract/service agreement/signoff) to secure the commitment
|
||||
6. Then we'll proceed to create the full Project Brief
|
||||
|
||||
**Remember**: The alignment phase is collaborative - we can negotiate and iterate until everyone is on the same page. The signoff document comes after acceptance to formalize the commitment. WDS has your back - we'll help you get alignment and secure commitment before starting the work!
|
||||
|
||||
Would you like to:
|
||||
- Review the alignment document together and make any adjustments before sharing?
|
||||
- Proceed to share it with stakeholders for feedback?
|
||||
- Make changes based on stakeholder feedback?
|
||||
- Or something else?"
|
||||
|
||||
---
|
||||
|
||||
## Decision Point
|
||||
|
||||
**If user wants to make changes**:
|
||||
- Update the alignment document
|
||||
- Return to this step after changes
|
||||
|
||||
**If alignment document is accepted**:
|
||||
→ `../04-generate-signoff/20-offer-signoff-document.md`
|
||||
|
||||
**If user wants to skip signoff**:
|
||||
→ Proceed to Project Brief workflow
|
||||
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
# Substep 20: Offer to Generate Signoff Document
|
||||
|
||||
**Purpose**: Offer to create signoff document after alignment acceptance
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**After the alignment document is accepted by stakeholders**, offer to create a signoff document:
|
||||
|
||||
"Great! The alignment document has been accepted and everyone is aligned on the idea, why, what, how, budget, and commitment.
|
||||
|
||||
Now let's secure this commitment with a signoff document. This will formalize what everyone has agreed to and ensure everyone stays committed to making this project happen.
|
||||
|
||||
**What type of document do you need?**
|
||||
|
||||
1. **Project Contract** - If you're a consultant and the client has approved the alignment document
|
||||
2. **Service Agreement** - If you're a founder/owner and suppliers have approved the alignment document
|
||||
3. **Project Signoff Document** - If this is an internal company project and stakeholders have approved
|
||||
- *Note: If you have an existing company signoff document format, you can upload it and I'll adapt it to match your company's format*
|
||||
4. **Skip** - If you don't need a formal document right now
|
||||
|
||||
Which applies to your situation?
|
||||
|
||||
**Remember**: WDS helps with alignment - the alignment document got everyone on the same page, and this signoff document secures the commitment before we start building something that makes the world a better place!"
|
||||
|
||||
---
|
||||
|
||||
## Decision Point
|
||||
|
||||
**If user chooses "Skip"**:
|
||||
- Acknowledge: "No problem! The alignment document is ready to share. You can always generate a signoff document later if needed."
|
||||
- Proceed to Project Brief workflow
|
||||
|
||||
**If user chooses document type**:
|
||||
→ `21-determine-business-model.md` (same folder - for external contracts)
|
||||
→ `../06-build-signoff-internal/34-build-internal-signoff.md` (for internal signoff)
|
||||
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
# Substep 21: Determine Business Model
|
||||
|
||||
**Purpose**: Determine how the service will be paid for (for external contracts)
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Before building contract sections**, determine the business model:
|
||||
|
||||
"First, let's determine the business model - how will this service be paid for? This helps us structure the contract correctly.
|
||||
|
||||
**What business model fits this project?**
|
||||
|
||||
1. **Fixed-Price Project** - Set price for a defined scope of work
|
||||
- Best for: Projects with clear deliverables and scope
|
||||
- Includes: Not-to-exceed clause, upfront payment recommended
|
||||
- Example: "$50,000 for complete website redesign with 5 pages"
|
||||
|
||||
2. **Hourly/Time-Based** - Pay for actual time worked
|
||||
- Best for: Ongoing work, uncertain scope, flexible requirements
|
||||
- Includes: Hourly rate, time tracking, optional not-to-exceed cap
|
||||
- Example: "$150/hour, estimated 200 hours"
|
||||
|
||||
3. **Retainer** - Monthly commitment with minimum hours
|
||||
- Best for: Ongoing support, regular availability needed
|
||||
- Includes: Monthly retainer amount, minimum hours, availability expectations, hourly rate for overage
|
||||
- Example: "$5,000/month retainer for 20 hours minimum, $200/hour for additional hours"
|
||||
|
||||
4. **Hybrid** - Combination of models (e.g., retainer + project work)
|
||||
- Best for: Complex arrangements with multiple work types
|
||||
- Includes: Multiple payment structures combined
|
||||
|
||||
Which model fits your situation?"
|
||||
|
||||
---
|
||||
|
||||
## After User Selects Business Model
|
||||
|
||||
**Confirm understanding**: "So you've chosen [model]. This means [brief explanation of what this means for the contract]."
|
||||
|
||||
**Note the selection**: This will determine which sections we include and how we configure payment terms, not-to-exceed, availability, etc.
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After determining business model:
|
||||
→ `../05-build-contract/22-build-section-01-project-overview.md`
|
||||
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# Substep 22: Build Section 1 - Project Overview
|
||||
|
||||
**Purpose**: Build the Project Overview section of the contract
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 1: Project Overview**
|
||||
|
||||
**Background**: Establishes what the project is about
|
||||
|
||||
**What it does**: Defines the realization and solution from the alignment document
|
||||
|
||||
**Purpose**: Sets clear expectations and context
|
||||
|
||||
**Content**: Pull from alignment document (pitch):
|
||||
- **The Realization**: {{realization}}
|
||||
- **Recommended Solution**: {{recommended_solution}}
|
||||
|
||||
**Explain to user**: "This section establishes what the project is about. I'll pull the realization and recommended solution from your alignment document."
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Project Overview:
|
||||
→ `23-build-section-02-business-model.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
# Substep 23: Build Section 2 - Business Model
|
||||
|
||||
**Purpose**: Build the Business Model section based on user's selection
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 2: Business Model**
|
||||
|
||||
**Background**: Defines how the service will be paid for - critical foundation for all payment terms
|
||||
|
||||
**What it does**: Explains the selected business model and its terms
|
||||
|
||||
**Purpose**: Sets clear expectations about payment structure, prevents misunderstandings
|
||||
|
||||
**Content**: Based on user's selection from micro-21
|
||||
|
||||
**For each business model, include**:
|
||||
|
||||
**If Fixed-Price Project**:
|
||||
- Model name: "Fixed-Price Project"
|
||||
- Description: "This contract uses a fixed-price model. The contractor commits to deliver the specified scope of work for the agreed price, regardless of actual time or costs incurred."
|
||||
- Key terms:
|
||||
- Total project price: {{total_amount}}
|
||||
- Price includes: All work within the defined scope
|
||||
- Price does NOT include: Work outside the original scope (requires change order)
|
||||
- Payment structure: {{payment_structure}} (e.g., 50% upfront, 50% on completion)
|
||||
- Not-to-exceed: Applies (see Section 10)
|
||||
|
||||
**If Hourly/Time-Based**:
|
||||
- Model name: "Hourly/Time-Based"
|
||||
- Description: "This contract uses an hourly billing model. The client pays for actual time worked at the agreed hourly rate."
|
||||
- Key terms:
|
||||
- Hourly rate: {{hourly_rate}}
|
||||
- Estimated hours: {{estimated_hours}} (if applicable)
|
||||
- Estimated total: {{estimated_total}} (hourly_rate × estimated_hours)
|
||||
- Time tracking: {{time_tracking_method}} (e.g., detailed timesheets, time tracking software)
|
||||
- Billing frequency: {{billing_frequency}} (e.g., weekly, bi-weekly, monthly)
|
||||
- Not-to-exceed: {{not_to_exceed_applies}} (optional cap - see Section 10 if applicable)
|
||||
|
||||
**If Retainer**:
|
||||
- Model name: "Monthly Retainer"
|
||||
- Description: "This contract uses a retainer model. The client pays a fixed monthly amount for a minimum number of hours, with additional hours billed at the overage rate."
|
||||
- Key terms:
|
||||
- Monthly retainer amount: {{monthly_retainer_amount}}
|
||||
- Minimum hours per month: {{minimum_hours_per_month}}
|
||||
- Effective hourly rate: {{effective_hourly_rate}} (retainer ÷ minimum hours)
|
||||
- Overage hourly rate: {{overage_hourly_rate}} (for hours beyond minimum)
|
||||
- Availability: {{availability_expectations}} (e.g., "Available during business hours, 2-3 day response time")
|
||||
- Retainer period: {{retainer_period}} (e.g., "Monthly, renewable")
|
||||
- Hour rollover: {{hour_rollover_policy}} (e.g., "Unused hours expire at month end" or "Up to X hours can roll over")
|
||||
- Billing: Retainer due {{retainer_due_date}} (e.g., "on the 1st of each month")
|
||||
|
||||
**If Hybrid**:
|
||||
- Model name: "Hybrid Model"
|
||||
- Description: "This contract combines multiple payment structures."
|
||||
- Key terms: Combine terms from each component
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Business Model section:
|
||||
→ `24-build-section-03-scope-of-work.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
# Substep 24: Build Section 3 - Scope of Work
|
||||
|
||||
**Purpose**: Build the Scope of Work section with IN scope, OUT of scope, and deliverables
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 3: Scope of Work**
|
||||
|
||||
**Background**: Defines exactly what will be delivered and what won't be
|
||||
|
||||
**What it does**: Lists path forward, deliverables, explicit IN scope, and explicit OUT of scope
|
||||
|
||||
**Purpose**: Prevents scope creep and sets clear boundaries - critical for avoiding disputes
|
||||
|
||||
**Why this matters**:
|
||||
- Most contract disputes arise from unclear scope
|
||||
- Clear IN/OUT scope prevents misunderstandings
|
||||
- Protects both parties from scope creep
|
||||
- Sets expectations upfront
|
||||
|
||||
**Content to gather**:
|
||||
1. **The Path Forward**: Pull from alignment document (path_forward) - how the work will be done
|
||||
2. **Deliverables**: Pull from alignment document (deliverables_list) - what will be delivered
|
||||
3. **IN Scope**: Ask user explicitly - "What work is explicitly included? Be specific about what's covered."
|
||||
4. **OUT of Scope**: Ask user explicitly - "What work is explicitly NOT included? What would require a change order?"
|
||||
|
||||
**Important**: Based on business model, adapt scope section:
|
||||
- **Fixed-Price**: Must have very clear IN scope and OUT of scope (critical for fixed-price - this protects both parties)
|
||||
- **Hourly**: Can be more flexible, but still define boundaries to prevent misunderstandings
|
||||
- **Retainer**: Define what types of work are included in retainer vs. project work
|
||||
- **Hybrid**: Define scope for each component separately
|
||||
|
||||
**What to ask user**:
|
||||
- "Let's be very clear about what's included and what's not. What work is explicitly IN scope for this contract?"
|
||||
- "What work is explicitly OUT of scope? What would require a change order?"
|
||||
- "Are there any assumptions about what's included that we should document?"
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Scope of Work section:
|
||||
→ `25-build-section-04-payment-terms.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
# Substep 25: Build Section 4 - Our Commitment & Payment Terms
|
||||
|
||||
**Purpose**: Build payment terms section tailored to business model
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 4: Our Commitment & Payment Terms**
|
||||
|
||||
**Background**: Financial commitment needed and payment structure - tailored to business model
|
||||
|
||||
**What it does**: States costs, payment schedule, and payment terms based on selected business model
|
||||
|
||||
**Purpose**: Clear financial expectations - transparency builds trust
|
||||
|
||||
**Why this matters**:
|
||||
- Protects supplier from non-payment risk
|
||||
- Ensures client commits financially to the project
|
||||
- Provides cash flow for supplier to deliver quality work
|
||||
- Prevents disputes about payment timing
|
||||
|
||||
**Adapt based on business model**:
|
||||
|
||||
**If Fixed-Price Project**:
|
||||
- **User options for payment structure**:
|
||||
- **Upfront payment** (recommended):
|
||||
- **50% upfront, 50% on completion**: Fair split, supplier gets commitment, client retains leverage
|
||||
- **100% upfront**: Full commitment, supplier assumes all risk, client gets best price
|
||||
- **30% upfront, 70% on completion**: Lower upfront, more risk for supplier
|
||||
- **Milestone payments**: Payments tied to specific deliverables or project phases
|
||||
- **Payment on completion**: All payment at end (risky for supplier, not recommended)
|
||||
- **Why upfront payment is fair**:
|
||||
- **Supplier assumes risk**: In fixed-price contracts, supplier commits to deliver for a set price regardless of actual costs
|
||||
- **Cost overruns are supplier's problem**: If work takes longer or costs more, supplier absorbs the loss
|
||||
- **Client gets price certainty**: Client knows exact cost upfront
|
||||
- **Upfront payment shows commitment**: Demonstrates client is serious about the project
|
||||
- **Enables quality delivery**: Supplier can invest in resources, tools, and team needed to deliver
|
||||
- **What to ask user**:
|
||||
- "For fixed-price contracts, upfront payment is fair since you're assuming the risk. Would you like 50% upfront and 50% on completion, or 100% upfront?"
|
||||
- "Upfront payment protects both parties - you show commitment, and I can deliver quality work without cash flow worries."
|
||||
- **Content**: Total project price, payment schedule, payment method, due dates, late payment terms
|
||||
|
||||
**If Hourly/Time-Based**:
|
||||
- **Payment structure**:
|
||||
- **Billing frequency**: {{billing_frequency}} (e.g., weekly, bi-weekly, monthly)
|
||||
- **Payment terms**: {{payment_terms}} (e.g., Net 15, Net 30)
|
||||
- **Time tracking**: {{time_tracking_method}} (detailed timesheets required)
|
||||
- **Invoice format**: {{invoice_format}} (itemized by date, hours, description)
|
||||
- **What to ask user**:
|
||||
- "How often would you like to be invoiced? Weekly, bi-weekly, or monthly?"
|
||||
- "What payment terms work for you? Net 15 or Net 30?"
|
||||
- **Content**: Hourly rate, billing frequency, payment terms, time tracking requirements
|
||||
|
||||
**If Retainer**:
|
||||
- **Payment structure**:
|
||||
- **Monthly retainer**: {{monthly_retainer_amount}} due {{retainer_due_date}} (e.g., "on the 1st of each month")
|
||||
- **Minimum hours**: {{minimum_hours_per_month}} hours included
|
||||
- **Overage billing**: {{overage_billing}} (e.g., "billed monthly for hours beyond minimum")
|
||||
- **Hour rollover**: {{hour_rollover_policy}}
|
||||
- **What to ask user**:
|
||||
- "When should the retainer be due each month? (e.g., 1st of the month)"
|
||||
- "How should we handle unused hours? Do they expire or can some roll over?"
|
||||
- "How should overage hours be billed? Monthly or as they occur?"
|
||||
- **Content**: Monthly retainer amount, due date, minimum hours, overage rate, rollover policy
|
||||
|
||||
**If Hybrid**:
|
||||
- **Payment structure**: Combine payment terms from each component
|
||||
- **Content**: Payment terms for each component clearly separated
|
||||
|
||||
**Content**: Pull from alignment document (our_commitment), add payment schedule and terms based on business model
|
||||
|
||||
**Fairness note**: Tailor to business model - for fixed-price emphasize upfront payment fairness, for retainer emphasize commitment and availability
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building payment terms:
|
||||
→ `26-build-section-05-timeline.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Substep 26: Build Section 5 - Timeline
|
||||
|
||||
**Purpose**: Build the Timeline section
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 5: Timeline**
|
||||
|
||||
**Background**: When work will happen
|
||||
|
||||
**What it does**: Defines schedule and milestones
|
||||
|
||||
**Purpose**: Sets expectations for delivery dates
|
||||
|
||||
**Content**: Extract from Work Plan or Investment Required from alignment document
|
||||
|
||||
**What to include**:
|
||||
- Key milestones
|
||||
- Delivery dates
|
||||
- Critical deadlines
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Timeline:
|
||||
→ `27-build-section-06-availability.md` (same folder - if Retainer model)
|
||||
→ `28-build-section-07-confidentiality.md` (same folder - if not Retainer)
|
||||
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
# Substep 27: Build Section 6 - Availability (Retainer Only)
|
||||
|
||||
**Purpose**: Build Availability section for retainer contracts
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 6: Availability** (Only for Retainer model)
|
||||
|
||||
**Background**: Defines when contractor is available for retainer work
|
||||
|
||||
**What it does**: Sets expectations for response times, working hours, availability windows
|
||||
|
||||
**Purpose**: Ensures client knows when they can expect work to be done
|
||||
|
||||
**Why this matters**:
|
||||
- Retainer clients need to know when contractor is available
|
||||
- Sets realistic expectations for response times
|
||||
- Prevents misunderstandings about availability
|
||||
|
||||
**What to include**:
|
||||
- **Business hours**: {{business_hours}} (e.g., "Monday-Friday, 9am-5pm EST")
|
||||
- **Response time**: {{response_time}} (e.g., "2-3 business days for non-urgent requests")
|
||||
- **Availability for meetings**: {{meeting_availability}} (e.g., "Available for scheduled calls during business hours")
|
||||
- **Urgent requests**: {{urgent_request_policy}} (e.g., "Urgent requests may incur additional fees")
|
||||
|
||||
**What to ask user**: "What availability expectations do you have? What response times work for you?"
|
||||
|
||||
**Content**: Define availability expectations based on retainer agreement
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Availability (if applicable):
|
||||
→ `28-build-section-07-confidentiality.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# Substep 28: Build Section 7 - Confidentiality Clause
|
||||
|
||||
**Purpose**: Build the Confidentiality clause
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 7: Confidentiality Clause**
|
||||
|
||||
**Background**: Protects sensitive information shared during the project
|
||||
|
||||
**What it does**: Requires both parties to keep project information confidential
|
||||
|
||||
**Purpose**: Protects proprietary information, business strategies, and trade secrets - mutual protection builds trust
|
||||
|
||||
**Why this matters**:
|
||||
- Without this clause, either party could share sensitive project details with competitors
|
||||
- Protects your business secrets, customer data, and strategic plans
|
||||
- Builds trust by showing mutual respect for confidentiality
|
||||
- Prevents legal disputes about information sharing
|
||||
|
||||
**User options**:
|
||||
- **Standard confidentiality** (recommended): Both parties keep all project information confidential
|
||||
- **Limited confidentiality**: Only specific information types are confidential (e.g., financial data only)
|
||||
- **One-way confidentiality**: Only one party is bound (rare, usually for public projects)
|
||||
- **Duration**: How long confidentiality lasts (typically 2-5 years, or indefinitely for trade secrets)
|
||||
- **Exceptions**: What's NOT confidential (public info, independently developed, required by law)
|
||||
|
||||
**What to ask user**: "Do you have sensitive information that needs protection? How long should confidentiality last? (Typically 2-5 years)"
|
||||
|
||||
**Content**: Standard confidentiality language (see template), customized based on user choices
|
||||
|
||||
**Fairness note**: "This protects both parties equally - your sensitive info stays private, and I'm protected too"
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Confidentiality:
|
||||
→ `29-build-section-08-not-to-exceed.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
# Substep 29: Build Section 8 - Not to Exceed Clause (Conditional)
|
||||
|
||||
**Purpose**: Build Not-to-Exceed clause based on business model
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 8: Not to Exceed Clause** (Conditional - applies to Fixed-Price and optionally Hourly)
|
||||
|
||||
**Background**: Sets maximum budget cap - only applies to certain business models
|
||||
|
||||
**What it does**: States that costs will not exceed a specified amount without approval
|
||||
|
||||
**Purpose**:
|
||||
- Protects both parties from unexpected cost overruns
|
||||
- **Prevents scope creep** - Any work beyond original scope requires approval
|
||||
- Fair budget protection for everyone
|
||||
|
||||
**When this section applies**:
|
||||
- **Fixed-Price Project**: ✅ REQUIRED - This is the project price cap
|
||||
- **Hourly/Time-Based**: ⚠️ OPTIONAL - Can include optional not-to-exceed cap if desired
|
||||
- **Retainer**: ❌ NOT APPLICABLE - Retainer already has monthly cap
|
||||
- **Hybrid**: ⚠️ CONDITIONAL - May apply to fixed-price components
|
||||
|
||||
**If applicable, include**:
|
||||
- **Why this matters**:
|
||||
- Without this clause, costs could spiral out of control (fixed-price)
|
||||
- Protects your budget from unexpected expenses
|
||||
- Prevents scope creep by requiring approval for additional work
|
||||
- Ensures contractor gets paid fairly for extra work through change orders
|
||||
- Creates clear boundaries that prevent misunderstandings
|
||||
- **User options**:
|
||||
- **Fixed budget cap**: Hard limit that cannot be exceeded without new agreement
|
||||
- **Soft cap with buffer**: Cap with small percentage buffer (e.g., 10%) for minor overruns
|
||||
- **Cap with change order process**: Cap exists, but change orders can adjust it with approval
|
||||
- **What to ask user**:
|
||||
- **For Fixed-Price**: "The not-to-exceed amount is [total_amount]. This protects both parties from cost overruns. Any work beyond the original scope requires a change order."
|
||||
- **For Hourly**: "Would you like to set an optional not-to-exceed cap? This protects your budget while still allowing flexibility."
|
||||
- **Content**:
|
||||
- **Fixed-Price**: Not-to-exceed = total project price
|
||||
- **Hourly**: Optional cap amount if user wants one
|
||||
- **Fairness note**: "This protects your budget while ensuring I get paid fairly for additional work if needed through the change order process"
|
||||
|
||||
---
|
||||
|
||||
## Decision Point
|
||||
|
||||
**If section applies**:
|
||||
→ `30-build-section-09-work-initiation.md` (same folder)
|
||||
|
||||
**If section doesn't apply** (Retainer):
|
||||
→ `30-build-section-09-work-initiation.md` (same folder - skip this section)
|
||||
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# Substep 30: Build Section 9 - Work Initiation
|
||||
|
||||
**Purpose**: Build the Work Initiation section
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 9: Work Initiation**
|
||||
|
||||
**Background**: Specifies exactly when work can begin
|
||||
|
||||
**What it does**: Defines start date or conditions before work begins
|
||||
|
||||
**Purpose**: Prevents unauthorized work, establishes timeline, protects both parties
|
||||
|
||||
**Why this matters**:
|
||||
- Without this clause, work might begin before contract is fully executed
|
||||
- Prevents disputes about when work actually started
|
||||
- Protects contractor from doing unpaid work
|
||||
- Protects client from unauthorized charges
|
||||
- Establishes clear timeline expectations
|
||||
|
||||
**User options**:
|
||||
- **Upon contract signing**: Work begins immediately when both parties sign
|
||||
- **Specific date**: Work begins on a set calendar date
|
||||
- **After initial payment**: Work begins when first payment/deposit is received
|
||||
- **After written notice**: Work begins when client sends written authorization
|
||||
- **Conditional start**: Work begins after specific conditions are met (e.g., materials received, approvals obtained)
|
||||
|
||||
**What to ask user**: "When should work begin? Options: immediately upon signing, a specific date, after initial payment, or when you give written notice?"
|
||||
|
||||
**Content**: Ask user when work should begin, document the chosen option clearly
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Work Initiation:
|
||||
→ `31-build-section-10-terms-and-conditions.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
# Substep 31: Build Section 10 - Terms and Conditions
|
||||
|
||||
**Purpose**: Build the Terms and Conditions section
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 10: Terms and Conditions**
|
||||
|
||||
**Background**: Legal framework for the agreement
|
||||
|
||||
**What it does**: Covers changes, termination, IP ownership, dispute resolution, jurisdiction
|
||||
|
||||
**Purpose**: Protects both parties legally
|
||||
|
||||
**Key sections to include**:
|
||||
- **Changes and Modifications**: How scope changes are handled (change orders)
|
||||
- **Termination**: How to exit the contract (fair notice, payment for work done)
|
||||
- **Intellectual Property**: Who owns what (usually client owns deliverables upon payment)
|
||||
- **Dispute Resolution**: How conflicts are handled (mediation/arbitration/litigation)
|
||||
- **Governing Law and Jurisdiction**: Which laws apply and where legal proceedings take place
|
||||
- **Contract Language**: Language of the contract
|
||||
|
||||
**Content**: Standard terms including governing law and jurisdiction (see template)
|
||||
|
||||
**What to ask user**:
|
||||
- "Which jurisdiction's laws should govern this contract? (e.g., 'State of California, USA', 'England and Wales')"
|
||||
- "What language should this contract be in? (e.g., English, Spanish, French)"
|
||||
- "If the contract is translated, which version should be the official one?"
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Terms and Conditions:
|
||||
→ `32-build-section-11-approval.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
# Substep 32: Build Section 11 - Approval
|
||||
|
||||
**Purpose**: Build the Approval section with signature lines
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**Section 11: Approval**
|
||||
|
||||
**Background**: Formal signoff
|
||||
|
||||
**What it does**: Signature lines for both parties
|
||||
|
||||
**Purpose**: Makes the contract legally binding
|
||||
|
||||
**Content**:
|
||||
- Client and contractor names
|
||||
- Signature lines
|
||||
- Date fields
|
||||
|
||||
**For Project Contract**:
|
||||
- Client signature
|
||||
- Contractor signature
|
||||
|
||||
**For Service Agreement**:
|
||||
- Client/Owner signature
|
||||
- Service Provider signature
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building Approval section:
|
||||
→ `33-finalize-contract.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Substep 33: Finalize Contract
|
||||
|
||||
**Purpose**: Finalize the contract document and present it
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**After building all sections**:
|
||||
|
||||
1. **Review the contract**: "I've built your contract section by section. Let me review it with you..."
|
||||
|
||||
2. **Present the contract**: "Your contract is ready at `docs/1-project-brief/contract.md` (or `service-agreement.md`)."
|
||||
|
||||
3. **Explain next steps**:
|
||||
- "Review the contract thoroughly"
|
||||
- "Both parties should sign before work begins"
|
||||
- "Once signed, we can proceed to the Project Brief workflow"
|
||||
|
||||
4. **Ask**: "Does everything look good? Any adjustments needed before signing?"
|
||||
|
||||
---
|
||||
|
||||
## After Contract is Signed
|
||||
|
||||
**Once contract is signed**:
|
||||
- ✅ Alignment achieved
|
||||
- ✅ Commitment secured
|
||||
- ✅ Legal protection in place
|
||||
- ✅ Ready to proceed to Project Brief
|
||||
|
||||
**Next**: Full Project Brief workflow
|
||||
→ `src/modules/wds/workflows/1-project-brief/project-brief/complete/workflow.md`
|
||||
|
||||
---
|
||||
|
||||
## State Update
|
||||
|
||||
Update frontmatter of contract file with completion status.
|
||||
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
# Substep 34: Build Internal Signoff Document
|
||||
|
||||
**Purpose**: Build internal signoff document (alternative to external contract)
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**For Internal Signoff Document**:
|
||||
|
||||
**Focus areas** (not detailed scope/hours):
|
||||
- Goals and success metrics
|
||||
- Budget estimates
|
||||
- Ownership and responsibility
|
||||
- Approval workflow
|
||||
- Timeline and milestones
|
||||
|
||||
**Section 1: Project Overview**
|
||||
- The Realization
|
||||
- Recommended Solution
|
||||
|
||||
**Section 2: Goals and Success Metrics**
|
||||
- What we're trying to accomplish
|
||||
- Success metrics
|
||||
- How we'll measure success
|
||||
- Key performance indicators (KPIs)
|
||||
|
||||
**Section 3: Budget and Resources**
|
||||
- Budget allocation (total budget estimate)
|
||||
- Budget breakdown (if applicable)
|
||||
- Resources needed (high-level)
|
||||
- Not-to-exceed budget cap (if applicable)
|
||||
|
||||
**Section 4: Ownership and Responsibility**
|
||||
- Project Owner
|
||||
- Process Owner
|
||||
- Key Stakeholders
|
||||
- Decision-Making Authority
|
||||
|
||||
**Section 5: Approval and Sign-Off**
|
||||
- Who needs to approve
|
||||
- Approval stages
|
||||
- Sign-off process
|
||||
- Timeline for approval
|
||||
|
||||
**Section 6: Timeline and Milestones**
|
||||
- Key milestones
|
||||
- Delivery dates
|
||||
- Critical deadlines
|
||||
|
||||
**Section 7: Optional Sections**
|
||||
- Risks and considerations (optional)
|
||||
- Confidentiality (optional)
|
||||
- The Path Forward (optional - high-level overview)
|
||||
|
||||
**Company Signoff Format (Optional)**:
|
||||
- If user has existing company format, ask: "Do you have an existing company signoff document format? You can upload it and I'll adapt it to match your format."
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
After building internal signoff document:
|
||||
→ `35-finalize-signoff.md` (same folder)
|
||||
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Substep 35: Finalize Signoff Document
|
||||
|
||||
**Purpose**: Finalize the signoff document and present it
|
||||
|
||||
---
|
||||
|
||||
## Instruction
|
||||
|
||||
**After building the signoff document**:
|
||||
|
||||
1. **Present the signoff**: "Your signoff document is ready at `docs/1-project-brief/signoff.md`."
|
||||
|
||||
2. **Explain next steps**:
|
||||
- "Share with stakeholders for approval"
|
||||
- "Follow your company's approval workflow"
|
||||
- "Get all required signatures"
|
||||
- "Once approved, we can proceed to the Project Brief workflow"
|
||||
|
||||
3. **Ask**: "Does everything look good? Any adjustments needed before seeking approval?"
|
||||
|
||||
---
|
||||
|
||||
## After Signoff Document is Approved
|
||||
|
||||
**Once signoff document is approved**:
|
||||
- ✅ Internal alignment achieved
|
||||
- ✅ Budget/resources committed
|
||||
- ✅ Stakeholders on board
|
||||
- ✅ Ready to proceed to Project Brief
|
||||
|
||||
**Next**: Full Project Brief workflow
|
||||
→ `src/modules/wds/workflows/1-project-brief/project-brief/complete/workflow.md`
|
||||
|
||||
---
|
||||
|
||||
## State Update
|
||||
|
||||
Update frontmatter of signoff file with completion status.
|
||||
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
# Alignment & Signoff Substeps
|
||||
|
||||
**Purpose**: Small, sequential instruction files for the Alignment & Signoff workflow
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
These substeps break down the Alignment & Signoff workflow into small, focused steps that agents can follow sequentially. Each substep file contains a single, clear action.
|
||||
|
||||
---
|
||||
|
||||
## Instruction Flow
|
||||
|
||||
### Phase 1: Start & Understand (`01-start-understand/`)
|
||||
1. `01-understand-situation.md` - Clarify user's situation
|
||||
2. `02-determine-if-needed.md` - Determine if alignment & signoff is needed
|
||||
3. `03-offer-extract-communications.md` - Offer to extract from communications
|
||||
4. `04-extract-info.md` - Extract information (if provided)
|
||||
5. `05-detect-starting-point.md` - Detect where user wants to start
|
||||
|
||||
### Phase 2: Explore Sections (`02-explore-sections/`) - Flexible Order
|
||||
6. `06-explore-realization.md` - Explore The Realization
|
||||
7. `07-explore-solution.md` - Explore Solution (if starting with solution)
|
||||
8. `08-explore-why-it-matters.md` - Explore Why It Matters
|
||||
9. `09-explore-how-we-see-it-working.md` - Explore How We See It Working
|
||||
10. `10-explore-paths-we-explored.md` - Explore Paths We Explored
|
||||
11. `11-explore-recommended-solution.md` - Explore Recommended Solution
|
||||
12. `12-explore-path-forward.md` - Explore The Path Forward
|
||||
13. `13-explore-value-we-create.md` - Explore The Value We'll Create
|
||||
14. `14-explore-cost-of-inaction.md` - Explore Cost of Inaction
|
||||
15. `15-explore-our-commitment.md` - Explore Our Commitment
|
||||
16. `16-explore-summary.md` - Explore Summary
|
||||
|
||||
### Phase 3: Synthesize & Present (`03-synthesize-present/`)
|
||||
17. `17-reflect-back.md` - Reflect back what you've captured
|
||||
18. `18-synthesize-document.md` - Synthesize into alignment document
|
||||
19. `19-present-for-approval.md` - Present for stakeholder approval
|
||||
|
||||
### Phase 4: Generate Signoff (`04-generate-signoff/`) - After Acceptance
|
||||
20. `20-offer-signoff-document.md` - Offer to generate signoff document
|
||||
21. `21-determine-business-model.md` - Determine business model (external contracts)
|
||||
|
||||
### Phase 5: Build External Contract (`05-build-contract/`) - If Selected
|
||||
22. `22-build-section-01-project-overview.md` - Build Project Overview
|
||||
23. `23-build-section-02-business-model.md` - Build Business Model
|
||||
24. `24-build-section-03-scope-of-work.md` - Build Scope of Work (IN/OUT scope)
|
||||
25. `25-build-section-04-payment-terms.md` - Build Payment Terms
|
||||
26. `26-build-section-05-timeline.md` - Build Timeline
|
||||
27. `27-build-section-06-availability.md` - Build Availability (Retainer only)
|
||||
28. `28-build-section-07-confidentiality.md` - Build Confidentiality
|
||||
29. `29-build-section-08-not-to-exceed.md` - Build Not-to-Exceed (Conditional)
|
||||
30. `30-build-section-09-work-initiation.md` - Build Work Initiation
|
||||
31. `31-build-section-10-terms-and-conditions.md` - Build Terms and Conditions
|
||||
32. `32-build-section-11-approval.md` - Build Approval
|
||||
33. `33-finalize-contract.md` - Finalize contract
|
||||
|
||||
### Phase 6: Build Internal Signoff (`06-build-signoff-internal/`) - If Selected
|
||||
34. `34-build-internal-signoff.md` - Build Internal Signoff Document
|
||||
35. `35-finalize-signoff.md` - Finalize signoff document
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
**For agents**: Follow these substeps sequentially. Each file contains a single, focused instruction with clear next steps.
|
||||
|
||||
**Decision points**: Some substeps have decision points that route to different next steps based on user choices.
|
||||
|
||||
**Flexible flow**: Section exploration (substeps 06-16) can be done in any order based on user's natural thinking flow.
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
- **One instruction per file**: Each substep focuses on a single action
|
||||
- **Clear next steps**: Each file specifies what comes next
|
||||
- **Decision points**: Route to different paths based on user choices
|
||||
- **Reference larger guides**: Substeps reference section-guide.md for detailed guidance
|
||||
- **Linear flow**: Follow sequentially, but allow flexibility in section exploration order
|
||||
|
||||
|
|
@ -0,0 +1,150 @@
|
|||
# Alignment & Signoff Workflow
|
||||
|
||||
**Purpose**: Create alignment around your idea before starting the project
|
||||
|
||||
**When to Use**:
|
||||
- ✅ **Use Alignment & Signoff** if you need alignment with others:
|
||||
- Consultant proposing a solution to a client
|
||||
- Business hiring consultants/suppliers to build software
|
||||
- Manager/employee seeking approval for an internal project
|
||||
- Any scenario where stakeholders need to agree before starting
|
||||
|
||||
- ⏭️ **Skip Alignment & Signoff** if you're doing it yourself:
|
||||
- You have full autonomy and don't need approval
|
||||
- Go straight to the Project Brief workflow
|
||||
|
||||
**Why WDS Exists**: You're building systems that make the world a better place. When you need others involved, you need alignment first.
|
||||
|
||||
---
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
**The Challenge**: When others are involved, you need alignment on:
|
||||
- **The Idea** - What are we building?
|
||||
- **Why** - Why should it be done?
|
||||
- **What** - What does it contain?
|
||||
- **How** - How will it be executed?
|
||||
- **Budget** - What resources are needed?
|
||||
- **Commitment** - What are we willing to commit to make it happen?
|
||||
|
||||
**The Solution**: The alignment & signoff workflow helps you get all your ducks in a row through 10 sections that ensure everyone understands and agrees on these critical elements.
|
||||
|
||||
**Key Features**:
|
||||
- Makes the case for why the project matters
|
||||
- Presents your idea in the best possible light
|
||||
- Gets stakeholder buy-in before starting detailed work
|
||||
- Can be read in 2-3 minutes
|
||||
- **Allows for negotiation and iteration** - refine until everyone is on board
|
||||
|
||||
**Key Principle**: WDS helps with alignment - getting everyone on the same page. The alignment phase is collaborative and iterative. Once approved, the signoff document formalizes that commitment.
|
||||
|
||||
**The Journey**:
|
||||
|
||||
1. **Create the Alignment Document** - Work through 10 sections to align on Idea, Why, What, How, Budget, and Commitment
|
||||
2. **Share & Negotiate** - Present to stakeholders, gather feedback, iterate until everyone is on board
|
||||
3. **Get Acceptance** - Once everyone agrees, you have alignment
|
||||
4. **Secure Commitment** - Generate signoff document (contract, service agreement, or internal signoff) to formalize the commitment
|
||||
5. **Proceed to Project Brief** - With alignment and commitment secured, dive into detailed planning
|
||||
|
||||
**Different User Scenarios**:
|
||||
- **Consultant proposing to client** → Alignment Document → Negotiation → Acceptance → Project Contract → Project Brief
|
||||
- **Business hiring consultants/suppliers** → Alignment Document → Negotiation → Acceptance → Service Agreement → Project Brief
|
||||
- **Manager/employee in company** → Alignment Document → Negotiation → Acceptance → Signoff Document → Project Brief
|
||||
- **Doing it yourself** → Skip alignment & signoff, go straight to Project Brief
|
||||
|
||||
**WDS Has Your Back**: We help you set up everything you need - from initial alignment through formal commitment, ensuring everyone is on the same page before work begins.
|
||||
|
||||
**After pitch acceptance and signoff document**, you have:
|
||||
- ✅ Alignment on the idea, why, what, how, budget, and commitment
|
||||
- ✅ Formal commitment from all stakeholders
|
||||
- ✅ Clear foundation for detailed project planning
|
||||
|
||||
**Project initiation is complete**. Proceed to the full Project Brief workflow to dive into the detailed strategic planning.
|
||||
|
||||
---
|
||||
|
||||
## Step-by-Step Process
|
||||
|
||||
**Who handles this**: **Saga WDS Analyst Agent** - She specializes in helping you articulate your vision and create compelling alignment documents that get everyone aligned.
|
||||
|
||||
**Getting started**:
|
||||
- **You can start with either Mimir or Saga**:
|
||||
- **Mimir WDS Orchestrator** - Great if you're new, unsure, or want emotional support and gentle guidance first. He'll help clarify your situation and can connect you with Saga.
|
||||
- **Saga WDS Analyst Agent** - Perfect if you know you need alignment & signoff or want to go directly to the expert. She's professional, direct, and efficient - she can handle everything from understanding your situation to creating the alignment document and getting signoff. She's nice but plays no games - focused on getting things done.
|
||||
|
||||
**Both can help**: Mimir provides emotional support and gentle coaching, Saga provides professional, efficient alignment & signoff creation.
|
||||
|
||||
**Start here**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/substeps/01-start-understand/01-understand-situation.md`
|
||||
|
||||
**Substeps Available**:
|
||||
- **Full substep flow**: `src/modules/wds/workflows/1-project-brief/alignment-signoff/substeps/README.md`
|
||||
- **35 substeps** organized into 6 phase folders
|
||||
|
||||
**Step Files** (main workflow steps):
|
||||
- `src/modules/wds/workflows/1-project-brief/alignment-signoff/steps/step-01-start.md` (references substeps)
|
||||
|
||||
**Workflow Phases** (organized in subfolders):
|
||||
1. **Start & Understand** (`01-start-understand/`) - substeps 01-05
|
||||
2. **Explore Sections** (`02-explore-sections/`) - substeps 06-16 (flexible order)
|
||||
3. **Synthesize & Present** (`03-synthesize-present/`) - substeps 17-19
|
||||
4. **Generate Signoff** (`04-generate-signoff/`) - substeps 20-21
|
||||
5. **Build Contract** (`05-build-contract/`) - substeps 22-33
|
||||
6. **Build Internal Signoff** (`06-build-signoff-internal/`) - substeps 34-35
|
||||
|
||||
**Important**: The alignment phase allows for negotiation and iteration. You can update and refine the alignment document until everyone is on board. The signoff document (contract/service agreement/signoff) is generated AFTER the alignment document is accepted, ensuring everyone is aligned before formalizing the commitment.
|
||||
|
||||
**After approval**: Proceed to full Project Brief workflow
|
||||
|
||||
---
|
||||
|
||||
## Alignment Document Structure
|
||||
|
||||
The alignment document (pitch) covers 10 sections:
|
||||
|
||||
1. **The Realization** - What we've realized needs attention
|
||||
2. **Why It Matters** - Why this matters and who we help
|
||||
3. **How We See It Working** - Brief overview of the solution approach
|
||||
4. **Paths We Explored** - 2-3 solution options we considered
|
||||
5. **Recommended Solution** - Preferred approach and why
|
||||
6. **The Path Forward** - How the work will be done (WDS phases and practical approach)
|
||||
7. **The Value We'll Create** - What happens if we DO build this
|
||||
8. **Cost of Inaction** - What happens if we DON'T build this
|
||||
9. **Our Commitment** - Resources needed and potential risks
|
||||
10. **Summary** - Summary of key points
|
||||
|
||||
---
|
||||
|
||||
## Outputs
|
||||
|
||||
**Alignment Document (Pitch)**: `docs/1-project-brief/pitch.md` (Always generated)
|
||||
- Clear, brief, readable in 2-3 minutes
|
||||
- Makes the case for the project
|
||||
- Share with clients/stakeholders for approval
|
||||
|
||||
**Signoff Document** (Generated AFTER alignment acceptance):
|
||||
- **Project Contract**: `docs/1-project-brief/contract.md` - For consultant → client (after client accepts alignment document)
|
||||
- **Service Agreement**: `docs/1-project-brief/service-agreement.md` - For business → suppliers (after suppliers accept alignment document)
|
||||
- **Signoff Document**: `docs/1-project-brief/signoff.md` - For internal company projects (after stakeholders accept alignment document)
|
||||
- Based on the accepted alignment document, includes scope, investment, timeline, deliverables, and commitment
|
||||
- Formalizes the commitment - everyone has signed off on the idea, why, what, how, budget, and commitment
|
||||
- Generated after alignment acceptance to secure commitment before starting work
|
||||
|
||||
---
|
||||
|
||||
## After Alignment Acceptance and Signoff Document
|
||||
|
||||
**Project Initiation Complete** ✅
|
||||
|
||||
Once the alignment document is accepted and the signoff document is finalized:
|
||||
- **Alignment achieved** - Everyone agrees on the idea, why, what, how, budget, and commitment
|
||||
- **Commitment secured** - Formal signoff from all stakeholders
|
||||
- **Foundation established** - Clear understanding of what will be built and how
|
||||
- Ready to proceed to detailed strategic planning
|
||||
|
||||
**Next**: Full Project Brief workflow
|
||||
→ `src/modules/wds/workflows/1-project-brief/project-brief/complete/workflow.md`
|
||||
|
||||
**Remember**: The alignment phase allows for negotiation and iteration. You can update the alignment document until everyone is on board. The signoff document is generated AFTER acceptance to formalize the commitment, ensuring everyone is aligned before starting the actual project work.
|
||||
|
||||
**WDS Has Your Back**: We've helped you get alignment and secure commitment. Now you're ready to build something that makes the world a better place! 🚀
|
||||
|
||||
|
|
@ -1,117 +0,0 @@
|
|||
# Step 0: Create Project Pitch
|
||||
|
||||
## Purpose
|
||||
|
||||
Establish the foundational case for why this project matters and should be built before diving into detailed strategic planning.
|
||||
|
||||
## Context for Agent
|
||||
|
||||
You are helping the user create a compelling pitch that makes the case for the project's existence. This pitch serves as the foundation that justifies investing time and resources into the project brief and subsequent design work. Think of this as the "elevator pitch" or "business case" that answers: "Why should we build this?"
|
||||
|
||||
## Key Elements
|
||||
|
||||
This step establishes the strategic justification for the project by exploring:
|
||||
|
||||
- **Problem/Opportunity** - What problem are we solving or opportunity are we capturing?
|
||||
- **Why Now?** - What makes this the right time to pursue this?
|
||||
- **Proposed Solution** - High-level approach (detailed solution comes later)
|
||||
- **Why This Will Work** - Credibility, feasibility, unique advantages
|
||||
- **Expected Impact** - What outcomes will this create?
|
||||
- **Investment Required** - What resources are needed?
|
||||
- **Call to Action** - Decision point to proceed
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Introduce the pitch concept**
|
||||
- Explain that before we dive into detailed strategic planning, we need to establish why this project matters
|
||||
- Frame this as creating the "business case" or "elevator pitch" for the project
|
||||
- Set expectation: This will be used to justify the project and guide decision-making
|
||||
|
||||
2. **Explore the Problem/Opportunity**
|
||||
- "What problem are we solving, or what opportunity are we capturing?"
|
||||
- "Who is experiencing this problem or missing this opportunity?"
|
||||
- "What happens if we don't address this?"
|
||||
- Listen for: Pain points, market gaps, unmet needs, emerging trends
|
||||
|
||||
3. **Understand Why Now**
|
||||
- "What makes this the right time to pursue this project?"
|
||||
- "What has changed that makes this urgent or timely?"
|
||||
- Listen for: Market shifts, technology readiness, competitive threats, timing factors
|
||||
|
||||
4. **Capture Proposed Solution (High-Level)**
|
||||
- "At a high level, what kind of solution are we proposing?"
|
||||
- "What's the general approach we're taking?"
|
||||
- Keep this high-level - detailed solution design comes later
|
||||
- Listen for: Solution type, general approach, key capabilities
|
||||
|
||||
5. **Explore Why This Will Work**
|
||||
- "What gives us confidence this will succeed?"
|
||||
- "What unique advantages or capabilities do we have?"
|
||||
- "What makes us the right team/approach for this?"
|
||||
- Listen for: Unique assets, expertise, market position, competitive advantages
|
||||
|
||||
6. **Define Expected Impact**
|
||||
- "What outcomes are we expecting from this project?"
|
||||
- "How will we measure success?"
|
||||
- "What changes will this create?"
|
||||
- Listen for: Business outcomes, user benefits, market impact, metrics
|
||||
|
||||
7. **Clarify Investment Required**
|
||||
- "What resources will this project require?"
|
||||
- "What's the scope of investment we're considering?"
|
||||
- Keep this at a high level - detailed planning comes later
|
||||
- Listen for: Time, budget, team, technology, dependencies
|
||||
|
||||
8. **Crystallize the Pitch**
|
||||
- Synthesize all elements into a cohesive pitch statement
|
||||
- Help craft a compelling narrative that ties everything together
|
||||
- Use collaborative language: "What I'm hearing is..." or "It sounds like..."
|
||||
- Ask: "Does this capture why this project matters and should be built?"
|
||||
|
||||
## Pitch Framework (Optional Guide)
|
||||
|
||||
If user needs structure, you can offer this framework:
|
||||
|
||||
```
|
||||
**The Problem/Opportunity:**
|
||||
[What we're addressing]
|
||||
|
||||
**Why Now:**
|
||||
[What makes this timely]
|
||||
|
||||
**Our Proposed Solution:**
|
||||
[High-level approach]
|
||||
|
||||
**Why This Will Work:**
|
||||
[Our unique advantages]
|
||||
|
||||
**Expected Impact:**
|
||||
[Outcomes we'll create]
|
||||
|
||||
**Investment Required:**
|
||||
[Resources needed]
|
||||
|
||||
**Decision Point:**
|
||||
[Why we should proceed]
|
||||
```
|
||||
|
||||
## Next Step
|
||||
|
||||
After capturing the pitch, proceed to step-01-init.md to begin the detailed Project Brief workflow.
|
||||
|
||||
## State Update
|
||||
|
||||
Update frontmatter of output file:
|
||||
|
||||
```yaml
|
||||
stepsCompleted: ['step-00-pitch.md']
|
||||
pitch:
|
||||
problem_opportunity: '[captured problem/opportunity]'
|
||||
why_now: '[captured timing rationale]'
|
||||
proposed_solution: '[high-level solution approach]'
|
||||
why_this_will_work: '[credibility/feasibility factors]'
|
||||
expected_impact: '[expected outcomes]'
|
||||
investment_required: '[resources needed]'
|
||||
pitch_statement: '[synthesized pitch narrative]'
|
||||
```
|
||||
|
||||
|
|
@ -55,6 +55,6 @@ Load and read full config from {project-root}/{bmad_folder}/wds/config.yaml and
|
|||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Load, read full file and then execute `{project-root}/{bmad_folder}/wds/workflows/1-project-brief/complete/steps/step-00-pitch.md` to begin workflow.
|
||||
Load, read full file and then execute `{project-root}/{bmad_folder}/wds/workflows/1-project-brief/complete/steps/step-01-init.md` to begin workflow.
|
||||
|
||||
**Note:** The pitch (step-00) establishes the foundational case for why the project matters and should be built. This is a prerequisite before proceeding to detailed strategic planning (step-01 and beyond).
|
||||
**Note:** Alignment & Signoff is now a separate, optional workflow. If you need stakeholder approval before starting, use the alignment & signoff workflow first: `{project-root}/{bmad_folder}/wds/workflows/1-project-brief/alignment-signoff/workflow.md`
|
||||
|
|
|
|||
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
name: Product Brief Workflow
|
||||
description: Create comprehensive product briefs through collaborative step-by-step discovery
|
||||
web_bundle: true
|
||||
---
|
||||
|
||||
# Product Brief Workflow
|
||||
|
||||
**Goal:** Create comprehensive product briefs through collaborative step-by-step discovery
|
||||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are also Saga, a product-focused Business Analyst collaborating with an expert peer. This is a partnership, not a client-vendor relationship. You bring structured thinking and facilitation skills, while user brings domain expertise and product vision. Work together as equals.
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **step-file architecture** for disciplined execution:
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||
- **Just-In-Time Loading**: Only current step file is in memory - never load future step files until told to do so
|
||||
- **Sequential Enforcement**: Sequence within step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to output file
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||
4. **CHECK CONTINUATION**: If step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||
6. **LOAD NEXT**: When directed, load, read entire file, then execute next step file
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- 🛑 **NEVER** load multiple step files simultaneously
|
||||
- 📖 **ALWAYS** read entire step file before execution
|
||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||
- 💾 **ALWAYS** update frontmatter of output files when writing final output for a specific step
|
||||
- 🎯 **ALWAYS** follow the exact instructions in step file
|
||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||
- 📋 **NEVER** create mental todo lists from future steps
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Configuration Loading
|
||||
|
||||
Load and read full config from {project-root}/{bmad_folder}/wds/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`, `user_skill_level`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Load, read full file and then execute `{project-root}/{bmad_folder}/wds/workflows/1-project-brief/project-brief/complete/steps/step-01-init.md` to begin workflow.
|
||||
|
||||
**Note:** Alignment & Signoff is now a separate, optional workflow. If you need stakeholder approval before starting, use the alignment & signoff workflow first: `{project-root}/{bmad_folder}/wds/workflows/1-project-brief/alignment-signoff/workflow.md`
|
||||
|
|
@ -26,12 +26,12 @@ installed_path: "{project-root}/{bmad_folder}/wds/workflows/1-project-brief"
|
|||
# Route to appropriate workflow based on brief_level
|
||||
workflows:
|
||||
simplified:
|
||||
instructions: "{installed_path}/simplified/instructions.md"
|
||||
template: "{installed_path}/simplified/simplified-brief.template.md"
|
||||
instructions: "{installed_path}/project-brief/simplified/instructions.md"
|
||||
template: "{installed_path}/project-brief/simplified/simplified-brief.template.md"
|
||||
complete:
|
||||
instructions: "{installed_path}/complete/workflow.md"
|
||||
template: "{installed_path}/complete/project-brief.template.md"
|
||||
steps: "{installed_path}/complete/steps"
|
||||
instructions: "{installed_path}/project-brief/complete/workflow.md"
|
||||
template: "{installed_path}/project-brief/complete/project-brief.template.md"
|
||||
steps: "{installed_path}/project-brief/complete/steps"
|
||||
|
||||
# Output configuration
|
||||
output_file: "{output_folder}/A-Product-Brief/project-brief.md"
|
||||
|
|
|
|||
|
|
@ -9,6 +9,32 @@
|
|||
|
||||
---
|
||||
|
||||
## Pre-Phase 1: Alignment & Signoff
|
||||
|
||||
**What I do**:
|
||||
|
||||
- **Understand their situation** - Ask clarifying questions: Are they a consultant? Manager? Founder? Doing it themselves?
|
||||
- **Help them determine if alignment & signoff is needed** - Do they need stakeholder alignment, or can they go straight to Project Brief?
|
||||
- Help articulate your vision and idea
|
||||
- Create compelling alignment documents (pitch)
|
||||
- Get stakeholder alignment on idea, why, what, how, budget, and commitment
|
||||
- Generate signoff documents (contracts, service agreements, signoffs)
|
||||
|
||||
**My style**: Professional, direct, and efficient. I'm nice but I play no games - we're here to get things done. If they need emotional support, they can go to Mimir. I focus on clarity and results.
|
||||
|
||||
**When to offer**:
|
||||
|
||||
- User mentions needing stakeholder buy-in or approval
|
||||
- User is a consultant proposing to client
|
||||
- User is a business hiring suppliers/consultants
|
||||
- User is a manager/employee seeking internal approval
|
||||
- User asks "Do I need alignment?" or "How do I get approval?"
|
||||
- Any scenario requiring alignment before project begins
|
||||
|
||||
**I can handle the full experience** - from initial support and clarification through creating the alignment document and securing signoff. Users don't need to go through Mimir first, though Mimir can also help route them to me.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Product Brief
|
||||
|
||||
**What I do**:
|
||||
|
|
@ -23,6 +49,7 @@
|
|||
- Phase 1 not started
|
||||
- Phase 1 in progress but incomplete
|
||||
- Product brief needs updates
|
||||
- **After pitch is accepted** - proceed to Product Brief
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -47,6 +74,8 @@
|
|||
|
||||
## When to Stay (Continue in Same Conversation)
|
||||
|
||||
✅ User asks about creating an alignment document
|
||||
✅ User needs stakeholder alignment & signoff
|
||||
✅ User asks about Product Brief
|
||||
✅ User wants to do Trigger Mapping
|
||||
✅ User needs user research
|
||||
|
|
|
|||
|
|
@ -7,10 +7,35 @@
|
|||
|
||||
---
|
||||
|
||||
## Project Initiation Overview
|
||||
|
||||
**Project Initiation consists of**:
|
||||
1. **Alignment & Signoff** (optional) - Get stakeholder alignment and secure commitment before starting
|
||||
- Location: `src/modules/wds/workflows/1-project-brief/alignment-signoff/workflow.md`
|
||||
- After alignment acceptance → **Project Initiation Complete** ✅
|
||||
- **Output**: `docs/1-project-brief/pitch.md` (alignment document) - Contains work plan and approach
|
||||
2. **Product Brief** - Strategic foundation
|
||||
3. **Project Outline** - Plan which phases to include (this workflow)
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
After completing the Product Brief, capture the user's intentions for each WDS phase through individual, focused questions. Each phase gets its own micro-step conversation.
|
||||
|
||||
**Important**: If a pitch was created, **reference it** during this conversation. The pitch contains:
|
||||
- Work plan (which phases will be used)
|
||||
- Practical workflow approach
|
||||
- Level of detail needed
|
||||
- Handoff approach
|
||||
|
||||
**Use the pitch to inform**:
|
||||
- Which phases are needed (from Work Plan section)
|
||||
- What deliveries are required (from Work Plan and Investment sections)
|
||||
- Timeline and approach (from Work Plan section)
|
||||
|
||||
**Note**: If a pitch was created and approved, project initiation is already complete. This outline conversation happens after the Product Brief to plan the detailed phases, but should reference the pitch for context.
|
||||
|
||||
**Important**:
|
||||
|
||||
- WDS v6 methodology is default (numbered folders: 1-8)
|
||||
|
|
@ -24,6 +49,16 @@ After completing the Product Brief, capture the user's intentions for each WDS p
|
|||
|
||||
**Goal**: Let user know you'll ask about their intentions for different project phases.
|
||||
|
||||
**Before starting**: Check if pitch document exists at `docs/1-project-brief/pitch.md`
|
||||
|
||||
**If pitch exists**:
|
||||
- Read the Work Plan section from the pitch
|
||||
- Use it to inform your questions
|
||||
- Reference it: "I see in your pitch that you mentioned [work plan details]. Let's use that as a starting point..."
|
||||
|
||||
**If no pitch exists**:
|
||||
- Proceed with standard questions
|
||||
|
||||
**Outcome to capture**: User understands and is ready to continue.
|
||||
|
||||
**What NOT to do**:
|
||||
|
|
@ -31,6 +66,7 @@ After completing the Product Brief, capture the user's intentions for each WDS p
|
|||
- Don't ask about methodology (v6 is default)
|
||||
- Don't show long lists of options
|
||||
- Keep it brief and warm
|
||||
- Don't ignore the pitch if it exists - use it as context
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -38,16 +74,34 @@ After completing the Product Brief, capture the user's intentions for each WDS p
|
|||
|
||||
**Goal**: Determine if user needs Trigger Mapping phase.
|
||||
|
||||
**Before asking**: Check pitch document for Work Plan section - does it mention Trigger Mapping or user research?
|
||||
|
||||
**Context for agent**:
|
||||
|
||||
- Critical for customer-facing products
|
||||
- Can be skipped for: internal tools, technical products, known users
|
||||
- **Focus**: Define value chains that connect business goals to user needs
|
||||
|
||||
**What Trigger Mapping defines**:
|
||||
|
||||
- **One main value chain** (required):
|
||||
- One business goal
|
||||
- One main user group
|
||||
- A primary user goal
|
||||
- User fear the solution will add value to
|
||||
- **Secondary value chains** (optional):
|
||||
- Additional business goals, user groups, user goals, and fears
|
||||
|
||||
**Questions to understand**:
|
||||
|
||||
- Is this customer-facing or internal?
|
||||
- Do you already know your target users?
|
||||
- Do you need help defining personas?
|
||||
- Do you need help defining value chains (business goals → user groups → user goals → user fears)?
|
||||
- Can you identify the main value chain, or do you need help exploring it?
|
||||
|
||||
**If pitch mentions work plan**:
|
||||
- Reference it: "In your pitch, you mentioned [work plan detail about user research/trigger mapping]. Does that still align with your thinking?"
|
||||
- Use pitch context to inform questions
|
||||
|
||||
**Outcome to capture**:
|
||||
|
||||
|
|
@ -56,13 +110,15 @@ phase_2_trigger_mapping:
|
|||
active: true/false
|
||||
intent: "[User's exact words about this phase]"
|
||||
skip_reason: '[If skipping, capture why]'
|
||||
value_chains_approach: 'Main value chain + optional secondary chains'
|
||||
```
|
||||
|
||||
**Examples of user answers**:
|
||||
|
||||
- "This is an internal tool, we know our users" → active: false
|
||||
- "Yes, I need help understanding my customers" → active: true
|
||||
- "I have personas already, just need to document them" → active: true
|
||||
- "Yes, I need help understanding my customers and defining value chains" → active: true
|
||||
- "I have personas already, just need to document the value chains" → active: true
|
||||
- "I know the main value chain but want to explore secondary ones" → active: true
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -178,17 +234,28 @@ phase_5_design_system:
|
|||
|
||||
**Goal**: Understand handoff/documentation needs.
|
||||
|
||||
**Before asking**: Check pitch document for:
|
||||
- Work Plan section (handoff approach)
|
||||
- Investment Required section (what resources are needed)
|
||||
- Recommended Solution (what's being delivered)
|
||||
|
||||
**Context for agent**:
|
||||
|
||||
- Idunn WDS PM Agent handles this
|
||||
- Packages design for handoff
|
||||
- Creates PRD, epics, stories
|
||||
- **Pitch defines what deliveries are needed** - use it as foundation
|
||||
|
||||
**Questions to understand**:
|
||||
|
||||
- Handing off to developers?
|
||||
- Implementing yourself?
|
||||
- Need organized backlog?
|
||||
- What deliverables are needed? (Reference pitch Work Plan if available)
|
||||
|
||||
**If pitch exists**:
|
||||
- Reference the Work Plan: "Your pitch mentioned [handoff approach]. Let's confirm what deliverables you'll need..."
|
||||
- Use pitch to understand delivery requirements
|
||||
|
||||
**Outcome to capture**:
|
||||
|
||||
|
|
@ -303,11 +370,18 @@ phase_8_ongoing_development:
|
|||
- Skip reasons
|
||||
- Current date and timestamps
|
||||
- Initial status: phase_1 = "in_progress", others = "not_started"
|
||||
- **Reference to pitch**: If pitch exists, add reference: `pitch_document: "docs/1-project-brief/pitch.md"`
|
||||
|
||||
**If pitch document exists**:
|
||||
- Reference it in the outline: "This outline is informed by the project pitch"
|
||||
- The pitch's Work Plan section should align with the phases marked active
|
||||
- Use pitch to validate phase selections and delivery requirements
|
||||
|
||||
**After creating file**:
|
||||
|
||||
- Confirm to user: "Project outline created"
|
||||
- Explain: "Other agents will read this to understand your goals"
|
||||
- If pitch exists: "This outline aligns with the work plan from your pitch"
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue