Connecting Cultures, Changing Organizations: The User Experience Practitioner As Change Agent

By Paul J. Sherman

Published: January 20, 2007

“User-centered design (UCD) and usability activities have the most positive impact when they’re carried out early in the ideation, design, and development cycle.”

Readers of UXmatters probably know that user-centered design (UCD) and usability 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 usability engineering. You may have experienced something like the following the interchange with a development manager:

Manager: Say, we’re just about to release this [product/Web site/application]. Could you take a look at it for us?

You: Okay, when do you plan to release it?

Manager: In three weeks.

You: 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?

You: 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.

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

Manager: You mean in life?

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

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

“We are all simultaneously members of many different cultures, at many different levels, including our professional cultures.”

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.

“Think of the different disciplines as subcultures within the broader organizational culture. Cultural differences between the disciplines engenders conflict.”

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?

Changing Organizations By Connecting Cultures

“Natural liaisons bridge gaps between functional areas, enabling communication between groups, and mitigating conflict and its consequences.”

In my recent book Usability Success Stories: How Organizations Improve By Making Easier-To-Use Software and Websites, the information architect Adam Polansky, a contributing author, identifies a role that is typical within organizations: the natural liaison. Natural liaisons bridge gaps between functional areas, enabling communication between groups, and mitigating conflict and its consequences.

Ideally, everyone in an organization should function as a natural liaison. However, in reality, it seems that there are a small number of natural liaisons within each subculture. These individuals almost always bear a disproportionate share of the weight of an organization.

It’s usually possible to trace the success of most initiatives back to the efforts of such natural liaisons. They communicate across discipline boundaries, forge relationships and shared understandings, and consistently go beyond the roles and responsibilities of their job descriptions. Natural liaisons function as change agents. By spanning the cultural divides between different functional groups, natural liaisons move organizations from the status quo to a better, more communicative and collaborative state.

The UX Professional As Change Agent

“Our most valuable contribution are not our design or user research efforts. Rather, our most valuable contributions occur when we function as change agents.”

As UX professionals, we have many tools and techniques available to us, and we contribute to our product teams in many ways. However, while having good UX skills is necessary, it is not alone sufficient. No matter the size of our organizations or the domains we work within, our most valuable contributions are not our design or user research efforts. Rather, our most valuable contributions occur when we function as change agents.

What is a change agent? Here’s a serviceable definition, from the Web site isixsigma.com:

“[A change agent is] a person who leads a change project or business-wide initiative by defining, researching, planning, building business support, and carefully selecting volunteers to be part of a change team. Change agents must have the conviction to state the facts based on data, even if the consequences are associated with unpleasantness.”

In many, many instances, UX professionals are functioning in precisely this role. And what is our goal in this role?

Above all, our goal is to bring the users’ wants, needs, abilities, and limitations into the organization, and ensure that the organization doesn’t forget the user during any of the design and development stages.

Think about it: Whether you’re an interaction designer, usability practitioner, information architect, or all of the above, your role is to prevent your organization from practicing business as usual. Our UX training and experience have given us the methods we employ to acquire the data, recognize the applicable design principles or patterns, and so on. But the soft skills we use to span the divides between disciplines and ensure that product teams consider users’ needs are part and parcel of the change agent role.

This may seem like a gross over generalization, but it’s true: Without continuous efforts to bring user data into ideation, design, and development, organizations inevitably backslide and lose focus on the user.

I argue that successful UX professionals would benefit from viewing themselves as change agents whose tools are those of user experience. What does this reconceptualization mean for UX professionals? From a practical standpoint, how would it change our jobs?

The short answer is that UX professionals’ external behavior wouldn’t change radically. But internally, this reconceptualization should help us stay focused on the long game—the never-ending effort to maintain and improve our organizations’ focus on the user, as well as to help our neighboring disciplines develop a clear, accurate picture of the users’ goals, needs, motivations, and struggles.

Let’s return again to the fictional interchange I described at the beginning of this article. Armed with your internal reconceptualization of your role as that of a change agent, how could you, as a UX professional, do a better job of working with your product team? Here’s another take on how such a dialogue might go:

You: Hey, I just wanted to drop in and visit with you. I noticed that your team is scheduled to begin work on [product/Web site/application]. Have you put together the schedule for the project yet?

Manager: No, not yet. Why do you ask?

You: Well, if you recall, my user-centered design team worked on [another product/Web site/application] last year. UCD was an integral part of that project’s schedule from the get-go, so we were able to provide a lot of direction and feedback during UI design and development.

And since we were able to get a bunch of people from the user base to use a UI prototype that we built and give us feedback on it, the product manager on that project felt confident that the product matched her vision of what the market needed.

The development team on that project came out looking really great, because they didn’t have to go through that typical last-minute scramble to change the UI at the end of the project.

