Manager: Um, they’re trying to accomplish a successful transaction on our site.
You: Okay, never mind about that for now. Who designed the user interface?
Manager: Our lead developer designed the UI. He’s pretty good at it.
You: Sigh… (Banging your head against the wall.)
What’s going on in this fictional, yet familiar dialogue? This dialogue suggests a pattern that is indicative of a cultural divide—that barriers to integrating UCD techniques earlier in the product development lifecycle are cultural in nature. It suggests that gulfs exist between the cultures of product management and engineering and between both of them and user experience.
My experience working within various organizational cultures has taught me that two effective ways of bridging this gulf between us and them are:
- becoming liaisons between these disciplines—that is, across cultures
- considering ourselves change agents whose primary approaches are those relating to user experience
First, let’s talk about culture.
The Role of Culture
Experts typically define culture as the attitudes, values, behaviors, and customs that reflect a group’s approaches to living their lives. Geert Hofstede, one the most well-known cross-cultural researchers, refers to culture as “the software of the mind,” equating computer operating systems and applications with people’s “mental programming.”
We are all simultaneously members of many different cultures, at many different levels, including our professional cultures. Cultures overlap, and thus, their spheres of influence overlap as well. Each culture to which we belong exerts some influence on our attitudes, opinions, motivations, and actual behaviors. These cultural influences come into play in different situations within the organizations in which we work.
Organizational culture and its effects on the people within organizations have been widely studied. One interesting aspect of the study of organizational culture looks at the ways people’s vocational, academic, or professional cultures affect their interactions with people from other disciplines. Another area of study assesses how the differences and similarities across subcultures within an organization shape the formal and informal processes that guide the creation of products and services.
In general, how do different professional cultures within an organization interact? Often with difficulty. The various disciplines that have roles within the product development and delivery cycle—including product management, engineering, marketing, and hopefully, user experience—function within a system in which conflict is a given.
In fact, some conflict between the disciplines is a necessary part of the process. For example, product management wants to build more in a given timeframe than its developers’ capacity allows. Or developers need more time to build complex features, but because of their company’s business requirements, product management wants to allocate less time for a development cycle. Or maybe QA identifies what it thinks is a severe defect, but development views it as a minor or moderate bug and would rather publish a workaround in the release notes and fix the bug in Release 1.1. Another way to think of these conflicts is as checks and balances. They exist to help ensure that a product or service addresses customers’ wants and needs, makes it to the marketplace on time, and has sufficient quality and robustness.
In addition to the designed-in conflict between functional groups, there are several other sources of conflict that impact the ideation, design, and development process. Think of the different disciplines as subcultures within the broader organizational culture. Cultural differences between the disciplines engenders conflict.
For example, the training of developers and QA engineers is typically in engineering or the hard sciences. These types of people typically have a high intrinsic motivation to understand systems in a more complete manner than do non-technical people. Because engineers design the technical aspects of systems, they tend to develop much more system-centric mental models. Their communications, with each other and other disciplines, will reflect this perspective.
Their problem-solving approaches will usually reflect their deep understanding of systems architecture and their system-centric mental models. Finally, their approach to conflict will reflect their tendency toward parsimony, lowering risk during implementation, and employing proven approaches to engineering. Like everyone else in the organization, they want to “do right” by the customer, but unavoidably their ownership of the technical aspects, predispositions, and mental models will subtly—sometimes not so subtly—shade their interactions.
Contrast this with the typical product manager, whose schooling is in economics, business, or finance and who is predisposed toward a more business-centric viewpoint. While product managers may have somewhat of a systems orientation from working in technology, they are almost always more removed from the system in comparison to the engineers. And product managers—especially if they have profit-and-loss responsibility for their products—tend to approach problems in terms of business needs—that is, how different solutions might affect revenue and customer satisfaction. Thus, their communications naturally reflect their focus on business problems. And their business focus will manifest itself in their approach to interdisciplinary conflicts.
Now, add user experience to this mix. Some UX professionals have an academic background in cognitive or experimental psychology; others in design or library sciences. Some have had no formal training—just a love of the work and knowledge born of experience and on-the-job training. The UX professional may have neither a deep understanding of systems and technology nor a solid foundation in business and finance. The UX professional thinks in terms of meeting users’ needs, removing or mitigating users’ frustrations, and helping users accomplish their goals. Our interactions with other disciplines reflect this focus. Think about it: How many times have others explicitly tagged you with the label user advocate?
I assert that these predispositions, tendencies, backgrounds, and shared experiences are the underpinnings of subcultures in an organization. Given that these different subcultures have differing ways of communicating, thinking about issues, approaching problems, and resolving conflicts, how do they get anything done?
