name: constraint-evaluation description: "Understand the constraints a design was built under and evaluate quality within that context. Use when reviewing work that had limited time, budget, or team size, or when assessing whether constraints were handled well."
Constraint Evaluation
Judge quality within context, not in a vacuum.
How to use
/constraint-evaluationApply constraint-aware evaluation to this conversation.
Constraints
Identify the Constraints
- MUST attempt to identify: team size, timeline, technology, budget, business model, and target audience
- MUST evaluate quality relative to constraints, not against an ideal with unlimited resources
- A strong design under tight constraints demonstrates more taste than a mediocre design with unlimited time
- SHOULD note where constraints were handled gracefully and where they caused visible damage
Essential vs. Incidental Quality
- MUST distinguish between decisions that are core to the experience and decisions that are execution details
- Core decisions (hierarchy, information architecture, primary flow) should hold up regardless of constraints
- Execution details (animation polish, micro-interactions, state coverage) scale with available resources
- NEVER excuse poor core decisions by pointing to tight constraints
Anti-Patterns
- Judging a startup MVP against enterprise product standards
- Ignoring constraints entirely ("this should have better animation" for a 2-week project)
- Using constraints as an excuse for fundamentally broken hierarchy or flow