A Pattern for User-Centric Organizational Change

October 6, 2014

During internal UX design presentations, many UX designers find themselves faced with well-meaning stakeholders who believe that their needs are highly representative of the needs of users, or customers. For example, in recent months, stakeholders have told designers on my team:

“I prefer using a house icon instead of the word Home in the navigation, and I am sure that our users would feel the same way.”
“I used to be in the same field as our users five years ago, so I am sure that I know what they want.”
“If this is too difficult, we’ll just put more information in the training manual. That is what our users would expect.”

Champion Advertisement

Rather than seeing this type of response to design decisions as an obstacle, I encourage my team to see this as an opportunity to help stakeholders understand that they are not representative of users. In all of the cases that I mentioned, my team already had direct user feedback that indicated the stakeholders’ assumptions were in fact incorrect. However, even this type of data may not be enough to change such deeply held beliefs.

On projects, for example, I have seen limited success when using tactics like providing access to usability test–session videos as a means of helping internal stakeholders to understand current user needs. While such an approach is helpful in building stakeholder understanding of specific user needs relating to a particular project, this type of learning is not necessarily portable across an entire organization.

After closely observing this organizational dance for several years, I conducted some research on how to help non-UX employees to develop a deeper understanding of user needs. The research that resulted from my curiosity about this issue eventually evolved into my doctoral research topic.

During that research, a pattern emerged that revealed a gap in UX professionals’ typical list of truisms. While “Know your users, because they are not you” is already on that list, we should add “Know your internal stakeholders, because they are not you” to the list. UX professionals are not representative of the average employee in an organization.

The Listen, Learn, Act Framework

Employing this new point of view, I began to research a more systemic way of communicating current user needs to stakeholders—that is, non-UX employees. I created an initial, three-step framework—Listen, Learn, Act—to support more systematic user connectedness. During my research, I found that many non-UX employees feel frustrated when

they want to listen, but do not have access to voice-of-the-customer (VOC) data
they want to learn about, but do not have a clear sense of their firm’s customer-centric vision
they want to act, but first need to engage in training so they can learn how to apply customer-centric behaviors in their daily work

Conversely, UX professionals—who are often more directly connected to user needs—become frustrated when internal stakeholders cannot understand how a design fulfills known user needs and, thus, their rationale for design decisions.

More recently, I have been working with my team to develop the Listen, Learn, Act framework into a UX pattern for customer-centric organizational change. Communicating this framework using the familiar construct of a UX pattern has helped the designers on my team to tackle the problem of the stakeholder-user disconnect as a design problem instead of an issue relating to organizational politics. By applying this type of design thinking, we have reconceived our typical UX artifacts for the purpose of communicating with an internal audience and bridging the stakeholder-user gap.

Listening

In applying this pattern for customer-centric organizational behavior change, we start by listening and applying qualitative analysis practices to UX artifacts such as

Usability Reports
Ethnography Studies
Usage Metrics

During our analysis, we apply qualitative thematic coding across various customer-feedback listening posts.

Learning

Once we have a strong coding pattern in place, we can move on to the next phase in our pattern for customer-centric organizational behavior change, whose goal is to discover insights and learn from our data.

During learning, we take our coded themes and translate them into a customer journey map. During this mapping process, we first create a simplified story about the customer’s journey when using our product. We then leverage this storytelling framework by inserting our coding from the listening phase so we can generate a data-driven storyboard. To increase the perceived validity of our journey map, we very carefully map our insights back to specific data sources. This approach has the added benefit of showing when it’s possible to triangulate a customer need across multiple listening posts.

Our goal during this learning phase is to create a journey map that both

conveys what our data shows is most important to customers
is comprehensible by a typical internal stakeholder in under ten minutes

The process of achieving this ten-minutes goal usually involves some pretty ruthless editing to ensure very succinct communication.

With this journey map in hand, our next step during the learning phase is to communicate the map broadly across the organization. By presenting this conceptual framework to our stakeholders, we build a common understanding of user needs—long before we present any design concepts. Because we have taken the additional step of tracking our data sources, stakeholders who remain skeptical can go back to the original data to review our analysis.

Acting

Having achieved an enhanced level of organizational understanding, we can then move on to the next stage of our pattern for customer-centric organizational behavior change and act.

During this stage, our primary action is to communicate a design solution and provide its accompanying design rationale. What makes this different from the way others might leverage journey maps is that we map our design rationale directly back to specific elements of the journey map. By delivering design documents that cross-reference our journey maps, we fully realize our pattern for customer-centric organizational behavior change. This approach lets us

