I think this is a very good point, and I think it suggests a resolution to the "antagonism" between developers and UCD practitioners suggested in the OP. In de

I think this is a very good point, and I think it suggests a resolution to the "antagonism" between developers and UCD practitioners suggested in the OP. In designing a system, the developers are the ones with the best grasp of what is possible, in both the positive ("here's a new way of solving this old problem") and negative ("that solution would not work because of X") senses. If the UCD practitioner is a true specialist, they will by necessity be unaware of the implementation details and even system architecture, which might cause them to either fail to spot a potential improvement or to suggest features which have poor cost-benefit ratios (even if the benefit is positive). UCD practitioners don't just ask the users "what do you want?" (I'm a developer but I have done some user research as part of UCD projects). They ask "what are your problems?" or "what are your needs?", and then create mock-up solutions which address those needs, which are then validated with the customer (think "lean startup", if it helps). It's not that different from traditional agile, except instead of "the customer" you now have "the customers" and you do a lot of your early-stage iterating in wireframes and mock-ups. This does create risks, of course. The UCD practitioner might propose designs that are unnecessarily difficult to deliver - yes, "the customer is always right", but the customer doesn't always want to pay enough to get what they're asking for, and it's the developers who will evaluate how much the designs are going to cost to implement. Or the UCDer might over-specify things, mapping out several months worth of development in wireframes that might imply major back-end work, with all of the waterfall delivery problems that entails - supposing that the back-end work takes longer than expected, would the customer prefer to cut some features or deliver later? If so, which ones? If the design reaches the developers as a single, cohesive package that cannot be broken down, we're back in waterfall-land and that's no good for anyone. To my mind, this can be resolved within the classic agile framework of cross-functional teams. User research should be a function of the team, and the decisions about what solutions to propose to the users should be team decisions. The designer should not be proposing work that will be carried out by the developers without consulting them first, and the developers should play an active role in suggesting features and solutions - offering their knowledge of what's technically possible to inform the designs. This keeps the design process grounded in technical reality but also allows for the designer to challenge the developers to come up with a way of achieving something that customers want.