Manager: Hmm… Tell you what. I was just going to set up a meeting with the project manager for that project. Do you think you can make the meeting if I set it up for Thursday?

You: Absolutely. I’ll be there.

Manager: Great. What role do you think UCD should have on this project?

You: Well, if we can design the main interactions and prototype the UI in Visual Basic or Visio, we can actually get feedback from users and iterate the design before your guys even start coding.

Manager: What do you mean when you say interactions?

You: Oh, sorry. By interactions, I mean the product’s main workflows and behaviors in response to users’ actions.

Manager: Oh, okay. I get it. So, can you tell me what things you see your team doing during the project?

You: Well, there are a bunch of things we could do. Ideally, I would like to work with the product manager who is building the business case and defining the market requirements for the product. Did you know that user-centered design people often help product managers write the requirements?

I realize that this project is already underway, but maybe next time, we’ll be able to work with the product manager when research is just starting. By the way, who is the product manager on this project?

Manager: It’s Julie, the Senior Product Manager who sits over by Finance.

You: Great. Thanks. I’ll get with her and let her know we were talking. Anyway, here’s what I think would work for this project…

You complete this dialogue by describing how you’ll identify and characterize the target user group, craft personas to function as design targets, design interactions to support the requirements, usability test a prototype, etcetera.

Concluding Thoughts

“Every time we reach across discipline boundaries to keep a product team focused on users…, we are functioning as agents of change within our organizations.”

Hopefully, after reading this article, you’re willing to entertain the notion that UX professionals are really change agents who happen to use a particular set of tools, methods, and techniques.

Regardless of whether we think of ourselves as change agents, the fact is that every time we reach across discipline boundaries to keep a product team focused on users, drive changes to products or services based on user data we’ve collected, or design interactions with a clear focus on the target user, we are functioning as agents of change within our organizations.

Now, let’s change our organizations for the better. Good luck!

12 Comments

I totally agree with your assertion that organizational culture acts as an impediment to employees as well as consultants who advocate implementing user experience as a framework for the development of products and services. However, it isn’t just a matter of including those professionals early in the design process to make the user experience better.

I recently attended a user experience conference in which two usability experts presented an overview of how they used usability techniques to redesign the Web site of a leading auto leasing company. They used all the tools and techniques one would expect of usability experts. At the end of their presentation, I asked them if they had developed a way to use observations from their customer support center to inform their user experience evaluations of the resulting Web site. As you might guess, they indicated no, saying that was something they want to do in the future.

I would suggest that usability professionals will have an extraordinarily difficult time leading a user—I prefer customer—experience initiative. It requires an enterprise perspective and few usability experts have the business, marketing, and sales sensibilities to provide the insights needed. Nor, I am sorry to say, do they have the organizational standing. Organizational culture needs to change, but the way to change it is to lobby for a Chief UX Officer whose position is independent of marketing, product development, sales, and IT.

A heartfelt cheer for the author for highlighting this!

I’ve found Jeff Patton’s way of looking at before-, during-, and after-people a useful way of thinking about what user experience skills need doing where.

(http://www.agileproductdesign.com/blog/beforeduringand_after.html)

Great directions, Paul! I’d like to point out that UX practitioners who come from computer science have a particularly important role in bridging the gap between designers, psychologists, and developers.

Thanks, Paul, for bringing this issue to the forefront. Like you, I’ve seen how important corporate and domain culture is to the success of a product or initiative. I agree that we must communicate and lead organizations to a focus on users’ wants, needs, abilities, and limitations. And to do this, I think one of the things we need to do is to walk the talk.

Part of the walk is, as Larry Irons said, to be able to go beyond the user and look at the alignment between user and business goals. Part of this is also being multidisciplinary. For example, with one client, I needed to be able to use asset management principles to define ROI, process re-engineering to understand project risks, and communication research and planning to support the diverse stakeholder needs. This is also true with differences we see in our own ranks—qualitative and quantitative, testing and designing, psychology and ethnography, user and customer.

The other thing that I’d like to see us do as a community is to explore what works and doesn’t work in being a change agent—and thank you, Paul, for doing this here. For any of you going to UPA this year—pardon the pitch—a group of us will be looking at this issue in a workshop titled: “Beyond ROI: UCD as a catalyst for organizational change.” Please join us if you’re interested in pursuing this topic more. UPA registration begins on February 26th, but until then, we have a description of the workshop posted here.

Quoting Larry:

“I would suggest that usability professionals will have an extraordinarily difficult time leading a user—I prefer customer—experience initiative. It requires an enterprise perspective and few usability experts have the business, marketing, and sales sensibilities to provide the insights needed. Nor, I am sorry to say, do they have the organizational standing. Organizational culture needs to change, but the way to change it is to lobby for a Chief UX Officer whose position is independent of marketing, product development, sales, and IT.”

Larry, I absolutely agree with what you’re saying here. And I’ll be the first to admit, in this public forum, that I know I still don’t have the chops to provide the enterprise perspective you speak of. I’m learning, but it feels like every lesson I learn is about one job too late. Thanks for the insightful comments, Larry.

Adrian, I’ll check out the resource link. And Anita, since I’m a UPA board member, I’m only too happy to have a workshop presenter pitch from the comments section. :-)