build a common understanding of customer needs through easy-to-understand customer-insights education—using our journey map
deliver our design rationale within the framework of this common understanding of customer needs

By tying our design decisions back to the journey map—our common organizational knowledge base—we make our decisions less mysterious to our stakeholders. This can reduce the friction that is often associated with the socialization of a design.

Prior to the introduction of this pattern for customer-centric organizational behavior change, UX designers had tried to accomplish too much during a single design presentation meeting. They attempted to get stakeholders up to speed on user needs, while at the same time defending their design solutions. During those meetings, many stakeholders had seemed overwhelmed by the amount of information the designers were communicating to them, causing them to fall into the familiar pattern of assuming they were representative of the user.

Although this may seem counterintuitive, we actually gained greater efficiency by having two meetings instead of one. Separating user-needs education—our journey map presentation—from the communication of our design rationale—our design presentation—helped our stakeholders to more effectively digest the information.

Becoming Customer Centric

To become customer centric, an organization must

derive its goals from VOC data—listen
communicate these goals broadly throughout the organization—learn
help employees to achieve these goals—act

By using this pattern for customer-centric organizational behavior change, UX professionals can position themselves as customer-centric change agents and create broader-based organizational support for their design solutions.

In UX Strategy | User-Centered Design

5 Comments

Steve Wolff

October 8, 2014 6:57 AM

The problem is: stakekholders will tell you that they already know the VOC.

No organization I’ve been a part of changes its organizational behavior via a well thought out program from a change agent. That type of change comes from organizational leadership.

I’d much rather read something that explains how I can overcome the attitude stakeholders have of representing the audience when I’m in a meeting with 2 or 3 of them discussing the work-a-day project we’re working on.

If we’re not already customer centric, by the time we accomplish that organizational change, my career will be winding down.

Frank

October 10, 2014 5:45 AM

I second Steve, with his argument about the change factor of this method. I don’t think this method changes an organization.

Nevertheless, I like it and think it will help me a lot.

Thanks for sharing.

simon marriott

October 12, 2014 12:27 AM

Hi,

I find this a timely and helpful article. Having recently completed an assessment of a recent software rollout/org change, I have a good understanding of the ‘VOC’, the journey map, and the issues. I’m trying to work out how to ensure that the decision makers and leaders absorb and learn from this information.

I like the idea of separating the recommendation from the user experience, partly because it validates the approach I was considering.

Simon

Kimberly Dunwoody in reply to comment from simon marriott:

October 15, 2014 9:56 AM

Hello Simon,

Separating the concerns has worked very well for my team. If it is feasible, please let me know how your approach shapes up as I am always looking for ways we can continue to improve this approach.

Kimberly Dunwoody

Kimberly Dunwoody in reply to comment from Frank:

October 15, 2014 10:24 AM

Hello Steve & Frank,

I understand your concerns with this type of change, and I have also had odd, unfortunate experiences with large-scale, customer-centric change programs.

Iterating through this approach for the last few years, I have had success guiding teams through an interdisciplinary approach to the journey-map phase. During these sessions I like to focus on the difference between the raw data that we’ve collected (VOC) and the resulting thematic analysis (Customer Insight). By agreeing to the themes uncovered via the Customer Insight, teams can then focus on solving the same problems. Plus, as this approach has matured, we have also been able to agree to the priority in which we address the themes, which provides further internal alignment.

During the sorts of day-to-day situations that Steve describes, we can then point back to the thematic coding and prioritization process we previously agreed to. While this approach may not necessarily change the organization, it can vastly improve the level of rigor that you apply to making experiential design decisions, as well as alignment around designs.

Kimberly Dunwoody

Join the Discussion

Full name

Email address

Remember me (Optional)

Comment

Kimberly Dunwoody

Director of User Experience at Truven Healthcare Analytics

Greenwood Village, Colorado, USA

Kimberly is a UX executive who focuses on design, technology, and leadership of change-management and customer-centric education. Her unique approach to the socialization of design solutions has developed from her belief that user experiences are an outward expression of an organization’s internal structure and behavior. Previously, as Director of Global Customer Experience for a Fortune-500 financial services company, Kimberly led formative customer research and design across five continents. Kimberly holds an Ed.D. from the University of Creighton in Leadership focused on Qualitative Research, an M.A. from the University of Colorado in eLearning Design and Implementation, and a B.S. from Metropolitan State University of Denver in IS: Human Computer Interaction. Read More