07

Constraint Blindness

Misses technical and organisational obstacles

The prototype looks right in the design tool. The constraints only become visible when engineering attempts implementation, by which time expectations are already set. Also your idea is completely illegal.

AI optimises for the version of the problem it can solve from its training material and its prompt context, a stylized, interpreted, often incompletely represented problem. What has to ship is a solution to the constrained problem, and the gap between the real problem, and what the model imagines, is where Constraint Blindness lives. Feasibility is not only technical: a design can be technically possible and still be unbuildable because it violates a business constraint, a regulatory requirement, an organisational capability the company doesn't have, or a political reality the model never heard about. AI has no access to constraints unless you provide them. It builds for a world where those constraints don't exist. The designer's job is to know which constraints are binding, and as early as possible.

Design transfer

  • Complex micro-interactions that can't run at 60fps on target devices
  • Layouts that break on real device sizes and viewport conditions
  • Data visualisations requiring backend infrastructure the team doesn't have
  • Designs that are technically sound but require organisational capabilities that don't exist
  • Glassmorphism and complex animation effects that are technically impossible without massive performance degradation

In the wild

Use cases

Custom Plugins

CON-026

Designers automate workflows without engineering support, creating custom tooling for tasks not covered by existing plugins.

Concept·Emerging

Interaction Pattern Suggestion

CON-083

Designers consider more pattern precedents during the concept stage, letting them make choices grounded in explicit trade-offs, while not missing underused options that may be better solutions.

Concept·Developing

Prompt-to-Prototype

CON-021

Produces functional, interactive prototypes without manually wiring hotspots or engineering support, achieving higher fidelity faster.

Concept·Developing

Cross-Library Component Comparison

DEL-090

Reduces cross-library alignment auditing from days of manual file-switching to minutes of AI-assembled side-by-side comparison, enabling governance of multi-brand architectures at scale.

Deliver·Emerging

Design Handoff Automation

DEL-046

Compresses the delay between finished design and first code commit, reducing translation time and interpretation errors that accumulate when developers build from static design artifacts.

Deliver·Developing

Design Token Management

DEL-048

Facilitates design tokens managements across brands and platforms, reducing manual effort and inconsistency risks that token changes introduce at scale.

Deliver·Developing

Design-to-Code

DEL-052

Generates code that uses the design system reliably enough to enter the production pipeline, compressing cycle time from approved design to shipped code.

Deliver·Emerging

Designer Code Contribution

DEL-053

Enables designers to make contained design-quality changes directly in the production codebase, bypassing the handoff cycle entirely for work that is within design's domain of expertise.

Deliver·Emerging

Product Primitive Documentation

DEL-102

Enables AI to generate task-appropriate, adaptive interfaces rather than generic page layouts by providing the domain-level context that component documentation alone cannot supply.

Deliver·Emerging