Schell / O'Brien Communicating the UX Vision

13 Anti-Patterns That Block Good Ideas
1. Auflage 2015
ISBN: 978-0-12-799924-1
Verlag: Elsevier Science & Techn.
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 374 Seiten

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

Martina is a User Experience consultant with over 15 years of experience in interactivity for web, desktop, TV and mobile devices. She specializes in user-centered design, experience strategy and qualitative design research to help Fortune 100 and start-up companies across a wide range of sectors develop new products and services, or measurably improve existing ones. Martina holds a MA in Applied Imagination from Central Saint Martins, where she conducted research into methods for multi-disciplinary collaboration to support creativity and innovation. She co-founded UX Tuesday and mentors at Method Design Lab and Seedcamp to bring UX expertise to startups. She serves on the UK UXPA committee, and regularly organizes and speaks at events.

Autoren/Hrsg.

Schell, Martina

O'Brien, James

Leseproben

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...