My company is planning to embrace Agile soon. Call me an utopist, but I am excited about the opportunities that Agile will bring to us designers. One of them is to better our relationship with developers. I believe we all have some who want us to provide the final designs and are happy to implement them. But there are also some who will reject our designs no matter how good they are. Being forced to work faster in the Agile world will hopefully force us all to join forces and work together as a team. I believe this in itself will solve a lot of issues described in this blog. And that is why I am so excited about going Agile.

Jana

Re-reading your post, I can see nothing that is particularly problematic (from a designer’s perspective) or even very new about what you suggest in terms of a remedy for the problems. Believe me, good designers are all about collaboration. Some, in fact, liken their roles to film directors (so-called practitioners of “Big IA”). They would like nothing better than to work in an environment that puts collaboration in the centre. So perhaps you have simply had bad luck in dealing with some very narrowly-focussed UI designers.

But even in accepting your proposed remedies, I am still worried that incorporating iterative UI development into the Agile process will effectively kill off “the vision thing.”

Vision, like it or not, is what UI designers are paid to provide. Wireframes, prototypes and user testing are mere means to an end. So, are you are willing to take the concept of re-factoring right into the heart of the business itself? I doubt many Agile operations would have the ability to allow vision to be manipulated in an iterative way.

But this is interesting. In my wilder moments, I sometimes muse about “design as business strategy” – but I soon put that idea back in its box. You, however, seem to want to run with just that.

So for that indeed, I salute you!

I don’t think that designers, in general, are lazy. I do think that many have a narrow view of their role, and are not yet comfortable stepping beyond those boundaries. By the same token, many developers take the same view in reverse, and don’t step beyond their self-imposed boundaries to help with the design.

And I don’t want designers to take the rap for failure. Instead, I want them to work more closely with the developers (and the developers more closely with them) so that both succeed. It does no one any good to say “the design phase was a success but the implementation phase failed.” That’s a major reason to eliminate phases. Instead, think of these as /aspects/ of deploying a successful application.

I understand that the way things are is not due to personal inadequacies on the part of designers. It more that the organizations and systems and processes we’ve set up to handle more complex UIs tend to get in the way of collaboration. The specialization between design and development both increases the skill brought to bear on each, and reduces the ability to make trade-offs between the two. It also seems to engender an “us” and “them” attitude that further confounds effective creation of applications.

It’s time that we recognize this and come up with strategies to break down these barriers. And while the “fault” may not be a personal one, the solution surely depends on individual people working thoughtfully and hard to do things differently.

I think your final point, “Those who would be experts in design have a responsibility to see that design through to successful deployment” hits the nail on the head. However, I get the impression you don’t realise how hard it is to accept that responsibility in practice.

Rather than try to explain what I mean by that, permit me to ask you a question through which you may discover more: why is it that designers are lazy? Why do you think they wish to pass the buck to developers for what the designer sees as failure?

You may also like to try for a bonus question: in an Agile world, why can’t developers be designers?