This article from Bill Kroyer is a bit outside the IxD field, but there are some interesting parallels to some of the struggles we experience between design and development.

…the master is the vision and the servant is the technology.

There has been this battle ever since I've seen these two working together in Tron. It's natural, because much of the work we do is technology based; it's also natural that the toolmakers believe that they are the best ones to use them, but it doesn't work that way. You go to hear Rubinstein play, not the guy who made the piano.

It's one of those things you have to be sensitive about, because you have to appreciate the skill of the person who knows how to use the technology. But there has to be a level of judgment about their ability to use it with artistic vision.”

Technology leads artists to cope in many different ways. One is by learning how to use the tools...

At the IxDA Interaction '08 event in Savannah, I heard many stories about how interaction designers are taking stakeholders out on customer site visits, doing collaborative synthesis, working through design problems with developers. Why? Business stakeholders and developers don't have the same skill set or motivations as interaction designers, but there's something about using our methods to work through problems together that helps everyone be on the same page. They don't have to learn to be interaction designers to benefit from the techniques we use.

Interaction design provides great solutions, but it also is necessary to facilitate those solutions into the organization. I don't believe that the people who provide those solutions should be the "boss," they have to be the guide, leading people to the right place. Just as we can't justify our design decisions "because we think so" we also can't own the design, it has to be a owned by everyone who contributes to solution we're building. Interaction designers must use our skills to identify the problem, find a workable solution and get it all into peoples' heads before anything will happen. We have to engage and inspire the organization to get something good built.

In this spirit, I like the idea of figuring out how IxDs can collaborate more with developers because it helps create better understanding of the design and sense of ownership. Now, exactly what "collaborative design" means and where it fits in the process is open for debate, but I feel there's something in there that could work. The "big design doc" approach is problematic for many companies, and I'm thinking about ways we could do it better. It worked well in a recent project where the document followed the design, rather than the other way 'round. I think we could use more collaboration time with the development team on most of our projects, starting as early as the framework. I think there's great value in communicating more about the problems our framework is trying to solve, and leaving some of the implementation details up for healthy discussion. I think we could meet with different stakeholder groups separately to address different concerns, as well as together to build mindshare.

So...I guess at the root I see this as a design communication problem. How do we get developers to understand and believe in our designs so things are built properly? Part of the solution may be to facilitate them into it, rather than dictate to them.