Communicating the UX Vision

13 Anti-Patterns That Block Good Ideas

Martina Schell, James O'Brien

• Publisher: Morgan Kaufmann
• Year: 2015
• Print ISBN: 9780124201972
• eBook ISBN: 9780127999241
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

This book identifies the 13 main challenges designers face when they talk about their work and provides communication strategies so that a better design, not a louder argument, is what makes it into the world. It is a fact that we all want to put great design into the world, but no product ever makes it out of the building without rounds of reviews, feedback, and signoff. As an interaction or UX designer, you've felt the general trend toward faster development, more work, and less discussion. As we spend time crafting, we become attached to our own ideas and it gets all too easy to react to feedback emotionally or dismiss it, when we should be taking the time to decode it and explain or adapt the design.  Communicating the UX Vision helps you identify the skills and behavioral patterns to present your work in more persuasive ways, and respond more constructively to feedback from coworkers and stakeholders. - Learn presentation tips that make stakeholders and other departments take your designs more seriously - Uncover valuable techniques to make feedback sessions more productive - Understand how to improve empathy with business stakeholders and learn to speak their language better - Discover how to better understand your behavior and identify your personal anti-patterns

Chapter 1

Speaking different languages

Abstract

Different departments speak different dialects, sometimes with terms that cross over but have different meanings to different people. These dialects are a source of unnecessary confusion and often of conflict. As designers, we are trained to understand different ways of representing concepts. By collecting an understanding of other groups’ dialects, we can cut down on confusion, drive the agenda, and maybe even become the universal translator for the whole project.

Keywords

agreement

disagreement

understanding

stakeholders

presentation

argument

meetings

etiquette

dialect

“Working with other people is simple: figure out what they want, and make sure they understand what you want. The rest is a rounding error.”

—Mike Monteiro, founder of Mule Design and author of Design is a Job

Imagine this: You are at an impasse in a design review meeting. You’ve explained your point numerous times. The other party, similarly exasperated, is staring you down as if you have clearly lost your mind. The time of friendly team play has long passed. You sigh and find yet another way of rewording your concerns – and all of a sudden, the other party is delighted that you’ve finally cottoned on to their view. “Wait,” you say, “we’ve both arguing the same point this whole time?”

This is a painfully common scenario. In the course of the authors’ careers, we have seen it derail progress far too often. We hasten to add that it’s not always designers who are misunderstood. This can just as easily arise between any two participants. If you could add up the cost of all that time spent accidentally disagreeing over a common position, you’d be horrified at what it adds to a project’s bottom line.

One of the most common reasons for this is that each discipline that contributes to product development has its own business dialect. This is a vocabulary and way of speaking that, while based in the group’s native language, subtly changes the meaning of words and terms to be specific to the aims of a single discipline. This gives them efficiency in communicating their goals within the group, and a common language for working with in-sector groups outside the organization. To an observer from outside the group, a business dialect can sound like a collection of jargon, buzzwords, and nonsensical use of normal words (think of how marketers use the term “reach” to talk about the number of people who view a campaign). This can lead to a gap in understanding when two groups with different dialects discuss their goals.

Sysadmins regularly talk about fingering, unzipping, stripping, and mounting. To the rest of us, this may sound like sophomoric humor, but to an HR rep, they sound like the kind of coded language that leads to disciplinary action. This is a somewhat extreme example of how differing dialects can cause offense (although see later in this chapter for a real-life example of how it can happen), but most often, the result of clashing dialects is that parties end up with differing expectations of what’s going to happen next. At least one of those parties is being set up for disappointment.

The first and most basic of our anti-patterns is to carry on a discussion based on what other parties are saying, without understanding what they mean.

Crossing wires

Even when we do the same jobs, we can often have different vocabularies from our colleagues in other types of business. Think of a UX strategist in a consultancy-type organization building a customer-facing portal, and someone in the equivalent role at a marketing agency building a campaign for a large brand. The former will talk about the value of a feature by addressing its business value – whether it is worth the cost of implementation for the return it will bring. However, the latter might refer to what return on investment (ROI) it will bring – having paid for this feature, will the business see any benefit from it? Close investigation will show that these are the same metric from different viewpoints.

Dialects also change depending on the development stage of a project. At the implementation stage, a UX designer who is reserving space in a wireframe needs to know whether a piece of advertising is a banner, skyscraper, takeover, or MPU. However, early on, when a UX strategist was calling the shots, these all came under the generic heading of “display advertising.”

More insidious is when the same, or similar, terms, mean different things to different groups. The classic example is the stakeholder to whom “user experience” means “user interface design” or even just “usability,” with its correspondingly limited scope of influence. Or take the word “engagement,” which implies a certain depth of relationship to UXers, while a marketing person may just take it as meaning a user has engaged with an ad and followed its call to action.

Think back over your latest project and see if there are moments of disagreement or circular conversations that could be explained by this mismatch of semantics. Were there moments where you dismissed or failed to understand a concern because it was in a different dialect?

You need to be aware of this anti-pattern before it becomes a visible problem, because errors in translation often go undetected at first, but have a nasty habit of combining, multiplying, and blowing up in a bigger way at a later date. Failing to understand the nuance of a first round of feedback is troublesome, because the misunderstanding will invalidate much of the work that is done for the second round, leading to added time and cost. If the misunderstanding slips through the second round and makes it to the third, you’ll have eroded the trust and confidence of that stakeholder in a serious way, in addition to escalation in the time and cost to fix the issue itself – and, when deadlines are tight, there simply may not be enough time to fix it at all.