Having a manager in place directly over a user experience group is a key piece to the whole design success puzzle. This provides direct support, advocacy, and protection for the group. However, the UX group does not necessarily have to be separated from Product Management, Marketing, or Development. In the past, I have worked in design groups that have been a part of Development or Marketing. Like everything, there are pros and cons to each.

Currently, I am in a group that is part of Product Management. The good part about being in Product Management is it ensures the design and the user are considered early on, which is a nice change of pace. We also have a Creative manager directly over the user experience group; and more importantly, we have upper management buy-in.

Changing the culture is just part of what each of us works on. However, it would not be nearly as successful if we did not have management buy-in supporting our drive and initiative.

Paul-

Thanks for writing an article about what all UX professionals are living and learning along the way. The more we can be seen as the glue and process to get an idea to development, while accomplishing the intentions of the business and achieving great user experience, the more we will grow as a profession.

Good read!

DeeDee DeMulling

Thanks DeeDee! I’m convinced that the future of UX is organizational. It’s our “last mile” problem. To borrow blatantly from the telecom world…

Paul, Thank you for the insightful and well written article—as well as those of you contributing to the discussion. I have a couple of comments—thoughts I should say—about the issue.

First of all, I really appreciated your comment about where UX professionals come from; some of us do come from a visual design background—yeah, I’m talking about myself. I often feel this puts me at a disadvantage—for reasons that are part of a different discussion. What I recognized was that you were practicing what you were teaching—that is, building unity and promoting inclusiveness within the audience you were trying to reach by setting an example. It worked well. This is one of the best ways to win people over.

My second comment is slightly abstract, but I believe relevant to the discussion about change. I respect the founders of the discipline we call user experience and use the formal name all the time. However, aside from the formal use, we are not setting a good example to those we are trying to educate/change when we use the term users to describe human beings. It may seem petty, but how can I truly say I am an advocate for a human being when I am referring to him or her as a user? It has a negative connotation; those who take advantage of people or situations for their own personal gain—you know, “he’s just using her for XYZ…” It also feels cold and unwelcoming. Think about the vast number of fields and then the terms they use to describe members of their audiences. Guests, customers, passengers, drivers, readers, the list is vast. In my (humble) opinion, we should call our audience members visitors. That’s what we want them to do, right? Since much of UX is really a philosophy or state of mind, this is an ideal way to begin our thought processes—that is, we can do a better job persuading others to change if we set an example and change our thinking first. Just something I wanted to add to the mix—and one of my many obsessions.

Finally, a question to anyone who has made it this far: How can one apply this strategy in a situation where those you need to reach and influence have no interest in changing? I understand this is based on fear most all the time, and I wish educating them was the simple solution, but in my experience, those who fear change do not want to be educated. They usually use excuses couched in the areas they work in and know best. However, I think resistance to being educated comes from the unconscious knowledge that being educated or learning something new is in itself change—or will possibly lead to change. This isn’t a hypothetical situation, by the way. I was hired by a company as a User Experience Designer, and one of my primary tasks was to lead in the creation of a UX strategy. For reasons that remain a mystery, the position was part of Product Marketing. The stakeholders, internal clients, development teams were so entrenched in the way things operated that I wasn’t even listened to when pointing out a glaring usability issue and the simple solution. I can’t resist. This is not made up: “Folks, I think I know why the membership promotion performed 60% lower than forecast. We forgot to put our company name on it, so members probably don’t know it’s a member promotion; instead they are assuming it is a third-party ad placement. The numbers suggest that it is performing as if it were a third-party ad. But I have a simply solution. Let’s add our name and our branding and test that against the current promotion.” The observation was ignored until one of the VPs pointed it out a week later and guess what? Yeah, the new promotions performed better than the original forecast.

Okay. Thank you for letting me ramble.

Michael, I noticed you used “fear change” and “not interested in change” somewhat interchangeably. I think there’s a critical distinction to be made between the two.

I believe it’s much easier to change organizations who fear change than it is to change organizations who are not interested in change. At least those who fear change recognize the need to take action—albeit they are afraid of taking action. Those who are not interested in change either see no burning need for change or may be actively resistant to change. This is a much harder group to influence.

Michael, nice ramble. I agree with your observations on resistance to change. It takes more than a willingness to reach out to people outside your discipline. Those people need to be accepting of change. I’ve run into resistance as well, and I think the incentive I presented has been too abstract—for the good of the company as a whole—whereas their interests and reward structure may be much narrower—how does it benefit me / my department?

Join the Discussion

Asterisks (*) indicate required information.