Top
Process
Business
Strategy

The UX Customer Experience: Communicating Effectively with Stakeholders and Clients

Beautiful Information

Discovering patterns in knowledge spaces

A column by Jonathan Follett
January 22, 2009
  2 Comments

“To design is to communicate clearly by whatever means you can control or master.”—Milton Glaser

User experience and its associated fields of expertise—such as usability, information architecture, interaction design, and user interface design—have expanded rapidly over the past decade to accommodate what seems like insatiable demand, as the world moves toward an increasingly digital existence.

As UX professionals, we often take technology for granted, accepting the massive complexity and rapid change in our field as the norm—and perhaps even something to embrace and enjoy. With this outlook and because we’re steeped in our daily professional activities, it becomes all too easy for us to forget that ours is not the usual point of view, and the technological change we expect, the expert jargon we speak, and the processes we use are foreign and confusing to other people. So, while we focus our attention on the users of digital products, we can sometimes be remiss in our treatment of another important audience—the stakeholders and clients with whom we collaborate to complete our assignments and projects.

Champion Advertisement
Please become a patron of UXmatters by subscribing on Patreon.
Continue Reading…

Effective communication with stakeholders and clients is critical to the design process itself, but this is not a topic we often address, because, at first glance, it doesn’t appear to contribute directly to our primary goals, which are to create, build, and ship digital products. Certainly, as an industry, we are attuned to client service in a general sense, but there’s no doubt that methods of UX customer communication, education, and collaboration are sometimes overlooked and underutilized aspects of the design process. We can and should treat the elements of stakeholder and client communication as a kind of user experience. And we should design this experience for our UX customers so far as it’s possible to do so.

Considering the overall stakeholder and client experience in a broader sense, it begins with the sales cycle, during which the stakeholders go through the process of deciding to purchase UX design; continues though project management and the design process itself, when they contribute to product creation; and concludes with the launch of a digital product, when a company releases its realized creation into the marketplace. All of these aspects of the UX customer experience, of course, determine whether that experience is an effective, satisfying, and successful one in the eyes of the stakeholder or client.

As UX professionals, the part of the UX customer cycle over which we have the most control is the stakeholder’s or client’s level of engagement in the problem-solving efforts that are part of the design process. So, while it’s beyond the scope of this article to suggest a complete experience for UX customers, I want to explore some of the ways in which we can approach the design phase from the perspective of stakeholders or clients and improve their overall understanding of it.

We need to communicate our design ideas effectively with non-technical customers and keep them engaged in the design process. Investing time and effort in this area brings returns in the form of more efficient design cycles and better products. As UX professionals, we’re adept at envisioning the end states of our labors. Communicating our vision to our stakeholders and clients is critical to our long-term success.

The User Group We Never Knew We Had: Our Stakeholders and Clients

Whether you’re an outside UX consultant or part of a company’s in-house UX design team, more often than not, you are designing, evaluating, and improving a digital product in conjunction with stakeholders and clients who are neither UX professionals nor a product’s users. They’re business people, project managers, marketers, and company owners.

If we are to look at our stakeholders and clients as a user group for the digital product design experience—as we would with any UX project—we must first understand who they are, their goals, the required tasks through which they can reach their goals, and how they perceive both their involvement and ours.

Seeing User Experience from the UX Customer Perspective

From the business side of the equation, it’s worth acknowledging that purchasing UX design can be a tricky task—especially for those who have little experience with the design process. As digital products continue to expand beyond software companies and into all types of businesses, UX professionals will increasingly encounter inexperienced stakeholders and clients who are responsible for specifying, hiring, and managing the services of a UX professional. This is difficult territory to navigate. It’s less like, say, purchasing a car and more like hiring a lawyer to create, write, and negotiate a complex and arcane agreement. There can be a lot of pressure and even some fear on the part of the stakeholder or client.

Though digital products are now ubiquitous, most people do not understand how such products are created. The way we should approach UX customer education and communication depends first on the level of our stakeholders’ or clients’ experience with UX. Because the world is going digital so rapidly, there are large groups of people who have varying degrees of incomplete knowledge about technology in general and the UX process more specifically. Even executives who consider UX every day from the business side do not necessarily understand the design process. So, we shouldn’t make any assumptions about the knowledge that our stakeholders or clients possess. Before a project starts or as a part of a project kickoff, interviewing a stakeholder or client team to get a general sense of what they understand about UX yields dividends down the road. While you may think you know what they’ll say, you may be surprised, too. If all of this sounds familiar, it should: We’re talking about employing basic UX ethnographic research principles to learn more about stakeholders and clients, much as we would try to learn all we can about any other users.

