lanehalley

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.