What can be done about all of those obstacles?
The authors of the quotation with which I began that blog entry answer the question this way:
"These barriers can be overcome if designers broaden their roles and better understand other stakeholders' charters."and
"Successful collaboration with other disciplines that make up the software development lifecycle is the key to success."In several blog entries, I've emphasized the importance of such collaboration to overcoming organizational obstacles. But successful collaboration isn't necessarily easy. Indeed, here is one of the obstacles within the long list referenced above:
"I Can Do It Myself"
Collaborating with or involving others is difficult for some people and is sometimes perceived as weakness and/or unnecessary.Exactly why can successful collaboration be so challenging? Earlier this year, I asked that question during a session of the Managing User Experience Groups course I co-taught in Silicon Valley. The answers came pouring out very quickly, as they described obstacles to collaboration as experienced where the students worked:
- not knowing that others are doing the same or related work elsewhere in the company
- different interpretations of the same terms
- language & time zone differences
- hidden agendas
- divergent interests (i.e., little interest in collaborating)
- differing priorities
- unclear work process
- lack of time
- the belief that "the more people involved, the less efficient the process"
- tendencies for people to engage in the same discussions over and over and over when trying to collaborate
- an inability to assess level of participants' understanding of UCD
- discrimination (of many types)
- lack of respect (though sometimes justified)
- conflicts of interest
- some feel threatened by UCD
- in many environments, collaboration is considered to be optional
- some prior negative experience with user experience personnel
- skilled facilitation;
- walls (of two types);
- an effective collaboration process;
- a willingness to have fun.
But it can require even more.
Among that "more" (though overlapping with some of what has already been listed): as quoted above, "designers broaden(ing) their roles and better understand(ing) other stakeholders' charters."
The paper quoted above: Kowalski, L., Ashley, J., & Vaughn, M. When Design is Not the Problem -- Better Usability Through Non-Design Means, CHI 2006, Montreal, Canada.