constraint-evaluation

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