I've seen too many successful teams work otherwise to think that way any more.
In my experience designers getting the design "right" before handing it over to developers is often just as wasteful, and goes wrong nearly as much, as the developers kicking off at the start and expecting the designers to "make it nice" afterwards.
Business folk, developers and designers need to work together right from the start. Figuring out the best ways to validate the assumptions that we're making so that we can be sure together that we're building the right product. Sometimes that's user research, sometimes that's validating business models, sometimes that's building stuff.
Adrian, I finally watched your talk. Thank you for the link. It was a good talk. (Note to self: keep a few 40 minute talks handy in case the next discussion goes into a general area of interest :-)
My specific complaint will be that the talk occasionally digresses to what UX is, how a designer should be a good citizen, and how developers can be nice, etc. I am not familiar with the context of the talk, perhaps the general track had to have such discussions.
Nobody would argue that there would be no need to update the interaction as the product ages. However, that does not warrant the persistence of a designer in the middle of the development process. I am not referring to small changes to accommodate UI conveniences, about a design that did not fulfill its promise in the first place. A product design should not go out of date before it is released. A major revision is another story in itself, and that should be taken as a design update, and should be planned accordingly.
It is true that software is the most malleable product material ever, but the temptation to count on that malleability instead of focusing on good design only brings about frustration both on the side of developers and eventually on the side of designers, and most importantly on the side of customers.
Perhaps there is a bit of distrust between designers and the developers, as the developer has the final say in what is going to be done and what will be ignored, in addition to the need to update the design a little bit as the real usage data flows in. Or, perhaps the blanks in product requirements is a lot bigger in startups vs enterprise in a way that would effectively get the product change drastically every 3 months. I have only seen iterative design work well in indie games and small-time mobile apps, but those really do not count, as they would only be considered as prototypes in an enterprise environment, and you'd probably go about doing that much prototype while designing your framework.
I've seen too many successful teams work otherwise to think that way any more.
In my experience designers getting the design "right" before handing it over to developers is often just as wasteful, and goes wrong nearly as much, as the developers kicking off at the start and expecting the designers to "make it nice" afterwards.
Business folk, developers and designers need to work together right from the start. Figuring out the best ways to validate the assumptions that we're making so that we can be sure together that we're building the right product. Sometimes that's user research, sometimes that's validating business models, sometimes that's building stuff.
I've a 40m rant-ish presentation on design & how it should be an ongoing process over here if you're interested http://www.infoq.com/presentations/Design-Never-Stops :-)