Depending on the type of organization for which you’re working, stakeholder and client teams and their politics can vary greatly. For instance, bootstrapped startups have far fewer stakeholders, each responsible for a number of tasks within the organization, while bigger corporate departments may have individuals representing every specialized position imaginable. Not surprisingly, on a day-to-day basis, most stakeholder or client goals have nothing to do with digital product design. Their other goals might include pleasing the boss, not being embarrassed in a meeting, or even not wasting their time. Such secondary considerations compete with the ideal, overarching goal: to make the best digital product possible for our customers.

Considering Our Communications with the Stakeholder or Client

Once we have a general sense of what our stakeholder or client team knows about UX, we can better tailor our conversations, meetings, and deliverables to them. The UX customer experience is made up of both personal interactions like brainstorming sessions, visioning meetings, and usability tests, as well as artifacts such as site maps, wireframes, and screen drawings. Dan Brown offers some excellent, practical suggestions for both creating information architecture deliverables and presenting them to clients in his book Communicating Design: Developing Web Site Documentation for Design and Planning. His general tips for running effective UX-related meetings include the following:

  • “Establish and communicate a purpose. …
  • Decide what you want to get out of the meeting before going into it. …
  • Think through participant expectations, agendas, and questions. …
  • Invite the minimal number of people possible. …
  • Send material around before the meeting. …
  • Write up an account of the meeting. …
  • Take pride in running a good meeting. …
  • For new clients, assume the first meeting won’t go well. …”

How can we measure progress? Checking in with your stakeholder or client periodically throughout the design process to validate that you’re actually achieving your communication goals is a simple way both to see what’s working—or not working—and keep their perspective in mind.

If we’re able to make non-technical stakeholders comfortable with the UX process, they can better understand the digital product we’re helping them to create, yielding better results for the project—from the perspectives of both design and management. Ideally, stakeholder or client knowledge and engagement in the UX process should help mitigate such common problems as

  • optimizing design to meet the stakeholder’s or client’s preferences rather than those of the users
  • introducing unanticipated changes late in the design-and-build process to resolve issues that should have been settled earlier

Artifacts as Evidence of Process

Of course, communicating design involves much more than just artfully directing a meeting or selling our solutions. Although we all want to obtain stakeholder or client buy-in for our designs, there’s a huge difference between presenting a deliverable like a site map or wireframe package to a client and the client’s actually understanding what that document means. If we’re serious about communicating with our stakeholders and clients, we must first admit that it’s not the artifacts we produce along the way, but the user-centered design thinking that generates those artifacts that is most important. So, to the extent that our design artifacts let us convey this design thinking to our audience, they are valuable. But if they’re merely checkpoints or blueprints for our own use, they're not as useful to the stakeholder or client.

When project managers and other stakeholders are unfamiliar with Web site or application development practices, design artifacts become technical details rather than evidence of a thoughtful process. When the hard work of design begins and decision making becomes critical to move a product forward, we have to be able to engage our clients.

In the August/September 2008 issue of the Bulletin of the American Society for Information Science and Technology, Nathan Curtis wrote about design deliverables in his article “Audiences & Artifacts.”

“People don’t read deliverables either.

“The truth is that consumers of your documentation scan deliverables. They’ll refer to deliverables; they’ll look for those nuggets of information they can use to complete their own work. Bottom line? They don’t read deliverables, but most of the time they try to use them.

“Therefore, we’re constantly inspired, driven, even forced to improve our design communications to be more effectively usable and efficiently produced, much like how we approach user-centered design itself.”—Nathan Curtis

It’s probably safe to say that a lot of stakeholders and clients don’t understand or care about the design deliverables—not because they’re stupid or inattentive, but because they’re not engaged.

Communication can be a stepping stone to better collaboration, but only if we’re willing to be innovative in the way we interact with our project audience.

Low-Fidelity Sketches for High-Level Discussions

To illustrate how we might reconsider our communication with stakeholders and clients, let’s look at one aspect of the UX process: presenting a wireframe draft for the purpose of establishing content types and areas. Wireframes work well with technical audiences who understand how this design artifact is put together, what it represents, and more importantly, what it doesn’t. However, one problem you may encounter when presenting wireframes is that, even with guidance, non-technical stakeholders and clients can have difficulty understanding what they illustrate and how the wireframes relate to the final product. For example, a client might get hung up on your use of Helvetica—“Is that the font we’re using on our Web site?”—or the style of a box or the way you’ve represented the navigation. And if your client is uncomfortable with the document he’s reviewing, he will hesitate to make decisions or buy in to the design.