Without a shared vocabulary, you won’t have the right terminology to reassure your stakeholders, raising the risk of your explanation making the matter worse. The more basic you have to make your explanation, the more it risks coming across as patronizing – “users know how to scroll” answers questions about the fold, but doesn’t address the information architecture challenges the stakeholder is really clashing with. Multiply these difficulties across the many stakeholders a typical project involves, and you’re in a lot of trouble.

Bitter experience

James: How damaging can this anti-pattern be? Let me share with you a story I once witnessed. I was on a team building a new public-facing product, and we were in a sprint demo. The team had just demonstrated a new feature to support an upcoming marketing promotion.

“We’ll need tracking tags added to the pages,” said the marketing representative in the room.

The front-end developer, looking down at his notes as he captured the requirement, said, “Uh-huh. That’s trivial.”

To a developer, the word trivial is positive. It identifies the kind of feature request that’s so simple it doesn’t need a card on the wall, the type of request where you leave the meeting and the confirmation e-mail that it’s in production is in your inbox before you’re back at the desk.

But to a marketer, hearing their request called trivial can be an insult. It implies that it’s unimportant and won’t be made a priority. Worse, the developer delivered his response without making eye contact, and with an ambiguous term of agreement: “Uh-huh.” This could mean “Yes, I will do that” or “I acknowledge that you’ve made that request.” He made the classic mistake of addressing the request, not the person.

Piqued, the marketer shot back, “It might be trivial to you, but it’s important to me!”

Now the tone had been raised and the developer was aware the marketer had been somehow offended, so he tried to explain: “I can check that in today, and it will go in the next drop.” In developerese, this is a strong commitment to delivering the feature: “I’ll make this my priority and it will be done today.”

But the marketer didn’t know the term check in, meaning to commit code to the version control system for inclusion in the release, and she didn’t understand the term “drop” as meaning the release. She understood this as meaning that he would “drop it in” when he had time.

Neither was willing to push the matter further, so it was left there, but a lingering trust issue had arisen. The marketer henceforth saw the developer as naïve and unhelpful, and the developer saw the marketer as volatile and demanding.

Both parties here were suffering from the anti-pattern. The developer used domain-specific language that the nontechnical marketer misunderstood to have negative connotations: he addressed the request, not the person. But equally, the marketer didn’t test her understanding of the terms she heard, even when she heard several terms that she had no reference for. Both sides of this fence are easy for UXers to get caught on.

Business dialects are troublesome, but they’re a blessing as well as a curse. As professionals, we often deliberately push our vocabulary into more technical terms that grant legitimacy to our ideas. For example, it can be easier to get a stakeholder to buy into the idea of “cognitive fatigue” than “A messy layout makes the user tune out.” We call this gain in credibility from using technical language the “$5 word” effect. But these specialized dialects also exist because disciplines form around core sets of new ideas, and those ideas need a way to be communicated for the core concepts they are.

To take a simple example, imagine the word “wireframe” had never been coined; would you really want to talk about a “low-fidelity schematic of the user interface” a hundred times a day? Now imagine that same scenario replicated across every piece of UX jargon that we use among ourselves. Jargon serves to simplify intrateam communications, so the resulting linguistic efficiency repeats itself within every department of an organization. Further, once everyone in a team or discipline is speaking the same jargon, it has a powerful bonding effect, defining that group as a tribe and promoting intrateam support.

For all their positive effects, there are further downsides to business dialects beyond just the cost of argument. When a team becomes too comfortable with its own jargon, it can lose the ability to communicate core concepts to the outside world. When they come to embody it in a user interface, the jargon has a tendency to seep through into labels and category names, resulting in wayfinding and calls to action that confuse users who have never come across those terms before. And, as jargon generally supports a team’s culture, jargon in the interface is also a sign that the underlying navigational model and information architecture of the site is based on the organization’s needs, not the user’s.

Of course, UX and design have their own dialects – dialects that, if anything, are more complex and cliquey than most. Design is a well-established discipline and UX is an ambitious young one, which gives us an odd situation where we often have several terms for the same thing. For instance, where exactly is the line drawn between a sketch, a scamp, a comp, a ...

Table of contents

• Cover
• Title page
• Table of Contents
• Copyright
• Dedication
• Foreword
• Acknowledgments
• Introduction
• Chapter 1: Speaking different languages
• Chapter 2: Having different KPIs
• Chapter 3: Not embracing everyone’s goals
• Chapter 4: Presenting without contextualizing
• Chapter 5: Being in the room but not present
• Chapter 6: Not having a consistent design language
• Chapter 7: Throwing deliverables over the fence
• Chapter 8: Living in the deliverables
• Chapter 9: Assuming others don’t get design
• Chapter 10: Insisting on perfection
• Chapter 11: Responding to tone, not content
• Chapter 12: Defending too hard
• Chapter 13: Not defending hard enough
• Chapter 14: Identifying and fixing your own anti-patterns
• Chapter 15: Relaxation techniques at work
• Chapter 16: Group design techniques
• Conclusion
• Glossary
• Index