Ask HN: How much knowledge of technical constraints should designers have?

Designers don't often understand technical constraints, and so propose things that are impractical. For example, my designer recently proposed something he thought was making a feature feel complete from the user's point of view. But in terms of engineering, it turned out to be a major new feature taking perhaps two quarters, which didn't make sense to do, as the designer agreed, too, once I told him the estimate. This happened earlier in my career as well — a designer designed an elaborate UX for an app on a primitive pre-iPhone feature phone platform (J2ME), where getting anything done had a lot of overhead. I told him this is not doable but he countered with "But we need to have a great UX". I escalated to my manager and told him, "Our roadmap calls for us to launch one feature every quarter for the next year. If you want that to happen, we can't design such an elaborate UI for everything." The designer didn't trouble us again. Designers could provide more useful input to the team if they understood the technical constraints, rather than living in a dreamland where everything they dream up is possible in the limited time available. On the other hand, I suppose it's counter-productive for designers to know too much about the implementation domain, because they'll then end up thinking like engineers, stop seeing things from the users' perspective, etc. The team needs a diverse perspective. Where do we draw the line? How much knowledge of technical constraints should designers have? Clearly more than zero, but at what point do we say it's going to be counter-productive?