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
Continue Reading…

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.


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.


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.


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. 

Director of User Experience at Truven Healthcare Analytics

Greenwood Village, Colorado, USA

Kimberly DunwoodyKimberly 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

Other Articles on UX Strategy

New on UXmatters