---
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-evaluation` Apply 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