During a user experience leadership seminar that I gave last summer, I asked about the extent to which the company's user experience personnel collaborated with each other as well as with others. I had just argued that such collaboration is important and can have a huge impact on the success of a multidisciplinary user experience group or organization.
For the only time during the seminar, the group of user experience practitioners responded with near silence.
I was surprised by this, since discussions about collaboration are often quite animated and can yield lengthy lists of frustrating obstacles encountered in the workplace. However, in this particular workplace, collaboration was seemingly not viewed as an important goal.
To some, collaboration means that nasty "designing by committee" or being forced to defend one's expertise.
To others, a process which facilitates contributions across discipline boundaries is often beneficial.
Consider what Dave Malouf wrote about his new work environment this past December:
Don Norman concurs, as quoted in "Ownership of the user-customer experience":
Bill advocates "complete submersion in togetherness (particularly) in the main design creative innovation phase," which is reflected pretty well in the diagram to the right which comes from a paper I and two former colleagues wrote about some of the work we did at Viant. Among the many activities in which multiple personnel of the design, strategy, and technology disciplines were submersed in that work: rapid ethnographic research and its interpretation, and subsequent business and design brainstorming.
Yet, guidance and structure for the activities in which everyone was submersed were provided by those with the greatest expertise in the activities and in facilitating them. This was true as well for the "intensive, rapid, cross-disciplinary collaboration" I referenced a couple of years ago in this blog and which resulted in user experience personnel becoming partners in the development of business and product strategy in a particular business unit within Yahoo!.
And, as reflected in the center of the diagram, at other points in the process, the disciplines "spread out," as Bill puts it -- "people bring their individual expertise to the picture" when appropriate [e.g., when you've identified "an interaction design problem, the best person to (address) that would be someone who has a lot of experience with user conceptual models and screen design"].
However, as also stated by Bill:
For the only time during the seminar, the group of user experience practitioners responded with near silence.
I was surprised by this, since discussions about collaboration are often quite animated and can yield lengthy lists of frustrating obstacles encountered in the workplace. However, in this particular workplace, collaboration was seemingly not viewed as an important goal.
To some, collaboration means that nasty "designing by committee" or being forced to defend one's expertise.
To others, a process which facilitates contributions across discipline boundaries is often beneficial.
Consider what Dave Malouf wrote about his new work environment this past December:
"While most design projects seem to have a single designer at the helm, there are projects where different players (industrial designer, researcher, ux designer [read interaction designer]) are all engaged on a single project (Industrial Designer is usually the lead), no one really cares where ideas come from. 'Credit' seems to be shared across the team, thus encouraging more ideas to be generated because people have less fear about grasping ownership and care more about creating great things."In a recent interview by Lisa Reichelt, Bill Moggridge calls this "checking your disciplines at the door," which he recommends for teams which also -- and which often should -- include personnel from additional disciplines, such as engineering and marketing.
Don Norman concurs, as quoted in "Ownership of the user-customer experience":
"Out of necessity, we divide ourselves up into discipline groups. But the goal when you are actually doing the work is to somehow forget what discipline group you are in and come together."More from Bill:
"where the complexity is high enough, you're much better with a shared mind, and if you put people together from different disciplines, if they work successfully together rather than having some form of a conflct, then the result with the shared mind will be much greater than any individual mind could be"
Bill advocates "complete submersion in togetherness (particularly) in the main design creative innovation phase," which is reflected pretty well in the diagram to the right which comes from a paper I and two former colleagues wrote about some of the work we did at Viant. Among the many activities in which multiple personnel of the design, strategy, and technology disciplines were submersed in that work: rapid ethnographic research and its interpretation, and subsequent business and design brainstorming.Yet, guidance and structure for the activities in which everyone was submersed were provided by those with the greatest expertise in the activities and in facilitating them. This was true as well for the "intensive, rapid, cross-disciplinary collaboration" I referenced a couple of years ago in this blog and which resulted in user experience personnel becoming partners in the development of business and product strategy in a particular business unit within Yahoo!.
And, as reflected in the center of the diagram, at other points in the process, the disciplines "spread out," as Bill puts it -- "people bring their individual expertise to the picture" when appropriate [e.g., when you've identified "an interaction design problem, the best person to (address) that would be someone who has a lot of experience with user conceptual models and screen design"].
However, as also stated by Bill:
"it is easy to sit around the table and argue the different case from the different discipline point of view; the big challenge is to work across disciplines fluently"That might be the most important thing teams need to learn how to do.
