Connecting Cultures, Changing Organizations: The User Experience Practitioner As Change Agent
Published: January 20, 2007
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
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?
Changing Organizations By Connecting Cultures
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
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.
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.