Initial commit
This commit is contained in:
Zhongwei Li
171
skills/constraint-based-creativity/SKILL.md
Normal file
171
skills/constraint-based-creativity/SKILL.md
Normal file
@@ -0,0 +1,171 @@
|
||||
---
|
||||
name: constraint-based-creativity
|
||||
description: Use when brainstorming feels stuck or generates obvious ideas, need to break creative patterns, working with limited resources (budget/time/tools/materials), want unconventional solutions, designing with specific limitations, user mentions "think outside the box", "we're stuck", "same old ideas", "tight constraints", "limited budget/time", or seeking innovation through limitation rather than abundance.
|
||||
---
|
||||
|
||||
# Constraint-Based Creativity
|
||||
|
||||
## Table of Contents
|
||||
- [Purpose](#purpose)
|
||||
- [When to Use](#when-to-use)
|
||||
- [What Is It](#what-is-it)
|
||||
- [Workflow](#workflow)
|
||||
- [Constraint Types](#constraint-types)
|
||||
- [Common Patterns](#common-patterns)
|
||||
- [Guardrails](#guardrails)
|
||||
- [Quick Reference](#quick-reference)
|
||||
|
||||
## Purpose
|
||||
|
||||
Turn limitations into creative fuel by strategically imposing constraints that force novel thinking, break habitual patterns, and reveal unexpected solutions.
|
||||
|
||||
## When to Use
|
||||
|
||||
**Invoke this skill when you observe:**
|
||||
- Unconstrained brainstorming produces predictable, generic ideas
|
||||
- Team defaulting to "same old approaches"
|
||||
- Creative block despite ample resources
|
||||
- Need to work within tight limitations (budget, time, materials, technical)
|
||||
- Want to differentiate from competitors using similar unlimited resources
|
||||
- Seeking simplicity and focus over feature bloat
|
||||
- Innovation feels incremental rather than breakthrough
|
||||
|
||||
**Common trigger phrases:**
|
||||
- "We keep coming up with the same ideas"
|
||||
- "How do we innovate on a tight budget?"
|
||||
- "Think outside the box"
|
||||
- "We're stuck"
|
||||
- "What if we could only use X?"
|
||||
- "Design this with severe limitations"
|
||||
- "Create something radically different"
|
||||
|
||||
## What Is It
|
||||
|
||||
**Constraint-based creativity** deliberately limits freedom (resources, rules, materials, format) to force creative problem-solving. Paradoxically, constraints often boost creativity by:
|
||||
|
||||
1. **Reducing decision paralysis** - Fewer options = clearer focus
|
||||
2. **Breaking habitual patterns** - Can't use usual solutions
|
||||
3. **Forcing novel combinations** - Must work with what's allowed
|
||||
4. **Increasing psychological safety** - "We had to because of X"
|
||||
5. **Creating memorable differentiation** - Constraints make solutions distinctive
|
||||
|
||||
**Quick example:** Twitter's original 140-character limit forced concise, punchy writing. Haiku's 5-7-5 syllable structure produces poetry. $10K budget forces guerrilla marketing over Super Bowl ads. Building with only CSS (no images) creates distinctive visual style.
|
||||
|
||||
## Workflow
|
||||
|
||||
Copy this checklist and track your progress:
|
||||
|
||||
```
|
||||
Constraint-Based Creativity Progress:
|
||||
- [ ] Step 1: Understand the problem and context
|
||||
- [ ] Step 2: Choose or design strategic constraints
|
||||
- [ ] Step 3: Generate ideas within constraints
|
||||
- [ ] Step 4: Evaluate and refine solutions
|
||||
- [ ] Step 5: Validate quality and deliver
|
||||
```
|
||||
|
||||
**Step 1: Understand the problem and context**
|
||||
|
||||
Ask user for the creative challenge (what needs solving), current state (what's been tried, why it's not working), ideal outcome (success criteria), and any existing constraints (real limitations already in place). Understanding why ideas feel stale or stuck helps identify which constraints will unlock creativity. See [Constraint Types](#constraint-types) for strategic options.
|
||||
|
||||
**Step 2: Choose or design strategic constraints**
|
||||
|
||||
If user has existing constraints (tight budget, short timeline, limited materials) → Use [resources/template.md](resources/template.md) to work within them creatively. If no constraints exist and ideation is stuck → Study [resources/methodology.md](resources/methodology.md) to design strategic constraints that force new thinking patterns. Choose 1-3 constraints maximum to avoid over-constraining.
|
||||
|
||||
**Step 3: Generate ideas within constraints**
|
||||
|
||||
Apply chosen constraints rigorously during ideation. Create `constraint-based-creativity.md` file documenting: problem statement, active constraints (what's forbidden/required/limited), idea generation process, and all ideas produced (including "failed" attempts that revealed insights). Quantity matters - aim for 20+ ideas before evaluating. See [resources/template.md](resources/template.md) for structured generation process.
|
||||
|
||||
**Step 4: Evaluate and refine solutions**
|
||||
|
||||
Assess ideas using dual criteria: (1) Does it satisfy all constraints? (2) Does it solve the original problem? Select strongest 2-3 ideas. Refine by combining elements, removing unnecessary complexity, and strengthening the constraint-driven insight. Document why certain ideas stand out - often the constraint reveals an unexpected angle. See [resources/methodology.md](resources/methodology.md) for evaluation frameworks.
|
||||
|
||||
**Step 5: Validate quality and deliver**
|
||||
|
||||
Self-assess using [resources/evaluators/rubric_constraint_based_creativity.json](resources/evaluators/rubric_constraint_based_creativity.json). Verify: constraints were genuinely respected (not bent/broken), solutions are novel (not slight variations of existing), the constraint created the creativity (solution wouldn't exist without it), ideas are actionable (not just conceptual), and creative insight is explained (why this constraint unlocked this idea). Minimum standard: Average score ≥ 3.5. Present completed `constraint-based-creativity.md` file highlighting the constraint-driven breakthroughs.
|
||||
|
||||
## Constraint Types
|
||||
|
||||
Strategic constraints fall into categories. Choose based on what pattern you want to break:
|
||||
|
||||
**Resource Constraints** (force efficiency):
|
||||
- Budget: "Design this campaign for $500" (vs typical $50K)
|
||||
- Time: "Ship in 48 hours" (vs typical 2-week sprint)
|
||||
- Team: "Solo project only" or "No engineers"
|
||||
- Materials: "Found objects only" or "Recyclables only"
|
||||
|
||||
**Format/Medium Constraints** (force adaptation):
|
||||
- Length: "Explain in 10 words" or "Story in 6 words"
|
||||
- Medium: "Text only, no images" or "Visual only, no words"
|
||||
- Platform: "Twitter thread only" (vs blog post)
|
||||
- Dimensions: "Square format only" or "Vertical video"
|
||||
|
||||
**Rule-Based Constraints** (force creative workarounds):
|
||||
- Forbidden elements: "No letter 'e'" or "No adjectives"
|
||||
- Required elements: "Must include these 3 objects"
|
||||
- Style rules: "Hemingway style only" or "As if Shakespeare"
|
||||
- Process rules: "No editing, one-take only"
|
||||
|
||||
**Technical Constraints** (force optimization):
|
||||
- Code: "100 lines maximum" or "No external libraries"
|
||||
- Performance: "Load in <1 second" or "Run on 1990s hardware"
|
||||
- Data: "No PII collection" or "Works offline"
|
||||
- Compatibility: "Text-based only (ASCII art)"
|
||||
|
||||
**Audience/Perspective Constraints** (force reframing):
|
||||
- Audience: "Explain to 5-year-olds" or "For experts only"
|
||||
- Perspective: "First person only" or "Second person only"
|
||||
- Tone: "No corporate speak" or "Casual only"
|
||||
- Voice: "Write as [specific person/character]"
|
||||
|
||||
## Common Patterns
|
||||
|
||||
**Pattern: The Limitation Sprint**
|
||||
When team is stuck, run 30-minute sprints with different constraints. Example: "10 ideas using only free tools" → "10 ideas in black/white only" → "10 ideas for $100 budget." Constraint rotation prevents pattern fixation.
|
||||
|
||||
**Pattern: The Subtraction Game**
|
||||
Remove assumed "essentials" one at a time. Example: "App without login" → "App without UI" (voice only) → "App without internet" (offline-first). Forces questioning assumptions.
|
||||
|
||||
**Pattern: The Format Flip**
|
||||
Change medium to force different thinking. Example: "Explain strategy as a recipe" or "Present roadmap as a movie trailer" or "Write documentation as a children's book."
|
||||
|
||||
**Pattern: The Resource Inversion**
|
||||
Make the assumed limitation the focus. Example: "We have no budget" → "Build guerrilla marketing campaign showcasing zero-budget creativity" or "Only 2-person team" → "Sell the 'small team, big care' advantage."
|
||||
|
||||
**Pattern: The Historical Constraint**
|
||||
Impose constraints from different eras. Example: "Design this as if it's 1995" (pre-smartphone) or "Build this with Victorian-era materials" or "Market this like 1960s Mad Men."
|
||||
|
||||
## Guardrails
|
||||
|
||||
**✓ Do:**
|
||||
- Choose constraints that directly counter the creative block (stuck on complexity → simplicity constraint)
|
||||
- Enforce constraints rigorously during ideation (no "bending" rules mid-process)
|
||||
- Generate high volume before judging (quantity first, then quality)
|
||||
- Document failed ideas - they often contain seeds of insight
|
||||
- Explain how the constraint created the solution (causality matters)
|
||||
- Use multiple different constraints in sequence (sprint pattern)
|
||||
|
||||
**✗ Don't:**
|
||||
- Over-constrain (3+ simultaneous constraints usually paralyzes)
|
||||
- Choose arbitrary constraints unrelated to the problem
|
||||
- Abandon constraints when ideas get hard (that's when breakthroughs happen)
|
||||
- Confuse constraint-based creativity with regular brainstorming
|
||||
- Accept slight variations of existing ideas (constraint should force novelty)
|
||||
- Skip the evaluation step (need to validate constraint drove the creativity)
|
||||
|
||||
## Quick Reference
|
||||
|
||||
**Resources:**
|
||||
- `resources/template.md` - Structured process for generating ideas within constraints
|
||||
- `resources/methodology.md` - Advanced techniques for designing strategic constraints, combining constraint types, and systematic exploration
|
||||
- `resources/examples/` - Worked examples showing constraint-driven breakthroughs
|
||||
- `resources/evaluators/rubric_constraint_based_creativity.json` - Quality assessment before delivery
|
||||
|
||||
**When to choose which resource:**
|
||||
- Working with existing constraints (budget, time, technical) → Start with template
|
||||
- No constraints but ideation is stuck → Study methodology to design constraints
|
||||
- Need to see examples of breakthroughs → Review examples folder
|
||||
- Before delivering to user → Always validate with rubric
|
||||
|
||||
**Expected deliverable:**
|
||||
`constraint-based-creativity.md` file containing: problem statement, chosen constraints with rationale, idea generation process (including volume metrics), top 2-3 solutions with refinement notes, explanation of how constraints drove creativity, and next steps.
|
||||
@@ -0,0 +1,289 @@
|
||||
{
|
||||
"criteria": [
|
||||
{
|
||||
"name": "Constraint Integrity",
|
||||
"description": "Are constraints clearly defined, rigorously enforced, and genuinely respected throughout the process?",
|
||||
"scoring": {
|
||||
"1": "Constraints poorly defined or ignored. Ideas violate stated constraints. No evidence of enforcement.",
|
||||
"2": "Constraints defined but loosely enforced. Some ideas 'bend' rules. Inconsistent application.",
|
||||
"3": "Constraints clearly defined and mostly enforced. Occasional flexibility but generally respected.",
|
||||
"4": "Constraints rigorously enforced. All top solutions fully respect constraints. Clear rationale for each constraint.",
|
||||
"5": "Exemplary constraint discipline. Constraints treated as hard rules, not suggestions. Rationale explains WHY each constraint unlocks creativity. Enforcement explicit."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Constraint-Creativity Causality",
|
||||
"description": "Can you explain HOW the constraint drove the creative solution? Would this solution exist without the constraint?",
|
||||
"scoring": {
|
||||
"1": "No causality explained. Solution could exist in unconstrained brainstorming. Constraint seems arbitrary.",
|
||||
"2": "Weak causality. Constraint mentioned but connection to solution unclear. Seems like regular brainstorming with constraints added after.",
|
||||
"3": "Moderate causality. Can see how constraint influenced solution, but solution might exist without it.",
|
||||
"4": "Strong causality. Clear explanation of how constraint unlocked this specific solution. Unlikely to exist without constraint.",
|
||||
"5": "Exemplary causality. Detailed explanation of thinking pattern broken, unexpected angle revealed, and why solution is impossible in unconstrained brainstorming. Constraint-creativity link is explicit and compelling."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Idea Volume & Process Rigor",
|
||||
"description": "Was sufficient volume generated (20+ ideas)? Were 'failed' ideas documented? Was quantity prioritized before quality?",
|
||||
"scoring": {
|
||||
"1": "Minimal ideas (< 5). No documentation of process. Appears to have evaluated while generating (quality-first approach).",
|
||||
"2": "Low volume (5-10 ideas). Some process notes. Evaluation may have started too early.",
|
||||
"3": "Adequate volume (10-20 ideas). Process documented. Some failed ideas captured. Mostly quantity-first.",
|
||||
"4": "Good volume (20-30 ideas). Failed ideas documented with insights. Clear quantity-first approach. Process includes timestamps or rounds.",
|
||||
"5": "Exceptional volume (30+ ideas). Comprehensive documentation of all ideas including failures. Explicit insights from failed attempts. Timeboxed generation rounds. Volume metrics tracked."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Solution Novelty",
|
||||
"description": "Are solutions novel and differentiated, or incremental variations of existing approaches?",
|
||||
"scoring": {
|
||||
"1": "Derivative. Solutions are essentially same as existing approaches with minor tweaks.",
|
||||
"2": "Incremental. Solutions are improvements but not fundamentally different.",
|
||||
"3": "Fresh. Solutions have interesting twists that make them distinctive.",
|
||||
"4": "Novel. Solutions take unexpected angles that competitors aren't pursuing.",
|
||||
"5": "Breakthrough. Solutions are completely unexpected, highly differentiated, and clearly constraint-driven. Competitors would be surprised by these approaches."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Problem-Solution Fit",
|
||||
"description": "Do solutions actually solve the original creative challenge? Do they meet success criteria?",
|
||||
"scoring": {
|
||||
"1": "Poor fit. Solutions don't address the original problem or miss key success criteria.",
|
||||
"2": "Partial fit. Solutions address some aspects but miss others. Success criteria partially met.",
|
||||
"3": "Adequate fit. Solutions address the problem and meet most success criteria.",
|
||||
"4": "Strong fit. Solutions fully address problem and meet all stated success criteria.",
|
||||
"5": "Exceptional fit. Solutions exceed success criteria and address unstated needs. Problem-solution alignment is obvious and well-explained."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Actionability & Implementation Detail",
|
||||
"description": "Can solutions be executed? Are there concrete next steps, timelines, and resource requirements?",
|
||||
"scoring": {
|
||||
"1": "Purely conceptual. No implementation details. Cannot execute without extensive additional planning.",
|
||||
"2": "Vague actionability. Some implementation hints but missing key details (timeline, resources, steps).",
|
||||
"3": "Actionable. Solutions include basic implementation notes and next steps.",
|
||||
"4": "Highly actionable. Detailed implementation plans with timeline, resource allocation, and execution steps.",
|
||||
"5": "Immediately executable. Comprehensive implementation plans with timeline, budget breakdown, success metrics, risk mitigation, and first actions clearly defined. Could start executing today."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Strategic Constraint Design",
|
||||
"description": "Were constraints strategically chosen to counter the creative block? Is there clear rationale for each constraint?",
|
||||
"scoring": {
|
||||
"1": "Arbitrary constraints. No clear connection to the creative challenge. Constraints seem random.",
|
||||
"2": "Loosely related constraints. Some connection to problem but not strategic.",
|
||||
"3": "Relevant constraints. Clear connection to creative challenge. Rationale provided.",
|
||||
"4": "Strategic constraints. Deliberately chosen to counter diagnosed creative block. Rationale explains connection.",
|
||||
"5": "Exemplary constraint strategy. Diagnosed creative block type explicitly. Constraints specifically designed to counter that block. Rationale explains not just WHAT constraints but WHY these specific ones unlock creativity for this specific challenge."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Constraint Tightness (Sweet Spot)",
|
||||
"description": "Are constraints tight enough to force creativity but not so tight they cause paralysis?",
|
||||
"scoring": {
|
||||
"1": "Too loose (no creative tension) OR too tight (paralysis, zero ideas). Missed the sweet spot entirely.",
|
||||
"2": "Somewhat off. Either didn't force much creativity OR made ideation very difficult.",
|
||||
"3": "Adequate tightness. Constraints forced some rethinking. Generated ideas with effort.",
|
||||
"4": "Good tightness. Constraints created productive struggle. Breakthrough zone reached.",
|
||||
"5": "Perfect tightness. Constraints forced radical creativity without paralysis. Clear evidence of being in the 'breakthrough zone'. May have used constraint escalation to find sweet spot."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Risk Honesty & Limitation Acknowledgment",
|
||||
"description": "Are risks, limitations, and potential failures honestly acknowledged?",
|
||||
"scoring": {
|
||||
"1": "No risk acknowledgment. Solutions presented as perfect with no downsides.",
|
||||
"2": "Minimal risk acknowledgment. Obvious limitations ignored or glossed over.",
|
||||
"3": "Adequate risk honesty. Key risks identified. Limitations mentioned.",
|
||||
"4": "Strong risk honesty. Comprehensive risk assessment. Limitations clearly stated. Some mitigation strategies.",
|
||||
"5": "Exemplary honesty. Detailed risk analysis including: execution risks, assumption risks, constraint violation risks, and market risks. Limitations honestly acknowledged. Mitigation strategies for each major risk. Failure modes considered."
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Documentation & Explanation Quality",
|
||||
"description": "Is the constraint-based-creativity.md file complete, well-organized, and clearly explained?",
|
||||
"scoring": {
|
||||
"1": "Incomplete documentation. Missing key sections. Unclear explanations.",
|
||||
"2": "Basic documentation. Most sections present but thin on details. Some unclear areas.",
|
||||
"3": "Good documentation. All sections completed. Clear explanations. Organized logically.",
|
||||
"4": "Excellent documentation. Comprehensive coverage of all sections. Clear explanations with examples. Well-organized.",
|
||||
"5": "Exemplary documentation. Complete, detailed, well-organized file. Includes all required sections: problem, context, constraints with rationale, all ideas generated, insights from failures, top solutions with causality explanations, evaluation, breakthrough explanation, next steps. Could serve as template for others."
|
||||
}
|
||||
}
|
||||
],
|
||||
"constraint_type_guidance": {
|
||||
"Resource Constraints (budget, time, team)": {
|
||||
"target_score": 3.5,
|
||||
"focus_criteria": [
|
||||
"Constraint-Creativity Causality",
|
||||
"Solution Novelty",
|
||||
"Strategic Constraint Design"
|
||||
],
|
||||
"key_patterns": [
|
||||
"Solutions should make limitation a feature, not just work within it",
|
||||
"Look for 'resource inversion' - turning scarcity into advantage",
|
||||
"Efficiency innovations often emerge from resource constraints"
|
||||
]
|
||||
},
|
||||
"Format/Medium Constraints (length, platform, style)": {
|
||||
"target_score": 3.5,
|
||||
"focus_criteria": [
|
||||
"Constraint Integrity",
|
||||
"Idea Volume & Process Rigor",
|
||||
"Solution Novelty"
|
||||
],
|
||||
"key_patterns": [
|
||||
"Format constraints should force different communication patterns",
|
||||
"High volume generation important (many ways to adapt to format)",
|
||||
"Look for creative use of the constrained medium"
|
||||
]
|
||||
},
|
||||
"Rule-Based Constraints (forbidden/required elements)": {
|
||||
"target_score": 4.0,
|
||||
"focus_criteria": [
|
||||
"Constraint Integrity",
|
||||
"Constraint-Creativity Causality",
|
||||
"Constraint Tightness"
|
||||
],
|
||||
"key_patterns": [
|
||||
"Rule constraints are easiest to 'cheat' - verify rigorous enforcement",
|
||||
"Should force creative workarounds (that's the point)",
|
||||
"Tightness is critical - too loose has no effect, too tight causes paralysis"
|
||||
]
|
||||
},
|
||||
"Technical Constraints (performance, compatibility, dependencies)": {
|
||||
"target_score": 4.0,
|
||||
"focus_criteria": [
|
||||
"Actionability & Implementation Detail",
|
||||
"Problem-Solution Fit",
|
||||
"Risk Honesty"
|
||||
],
|
||||
"key_patterns": [
|
||||
"Technical constraints often reveal elegant solutions",
|
||||
"Implementation details are critical for technical solutions",
|
||||
"Trade-offs must be explicitly acknowledged"
|
||||
]
|
||||
},
|
||||
"Perspective/Audience Constraints (point of view, target audience)": {
|
||||
"target_score": 3.5,
|
||||
"focus_criteria": [
|
||||
"Solution Novelty",
|
||||
"Constraint-Creativity Causality",
|
||||
"Strategic Constraint Design"
|
||||
],
|
||||
"key_patterns": [
|
||||
"Perspective shift should reveal new angles on problem",
|
||||
"Look for reframing, not just translation",
|
||||
"Audience constraints work best when forcing empathy shift"
|
||||
]
|
||||
}
|
||||
},
|
||||
"challenge_complexity_guidance": {
|
||||
"Simple Challenge (clear problem, straightforward constraints)": {
|
||||
"target_score": 3.0,
|
||||
"acceptable_shortcuts": [
|
||||
"Lower idea volume acceptable (15+ instead of 20+)",
|
||||
"Single constraint sufficient",
|
||||
"Less detailed implementation plans"
|
||||
],
|
||||
"key_quality_gates": [
|
||||
"Constraint integrity still required",
|
||||
"Causality must be clear",
|
||||
"Solution must be actionable"
|
||||
]
|
||||
},
|
||||
"Standard Challenge (typical creative block, standard constraints)": {
|
||||
"target_score": 3.5,
|
||||
"required_elements": [
|
||||
"20+ ideas generated",
|
||||
"1-2 strategic constraints",
|
||||
"Clear causality explanation",
|
||||
"Implementation plan with timeline"
|
||||
],
|
||||
"key_quality_gates": [
|
||||
"All 10 criteria evaluated",
|
||||
"Minimum score of 3 on each criterion",
|
||||
"Average ≥ 3.5"
|
||||
]
|
||||
},
|
||||
"Complex Challenge (multi-faceted problem, multiple constraints)": {
|
||||
"target_score": 4.0,
|
||||
"required_elements": [
|
||||
"30+ ideas across constraint combinations",
|
||||
"2-3 strategic constraints with interaction effects",
|
||||
"Detailed causality explanation for each constraint",
|
||||
"Comprehensive implementation plan with risk mitigation",
|
||||
"Constraint escalation or combination documented"
|
||||
],
|
||||
"key_quality_gates": [
|
||||
"All 10 criteria evaluated",
|
||||
"Minimum score of 3.5 on each criterion",
|
||||
"Average ≥ 4.0",
|
||||
"Exceptional scores (5) on Causality and Strategic Design"
|
||||
]
|
||||
}
|
||||
},
|
||||
"common_failure_modes": {
|
||||
"1. Bending Constraints": {
|
||||
"symptom": "Ideas violate constraints with justifications like 'close enough' or 'in spirit'",
|
||||
"why_it_fails": "Defeats the purpose. Breakthrough ideas come from rigorous constraint enforcement.",
|
||||
"fix": "Reject any idea that violates constraints, even slightly. The difficulty is the point.",
|
||||
"related_criteria": ["Constraint Integrity", "Constraint Tightness"]
|
||||
},
|
||||
"2. Incremental Ideas": {
|
||||
"symptom": "Solutions are slight variations of existing approaches, not fundamentally different",
|
||||
"why_it_fails": "Constraint-based creativity should produce novel solutions, not optimizations.",
|
||||
"fix": "Use novelty assessment (5-point scale). If scoring < 4, keep generating. Ask: 'Would this exist in unconstrained brainstorming?'",
|
||||
"related_criteria": ["Solution Novelty", "Constraint-Creativity Causality"]
|
||||
},
|
||||
"3. Over-Constraining": {
|
||||
"symptom": "Zero ideas generated, complete paralysis, frustration",
|
||||
"why_it_fails": "Too many constraints or too-tight constraints prevent any ideation.",
|
||||
"fix": "Reduce to 1-2 constraints maximum. Use constraint escalation to find sweet spot (start loose, progressively tighten).",
|
||||
"related_criteria": ["Constraint Tightness", "Idea Volume & Process Rigor"]
|
||||
},
|
||||
"4. Arbitrary Constraints": {
|
||||
"symptom": "Constraints have no clear connection to the creative block or challenge",
|
||||
"why_it_fails": "Random constraints don't unlock creativity, they just add busywork.",
|
||||
"fix": "Diagnose creative block first (abundance paralysis, pattern fixation, etc.). Choose constraints that counter that specific block.",
|
||||
"related_criteria": ["Strategic Constraint Design", "Constraint-Creativity Causality"]
|
||||
},
|
||||
"5. Skipping Volume Phase": {
|
||||
"symptom": "Only 3-5 ideas generated before evaluating and refining",
|
||||
"why_it_fails": "Breakthrough ideas rarely appear in first few attempts. Need quantity to find quality.",
|
||||
"fix": "Force minimum 20 ideas before ANY evaluation. Set timer and don't stop early. Document all ideas including 'bad' ones.",
|
||||
"related_criteria": ["Idea Volume & Process Rigor", "Solution Novelty"]
|
||||
},
|
||||
"6. Missing Causality": {
|
||||
"symptom": "Cannot explain how constraint drove the creativity. Solution could exist without constraint.",
|
||||
"why_it_fails": "If constraint didn't drive the solution, it's not constraint-based creativity - it's regular brainstorming with constraints added after.",
|
||||
"fix": "For each top solution, explicitly answer: 'Would this exist in unconstrained brainstorming? Why/why not?' If answer is 'yes', keep generating.",
|
||||
"related_criteria": ["Constraint-Creativity Causality", "Strategic Constraint Design"]
|
||||
},
|
||||
"7. Conceptual Without Actionable": {
|
||||
"symptom": "Solutions are interesting ideas but lack implementation details, timeline, resources",
|
||||
"why_it_fails": "Creativity without execution is just daydreaming. Need actionable plans.",
|
||||
"fix": "Add implementation section to each top solution: What are the first 3 actions? Timeline? Budget? Success metrics? If can't answer, solution is too conceptual.",
|
||||
"related_criteria": ["Actionability & Implementation Detail", "Problem-Solution Fit"]
|
||||
},
|
||||
"8. Ignoring Risks": {
|
||||
"symptom": "Solutions presented as perfect with no acknowledged downsides or risks",
|
||||
"why_it_fails": "All solutions have trade-offs. Ignoring them suggests shallow thinking or overconfidence.",
|
||||
"fix": "For each top solution, explicitly list: execution risks, assumption risks, failure modes, and limitations. If can't identify any risks, look harder.",
|
||||
"related_criteria": ["Risk Honesty & Limitation Acknowledgment", "Actionability & Implementation Detail"]
|
||||
}
|
||||
},
|
||||
"scale": {
|
||||
"description": "Each criterion scored 1-5",
|
||||
"min_score": 1,
|
||||
"max_score": 5,
|
||||
"passing_threshold": 3.5,
|
||||
"excellence_threshold": 4.5
|
||||
},
|
||||
"usage_notes": {
|
||||
"when_to_score": "After generating all ideas and selecting top solutions, before delivering to user",
|
||||
"minimum_standard": "Average score ≥ 3.5 across all criteria (standard challenge). Simple challenges: ≥ 3.0. Complex challenges: ≥ 4.0.",
|
||||
"how_to_improve": "If scoring < threshold, identify lowest-scoring criteria and iterate on those specific areas before delivering",
|
||||
"self_assessment": "Score yourself honestly. This rubric is for quality assurance, not for impressing the user. Better to iterate now than deliver weak constraint-based creativity."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,465 @@
|
||||
# Constraint-Based Creativity: API Design with Minimalism Constraint
|
||||
|
||||
## Problem Statement
|
||||
|
||||
Design REST API for a task management service. Need to create clean, intuitive API that developers love using. Compete with established players (Todoist, Asana, etc.) by offering superior developer experience.
|
||||
|
||||
## Context
|
||||
|
||||
**What's been tried:** Initial unconstrained design produced typical REST API:
|
||||
- 23 endpoints across 6 resources
|
||||
- CRUD operations for everything (tasks, projects, users, tags, comments, attachments)
|
||||
- Complex nested routes: `/api/v1/projects/{id}/tasks/{taskId}/comments/{commentId}/attachments`
|
||||
- Auth tokens, pagination params, filtering, sorting on every endpoint
|
||||
- 147-page API documentation needed
|
||||
|
||||
**Why we're stuck:** API feels bloated despite being "RESTful best practices." Developers in user testing confused by too many options. Onboarding taking 2+ hours just to understand available endpoints. Defaulting to "add more endpoints for more use cases" pattern.
|
||||
|
||||
**Success criteria:**
|
||||
- New developer can make first successful API call in < 5 minutes
|
||||
- Complete API documentation fits on single page (not 147 pages)
|
||||
- Differentiated from competitor APIs (memorable, not just "another REST API")
|
||||
- Supports all core use cases without sacrificing capability
|
||||
|
||||
## Active Constraints
|
||||
|
||||
**Constraint 1: Maximum 5 HTTP Endpoints**
|
||||
- **Rationale:** Forces ruthless prioritization. Can't add endpoint for every use case. Must design for composability instead of proliferation.
|
||||
- **Enforcement:** API spec cannot exceed 5 endpoint definitions. Any new endpoint requires removing an existing one.
|
||||
|
||||
**Constraint 2: Single-Page Documentation**
|
||||
- **Rationale:** If docs don't fit on one page, API is too complex. Forces clarity and simplicity in design.
|
||||
- **Enforcement:** Entire API reference (all endpoints, params, responses, examples) must render on single scrollable page.
|
||||
|
||||
**Constraint 3: No Nested Routes Beyond 2 Levels**
|
||||
- **Rationale:** Prevents complexity creep from deeply nested resources. Forces flatter, more intuitive structure.
|
||||
- **Enforcement:** Routes like `/projects/{id}/tasks` are allowed (2 levels). Routes like `/projects/{id}/tasks/{taskId}/comments` are forbidden (3 levels).
|
||||
|
||||
## Idea Generation Process
|
||||
|
||||
**Technique used:** Constraint Escalation - started with 10 endpoints, progressively reduced to find creative sweet spot
|
||||
|
||||
**Volume:** Generated 27 different API designs across 4 constraint levels
|
||||
|
||||
**Mindset:** Initial resistance ("5 endpoints is impossible!"), then breakthrough moment when team realized constraint forced better abstraction.
|
||||
|
||||
## All Ideas Generated
|
||||
|
||||
### Round 1: 10 endpoints (baseline - 50% reduction from 23)
|
||||
|
||||
1. Standard CRUD for tasks (4 endpoints)
|
||||
2. Standard CRUD for projects (4 endpoints)
|
||||
3. Authentication (1 endpoint)
|
||||
4. Search (1 endpoint)
|
||||
- Assessment: Still too many, documentation still multi-page
|
||||
|
||||
### Round 2: 7 endpoints (70% reduction)
|
||||
|
||||
5. Combine tasks + projects into "items" resource (4 endpoints for items)
|
||||
6. Auth (1 endpoint)
|
||||
7. Query (1 endpoint for search/filter)
|
||||
8. Batch operations (1 endpoint)
|
||||
- Assessment: Better, but "items" abstraction feels forced
|
||||
|
||||
### Round 3: 5 endpoints (breakthrough target - 78% reduction)
|
||||
|
||||
9. **Design A: Everything is a "node"**
|
||||
- POST /nodes (create)
|
||||
- GET /nodes (list/search)
|
||||
- GET /nodes/{id} (read)
|
||||
- PATCH /nodes/{id} (update)
|
||||
- DELETE /nodes/{id} (delete)
|
||||
- Assessment: ⭐ Clean but too generic, loses semantic meaning
|
||||
|
||||
10. **Design B: Action-oriented**
|
||||
- POST /create
|
||||
- GET /query
|
||||
- POST /update
|
||||
- POST /delete
|
||||
- GET /status
|
||||
- Assessment: RESTful purists would hate it, but simple
|
||||
|
||||
11. **Design C: Resource + actions**
|
||||
- POST /tasks (create)
|
||||
- GET /tasks (list all with query params)
|
||||
- GET /tasks/{id} (get specific)
|
||||
- PATCH /tasks/{id} (update)
|
||||
- POST /tasks/batch (batch operations)
|
||||
- Assessment: Can't handle projects, tags, users in 5 endpoints
|
||||
|
||||
12. **Design D: GraphQL-like but REST**
|
||||
- POST /query (get anything)
|
||||
- POST /mutate (change anything)
|
||||
- POST /auth (authentication)
|
||||
- GET /schema (API schema)
|
||||
- GET /health (health check)
|
||||
- Assessment: ⭐ Interesting, but not really REST anymore
|
||||
|
||||
13. **Design E: Hypermedia-driven**
|
||||
- GET / (entry point, returns links to everything)
|
||||
- POST /{resource} (create anything)
|
||||
- GET /{resource} (list anything)
|
||||
- GET /{resource}/{id} (get anything)
|
||||
- PATCH /{resource}/{id} (update anything)
|
||||
- Assessment: ⭐⭐ Generic but powerful, documentation points to root
|
||||
|
||||
### Round 4: 3 endpoints (extreme - 87% reduction)
|
||||
|
||||
14. **Design F: Commands pattern**
|
||||
- POST /command (send any command)
|
||||
- GET /query (query any data)
|
||||
- GET / (documentation + schema)
|
||||
- Assessment: ⭐⭐ Ultra-minimal, but loses REST semantics
|
||||
|
||||
15. **Design G: Single endpoint**
|
||||
- POST /api (everything goes here, JSON-RPC style)
|
||||
- Assessment: Too extreme, not REST, documentation nightmare
|
||||
|
||||
## Insights from "Failed" Ideas
|
||||
|
||||
- **Designs 1-8 (10-7 endpoints):** Constraint not tight enough, still thinking in traditional CRUD patterns
|
||||
- **Design G (1 endpoint):** Over-constrained to point of paralysis, lost REST principles entirely
|
||||
- **Breakthrough zone:** 5 endpoints forced abstraction without losing usability
|
||||
- **Key insight:** Generic resource paths (`/{resource}`) + comprehensive query params = flexibility without endpoint proliferation
|
||||
|
||||
## Top Solutions (Refined)
|
||||
|
||||
### Solution 1: Hypermedia-Driven Minimalist API
|
||||
|
||||
**Description:**
|
||||
|
||||
Five-endpoint API that uses generic resource routing + HATEOAS (Hypermedia as the Engine of Application State) to provide full functionality while staying minimal.
|
||||
|
||||
**The 5 Endpoints:**
|
||||
|
||||
```
|
||||
1. GET /
|
||||
- Entry point (root document)
|
||||
- Returns all available resources and links
|
||||
- Includes inline documentation
|
||||
- Response:
|
||||
{
|
||||
"resources": ["tasks", "projects", "users", "tags"],
|
||||
"actions": {
|
||||
"create": "POST /{resource}",
|
||||
"list": "GET /{resource}",
|
||||
"get": "GET /{resource}/{id}",
|
||||
"update": "PATCH /{resource}/{id}",
|
||||
"delete": "DELETE /{resource}/{id}"
|
||||
},
|
||||
"docs": "https://docs.example.com",
|
||||
"_links": {
|
||||
"tasks": {"href": "/tasks"},
|
||||
"projects": {"href": "/projects"}
|
||||
}
|
||||
}
|
||||
|
||||
2. POST /{resource}
|
||||
- Create any resource (tasks, projects, users, tags, etc.)
|
||||
- Resource type determined by URL path
|
||||
- Example: POST /tasks, POST /projects
|
||||
- Response includes _links for related actions
|
||||
|
||||
3. GET /{resource}
|
||||
- List all items of resource type
|
||||
- Query params: ?filter, ?sort, ?limit, ?offset
|
||||
- Example: GET /tasks?filter=completed:false&sort=dueDate
|
||||
- Response includes pagination links and available filters
|
||||
|
||||
4. GET /{resource}/{id}
|
||||
- Retrieve specific resource by ID
|
||||
- Response includes _links to related resources and actions
|
||||
- Example: GET /tasks/123 includes link to project, assigned user
|
||||
|
||||
5. PATCH /{resource}/{id}
|
||||
- Update specific resource
|
||||
- Partial updates supported (send only changed fields)
|
||||
- DELETE also uses this endpoint with {"deleted": true} flag
|
||||
- Atomic updates with version checking
|
||||
```
|
||||
|
||||
**How constraints shaped it:**
|
||||
|
||||
The 5-endpoint limit forced us to stop thinking "one endpoint per use case" and start thinking "generic operations on any resource." We couldn't add `/tasks/batch` or `/projects/{id}/tasks` or `/search` - those would exceed 5 endpoints. Instead, batch operations go through PATCH with arrays, nested resources are discovered via hypermedia links, search uses query params on GET.
|
||||
|
||||
Single-page documentation constraint forced us to make the API self-documenting (GET / returns structure) rather than writing extensive docs for 23 different endpoints. The API documentation became the API itself.
|
||||
|
||||
No-nesting-beyond-2-levels constraint meant we couldn't do `/projects/{id}/tasks/{taskId}/comments` - instead, comments are queried via `GET /comments?taskId=123`, which is actually simpler for client code.
|
||||
|
||||
**Strengths:**
|
||||
- Extreme simplicity: 5 endpoints to learn (vs 23 in original design)
|
||||
- Self-documenting: GET / explains the entire API
|
||||
- Extensible: Add new resources without adding endpoints
|
||||
- Consistent: Same pattern for all resources (POST to create, GET to list, etc.)
|
||||
- Developer-friendly: First API call can happen in 2 minutes (just GET /)
|
||||
- Documentation fits on single page (literally - root response + 5 endpoint patterns)
|
||||
- Hypermedia enables discovery (clients follow links rather than construct URLs)
|
||||
|
||||
**Implementation notes:**
|
||||
|
||||
**Resource Definitions:**
|
||||
```javascript
|
||||
// All resources share same interface
|
||||
interface Resource {
|
||||
id: string;
|
||||
type: string; // "task" | "project" | "user" | "tag"
|
||||
attributes: Record<string, any>;
|
||||
relationships?: Record<string, ResourceLink>;
|
||||
_links: {
|
||||
self: { href: string };
|
||||
[key: string]: { href: string };
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
**Example: Create task**
|
||||
```bash
|
||||
POST /tasks
|
||||
{
|
||||
"title": "Write API docs",
|
||||
"completed": false,
|
||||
"projectId": "proj-123"
|
||||
}
|
||||
|
||||
Response:
|
||||
{
|
||||
"id": "task-456",
|
||||
"type": "task",
|
||||
"attributes": {
|
||||
"title": "Write API docs",
|
||||
"completed": false
|
||||
},
|
||||
"relationships": {
|
||||
"project": {"data": {"type": "project", "id": "proj-123"}}
|
||||
},
|
||||
"_links": {
|
||||
"self": {"href": "/tasks/task-456"},
|
||||
"project": {"href": "/projects/proj-123"},
|
||||
"update": {"href": "/tasks/task-456", "method": "PATCH"},
|
||||
"complete": {"href": "/tasks/task-456", "method": "PATCH", "body": {"completed": true}}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Example: Query with filters**
|
||||
```bash
|
||||
GET /tasks?filter=completed:false&filter=projectId:proj-123&sort=-dueDate&limit=20
|
||||
|
||||
Response:
|
||||
{
|
||||
"data": [ /* array of task resources */ ],
|
||||
"meta": {
|
||||
"total": 45,
|
||||
"limit": 20,
|
||||
"offset": 0
|
||||
},
|
||||
"_links": {
|
||||
"self": {"href": "/tasks?filter=completed:false&filter=projectId:proj-123&sort=-dueDate&limit=20"},
|
||||
"next": {"href": "/tasks?filter=completed:false&filter=projectId:proj-123&sort=-dueDate&limit=20&offset=20"}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Example: Batch update**
|
||||
```bash
|
||||
PATCH /tasks/task-456
|
||||
{
|
||||
"updates": [
|
||||
{"id": "task-456", "completed": true},
|
||||
{"id": "task-789", "completed": true}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Risks/Limitations:**
|
||||
- Generic routing may feel less "RESTful" to purists
|
||||
- Requires client to understand hypermedia (though _links help)
|
||||
- Query param complexity could grow (mitigate with clear documentation)
|
||||
- Initial learning curve for developers used to specific endpoints
|
||||
|
||||
### Solution 2: Command-Query API
|
||||
|
||||
**Description:**
|
||||
|
||||
Extreme minimalism using Command Query Responsibility Segregation (CQRS) pattern with only 3 endpoints.
|
||||
|
||||
**The 3 Endpoints:**
|
||||
|
||||
```
|
||||
1. POST /command
|
||||
- Send any write operation (create, update, delete)
|
||||
- Body specifies command type and parameters
|
||||
- Example:
|
||||
{
|
||||
"command": "createTask",
|
||||
"data": {"title": "Write docs", "projectId": "proj-123"}
|
||||
}
|
||||
|
||||
2. POST /query
|
||||
- Retrieve any data (list, get, search, filter)
|
||||
- Body specifies query type and parameters
|
||||
- Example:
|
||||
{
|
||||
"query": "getTasks",
|
||||
"filters": {"completed": false, "projectId": "proj-123"},
|
||||
"sort": ["-dueDate"],
|
||||
"limit": 20
|
||||
}
|
||||
|
||||
3. GET /
|
||||
- API schema and available commands/queries
|
||||
- Self-documenting entry point
|
||||
```
|
||||
|
||||
**How constraints shaped it:**
|
||||
|
||||
3-endpoint constraint forced us completely away from REST resource-based thinking toward command/query pattern. We couldn't map resources to endpoints, so we mapped *intentions* (commands/queries) to a single endpoint each. This wouldn't exist in unconstrained design because REST resource mapping is default pattern.
|
||||
|
||||
**Strengths:**
|
||||
- Ultimate minimalism: 3 endpoints total
|
||||
- Clear separation of reads (queries) vs writes (commands)
|
||||
- All commands versioned and auditable (event sourcing compatible)
|
||||
- Extremely flexible (add new commands without new endpoints)
|
||||
|
||||
**Risks/Limitations:**
|
||||
- Not REST (breaks HTTP verb semantics)
|
||||
- POST for queries feels wrong to REST purists
|
||||
- Loses HTTP caching benefits (GET query would cache better)
|
||||
- Requires comprehensive command/query documentation
|
||||
|
||||
### Solution 3: Smart Defaults API
|
||||
|
||||
**Description:**
|
||||
|
||||
5 endpoints with "intelligent defaults" that make common use cases zero-config while allowing full customization.
|
||||
|
||||
**The 5 Endpoints:**
|
||||
|
||||
```
|
||||
1. GET /
|
||||
- Entry point + documentation
|
||||
|
||||
2. POST /{resource}
|
||||
- Create with smart defaults
|
||||
- Example: POST /tasks with just {"title": "Write docs"}
|
||||
- Auto-assigns: current user, default project, due date (24h from now)
|
||||
|
||||
3. GET /{resource}
|
||||
- Defaults to useful view (not everything)
|
||||
- GET /tasks → uncompleted tasks for current user, sorted by due date
|
||||
- Full query: GET /tasks?view=all&user=*&completed=*
|
||||
|
||||
4. GET /{resource}/{id}
|
||||
- Retrieve specific item
|
||||
- Response includes related items intelligently
|
||||
- GET /tasks/123 → includes project, assigned user, recent comments (last 5)
|
||||
|
||||
5. POST /{resource}/{id}/action
|
||||
- Semantic actions instead of PATCH
|
||||
- POST /tasks/123/complete (vs PATCH with {"completed": true})
|
||||
- POST /tasks/123/assign?userId=456
|
||||
- POST /tasks/123/move?projectId=789
|
||||
```
|
||||
|
||||
**How constraints shaped it:**
|
||||
|
||||
5-endpoint limit meant we couldn't have separate endpoints for common actions (complete task, assign task, move task, etc.). Instead of PATCH with various payloads, we created semantic action endpoint that's more intuitive for developers. The constraint forced us to think: "What actions do developers actually want?" vs "What CRUD operations exist?"
|
||||
|
||||
**Strengths:**
|
||||
- Developer-friendly (semantic actions match mental model)
|
||||
- Smart defaults reduce API calls (get task includes related data)
|
||||
- Progressive disclosure (simple cases are simple, complex cases possible)
|
||||
|
||||
**Risks/Limitations:**
|
||||
- "Actions" endpoint could grow complex
|
||||
- Magic defaults might surprise users
|
||||
- Less "pure REST" than Solution 1
|
||||
|
||||
## Evaluation
|
||||
|
||||
**Constraint compliance:** ✓ All solutions respect 5-endpoint max (Solution 2 uses only 3), single-page documentation, and no deep nesting
|
||||
|
||||
**Novelty assessment:** All solutions are novel (score: 5/5)
|
||||
- Solution 1: Hypermedia-driven design is uncommon in modern APIs
|
||||
- Solution 2: Command-Query pattern breaks REST entirely (radical)
|
||||
- Solution 3: Semantic actions vs CRUD is differentiated
|
||||
- None would exist with unconstrained design (would default to 23-endpoint CRUD API)
|
||||
|
||||
**Problem fit:** Solutions address original challenge
|
||||
- **Developer onboarding < 5 min:** ✓ GET / self-documents, simple patterns
|
||||
- **Single-page docs:** ✓ All solutions achievable with 1-page documentation
|
||||
- **Differentiation:** ✓ All three approaches are memorable vs typical REST APIs
|
||||
- **Supports use cases:** ✓ Generic patterns support all original use cases
|
||||
|
||||
**Actionability:** All three designs can be implemented immediately
|
||||
|
||||
## Creative Breakthrough Explanation
|
||||
|
||||
The constraint-driven breakthrough happened when we stopped asking "How do we fit 23 endpoints into 5?" and started asking "How do we design an API that only needs 5 endpoints?"
|
||||
|
||||
**Thinking pattern broken:**
|
||||
- Old pattern: "Each use case needs an endpoint" (additive thinking)
|
||||
- New pattern: "Each endpoint should handle multiple use cases" (multiplicative thinking)
|
||||
|
||||
**Unexpected angle revealed:**
|
||||
Minimalism isn't about removing features - it's about better abstraction. Generic `/{resource}` pattern with query params provides MORE flexibility than specific endpoints, not less.
|
||||
|
||||
**Why wouldn't this exist in unconstrained brainstorming:**
|
||||
With no constraints, we defaulted to REST "best practices" which led to endpoint proliferation. The 5-endpoint constraint forced us to question whether those "best practices" were actually best for developer experience. Turns out, simplicity beats completeness for DX.
|
||||
|
||||
**Real-world validation:**
|
||||
- Stripe API: Uses resource patterns (minimal endpoints)
|
||||
- GitHub API v3→v4: Moved from REST to GraphQL (single endpoint) for exactly this reason
|
||||
- Twilio API: Consistent resource patterns across all products
|
||||
|
||||
The constraint helped us discover patterns that successful APIs already use.
|
||||
|
||||
## Next Steps
|
||||
|
||||
**Decision:** Implement Solution 1 (Hypermedia-Driven Minimalist API) as primary design
|
||||
|
||||
**Rationale:**
|
||||
- Maintains REST principles (HTTP verbs matter)
|
||||
- Self-documenting (GET / returns structure)
|
||||
- Most familiar to developers (resource-based)
|
||||
- Proven pattern (HAL, JSON:API specs exist)
|
||||
- Best balance of minimalism and usability
|
||||
|
||||
**Immediate actions:**
|
||||
1. Create OpenAPI spec for 5 endpoints (TODAY)
|
||||
2. Build prototype implementation (THIS WEEK)
|
||||
3. User test with 5 developers (NEXT WEEK)
|
||||
4. Measure onboarding time (target: < 5 minutes to first successful call)
|
||||
5. Write single-page documentation (NEXT WEEK)
|
||||
|
||||
**Success metrics:**
|
||||
- Time to first API call (target: < 5 min)
|
||||
- Documentation page count (target: 1 page)
|
||||
- Developer satisfaction (NPS after onboarding)
|
||||
- Comparison: Our 5 endpoints vs competitor's 20+ endpoints
|
||||
|
||||
## Self-Assessment (using rubric)
|
||||
|
||||
**Constraint Integrity (5/5):** Rigorous adherence. Solution 1 uses exactly 5 endpoints. Documentation will fit on single page (verified with draft). No nesting beyond 2 levels.
|
||||
|
||||
**Constraint-Creativity Causality (5/5):** Clear causality. Generic `/{resource}` pattern exists ONLY because 5-endpoint limit forbid per-use-case endpoints. Hypermedia self-documentation exists because single-page constraint forced self-documenting design.
|
||||
|
||||
**Idea Volume & Quality (5/5):** Generated 15+ distinct API designs across 4 constraint levels. Top 3 solutions all score 5/5 novelty.
|
||||
|
||||
**Problem-Solution Fit (5/5):** All solutions hit success criteria: < 5 min onboarding, single-page docs, differentiation, full capability.
|
||||
|
||||
**Actionability (5/5):** Solution 1 includes OpenAPI spec, code examples, implementation notes, and testing plan. Can implement immediately.
|
||||
|
||||
**Technical Rigor (5/5):** Solutions are architecturally sound. Hypermedia pattern is proven (HAL/JSON:API specs). Resource abstraction is clean.
|
||||
|
||||
**Differentiation (5/5):** Design differentiates through minimalism (5 vs 23 endpoints), self-documentation (GET /), and developer experience focus.
|
||||
|
||||
**Risk Honesty (4/5):** Acknowledged risks (hypermedia learning curve, query param complexity). Could add more mitigation details.
|
||||
|
||||
**Documentation Quality (5/5):** Complete constraint-based-creativity.md file with full examples, code snippets, evaluation.
|
||||
|
||||
**Breakthrough Clarity (5/5):** Explicitly explained how constraints drove creativity. Pattern shift from additive (endpoint per use case) to multiplicative (endpoint handles multiple use cases) is clearly articulated.
|
||||
|
||||
**Overall Score: 4.9/5**
|
||||
|
||||
API design is ready for implementation. Constraint-driven approach produced significantly better developer experience than unconstrained "REST best practices" approach.
|
||||
@@ -0,0 +1,404 @@
|
||||
# Constraint-Based Creativity: Product Launch Guerrilla Marketing
|
||||
|
||||
## Problem Statement
|
||||
|
||||
Launch a new B2B SaaS product (team collaboration tool) to market with goal of 1,000 signups in first month. Need creative marketing campaign that gets attention in crowded market.
|
||||
|
||||
## Context
|
||||
|
||||
**What's been tried:** Traditional approaches considered
|
||||
- Paid ads on LinkedIn ($20K/month budget quoted)
|
||||
- Content marketing (would take 6+ months to build audience)
|
||||
- Conference sponsorships ($15K-50K per event)
|
||||
- PR agency ($10K/month retainer)
|
||||
|
||||
**Why we're stuck:** All conventional approaches require significant budget we don't have. Team defaulting to "we can't compete without money" mindset. Ideas feel defeated before starting.
|
||||
|
||||
**Success criteria:**
|
||||
- Generate 1,000 signups in 30 days
|
||||
- Cost per acquisition under $5
|
||||
- Build brand awareness in target market (engineering/product teams at tech companies)
|
||||
- Create memorable, differentiated campaign
|
||||
|
||||
## Active Constraints
|
||||
|
||||
**Constraint 1: Budget - $500 Maximum Total Spend**
|
||||
- **Rationale:** Forces creativity beyond paid media. Can't outspend competitors, so must out-think them. Low budget eliminates expensive conventional tactics.
|
||||
- **Enforcement:** All tactics must have documented costs under $500 total.
|
||||
|
||||
**Constraint 2: Platform - Twitter + GitHub Only**
|
||||
- **Rationale:** Forces focus. Instead of spreading thin across all channels, dominate where target audience (developers/PMs) already congregates.
|
||||
- **Enforcement:** No tactics on LinkedIn, Facebook, Instagram, or other platforms. Twitter and GitHub are the entire playing field.
|
||||
|
||||
**Constraint 3: No Paid Promotion**
|
||||
- **Rationale:** Organic virality only. Forces ideas to be inherently shareable/interesting rather than amplified by money.
|
||||
- **Enforcement:** Zero ad spend. No boosted posts, no sponsored content, no influencer payments.
|
||||
|
||||
## Idea Generation Process
|
||||
|
||||
**Technique used:** Constraint Rotation Sprints (3 rounds of 10 minutes each)
|
||||
|
||||
**Volume:** Generated 32 ideas across 3 constraint focus rounds
|
||||
|
||||
**Mindset:** Initial resistance ("this is impossible"), but by round 2 team energized by the challenge. Constraint difficulty unlocked creativity.
|
||||
|
||||
## All Ideas Generated
|
||||
|
||||
### Round 1: Focus on $500 budget constraint (10 ideas)
|
||||
|
||||
1. Free stickers ($200) mailed to anyone who requests
|
||||
- Compliance: ✓ | Assessment: Cute but low impact
|
||||
|
||||
2. $500 bounty for best integration built by community
|
||||
- Compliance: ✓ | Assessment: Interesting, engages devs
|
||||
|
||||
3. Sponsor a small hackathon ($500 venue/pizza)
|
||||
- Compliance: ✓ | Assessment: Limited reach, one-time
|
||||
|
||||
4. Create 100 GitHub repos demonstrating use cases ($0)
|
||||
- Compliance: ✓ | Assessment: SEO value, educational
|
||||
|
||||
5. Daily Twitter threads documenting "building in public" ($0)
|
||||
- Compliance: ✓ | Assessment: Authentic, takes time
|
||||
|
||||
6. "Tiny budget challenge": Document building company on $500
|
||||
- Compliance: ✓ | Assessment: Meta and interesting
|
||||
|
||||
7. Commission artwork ($500) from developer-artist, make it public domain
|
||||
- Compliance: ✓ | Assessment: Unique, ownable asset
|
||||
|
||||
8. Create CLI tool that's actually useful, includes subtle product promo ($0)
|
||||
- Compliance: ✓ | Assessment: Value-first approach
|
||||
|
||||
9. Host AMA on r/programming ($0) + Twitter Spaces ($0)
|
||||
- Compliance: ✓ | Assessment: Direct engagement, authentic
|
||||
|
||||
10. Create comprehensive benchmark comparison ($0 research time)
|
||||
- Compliance: ✓ | Assessment: SEO + authority building
|
||||
|
||||
### Round 2: Focus on Twitter + GitHub only (12 ideas)
|
||||
|
||||
11. 30-day Twitter thread series: "Things I learned building our product"
|
||||
- Compliance: ✓ | Assessment: Storytelling, serialized content
|
||||
|
||||
12. GitHub Actions workflow that developers can actually use (free distribution)
|
||||
- Compliance: ✓ | Assessment: Utility-first, viral potential
|
||||
|
||||
13. Live-code on Twitter (video) building common integration
|
||||
- Compliance: ✓ | Assessment: Educational, shows product value
|
||||
|
||||
14. Create "anti-roadmap" GitHub repo (what we WON'T build and why)
|
||||
- Compliance: ✓ | Assessment: Contrarian, honest, refreshing
|
||||
|
||||
15. Twitter bot that solves common developer problem, mentions product
|
||||
- Compliance: ✗ (might feel spammy) | Assessment: Risky
|
||||
|
||||
16. "Tiny tools" GitHub org: 50 micro-tools, all showcase product API
|
||||
- Compliance: ✓ | Assessment: SEO + utility, long-tail
|
||||
|
||||
17. GitHub issue templates that non-customers can use
|
||||
- Compliance: ✓ | Assessment: Generous, builds goodwill
|
||||
|
||||
18. Tweet source code snippets daily with "how it works" explanations
|
||||
- Compliance: ✓ | Assessment: Transparency, educational
|
||||
|
||||
19. Create GitHub "awesome list" for collaboration tools (include ours honestly)
|
||||
- Compliance: ✓ | Assessment: Authority, fair comparison
|
||||
|
||||
20. Run "Twitter office hours" - answer any dev question daily for 30 days
|
||||
- Compliance: ✓ | Assessment: Time-intensive but high engagement
|
||||
|
||||
21. Create memorable Twitter personality/voice (snarky? earnest? technical?)
|
||||
- Compliance: ✓ | Assessment: Differentiation through tone
|
||||
|
||||
22. GitHub repo: "Interview questions for team collaboration tools"
|
||||
- Compliance: ✓ | Assessment: Helps buyers evaluate ALL tools (generous)
|
||||
|
||||
### Round 3: Focus on organic virality (10 ideas)
|
||||
|
||||
23. "The $500 Company" - Document entire launch journey publicly
|
||||
- Compliance: ✓ | Assessment: ⭐ Meta-story, highly shareable
|
||||
|
||||
24. Create genuinely useful free tools first, product second
|
||||
- Compliance: ✓ | Assessment: ⭐ Value-first, builds trust
|
||||
|
||||
25. Controversial take: "Why most collaboration tools are built wrong"
|
||||
- Compliance: ✓ | Assessment: Attention-grabbing, risky
|
||||
|
||||
26. Show real revenue numbers publicly (radical transparency)
|
||||
- Compliance: ✓ | Assessment: Differentiated, bold
|
||||
|
||||
27. Create "Collaboration Tool Bingo" card (poke fun at industry clichés)
|
||||
- Compliance: ✓ | Assessment: ⭐ Funny, relatable, shareable
|
||||
|
||||
28. "Build your own [our product]" tutorial (gives away the secret sauce)
|
||||
- Compliance: ✓ | Assessment: ⭐ Generous, confident, educational
|
||||
|
||||
29. Rate competitors honestly on public spreadsheet (include ourselves)
|
||||
- Compliance: ✓ | Assessment: Brave, helpful, trustworthy
|
||||
|
||||
30. Create crisis/incident templates (free, useful, shows product in action)
|
||||
- Compliance: ✓ | Assessment: Timely, practical value
|
||||
|
||||
31. Start movement: "#NoMoreMeetings challenge" with our tool
|
||||
- Compliance: ✓ | Assessment: ⭐ Aligns with pain point, movement potential
|
||||
|
||||
32. Apologize publicly for something competitors do (but we don't)
|
||||
- Compliance: ✓ | Assessment: ⭐ Contrarian positioning
|
||||
|
||||
## Insights from "Failed" Ideas
|
||||
|
||||
- **Idea #15 (Twitter bot):** Too promotional, violates "organic virality" spirit even if technically compliant
|
||||
- **Constraint tension revealed:** Hardest challenge is being interesting enough to spread WITHOUT money for amplification
|
||||
- **Pattern observed:** Ideas scoring ⭐ all share "generosity" angle - give away something valuable for free
|
||||
|
||||
## Top Solutions (Refined)
|
||||
|
||||
### Solution 1: "The $500 Startup" Public Journey
|
||||
|
||||
**Description:**
|
||||
|
||||
Launch product AND document the entire journey publicly as "The $500 Startup Challenge." Every dollar spent, every decision made, every failure encountered - shared in real-time via Twitter threads and GitHub repo.
|
||||
|
||||
- **Twitter:** Daily thread updates (wins, losses, learnings, numbers)
|
||||
- **GitHub:** Public repo with all costs tracked, decisions documented, templates/tools shared
|
||||
- **Deliverables:** 30-day chronicle becomes case study, templates, and playbook others can use
|
||||
|
||||
**How constraints shaped it:**
|
||||
|
||||
This solution exists ONLY because of the constraints. With unlimited budget, we'd run conventional ads and never think to turn our limitation into our story. The $500 constraint became the entire narrative hook - it's not a bug, it's the feature. Platform constraint (Twitter + GitHub) forced us to storytelling formats (threads + repos) rather than polished landing pages. Organic-only constraint meant the story itself must be compelling enough to spread.
|
||||
|
||||
**Strengths:**
|
||||
- Authentic and relatable (most startups are resource-constrained)
|
||||
- Built-in narrative tension ("Can they succeed on $500?")
|
||||
- Educational value (others learn from the journey)
|
||||
- Differentiates through transparency (competitors hide their budgets)
|
||||
- Meta-viral (the campaign IS the story)
|
||||
- Generates daily content without feeling promotional
|
||||
|
||||
**Implementation notes:**
|
||||
|
||||
**Week 1:** Launch announcement
|
||||
- Tweet: "We're launching a B2B SaaS product with a $500 budget. Total. Here's the plan: [thread]"
|
||||
- GitHub repo: Create "500-dollar-startup" repo with budget tracker ($500 remaining)
|
||||
- Commit: Daily updates to README with spend tracking
|
||||
|
||||
**Week 2-4:** Daily chronicle
|
||||
- Daily Twitter thread (7am): Yesterday's progress, today's plan, $ spent, learning
|
||||
- Every dollar spent gets GitHub commit with rationale
|
||||
- Weekend: Long-form recap threads (3-5 tweets)
|
||||
- Engage authentically with every reply/question
|
||||
|
||||
**Week 4:** Results summary
|
||||
- Final thread: Total signups, CAC, what worked/didn't, full financial breakdown
|
||||
- GitHub: Release all templates, scripts, playbooks as MIT licensed
|
||||
- Turn journey into permanent case study/resource
|
||||
|
||||
**Budget allocation:**
|
||||
- Domain name: $12
|
||||
- Hosting (1 month): $5
|
||||
- Stickers (50): $100 (given to first 50 signups as "founding users")
|
||||
- GitHub Actions runner time: $20 (for automated tools we build)
|
||||
- Twitter spaces hosting tools: $0 (free)
|
||||
- Reserved for experiments: $363
|
||||
|
||||
**Risks/Limitations:**
|
||||
- Requires consistent daily effort (30 days straight)
|
||||
- Vulnerability - public failure if we don't hit goals
|
||||
- Could appear gimmicky if not executed authentically
|
||||
- Copycat risk (others could run same constraint challenge)
|
||||
|
||||
### Solution 2: "Generous Engineering" - Free Tools Arsenal
|
||||
|
||||
**Description:**
|
||||
|
||||
Build and open-source 10-15 genuinely useful dev tools/templates/workflows over 30 days, all showcasing product integration. Each tool solves a real problem for target audience. Tools live on GitHub, announced on Twitter, zero promotion - just pure utility.
|
||||
|
||||
Tools include:
|
||||
1. GitHub Actions workflow for team notifications
|
||||
2. Incident response templates (runbooks)
|
||||
3. Meeting cost calculator (Chrome extension)
|
||||
4. Async standup bot (open source)
|
||||
5. Team health check template
|
||||
6. Collaboration metrics dashboard (open source)
|
||||
7. "Decision log" template
|
||||
8. Onboarding checklist generator
|
||||
9. Team documentation starter kit
|
||||
10. Integration examples repository
|
||||
|
||||
**How constraints shaped it:**
|
||||
|
||||
Budget constraint eliminated paid distribution, forcing "valuable enough to spread organically" approach. Can't buy attention, so must earn it through utility. Platform constraint (GitHub + Twitter) matches where devs already are - distribute where they work. Organic-only constraint means tools must be NO-STRINGS-ATTACHED valuable. Product mention is subtle (integration examples), not pushy.
|
||||
|
||||
**Strengths:**
|
||||
- Builds genuine goodwill (helping before selling)
|
||||
- SEO value (10-15 repos ranking for relevant searches)
|
||||
- Demonstrates product capability (integration examples)
|
||||
- Long-tail value (tools keep attracting users after 30 days)
|
||||
- Community contribution potential (others fork/improve)
|
||||
- Positions team as "engineers who build useful things"
|
||||
|
||||
**Implementation notes:**
|
||||
|
||||
**Pre-launch:** Build 5 tools completely, outline next 5
|
||||
**Days 1-5:** Launch 1 tool per day
|
||||
- GitHub: Release with comprehensive README
|
||||
- Twitter: Announce with demo GIF, use case, why we built it
|
||||
- Zero product mention in tool itself
|
||||
- Links to product only in "built by" footer
|
||||
|
||||
**Days 6-15:** Continue tool releases + community engagement
|
||||
- Respond to GitHub issues
|
||||
- Merge community PRs
|
||||
- Share user success stories
|
||||
|
||||
**Days 16-30:** Integration showcase
|
||||
- Create "using these tools with [product]" examples
|
||||
- Not required, but available for those interested
|
||||
- Focus remains on tool utility
|
||||
|
||||
**Budget allocation:**
|
||||
- Domain for tools site: $12
|
||||
- Hosting (static site): $5
|
||||
- GitHub Actions CI: $20
|
||||
- Designer time for og:images ($50 Fiverr): $50
|
||||
- Reserved: $413
|
||||
|
||||
**Risks/Limitations:**
|
||||
- Requires significant engineering time (building 10-15 tools)
|
||||
- Tools must actually be useful (not vaporware)
|
||||
- Delayed attribution (hard to track which tool drove which signup)
|
||||
- Others could copy tools without attributing
|
||||
|
||||
### Solution 3: "Collaboration Tool Bingo" + Movement
|
||||
|
||||
**Description:**
|
||||
|
||||
Create shareable "Collaboration Tool Bingo" card that pokes fun at industry clichés ("Synergy!", "Seamless integration!", "Revolutionize teamwork!", "10x productivity!"). Make it funny, relatable, and slightly self-deprecating. Launch #CollabToolBingo movement on Twitter.
|
||||
|
||||
Launch with manifesto: "Most collaboration tools over-promise and under-deliver. Here's what we're building instead" + anti-bingo commitment (what we WON'T do).
|
||||
|
||||
**How constraints shaped it:**
|
||||
|
||||
Organic virality constraint forced "inherently shareable" approach - bingo cards are easy to screenshot and share. Budget constraint means can't buy attention, so must create "social currency" through humor. Platform constraint (Twitter) perfect for viral image-based content. This solution is pure constraint-driven creativity - wouldn't exist with paid media budget.
|
||||
|
||||
**Strengths:**
|
||||
- Highly shareable (humor + relatable)
|
||||
- Positions product through contrast (anti-cliché stance)
|
||||
- Low effort to participate (#CollabToolBingo tweets)
|
||||
- Starts conversation about industry problems
|
||||
- Memorable and distinctive
|
||||
- Can evolve into movement/community
|
||||
|
||||
**Implementation notes:**
|
||||
|
||||
**Day 1:** Launch bingo card
|
||||
- Tweet bingo card image (16 clichés in 4x4 grid)
|
||||
- Thread: "If collaboration tools were honest" with explanation
|
||||
- Pin tweet for 30 days
|
||||
|
||||
**Day 2-7:** Encourage participation
|
||||
- Retweet best bingo completions
|
||||
- Add new clichés based on community suggestions
|
||||
- Create "Bingo Hall of Fame" for funniest examples
|
||||
|
||||
**Day 8-15:** Launch "Anti-Bingo Manifesto"
|
||||
- "We took the Bingo Card seriously. Here's what we're NOT building"
|
||||
- Commit publicly to avoiding each cliché
|
||||
- Explain how we're different
|
||||
|
||||
**Day 16-30:** Community content
|
||||
- User-generated bingo cards
|
||||
- "Before/After" bingo (what they had vs what they wanted)
|
||||
- Expand into other SaaS bingo cards (community-driven)
|
||||
|
||||
**Budget allocation:**
|
||||
- Designer for bingo card: $150 (Fiverr)
|
||||
- Domain for bingo microsite: $12
|
||||
- Hosting: $5
|
||||
- Reserved: $333
|
||||
|
||||
**Risks/Limitations:**
|
||||
- Humor could fall flat or offend
|
||||
- Negative framing (criticizing competitors) could backfire
|
||||
- Requires cultural awareness (clichés must be universally recognized)
|
||||
- One-hit-wonder risk (viral moment doesn't translate to signups)
|
||||
|
||||
## Evaluation
|
||||
|
||||
**Constraint compliance:** ✓ All three solutions respect $500 budget, Twitter+GitHub platforms, and organic-only distribution
|
||||
|
||||
**Novelty assessment:** All three solutions are novel (score: 5/5)
|
||||
- None would exist with unlimited budget (would run conventional ads instead)
|
||||
- Constraints directly shaped the creative direction
|
||||
- No competitors doing "The $500 Startup" or "Collaboration Bingo" campaigns
|
||||
|
||||
**Problem fit:** Solutions address original challenge
|
||||
- **1,000 signups:** Viral potential + daily engagement + educational value = traffic
|
||||
- **Under $5 CAC:** All solutions well under $500 for 1K signups = $0.50 CAC if successful
|
||||
- **Brand awareness:** All three create memorable moments in target community
|
||||
- **Differentiation:** Transparency, generosity, humor = distinct from competitor marketing
|
||||
|
||||
**Actionability:** All three can be executed immediately with existing team and budget
|
||||
|
||||
## Creative Breakthrough Explanation
|
||||
|
||||
The constraint-driven breakthroughs happened when we stopped viewing $500 as a limitation and started viewing it as:
|
||||
1. **The story** (Solution 1: The $500 constraint became the campaign narrative)
|
||||
2. **The focus** (Solution 2: Can't spread wide, so go deep with utility)
|
||||
3. **The freedom** (Solution 3: No budget for safe/boring, so take creative risks)
|
||||
|
||||
**Thinking pattern broken:** "We need money to market" → "Our lack of money IS the marketing"
|
||||
|
||||
**Unexpected angle revealed:** Transparency and vulnerability as differentiation strategy. Competitors hide their budgets and processes; we make ours the whole campaign.
|
||||
|
||||
**Why wouldn't this exist in unconstrained brainstorming:** With $50K budget, we'd run LinkedIn ads and content marketing - conventional but forgettable. The $500 constraint forced us to think "What can ONLY we do with $500 that creates more attention than $50K in ads?" Answer: Turn the limitation into the story.
|
||||
|
||||
## Next Steps
|
||||
|
||||
**Decision:** Execute Solution 1 ("The $500 Startup") as primary campaign
|
||||
|
||||
**Rationale:**
|
||||
- Highest narrative tension (can they succeed?)
|
||||
- Generates daily content (30 days of touchpoints)
|
||||
- Most authentic (real constraints, real challenges)
|
||||
- Educational value outlasts 30 days (becomes permanent resource)
|
||||
|
||||
**Immediate actions:**
|
||||
1. Create GitHub repo "500-dollar-startup" with budget tracker (TODAY)
|
||||
2. Draft launch tweet thread (TOMORROW)
|
||||
3. Set up daily reminder for chronicle posts (TOMORROW)
|
||||
4. Build in public starting Day 1 (THIS WEEK)
|
||||
|
||||
**Success metrics:**
|
||||
- Twitter followers gained
|
||||
- GitHub repo stars
|
||||
- Website signups (tracked via /500 UTM)
|
||||
- Media mentions
|
||||
- Community engagement (replies, retweets, issues)
|
||||
|
||||
## Self-Assessment (using rubric)
|
||||
|
||||
**Constraint Integrity (5/5):** All constraints rigorously respected. No bending rules. $500 is absolute limit. Twitter+GitHub only. Zero paid promotion.
|
||||
|
||||
**Constraint-Creativity Causality (5/5):** Clear causality. These solutions exist BECAUSE of constraints, not despite them. Limitation became feature.
|
||||
|
||||
**Idea Volume & Quality (5/5):** Generated 32 ideas in 30 minutes. Top 3 solutions are all novel (score 5/5 on novelty). Documented "failed" ideas and learnings.
|
||||
|
||||
**Problem-Solution Fit (5/5):** All solutions address 1,000 signup goal, CAC target, brand awareness, and differentiation.
|
||||
|
||||
**Actionability (5/5):** Solutions have detailed implementation plans, budget breakdowns, timeline, and next steps. Can execute immediately.
|
||||
|
||||
**Strategic Insight (5/5):** Core insight is "constraint as campaign" - turning limitation into narrative advantage. This is replicable pattern for other resource-constrained launches.
|
||||
|
||||
**Differentiation (5/5):** None of these campaigns exist in competitor space. Transparency and vulnerability as strategy is highly differentiated.
|
||||
|
||||
**Risk Honesty (4/5):** Acknowledged risks (public failure, consistency required, vulnerability, copycat risk). Could add more mitigation strategies.
|
||||
|
||||
**Documentation Quality (5/5):** Complete constraint-based-creativity.md file with all sections, metrics, causality explanation.
|
||||
|
||||
**Breakthrough Clarity (5/5):** Explicitly explained how constraints drove creativity. Identified thinking pattern broken: "need money" → "lack of money IS the story."
|
||||
|
||||
**Overall Score: 4.9/5**
|
||||
|
||||
Campaign is ready for execution. Constraint-driven creativity successfully unlocked novel, differentiated, actionable marketing approach.
|
||||
479
skills/constraint-based-creativity/resources/methodology.md
Normal file
479
skills/constraint-based-creativity/resources/methodology.md
Normal file
@@ -0,0 +1,479 @@
|
||||
# Constraint-Based Creativity: Advanced Methodology
|
||||
|
||||
## Workflow
|
||||
|
||||
Copy this checklist and track your progress:
|
||||
|
||||
```
|
||||
Advanced Constraint-Based Creativity:
|
||||
- [ ] Step 1: Diagnose the creative block systematically
|
||||
- [ ] Step 2: Design strategic constraints using frameworks
|
||||
- [ ] Step 3: Apply advanced generation techniques
|
||||
- [ ] Step 4: Use constraint combinations and escalation
|
||||
- [ ] Step 5: Troubleshoot and adapt
|
||||
```
|
||||
|
||||
**Step 1: Diagnose the creative block systematically**
|
||||
|
||||
Use [1. Diagnosing Creative Blocks](#1-diagnosing-creative-blocks) to identify root cause (abundance paralysis, pattern fixation, resource anxiety, etc.). Understanding the block type determines optimal constraint design.
|
||||
|
||||
**Step 2: Design strategic constraints using frameworks**
|
||||
|
||||
Apply [2. Strategic Constraint Design](#2-strategic-constraint-design) frameworks to create constraints that directly counter the diagnosed block. Use constraint design principles and psychology insights from [3. Psychology of Constraints](#3-psychology-of-constraints).
|
||||
|
||||
**Step 3: Apply advanced generation techniques**
|
||||
|
||||
Use methods from [4. Advanced Idea Generation](#4-advanced-idea-generation) including parallel constraint exploration, constraint rotation sprints, and meta-constraint thinking. These techniques maximize creative output.
|
||||
|
||||
**Step 4: Use constraint combinations and escalation**
|
||||
|
||||
Apply [5. Constraint Combination Patterns](#5-constraint-combination-patterns) to layer multiple constraints strategically. Use [6. Constraint Escalation](#6-constraint-escalation) to progressively tighten constraints for breakthrough moments.
|
||||
|
||||
**Step 5: Troubleshoot and adapt**
|
||||
|
||||
If constraints aren't working, use [7. Troubleshooting](#7-troubleshooting) to diagnose and fix. Adapt constraints based on what's (not) working.
|
||||
|
||||
---
|
||||
|
||||
## 1. Diagnosing Creative Blocks
|
||||
|
||||
Before designing constraints, diagnose WHY creativity is stuck:
|
||||
|
||||
### Block Type 1: Abundance Paralysis
|
||||
**Symptoms:** Too many options, can't decide, everything feels possible but nothing feels right
|
||||
**Root cause:** Unlimited freedom creates decision anxiety
|
||||
**Best constraint types:** Resource (force scarcity), Format (force specificity)
|
||||
**Example constraint:** "Choose from exactly 3 options" or "$500 budget only"
|
||||
|
||||
### Block Type 2: Pattern Fixation
|
||||
**Symptoms:** All ideas feel similar, defaulting to "what we always do", conventional thinking
|
||||
**Root cause:** Mental habits, industry best practices dominating, lack of novelty pressure
|
||||
**Best constraint types:** Rule-based (forbid the pattern), Historical (different era), Perspective (different audience)
|
||||
**Example constraint:** "Cannot use industry-standard approach" or "Design as if it's 1950"
|
||||
|
||||
### Block Type 3: Complexity Creep
|
||||
**Symptoms:** Ideas keep getting more elaborate, feature bloat, "we need to add X and Y and Z"
|
||||
**Root cause:** Mistaking complexity for sophistication, no forcing function for simplicity
|
||||
**Best constraint types:** Format (force brevity), Resource (force efficiency), Technical (force optimization)
|
||||
**Example constraint:** "Explain in 10 words" or "Must work on 1990s hardware"
|
||||
|
||||
### Block Type 4: Resource Anxiety
|
||||
**Symptoms:** "We can't do anything with this budget/time/team", defeatism, giving up before ideating
|
||||
**Root cause:** Viewing limitation as blocker rather than creative fuel
|
||||
**Best constraint types:** Resource Inversion (make limitation the feature), Success Stories (show constraint-driven wins)
|
||||
**Example constraint:** "Create marketing campaign that showcases our tiny budget as advantage"
|
||||
|
||||
### Block Type 5: Incremental Thinking
|
||||
**Symptoms:** Ideas are "better" but not "different", improvements without breakthroughs
|
||||
**Root cause:** Optimization mindset, risk aversion, lack of permission for radical ideas
|
||||
**Best constraint types:** Forced Connection (force novelty), Forbidden Element (force workarounds), Extreme (force dramatic shift)
|
||||
**Example constraint:** "Combine your product with [random unrelated concept]" or "No gradual improvements allowed"
|
||||
|
||||
### Block Type 6: Stakeholder Gridlock
|
||||
**Symptoms:** Every idea gets shot down, conflicting requirements, "we can't satisfy everyone"
|
||||
**Root cause:** Trying to please all stakeholders creates bland compromises
|
||||
**Best constraint types:** Audience (design for ONE stakeholder only), Perspective (extreme user), Polarity (embrace the conflict)
|
||||
**Example constraint:** "Design exclusively for power users, ignore novices" or "Optimize for speed OR quality, not both"
|
||||
|
||||
---
|
||||
|
||||
## 2. Strategic Constraint Design
|
||||
|
||||
Frameworks for designing constraints that unlock creativity:
|
||||
|
||||
### Framework 1: The Counterfactual Principle
|
||||
Design constraints that are the **opposite** of current assumptions.
|
||||
|
||||
**Current assumption → Constraint:**
|
||||
- "We need more features" → "Maximum 3 features"
|
||||
- "We need more time" → "Ship in 48 hours"
|
||||
- "We need bigger budget" → "Spend $100 only"
|
||||
- "We need expert team" → "Design for novice execution"
|
||||
- "We need to add" → "Remove 50% of current"
|
||||
|
||||
### Framework 2: The Subtraction Cascade
|
||||
Remove assumed "essentials" one at a time to reveal what's truly necessary.
|
||||
|
||||
**Process:**
|
||||
1. List all assumed essentials (budget, time, team, features, marketing, etc.)
|
||||
2. For each essential, ask: "What if we had zero X?"
|
||||
3. Generate 5 ideas for zero-X scenario
|
||||
4. Identify which "essential" assumptions are actually optional
|
||||
|
||||
**Example:** E-commerce site
|
||||
- What if zero budget for ads? → Viral/organic/referral strategies emerge
|
||||
- What if zero product photos? → Text-driven, story-driven commerce emerges
|
||||
- What if zero checkout process? → One-click, subscription, or auto-replenish models emerge
|
||||
|
||||
### Framework 3: The Constraint Ladder
|
||||
Progressive constraint tightening to find the creative sweet spot.
|
||||
|
||||
**Level 1 (Gentle):** Constraint is noticeable but comfortable
|
||||
**Level 2 (Challenging):** Constraint forces rethinking but still manageable
|
||||
**Level 3 (Extreme):** Constraint seems impossible, forces radical creativity
|
||||
**Level 4 (Paralyzing):** Constraint too tight, generates zero ideas
|
||||
|
||||
**Example:** Content creation
|
||||
- L1: "Write in 500 words" (comfortable)
|
||||
- L2: "Write in 100 words" (challenging)
|
||||
- L3: "Write in 10 words" (extreme, forces breakthroughs)
|
||||
- L4: "Write in 3 words" (paralysis, too tight)
|
||||
|
||||
Aim for Level 2-3. If hitting Level 4, back off one level.
|
||||
|
||||
### Framework 4: The Medium-as-Constraint
|
||||
Force creativity by changing the medium.
|
||||
|
||||
**Original medium → Constraint medium:**
|
||||
- Strategy document → Strategy as recipe
|
||||
- Product roadmap → Roadmap as movie trailer script
|
||||
- Technical docs → Docs as children's book
|
||||
- Business proposal → Proposal as Shakespearean sonnet
|
||||
- Data presentation → Data as visual art installation
|
||||
|
||||
Medium shift breaks habitual communication patterns.
|
||||
|
||||
---
|
||||
|
||||
## 3. Psychology of Constraints
|
||||
|
||||
Why constraints boost creativity (science-backed principles):
|
||||
|
||||
### Principle 1: Cognitive Load Reduction
|
||||
**Theory:** Unlimited options overwhelm working memory. Constraints reduce cognitive load, freeing mental energy for creativity.
|
||||
**Application:** When team is overwhelmed, add constraints to reduce decision space.
|
||||
**Example:** "Choose from 3 pre-selected options" vs "anything is possible"
|
||||
|
||||
### Principle 2: Breaking Automaticity
|
||||
**Theory:** Brains default to habitual patterns (energy-efficient). Constraints force conscious, deliberate thinking.
|
||||
**Application:** When stuck in patterns, add constraints that forbid the habit.
|
||||
**Example:** "No bullet points" forces different communication structure
|
||||
|
||||
### Principle 3: Psychological Reactance
|
||||
**Theory:** Being told "you can't" triggers motivation to prove you can (within the rules).
|
||||
**Application:** Frame constraints as challenges, not limitations.
|
||||
**Example:** "Design without using any images" becomes a creative challenge
|
||||
|
||||
### Principle 4: Permission Through Limitation
|
||||
**Theory:** Constraints provide "excuse" for radical ideas ("we HAD to because of X").
|
||||
**Application:** Use constraints to create safety for risky ideas.
|
||||
**Example:** "$100 budget" gives permission for guerrilla marketing tactics
|
||||
|
||||
### Principle 5: Forced Combination
|
||||
**Theory:** Constraints force novel combinations that wouldn't occur in unconstrained thinking.
|
||||
**Application:** Use constraints that require merging unrelated concepts.
|
||||
**Example:** "Explain technical architecture using cooking metaphors only"
|
||||
|
||||
---
|
||||
|
||||
## 4. Advanced Idea Generation
|
||||
|
||||
Techniques beyond basic listing:
|
||||
|
||||
### Technique 1: Parallel Constraint Exploration
|
||||
Run multiple constraint sets simultaneously, compare results.
|
||||
|
||||
**Process:**
|
||||
1. Choose 3 different constraint types
|
||||
2. Set timer for 10 minutes per constraint
|
||||
3. Generate ideas for Constraint A (10 min)
|
||||
4. Switch to Constraint B (10 min)
|
||||
5. Switch to Constraint C (10 min)
|
||||
6. Compare: which constraint produced most novel ideas?
|
||||
7. Double down on that constraint type
|
||||
|
||||
**Example:** Logo design
|
||||
- Constraint A: 3 colors maximum → 8 ideas
|
||||
- Constraint B: Circles only → 12 ideas
|
||||
- Constraint C: Black/white only → 15 ideas (winner)
|
||||
- → Continue with black/white constraint
|
||||
|
||||
### Technique 2: Constraint Rotation Sprints
|
||||
Rapid cycling through different constraints to prevent fixation.
|
||||
|
||||
**Process:**
|
||||
1. Set 5-minute timer
|
||||
2. Generate ideas for Constraint 1
|
||||
3. When timer rings, IMMEDIATELY switch to Constraint 2
|
||||
4. Generate for 5 minutes, switch to Constraint 3
|
||||
5. After 3 constraints, review all ideas
|
||||
6. Select strongest, refine for 10 minutes
|
||||
|
||||
Prevents over-thinking any single constraint.
|
||||
|
||||
### Technique 3: Meta-Constraint Thinking
|
||||
Apply constraints to the constraint-selection process itself.
|
||||
|
||||
**Meta-constraints:**
|
||||
- "Must use constraint type I've never tried"
|
||||
- "Must combine 2 opposite constraints" (e.g., "minimal" + "maximal")
|
||||
- "Must choose constraint that scares me"
|
||||
- "Must use constraint from unrelated domain" (e.g., music constraints for business problem)
|
||||
|
||||
### Technique 4: The "Yes, But What If" Ladder
|
||||
Progressive constraint tightening with idea building.
|
||||
|
||||
**Process:**
|
||||
1. Start with idea from loose constraint
|
||||
2. "Yes, but what if [tighter constraint]?" → Adapt idea
|
||||
3. "Yes, but what if [even tighter]?" → Adapt again
|
||||
4. Continue until idea breaks or becomes brilliant
|
||||
|
||||
**Example:** Marketing campaign
|
||||
- Idea: Email newsletter
|
||||
- Yes, but what if no images? → Text-only newsletter with strong copy
|
||||
- Yes, but what if 50 words max? → Punchy, Hemingway-style newsletter
|
||||
- Yes, but what if one sentence only? → Twitter-thread-style micro-newsletter
|
||||
- Yes, but what if 6 words only? → Six-word story newsletter (breaks through!)
|
||||
|
||||
### Technique 5: Constraint Archaeology
|
||||
Mine history for proven constraint-driven successes, adapt to current challenge.
|
||||
|
||||
**Historical constraint successes:**
|
||||
- Twitter's 140 characters → Brevity revolution
|
||||
- Haiku's 5-7-5 syllables → Poetic concision
|
||||
- Dr. Seuss's 50-word challenge (Green Eggs and Ham) → Children's lit classic
|
||||
- Dogme 95 film rules → Cinema movement
|
||||
- Helvetica font (limited character set) → Timeless design
|
||||
|
||||
**Process:**
|
||||
1. Research historical constraint-driven successes in any domain
|
||||
2. Extract the constraint principle
|
||||
3. Adapt to your challenge
|
||||
4. Test if same principle unlocks creativity
|
||||
|
||||
---
|
||||
|
||||
## 5. Constraint Combination Patterns
|
||||
|
||||
Strategic ways to layer multiple constraints:
|
||||
|
||||
### Pattern 1: Complementary Pairing
|
||||
Combine constraints that reinforce each other.
|
||||
|
||||
**Examples:**
|
||||
- Resource + Format: "$100 budget" + "One-page proposal"
|
||||
- Time + Technical: "48-hour deadline" + "Use existing tools only"
|
||||
- Audience + Medium: "For 5-year-olds" + "Visual only, no text"
|
||||
|
||||
**Why it works:** Constraints push in same direction, compounding effect.
|
||||
|
||||
### Pattern 2: Tension Pairing
|
||||
Combine constraints that conflict, forcing creative resolution.
|
||||
|
||||
**Examples:**
|
||||
- "Minimal design" + "Maximum information density"
|
||||
- "Professional tone" + "No corporate jargon"
|
||||
- "Fast execution" + "Zero technical debt"
|
||||
|
||||
**Why it works:** Tension forces innovation to satisfy both.
|
||||
|
||||
### Pattern 3: Progressive Layering
|
||||
Add constraints sequentially, not all at once.
|
||||
|
||||
**Process:**
|
||||
1. Start with Constraint 1 → Generate 10 ideas
|
||||
2. Add Constraint 2 → Adapt best ideas or generate new ones
|
||||
3. Add Constraint 3 → Further refinement
|
||||
|
||||
**Example:** Product launch
|
||||
1. Constraint 1: "Organic channels only" → 10 ideas
|
||||
2. Add Constraint 2: "+ $500 budget max" → 6 adapted ideas
|
||||
3. Add Constraint 3: "+ 48-hour timeline" → 3 final ideas (highly constrained, highly creative)
|
||||
|
||||
### Pattern 4: Domain Transfer
|
||||
Apply constraints from one domain to another.
|
||||
|
||||
**Examples:**
|
||||
- Music constraints → Business (rhythm, harmony, tempo applied to workflow)
|
||||
- Sports constraints → Product (rules, positions, scoring applied to features)
|
||||
- Cooking constraints → Writing (ingredients, timing, presentation applied to content)
|
||||
|
||||
**Why it works:** Cross-domain constraints break industry-specific patterns.
|
||||
|
||||
---
|
||||
|
||||
## 6. Constraint Escalation
|
||||
|
||||
Systematically tightening constraints to find breakthrough moments:
|
||||
|
||||
### The Escalation Curve
|
||||
|
||||
```
|
||||
Constraint Tightness →
|
||||
↑ Creativity
|
||||
Comfort Zone | Moderate ideas
|
||||
Productive Struggle | Interesting ideas
|
||||
Breakthrough | NOVEL ideas ← Target this zone
|
||||
Paralysis | Zero ideas (too tight)
|
||||
```
|
||||
|
||||
### Escalation Process
|
||||
|
||||
**Step 1: Establish Baseline**
|
||||
- Start with loose constraint
|
||||
- Generate 5 ideas
|
||||
- Assess novelty (probably low)
|
||||
|
||||
**Step 2: First Escalation (50% tighter)**
|
||||
- Tighten constraint by half
|
||||
- Generate 5 ideas
|
||||
- Assess novelty (probably moderate)
|
||||
|
||||
**Step 3: Second Escalation (75% tighter)**
|
||||
- Tighten significantly
|
||||
- Generate 5 ideas
|
||||
- Assess novelty (should be high)
|
||||
- **This is usually the breakthrough zone**
|
||||
|
||||
**Step 4: Third Escalation (90% tighter)**
|
||||
- Tighten to near-impossibility
|
||||
- Attempt to generate ideas
|
||||
- If zero ideas → You've hit paralysis, back off to Step 3
|
||||
- If ideas emerge → Exceptional breakthroughs
|
||||
|
||||
### Escalation Examples
|
||||
|
||||
**Budget escalation:**
|
||||
- Baseline: $50K budget → Conventional ideas
|
||||
- 50%: $25K budget → Efficient ideas
|
||||
- 75%: $12.5K budget → Creative ideas
|
||||
- 90%: $5K budget → **Breakthrough** guerrilla ideas
|
||||
- 95%: $2.5K budget → Possible paralysis
|
||||
|
||||
**Time escalation:**
|
||||
- Baseline: 4 weeks → Standard timeline
|
||||
- 50%: 2 weeks → Aggressive timeline
|
||||
- 75%: 1 week → **Breakthrough** rapid ideas
|
||||
- 90%: 48 hours → Extreme ideas or paralysis
|
||||
- 95%: 24 hours → Likely paralysis
|
||||
|
||||
**Feature escalation:**
|
||||
- Baseline: 10 features → Feature bloat
|
||||
- 50%: 5 features → Focused product
|
||||
- 75%: 3 features → **Breakthrough** simplicity
|
||||
- 90%: 1 feature → Single-purpose tool (possible brilliance)
|
||||
- 95%: 0.5 features → Probably paralysis
|
||||
|
||||
---
|
||||
|
||||
## 7. Troubleshooting
|
||||
|
||||
When constraints don't produce creativity:
|
||||
|
||||
### Problem 1: Constraint Too Loose
|
||||
**Symptom:** Ideas feel conventional, no creative tension
|
||||
**Diagnosis:** Constraint isn't actually constraining behavior
|
||||
**Fix:** Escalate constraint (see Section 6). Make it tighter until you feel resistance.
|
||||
|
||||
### Problem 2: Constraint Too Tight
|
||||
**Symptom:** Zero ideas generated, complete paralysis, frustration
|
||||
**Diagnosis:** Constraint exceeded breakthrough zone into paralysis
|
||||
**Fix:** Back off one level. Use Constraint Ladder (Framework 3) to find sweet spot.
|
||||
|
||||
### Problem 3: Wrong Constraint Type
|
||||
**Symptom:** Lots of ideas but none address the original block
|
||||
**Diagnosis:** Constraint doesn't counter the diagnosed creative block
|
||||
**Fix:** Return to Section 1 (Diagnosing Creative Blocks). Match constraint type to block type.
|
||||
|
||||
### Problem 4: Constraint Not Enforced
|
||||
**Symptom:** Ideas "bend" the constraint or ignore it entirely
|
||||
**Diagnosis:** Treating constraint as suggestion rather than rule
|
||||
**Fix:** Make constraint enforcement explicit. Reject any idea that violates constraint.
|
||||
|
||||
### Problem 5: Too Many Constraints
|
||||
**Symptom:** Overwhelmed, don't know where to start, ideas satisfy some constraints but not others
|
||||
**Diagnosis:** Over-constrained (4+ simultaneous constraints)
|
||||
**Fix:** Reduce to 1-2 constraints maximum. Use Progressive Layering (Pattern 3) if multiple constraints needed.
|
||||
|
||||
### Problem 6: Arbitrary Constraint
|
||||
**Symptom:** Constraint feels random, no clear purpose
|
||||
**Diagnosis:** Constraint wasn't strategically designed
|
||||
**Fix:** Use Strategic Constraint Design frameworks (Section 2). Constraint should counter specific block.
|
||||
|
||||
### Problem 7: Evaluating Too Early
|
||||
**Symptom:** Only 3-5 ideas generated before giving up
|
||||
**Diagnosis:** Judging ideas before achieving volume
|
||||
**Fix:** Force 20+ ideas minimum before any evaluation. Quantity first, quality later.
|
||||
|
||||
### Problem 8: Missing the Causality
|
||||
**Symptom:** Solutions are good but could exist without the constraint
|
||||
**Diagnosis:** Not truly constraint-driven creativity
|
||||
**Fix:** Ask: "Would this idea exist in unconstrained brainstorming?" If yes, keep generating. If no, you've found constraint-driven creativity.
|
||||
|
||||
---
|
||||
|
||||
## 8. Advanced Patterns
|
||||
|
||||
### Pattern: Constraint-Driven Positioning
|
||||
Use constraint as market differentiator.
|
||||
|
||||
**Example:** Basecamp's "No" list
|
||||
- Constraint: No enterprise features, no unlimited plans, no customization
|
||||
- Result: Positioned as "simple project management" vs complex competitors
|
||||
- Outcome: Constraint became brand identity
|
||||
|
||||
### Pattern: The Constraint Manifesto
|
||||
Publicly commit to constraints as values.
|
||||
|
||||
**Example:** Craigslist
|
||||
- Constraint: No modern UI, no VC funding, no ads (except jobs/housing)
|
||||
- Result: Authenticity, trustworthiness, community focus
|
||||
- Outcome: Constraint-driven culture
|
||||
|
||||
### Pattern: Constraint as Filter
|
||||
Use constraints to make decisions effortless.
|
||||
|
||||
**Example:** "If it's not a hell yes, it's a no" (Derek Sivers)
|
||||
- Constraint: Binary decision (yes/no only, no maybe)
|
||||
- Result: Clarity, focus, fewer regrets
|
||||
- Outcome: Constraint simplifies complex decisions
|
||||
|
||||
### Pattern: Constraint Stacking
|
||||
Layer constraints over time as you master each.
|
||||
|
||||
**Process:**
|
||||
1. Month 1: Master Constraint A (e.g., "Ship weekly")
|
||||
2. Month 2: Add Constraint B (e.g., "+ under 100 lines")
|
||||
3. Month 3: Add Constraint C (e.g., "+ zero dependencies")
|
||||
4. Result: Constraint-driven expertise
|
||||
|
||||
### Pattern: The Anti-Portfolio
|
||||
Document what you're NOT doing (constraint as strategy).
|
||||
|
||||
**Example:** Y Combinator's anti-portfolio
|
||||
- Constraint: "We passed on X because [reason]"
|
||||
- Result: Learning from constraint violations
|
||||
- Outcome: Refine constraint strategy
|
||||
|
||||
---
|
||||
|
||||
## 9. Constraint Design Workshop
|
||||
|
||||
For teams stuck in creative blocks, run this structured workshop:
|
||||
|
||||
**Pre-Work (15 min):**
|
||||
- Each person lists 5 ideas from unconstrained brainstorming
|
||||
- Share: Notice how similar ideas are
|
||||
|
||||
**Round 1: Diagnosis (15 min):**
|
||||
- As team, diagnose the creative block type (Section 1)
|
||||
- Vote on constraint type to try
|
||||
|
||||
**Round 2: Constraint Generation (30 min):**
|
||||
- Split into 3 groups, each with different constraint
|
||||
- Each group generates 10 ideas in 10 minutes
|
||||
- Share all ideas (30 total)
|
||||
|
||||
**Round 3: Constraint Escalation (20 min):**
|
||||
- Choose winning constraint from Round 2
|
||||
- Tighten it (50% more restrictive)
|
||||
- Generate 10 more ideas as full team
|
||||
|
||||
**Round 4: Evaluation (20 min):**
|
||||
- Identify top 3 ideas
|
||||
- Explain how constraint drove the creativity
|
||||
- Plan next steps
|
||||
|
||||
**Total time:** 100 minutes
|
||||
**Expected outcome:** 40+ ideas, 3 constraint-driven breakthroughs
|
||||
382
skills/constraint-based-creativity/resources/template.md
Normal file
382
skills/constraint-based-creativity/resources/template.md
Normal file
@@ -0,0 +1,382 @@
|
||||
# Constraint-Based Creativity Template
|
||||
|
||||
## Workflow
|
||||
|
||||
Copy this checklist and track your progress:
|
||||
|
||||
```
|
||||
Constraint-Based Creativity Progress:
|
||||
- [ ] Step 1: Gather inputs and clarify the creative challenge
|
||||
- [ ] Step 2: Select or design 1-3 strategic constraints
|
||||
- [ ] Step 3: Generate 20+ ideas within constraints
|
||||
- [ ] Step 4: Evaluate and refine top solutions
|
||||
- [ ] Step 5: Document and validate
|
||||
```
|
||||
|
||||
**Step 1: Gather inputs and clarify the creative challenge**
|
||||
|
||||
Ask user for problem/creative challenge, context (what's been tried, why stuck), success criteria, existing constraints (real limitations), and preferred constraint types (if any). Use [Input Questions](#input-questions) to gather comprehensive context.
|
||||
|
||||
**Step 2: Select or design 1-3 strategic constraints**
|
||||
|
||||
If existing constraints → Work within them creatively. If no constraints → Design strategic ones using [Constraint Selection Guide](#constraint-selection-guide). Maximum 3 constraints to avoid paralysis. Document constraint rationale in the output file.
|
||||
|
||||
**Step 3: Generate 20+ ideas within constraints**
|
||||
|
||||
Use [Idea Generation Techniques](#idea-generation-techniques) to produce volume. Document ALL ideas including "failures" - they contain insights. Aim for 20+ ideas minimum before evaluating. Quality comes after quantity.
|
||||
|
||||
**Step 4: Evaluate and refine top solutions**
|
||||
|
||||
Apply [Evaluation Framework](#evaluation-framework) to select strongest 2-3 ideas. Refine by combining elements, removing complexity, and strengthening the constraint-driven insight. Document why these solutions stand out.
|
||||
|
||||
**Step 5: Document and validate**
|
||||
|
||||
Create `constraint-based-creativity.md` file with complete documentation. Validate using [Quality Checklist](#quality-checklist) before delivering. Ensure constraint-creativity causality is explained.
|
||||
|
||||
---
|
||||
|
||||
## Input Questions
|
||||
|
||||
Ask the user to provide:
|
||||
|
||||
**1. Creative Challenge:**
|
||||
- What needs solving, creating, or improving?
|
||||
- What's the core problem or opportunity?
|
||||
|
||||
**2. Context:**
|
||||
- What's been tried already? Why didn't it work?
|
||||
- Why does ideation feel stuck or stale?
|
||||
- What assumptions are currently in place?
|
||||
|
||||
**3. Success Criteria:**
|
||||
- What does a good solution look like?
|
||||
- How will you know if the constraint-based approach worked?
|
||||
- Are there measurable goals (cost, time, engagement)?
|
||||
|
||||
**4. Existing Constraints (Real Limitations):**
|
||||
- Budget limitations? (exact amount)
|
||||
- Time constraints? (deadline)
|
||||
- Technical limitations? (platform, tools, compatibility)
|
||||
- Material/resource limitations? (team size, equipment)
|
||||
- Regulatory/policy constraints? (legal, compliance)
|
||||
|
||||
**5. Constraint Preferences (Optional):**
|
||||
- Are there specific constraint types that interest you? (resource, format, rule-based, technical, perspective)
|
||||
- Any constraints you want to avoid?
|
||||
- Preference for tight vs loose constraints?
|
||||
|
||||
---
|
||||
|
||||
## Quick Template
|
||||
|
||||
Create file: `constraint-based-creativity.md`
|
||||
|
||||
```markdown
|
||||
# Constraint-Based Creativity: [Project Name]
|
||||
|
||||
## Problem Statement
|
||||
|
||||
[What creative challenge needs solving? Why is it important?]
|
||||
|
||||
## Context
|
||||
|
||||
**What's been tried:** [Previous approaches and why they didn't work]
|
||||
|
||||
**Why we're stuck:** [Pattern that needs breaking - e.g., "All ideas feel incremental" or "Default to expensive solutions"]
|
||||
|
||||
**Success criteria:** [What makes a solution successful? Measurable if possible]
|
||||
|
||||
## Active Constraints
|
||||
|
||||
**Constraint 1: [Type] - [Specific Limitation]**
|
||||
- Rationale: [Why this constraint will unlock creativity]
|
||||
- Enforcement: [How we'll ensure it's respected]
|
||||
|
||||
**Constraint 2: [Type] - [Specific Limitation]**
|
||||
- Rationale: [Why this constraint matters]
|
||||
- Enforcement: [How we'll check compliance]
|
||||
|
||||
**Constraint 3 (if applicable): [Type] - [Specific Limitation]**
|
||||
- Rationale: [Strategic purpose]
|
||||
- Enforcement: [Validation method]
|
||||
|
||||
## Idea Generation Process
|
||||
|
||||
**Technique used:** [e.g., Rapid listing, SCAMPER within constraints, Forced connections]
|
||||
|
||||
**Volume:** Generated [X] ideas in [Y] minutes
|
||||
|
||||
**Mindset:** [Notes on staying within constraints vs urge to bend rules]
|
||||
|
||||
## All Ideas Generated
|
||||
|
||||
1. [Idea 1 - brief description]
|
||||
- Constraint compliance: ✓/✗
|
||||
- Initial assessment: [Quick gut reaction]
|
||||
|
||||
2. [Idea 2]
|
||||
- Constraint compliance: ✓/✗
|
||||
- Initial assessment:
|
||||
|
||||
[Continue for all 20+ ideas...]
|
||||
|
||||
## Insight from "Failed" Ideas
|
||||
|
||||
[Document ideas that broke constraints or didn't work - what did they reveal?]
|
||||
|
||||
## Top Solutions (Refined)
|
||||
|
||||
### Solution 1: [Name/Title]
|
||||
|
||||
**Description:** [Detailed explanation of the solution]
|
||||
|
||||
**How constraints shaped it:** [Explain causality - this solution wouldn't exist without the constraints because...]
|
||||
|
||||
**Strengths:**
|
||||
- [Strength 1]
|
||||
- [Strength 2]
|
||||
- [Strength 3]
|
||||
|
||||
**Implementation notes:** [How to execute this]
|
||||
|
||||
**Risks/Limitations:** [What could go wrong or where it falls short]
|
||||
|
||||
### Solution 2: [Name/Title]
|
||||
|
||||
**Description:** [Detailed explanation]
|
||||
|
||||
**How constraints shaped it:** [Constraint-creativity causality]
|
||||
|
||||
**Strengths:**
|
||||
- [Strength 1]
|
||||
- [Strength 2]
|
||||
|
||||
**Implementation notes:** [Execution plan]
|
||||
|
||||
**Risks/Limitations:** [Honest assessment]
|
||||
|
||||
### Solution 3 (if applicable): [Name/Title]
|
||||
|
||||
[Same structure as above]
|
||||
|
||||
## Evaluation
|
||||
|
||||
**Constraint compliance:** All top solutions fully respect the imposed limitations
|
||||
|
||||
**Novelty assessment:** These solutions are [novel/somewhat novel/incremental] because [reasoning]
|
||||
|
||||
**Problem fit:** Solutions address the original challenge by [explanation]
|
||||
|
||||
**Actionability:** [Can these be implemented? What resources needed?]
|
||||
|
||||
## Creative Breakthrough Explanation
|
||||
|
||||
[Explain how the constraints drove the creativity. What thinking pattern did they break? What unexpected angle did they reveal? Why wouldn't these solutions exist in unconstrained brainstorming?]
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. [Immediate action]
|
||||
2. [Follow-up action]
|
||||
3. [Testing/validation plan]
|
||||
|
||||
## Self-Assessment (using rubric)
|
||||
|
||||
[Score against rubric criteria before delivering to user]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Constraint Selection Guide
|
||||
|
||||
**If user has existing constraints (real limitations):**
|
||||
|
||||
1. **Accept and amplify:** Make the constraint tighter to force more creativity
|
||||
- Budget is $5K → Challenge: "Design for $1K"
|
||||
- Timeline is 2 weeks → Challenge: "Ship in 3 days"
|
||||
|
||||
2. **Add complementary constraint:** Pair resource constraint with format constraint
|
||||
- Low budget + "No text, visuals only"
|
||||
- Short timeline + "Using existing tools only"
|
||||
|
||||
**If user has no constraints (brainstorming is just stuck):**
|
||||
|
||||
1. **Diagnose the stuck pattern:**
|
||||
- Ideas too complex? → Add simplicity constraint ("Maximum 3 features")
|
||||
- Ideas too conventional? → Add rule-based constraint ("Can't use industry standard approach")
|
||||
- Ideas too similar? → Add perspective constraint ("Design for opposite audience")
|
||||
|
||||
2. **Choose constraint type strategically:**
|
||||
|
||||
| Stuck Pattern | Recommended Constraint | Example |
|
||||
|--------------|----------------------|---------|
|
||||
| Too complex/feature-bloated | Resource or Format | "One-page explanation" or "$100 budget" |
|
||||
| Too conventional | Rule-based | "Can't use competitor's approach" or "No best practices" |
|
||||
| Too similar to each other | Technical or Medium | "Text-based only" or "Works offline" |
|
||||
| Too vague/abstract | Format | "Explain in 6 words" or "Show with single image" |
|
||||
| Too incremental | Historical or Audience | "Design as if it's 1990" or "For 5-year-olds" |
|
||||
|
||||
3. **Apply the "1-3 rule":**
|
||||
- 1 constraint: Safe, good for first-timers
|
||||
- 2 constraints: Sweet spot for most challenges
|
||||
- 3 constraints: Maximum before over-constraining
|
||||
- 4+ constraints: Usually paralyzes creativity (avoid)
|
||||
|
||||
---
|
||||
|
||||
## Idea Generation Techniques
|
||||
|
||||
**Technique 1: Rapid Constraint-Compliant Listing**
|
||||
- Set timer for 15 minutes
|
||||
- List every idea that respects constraints, no matter how wild
|
||||
- Don't judge or refine - just capture volume
|
||||
- Aim for 30+ ideas in timeboxed session
|
||||
- Good for: Getting unstuck quickly
|
||||
|
||||
**Technique 2: Constraint-Focused SCAMPER**
|
||||
- Apply SCAMPER prompts while respecting constraints:
|
||||
- **S**ubstitute: What can replace X (within constraints)?
|
||||
- **C**ombine: What can merge (within constraints)?
|
||||
- **A**dapt: What can we adapt from elsewhere (within constraints)?
|
||||
- **M**odify: What can we change (within constraints)?
|
||||
- **P**ut to other use: Different purpose (within constraints)?
|
||||
- **E**liminate: What can we remove (constraint might already do this)?
|
||||
- **R**everse: What can we flip (within constraints)?
|
||||
- Good for: Systematic exploration
|
||||
|
||||
**Technique 3: Forced Connections**
|
||||
- Pick 3 random elements (objects, concepts, brands)
|
||||
- Force connection between challenge + random element + constraint
|
||||
- Example: "App redesign" + "Coffee shop" + "No images" = Text-based app with coffee shop naming metaphors
|
||||
- Good for: Breaking patterns completely
|
||||
|
||||
**Technique 4: Constraint Escalation**
|
||||
- Start with mild constraint, generate 5 ideas
|
||||
- Tighten constraint, generate 5 more
|
||||
- Tighten again, generate 5 more
|
||||
- Example: "$10K budget" → "$1K budget" → "$100 budget"
|
||||
- Good for: Finding the creative sweet spot
|
||||
|
||||
**Technique 5: The "Yes, And" Game**
|
||||
- Build on each idea while adding constraint layer
|
||||
- Idea 1: "Simple landing page"
|
||||
- Yes, and (constraint): "...with no images, text only"
|
||||
- Yes, and: "...using only questions, no statements"
|
||||
- Yes, and: "...in under 50 words"
|
||||
- Good for: Progressive refinement
|
||||
|
||||
---
|
||||
|
||||
## Evaluation Framework
|
||||
|
||||
**Phase 1: Constraint Compliance Check**
|
||||
|
||||
For each idea, verify:
|
||||
- [ ] Respects ALL imposed constraints (no "bending" or exceptions)
|
||||
- [ ] Uses constraint as feature, not workaround (embraces limitation)
|
||||
- [ ] Would be eliminated in unconstrained brainstorming (proves constraint drove it)
|
||||
|
||||
Eliminate any ideas that fail these checks.
|
||||
|
||||
**Phase 2: Problem-Solution Fit**
|
||||
|
||||
For remaining ideas, assess:
|
||||
- [ ] Addresses the original creative challenge
|
||||
- [ ] Meets success criteria (if measurable)
|
||||
- [ ] Is actionable with available resources
|
||||
- [ ] Differentiates from existing approaches
|
||||
|
||||
Rank ideas by problem fit.
|
||||
|
||||
**Phase 3: Novelty Assessment**
|
||||
|
||||
For top-ranked ideas, evaluate:
|
||||
- **Novel (5)**: Completely unexpected angle, wouldn't exist without constraint
|
||||
- **Fresh (4)**: Interesting twist on existing concept, constraint made it distinctive
|
||||
- **Improved (3)**: Better version of known approach, constraint forced refinement
|
||||
- **Incremental (2)**: Slight variation, constraint didn't add much
|
||||
- **Derivative (1)**: Essentially same as existing, constraint was superficial
|
||||
|
||||
Select ideas scoring 4-5 for refinement.
|
||||
|
||||
**Phase 4: Refinement**
|
||||
|
||||
For selected ideas:
|
||||
1. **Combine elements:** Can you merge strengths from multiple ideas?
|
||||
2. **Subtract complexity:** Remove anything non-essential
|
||||
3. **Strengthen constraint insight:** Make the constraint-creativity link more explicit
|
||||
4. **Add implementation details:** How would this actually work?
|
||||
5. **Acknowledge limitations:** Where does this solution fall short?
|
||||
|
||||
---
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
Before delivering `constraint-based-creativity.md` to user, verify:
|
||||
|
||||
**Constraint Integrity:**
|
||||
- [ ] Constraints are clearly stated and rationalized
|
||||
- [ ] All top solutions genuinely respect constraints (no cheating)
|
||||
- [ ] Constraint enforcement was rigorous during ideation
|
||||
- [ ] Document includes 1-3 constraints (not over-constrained)
|
||||
|
||||
**Idea Volume:**
|
||||
- [ ] Generated 20+ ideas minimum
|
||||
- [ ] Documented "failed" ideas and insights
|
||||
- [ ] Showed quantity before quality approach
|
||||
- [ ] Timeboxed generation to avoid perfectionism
|
||||
|
||||
**Solution Quality:**
|
||||
- [ ] Selected 2-3 strongest solutions
|
||||
- [ ] Solutions are novel (not incremental variations)
|
||||
- [ ] Solutions solve the original problem
|
||||
- [ ] Solutions are actionable (not just conceptual)
|
||||
- [ ] Strengths and limitations are honestly assessed
|
||||
|
||||
**Creative Causality:**
|
||||
- [ ] Explanation of HOW constraints drove creativity
|
||||
- [ ] Clear link between limitation and breakthrough
|
||||
- [ ] Wouldn't exist in unconstrained brainstorming
|
||||
- [ ] Identified what thinking pattern was broken
|
||||
|
||||
**Documentation:**
|
||||
- [ ] Problem statement is clear
|
||||
- [ ] Context explains why stuck/what's been tried
|
||||
- [ ] Success criteria are stated
|
||||
- [ ] All ideas documented (including volume metrics)
|
||||
- [ ] Next steps are actionable
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
**Pitfall 1: Bending constraints mid-process**
|
||||
- **Symptom:** "This constraint is too hard, can we adjust it?"
|
||||
- **Fix:** Constraint difficulty is the point. Breakthroughs happen when you can't take the easy path.
|
||||
|
||||
**Pitfall 2: Accepting incremental ideas**
|
||||
- **Symptom:** Ideas that are slight variations of existing approaches
|
||||
- **Fix:** Use novelty assessment. If it scores < 4, keep generating.
|
||||
|
||||
**Pitfall 3: Over-constraining**
|
||||
- **Symptom:** Zero ideas generated, complete creative paralysis
|
||||
- **Fix:** Reduce to 1-2 constraints max. Add constraints progressively, not all at once.
|
||||
|
||||
**Pitfall 4: Arbitrary constraints**
|
||||
- **Symptom:** Constraint has no relationship to the creative block
|
||||
- **Fix:** Choose constraints strategically (see Constraint Selection Guide). Constraint should counter the stuck pattern.
|
||||
|
||||
**Pitfall 5: Skipping volume phase**
|
||||
- **Symptom:** Evaluating/refining ideas before generating quantity
|
||||
- **Fix:** Force 20+ ideas before any judgment. Set timer and don't stop early.
|
||||
|
||||
**Pitfall 6: Missing the causality**
|
||||
- **Symptom:** Can't explain how constraint drove the creativity
|
||||
- **Fix:** If solution could exist without constraint, it's not constraint-based creativity. Keep generating.
|
||||
|
||||
**Pitfall 7: Confusing constraint-based with regular brainstorming**
|
||||
- **Symptom:** Treating constraints as optional or as framing device only
|
||||
- **Fix:** Constraints must be enforced rigorously. They're not suggestions.
|
||||
|
||||
**Pitfall 8: Stopping at conceptual**
|
||||
- **Symptom:** Solutions are interesting but not actionable
|
||||
- **Fix:** Add implementation notes. Verify solution can actually be executed.
|
||||
Reference in New Issue
Block a user