Readers of OMM probably know that user-centered design (UCD) and user experience (UX) design activities have the most positive impact when they’re carried out early in the ideation, design, and development cycle. Probably, many of you have worked in organizations that weren’t very experienced in UCD or UX. You may have heard something like the following interchange with a user experience practitioner and a development manager:

Manager: Say, we’re just about to release the next version of our Web site. Could you take a look at it for us?

UX professional: Okay, when do you plan to release it?

Manager: In three weeks.

UX professional: That’s really soon. Okay, I’ll look at it, but I have to tell you, it’s not going to do much good for me to look at it this late in the game. You should’ve come to me before you started working on it.

Manager: So, will you look at it anyway?

UX professional: I want to ask a few more questions before I start. Do you know who your users are?

Manager: Yes, they’re computer-literate people who use the Internet between 10 and 20 hours a week and make about 10 online purchases a year.

UX professional: No, I mean who are they as individuals? What are their goals?

Manager: You mean in life?

UX professional: No, I mean what are they trying to accomplish?

Manager: Um, they’re trying to accomplish a successful transaction on our site.

UX professional: 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.

UX professional: Sigh… (Bangs head against 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 user experience techniques earlier in a web site’s 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

Further, I intend to make the case that online marketing professionals are also change agents, and as such are natural allies with UX professionals. But 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 engender 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 or marketing manager, whose schooling is in economics, business, or finance and who is predisposed toward a more business-centric viewpoint. While product and marketing 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 and marketing 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 inter-discipline 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.

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?

Coming in Part II:  Uniting Cultures and the Online Marketing Professional as Organizational Change Agent

Paul Sherman is founder and principal consultant at Sherman Group User Experience.