Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint.
It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc.
You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests.
Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text?
Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets.
The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.
I doubt the real answer is for the designer to code (though it's nice when you get to work with someone like that), but you sure have to ask a lot of questions, and you never manage to check everything up front. Especially anything that doesn't immediately open a new web page, at every step there are just so many input possibilities: the user clicks this button or that, clicks elsewhere, types a bit here then a bit there, presses Enter, presses Tab, presses Escape, has a screenreader, is on a phone, is on an iPad, gets an error, gets 1000 results, changes the dropdown that enabled this other control. . . . I guess you do the best you can imagining flows up front, but plan on having some iteration as you discover gaps in the design.
I'm not saying they have to code 100% of everything, but I'm really fed up with having to deal with that sort of "well gosh that's not our issue!" hands off sort of 'design' folks.
Internal design teams that work in the same building as the implementors/devs... maybe a different experience. I'm sometimes brought in and given "mockups" from an external team, done in whatever tool of the day they use, that have little bearing on real world web implementation.
it's apparently beneath some of these folks to learn css/html and use ... you know... a web browser to mock up a web site. i don't care how much 'freedom' some tool gives you, you're just punting the hard implementation to someone else.
Came off a project recently like this - the original team had done 'weeks' of 'design' and 'planning' with an external design firm. "but plan on having some iteration as you discover gaps in the design" sounds nice, but in their mind, they'd already "thought a lot about it" 8 weeks earlier, so any implementation issues I found were somehow... my fault? my problem? "these guys are a really strong design firm..." who don't seem to have ever actually implemented anything they design, from what I could tell.
From the other side of the aisle, this isn't what happened.
I want to preface this by saying that in general I like designers, but there are things about your good friends that you find annoying and tease them about. So now for some teasing.
What happened was that a bunch of up-in-the-clouds designers kept denigrating (directly or by omission) developers in front of their bosses and we got tired of it. The response to "why can't you guys figure this out? It's really simple" was "Well if you're so smart why don't you implement it?"
Constructively, that translates to engineering the situation so the designers felt our pain. But on a particularly bad day the sentiment tended to be more like "choke on it."