In his book, The Back of the Napkin: Solving Problems and Selling Ideas with Pictures, Dan Roam explains:

“Seeing is the flip side of looking. Looking is the open process of collecting visual information; seeing is the narrowing process of putting the visual pieces together in order to make sense of them. Looking is collecting; seeing is selecting and identifying patterns. And really good seeing is even more than just pattern recognition; good seeing is problem recognition.”

One way of describing this problem, using Roam’s terminology, is that stakeholders or clients may not be able to put the visual pieces together. They’re looking, but not seeing.

The polished, exact lines and shapes of a wireframe drawn in Visio, OmniGraffle, or Illustrator can give stakeholders the impression that the document is somehow finished—although this is often far from the case. On the other hand, sometimes a wireframe sketch representing the very same information as a wireframe you’d create in Visio or OmniGraffle is enough to generate client response and engagement. Why? A sketch immediately conveys that a design is unfinished, and more importantly, that the stakeholder’s or client’s focus should be on the concept itself, not the style and visual depiction.

Could it be that easy? Is the look of a wireframe that important? If we’re considering this from the perspective of our stakeholders and clients, the answer is probably, yes. Drawing is familiar—maybe even universal—territory. We’ve all hastily drawn sketches on the back of an envelope or a whiteboard. This is preliminary design communication at its finest.

So, it shouldn’t surprise us that software tools for creating sketch-like wireframes are now becoming available. For instance, Balsamiq Mockups is an application that lets an information architect or visual designer quickly create a basic wireframe, while retaining the rawness of the sketched look, as shown in Figure 1. And using Mockups, you can continue changing and saving your sketches, unlike, say, when you scan a sketch you’ve created on a notepad. The downside, of course, is that you’re no longer using the physical media to sketch—the pen or pencil and paper or whiteboard.

Figure 1—A wireframe created with Balsamiq Mockups
Sketch-like wireframe

The only time it’s useful to present the artifacts of our work process is if the client understands them and they move the design process forward. In his book Sketching User Experiences, Bill Buxton describes a number of case studies in which designers use sketching to aid thinking about a design problem. In “Chapter 3: The Anatomy of Sketching,” Buxton says:

“Sketches don’t ‘tell’, they ‘suggest’. Their value lies not in the artifact of the sketch itself, but in its ability to provide a catalyst to the desired and appropriate behaviours, conversations, and interactions.”

Low-fidelity sketches establish—for both designer and audience—that it’s time to discuss possibilities, providing just enough detail so a stakeholder or client won’t get caught up in the details of specific elements and allowing the team to narrow down the possibilities and converge on a solution.

Sharing the UX Perspective with Your Stakeholders and Clients

It’s part of a UX designer’s job to explain and defend the logic behind his or her designs, facilitate stakeholder or client buy-in, and bring the product team along when making design decisions. But, in practice, this can be much, much harder than it at first appears.

Ultimately, for our stakeholders and clients, the UX design process is an experience in itself—one that we should design iteratively as we identify best practices. By considering the UX design process from the stakeholder or client point of view, we can better evaluate our methods and ways of communicating design thinking. And as we do this, it’s well worth remembering that, as UX designers, our tools are not fixed. Communicating your design effectively may be as important as the design itself. 

In Communicating Design | Deliverables | Design Process | Stakeholders | UX Strategy

Jonathan Follett

Principal at GoInvo

Boston, Massachusetts, USA

Jonathan FollettAt GoInvo, a healthcare design and innovation firm, Jon leads the company’s emerging technologies practice, working with clients such as Partners HealthCare, the Personal Genome Project, and Walgreens. Articles in The Atlantic, Forbes, The Huffington Post, and WIRED have featured his work. Jon has written or contributed to half a dozen non-fiction books on design, technology, and popular culture. He was the editor for O’Reilly Media’s Designing for Emerging Technologies, which came out in 2014. One of the first UX books of its kind, the work offers a glimpse into what future interactions and user experiences may be for rapidly developing technologies such as genomics, nano printers, or workforce robotics. Jon’s articles on UX and information design have been translated into Russian, Chinese, Spanish, Polish, and Portuguese. Jon has also coauthored a series of alt-culture books on UFOs and millennial madness and coauthored a science-fiction novel for young readers with New York Times bestselling author Matthew Holm, Marvin and the Moths, which Scholastic published in 2016. Jon holds a Bachelor’s degree in Advertising, with an English Minor, from Boston University.  Read More

Other Columns by Jonathan Follett

Other Articles by Jonathan Follett

Other Articles on Communicating Design

New on UXmatters