It does matter who does it, when it is done, and how the results are used.

Doing user study with the intention to iterate on the design after the development progress is already far into completion is failure of the designer. If the design is so weak that it hasn't been validated by users, then it is not finished yet, that's it. One has to straighten up the design and validate it with users first. And it has to be done -before- giving a detailed framework to the developers, and claiming that the design is good enough.

After the fact user studies to brush up the UI polish is fine, but that is not the core task of the interaction designer. It can be done by a different expert other than the designer if needed (a junior designer, a developer with interest in usability, etc.).

Ten years ago I thought this way. Now I don't.

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 :-)

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.