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