Yes! Totally agree! There should never be a person whose sole job is "UX". I've encountered many of these people and have never seen one add value to a project.
As a further aside, I also despise "information architectures" which these UX people always want to hammer out. To me, information architecture is a buzzword and total crap. I want to see high fidelity design comps. No more Omnigraffle low fi wireframes. (And especially no Omnigraffle wireframes as a deliverable to developers to code real UIs!)
Well - there's a lot more to IA than wireframes :-) Lou Rosenfeld's book "Information Architecture for the World Wide Web" is still a nice, small read if a little dated now and more oriented to content-based sites.
Wireframes are just one possible deliverable - a way of communicating the results of some kinds of UX work that include IA.
There's a lot of UX folk who hate 'em to - and would much rather spend their time working with the developers rather than waste a stack of time producing pointless documents.
A good UX designer doesn't linger around after doing the job. Their utility drops drastically after the initial design. If they do have to stay, then they haven't done a good job of communicating the key points and observations.
A good UX designer SHOULD stick around because their utility after the initial design is to conduct usability tests, user research, and user feedback to make sure initial design decisions were sound and that the experience that actual users and customers have align with the goals of the business/organization (ie - conversion rates, profitability, ease of navigation, etc).
Ultimately, the UX lead helps with product decisions by leveraging said user feedback to suggest incremental changes to the product. If they simply leave after the designs are "done" and never touch the product or app again, then their utility is marginal to an organization.
"stick around ... to conduct usability tests, user research, and user feedback" is exactly the pitfall that UX falls into when it fails. We've seen it happen so many times, and en masse. This process-driven design fails, because it tries to put the designer in the middle of development, while taking away the responsibility for good design. It is attractive, because the UX designer can blame the users' "unexpected" behavior. It is attractive, because it exchanges the experience, with experiment. If the design is incomplete, it is incomplete, period. If the users have to be observed, let it be done, the development can wait. There is nothing worse than a designer who makes blind guesses about the design hoping that some miracle during the "usability test" will reveal a beautiful solution.
I don't care who does it - but doing usability testing, user research and user feedback isn't failure. It's validation. It's testing. It's closing the feedback loop.
That's not putting "design" in the middle of "development". It's making sure that we're actually doing what we think we're doing - building something that works and gives value to the user.
What's the alternative - just hoping that we got it right?
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.).
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.
As a further aside, I also despise "information architectures" which these UX people always want to hammer out. To me, information architecture is a buzzword and total crap. I want to see high fidelity design comps. No more Omnigraffle low fi wireframes. (And especially no Omnigraffle wireframes as a deliverable to developers to code real UIs!)