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.
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.
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 wireframe, a mock-up, and a “static”? The distinction may be clear to you, but imagine being a stakeholder encountering UX for the first time; without context, it would seem like a whirlwind of very similar terms being thrown around, but each must have a different and important function, because each has a different name.
This anti-pattern has an insidious trap for us, because we learn in our careers that speaking with authority is the way to make others trust our designs. And the $5 word effect often does work, except that, when it doesn’t, suddenly it causes people to disengage, to see design as exclusive and difficult to understand, and to question how it ties back to their “bread-and-butter” business needs.
When this happens, we usually pull back and try to restate our point in simpler terms, but simplify too much or choose the wrong metaphor and your audience can just get more confused. If, instead, we know their dialects and can translate our point directly, we’ll gain trust and help the audience understand that our terminology and design concepts are well-grounded.
There’s good news here, though: Design is language in visual form. That means that, as designers, we have the perfect toolkit to collect the dialects of our organization, translate them into a simple visual form everyone can understand, and capture them in a common vocabulary for the life of the project. For example, user journeys, iconographic maps, and personas are all methods of taking a complex verbal concept and recasting it into a form that is easier to understand and prevents elastic interpretation. Ultimately, when we do our job well, the outcome of our influence is to ensure that the common vocabulary the team adopts is the language the user speaks.
If we just extend this role as a translator into our business relationships, we can combat this anti-pattern and, as a bonus, earn the trust of our colleagues and even become the go-to people for facilitating decisions within the project scope.
Summary
Departments within an organization develop their own internal dialect for the purpose of efficient communication and team bonding. However, each department’s dialect will be slightly different and sometimes words overlap but meanings don’t. If we don’t truly understand what our colleagues are really saying, we can’t understand their motives or the questions they ask of our designs. We’ll answer the question we hear, not the question that’s asked. Or we’ll answer incompletely or with the wrong focus, leaving the questioner’s concerns unanswered and eroding their trust in us.
The “Speaking Different Languages” anti-pattern
Everyone in a cross-functional team brings not just different abilities and experience, but also a different dialect formed around their specialist area. Two different dialects may use the same word with different meanings, call the same thing by a different name, or one may not include the specialized use of a common word from the other. These can lead to mis-set expectations, confusion, and disappointment that, if left unchecked, can derail the development process. Unless you check for understanding and ensure that everyone has understood not just what’s been said, but what was meant by it, this anti-pattern can come back to bite the whole team later down the road.
Figure 1.1 Journey Map: Putting the journey into a visual form ties down the language used. (Photo credit: James O’Brien.)
You know you’re in it when…
• You find yourself suddenly resolving design issues by realizing that you’ve been arguing on the same side as the other party.
• Your answers to a question are met by “yes, but...” and a reframed version of the same question.
• Stakeholders start asking design questions of the project manager instead of you.
• You struggle to frame your answer in new ways when it’s clear the other party hasn’t understood.
• You know you’ve answered the other party’s question correctly, but they haven’t grasped your terminology.
Patterns
We can be proactive about this anti-pattern, ensuring that we’re exposed to as much of the business as possible and being omnivorous about what each department needs and why. Understanding of the need, and the language to describe it, should grow in tandem. Be interested in everything your company does – it will teach you the languages and ensure that your design responds more holistically to the company’s needs.
Stakeholder safari
Usually when we become involved in a project, it happens in the form of a kick-off meeting for all the involved parties. These are great for getting requirements on the table, but they’re often the first time everyone meets. As a result, they don’t do much to facilitate learning the dialects of other departments or promote a team bond. Some stakeholders can seem as remote and unapproachable as lions on the Serengeti, so, wherever possible, it’s important to find a way to interact with them in their natural habitats. You can do this after the kick-off, but it often helps to go out on a safari beforehand if you know who will be involved. If you’re in the same building, head up to their desk to have a chat about their needs and their expectations from the project. If not, try and get some time on the phone or video chat. The important thing is to seek them out proactively.
Figure 1.2 Stakeholder Safari: Seek out your stakeholders to better understand their language and needs. (Photo credit: Katy Dickens.)
This interaction is designed to work two ways. You’re learning about their language and key needs. They’re gaining trust in your ability to understand them and, in many cases, they’ll also be learning about what UX is, and what it can do for them. It’s not uncommon, especially in siloed organizations, for other departments to be unclear about the role and capabilities of UX. This technique really helps them understand it, because you can use your newfound fluency in their dialect to explain it in terms that resonate with them.
The difficulty with running unstructured sessions like this is that, in some organizations, they can be seen as unproductive and frivolous. It can be hard to convince a project manager of the need to make time in the schedule for them, or the stakeholders themselves may not make time to be available. In the first case, recast the safari as “requirements validation and refinement” sessions; this more formal description still describes what they do, but can be easier to see as a risk-reduction strategy. In the latter, it’s important to be persistent. Doorstep the stakeholder if necessary: arrange a lunch or find (or create) a social opportunity. Remember that it’s hard to turn down someone who comes bearing a gift, so if you can find out what kind of coffee or tea they like and bring them a cup to open the conversation, you have a better chance of making your advance stick.
The initial round of stakeholder safaris is important in opening the dialogue and setting expectations. But don’t let them slip away once the requirements are set and understood. Regular facetime with your stakeholders is vital to not be blindsided by changes. Watercooler conversations are another of those communication aspects that seem trivial, but can actually give you advance warning of situations that can affect the project, like budget cuts, staff changes, or things happening in the wider business landscape. It’s far better to know and prepare for these things as early possibilities than to have them delivered as faits accomplis by someone who hasn’t been made sympathetic by shared chats.
The next few chapters contain lots of useful goals and techniques to pursue during your stakeholder safaris.
The meeting before the meeting and the meeting after the meeting
Meetings are a special beast in the world of business. They have their own rhythm and etiquette and, as the place where business dialects crash into each other, they also have their own special dialect. When you’re in a meeting, you tend to slip into a different communication pattern, with or without noticing. This makes meetings very powerful, but also extremely susceptible to this anti-pattern. But there are two other special aspects to a meeting where the possibility exists to interact in an unstructured way and break out of this pattern: the on-topic but casual time while everyone is gathering, and the time when the meeting is over and people disperse.
At the meetings before and after the meeting, the normal etiquette isn’t in play, but any agreements that are made will usually feel to the bargaining parties like part of the meeting itself in retrospect. This means that these moments are a great time to set up your argument for the meeting with stakeholders who might be sympathetic with the right priming, or to crystallize actions based on a decision that’s been made.
The meeting before the meeting
It’s important to enter a meeting knowing the outcome you expect. Before the meeting, you can engage in conversation with the other attendees present to give them a positive sense of your ideas. If you’ve done a stakeholder safari, it should be easy to understand how to cast the conversation in ways that will resonate with each stakeholder. You can also affect the shape of the meeting by priming them for certain topics: “I hope we’ll get a chance to discuss the navigation today; we really need to get moving on that.” Agreement (and especially discussion) to a statement like this in the meeting before the meeting means that you’ll be likely to get support when you raise it in the meeting itself, and you’ll know from which direction, too.
The meeting after the meeting
In the dispersal after the meeting, you’ll have a chance to choose which stakeholders to re-engage with. Usually a meeting will decide what will happen, and the meeting after the meeting will decide how. Those moments in flagship political dramas, where people follow each other down corridors trying to sway their decisions, are examples of how important the meeting after the meeting is.
Again, it’s important to understand what outcome you need. Which stakeholder could support the right process, and might be open to a conversational nudge? That’s the person whose ear you want to catch as you leave the room. Engage them positively and explain that you have a few ideas about how you can achieve the agreed-upon outcome that you’d like to briefly bounce off them. Treat it as striking while the iron’s hot and the discussion is fresh in everyone’s mind, and the stakeholder should see the sense of discussing it at that time.
The meetings before and after the meeting have lots of extra uses, too. They’re great for smoothing over any frictions that have occurred, restating your dedication to the project and a stakeholder’s needs, or just opening up the opportunity to carve out a time for safari visits. Once you recognize the existence of these moments, you’ll begin to see plenty of opportunities in them for yourself. Next time you’re in a meeting, observe the room before, during, and after it happens. What are the topics and who are the actors at each stage? Who’s grabbing whose ear as you leave?
Using these conversational spaces this way may seem a little manipulative. But it’s important to understand that most stakeholders of any seniority will understand this aspect of meetings and use them for their own ends. This pattern just brings you up to parity with them, and we trust you to have the best intentions.
Lowering the wall
By the time we reach the workplace, we UXers have generally been in creative spaces for at least a few years, as part of a design degree or involvement in other creative aspects of business such as coding and business analysis. Experience of that creative environment is vital, but it can lead us to forget that not every department of every organization works in the same way we do. The confidence that we gain through presenting our ideas can be intimidating to people who don’t see their roles as creative. The implication of readiness for critiquing that goes along with presenting our work can be missed. And terms that we use for efficiency or to cast our ideas with authority can feel like a wall being built between us and the other party.
However, when we speak with too much authority, it can feel like we are presenting ourselves as the masters not only of experience, but of the entire business. This can lead other parties to think we implicitly understand all their terms and the background of their requirements, or to feel that we cannot be challenged on those occasions when our knowledge is incomplete or wrong. It is necessary to find a way to expose the gaps in your knowledge in a way that encourages others to contribute positively.
It is, of course, vital from a credibility point of view to present with confidence and to be conversant with the business dialect of design. How do we ensure that this doesn’t tip over into alienating stakeholders or coworkers? The more informal communication opportunities you take outside these times, the more options you have. When you’re very comfortable with the other parties, you can step in and out of formality during a meeting, keeping the wall low and allowing the other parties to understand that they can step in any time to ask questions without losing face. If that level of informality hasn’t been reached, then you can keep the wall low by checking for buy-in on concepts – “Am I making sense when I say ‘affinity mapping’?” – and by actively inviting critique.
In the introduction to this book, we introduced the importance of knowing your style. This pattern is one of the places where your style is vital to how you use it. For example, James grew up in England and is comfortable using self-deprecating humor as a way to lower the barrier (in early drafts, he wanted to call this pattern “Call me stupid...”). Martina finds that her sense of humor doesn’t translate from German in this context, so she uses a warm, inclusive tone to encourage other parties to engage. It’s important that you choose a way of doing this that feels comfortable to you. If you’re not, stakeholders will be able to sense your discomfort and you risk raising the wall instead of lowering it.
It may seem counterintuitive to suggest that showing “weakness” in a business context can be a positive and productive way to work. However, remember that creativity has its own needs, which many businesses are now finding themselves rushing to embrace. In businesses that develop products, the maxim “fail early, fail often” is used as a way of admitting the boundaries of our experience as we push into unknown territory, and minimizing the risk of failure. As designers, we can expose the boundaries of our experience to give the business permission to focus on being good at what it does, and demonstrate that design will not impose undue risk by investing too heavily in incorrect assumptions.
Step back
Many anti-patterns arise from rushing in to answer questions or challenges rather than taking a moment to look at the problem from a different perspective and empathize with the other party. The pattern that underpins everything else we talk about in this book is to hold back on your initial response and take a second to evaluate what you’ve heard before responding.
In the case of this anti-pattern, Step Back is important in giving you the time to translate the dialect of the challenge into terms that are natural to you. Never try to answer a question or challenge without doing this first, because you will almost certainly answer a question that wasn’t being directly asked. Or worse, you may end up defending a point that wasn’t actually being challenged.
Taking a step back also gives you the opportunity to remember that the deliverable you brought to this meeting is not intended to be the perfect answer, but rather an embodiment of your current understanding to facilitate conversation. Once you have this view, it’s a little easier to be empathetic to other parties who challenge it. It opens up the possibility that, rather than your work being bad, it just reflects contemporary assumptions within the business that are now being tested. Whether that’s true or not, it offers a better headspace for you to collaborate in.
Play it back
Check the quality of your translation by playing back what you heard. This gives the other party a chance to confirm or correct your interpretation, and helps them get a hold on what you mean when you use particular terms. We’ll expand more on this in Chapter 12.
If others inflict this anti-pattern on you
UX would be an impossible discipline if we didn’t have a dialect of our own, but this does mean that the same problem we have with other departments can affect their understanding of us. Your stakeholder safari and lowering the wall will help share understanding with other groups, but there will always be times when, despite our best intentions, we can’t find the right terms to explain our thinking.
If this happens, it’s tempting to explain using a metaphor, but although a well-chosen metaphor can illuminate the point like a bolt of lightning, we recommend you tread very carefully on this path. Metaphors about UX goals have a habit of taking over the argument, giving the stakeholder the opportunity to disprove the metaphor rather than engage with the underlying point – for example, “We need the site to feel solid and dependable, like the way a Volvo’s door goes thunk when you close it” can easily turn into an argument about how the stakeholder’s aunt once owned a Volvo and the door fell off it. They also risk sounding patronizing if too simplistic, or making the misunderstanding worse if too complex.
Start by playing your understanding back in as much of their dialect as you can, and test understanding of any UX terms you can’t translate. Don’t try to simplify common UX terms too much – for example, if you try to simplify the term “persona” by calling it an “example user,” a stakeholder could miss the link to research and understand this as a single person rather than a composite. Instead, get to a common base of understanding and then lead in with a needs-based explanation of the gaps. For example, “To understand why Ravi isn’t converting, we need to know what’s going on inside his head. To help us empathize with what he’s seeing, thinking, hearing, and doing, we use a tool called an empathy map.”
Conversations are a high-bandwidth method of communication, but they get an extra boost when sketching is also involved. Consider your sketching practice not just as design exploration for yourself, but also communicating ideas simply to nondesigners – the first step in creating the visual language we described earlier. Getting your explanation out as a sketch, and inviting the other party to sketch their side, is the best way to build common understanding, bar none.
If you’re still struggling, remember the meetings before and after the meeting. Use these to humanize the other party’s view of you and find ways to align your approaches.
Terminology explained
$5 word effect
Accidental disagreement
Business dialects
Cost of argument
Playback
The meeting before the meeting
The meeting after the meeting
Case study
Speaking different languages in software development
Figure 1.3 Eli Toftøy-Andersen. (Photo credit: Eli Toftøy-Andersen.)
I think understanding the words we use to describe the work we do and the complex domains we deal with is key to success in cross-functional teams. If the word “design” is already in use by five different experts, clarification is necessary. It’s part of my job as a consultant and as a designer to make sure we all understand each other. In workshops with designers, clients and end user representatives, I always encourage “stupid questions” regarding the domain and the words that we use on all sides of the table.
How to learn the client and project domain
As an interaction designer, I know that the words that you use in an application are important. In 2010, I worked at Norway’s largest Agile project, the PUMA project at the State Pension Fund. Both working within the domain of pensions and the idea of Agile were new to me. In my first day at the project, I was walking around and stopped, looking at the different whiteboards. Suddenly somebody told me that I was “standing in the middle of their standup.” I had no idea what that meant at the time, but figured I had to move out of their way. Over the next few days, I was bombarded with new words. I had to design user interaction with values I knew nothing about. When I asked what “erhvervskoffisient” meant, I was told that it was a value between 1 and 10; usually between 1 and 2.
For an application for a hospital, I had to learn words like “diurese” and “cardio” and understand the responsibilities of the different departments. For an application for the Norwegian Department of Defense, I had to learn the difference between “ETA” and “ATA” and the rules for foreign ships that cross into Norwegian waters. Designing such applications would not be possible without knowing the words.
I’ve learnt the words by observation, talking to the people who work there, reading books, the intranet, brochures, and just spending time learning the client’s business.
Multilingual projects
In multilingual projects, the risk of misunderstandings is even greater, not just because of the different words that we use, but also because of the cultural differences. The need for clarification and explanation of the way we work, what we mean by design and what we deliver will always be there.
The differences in the words also come into the applications and websites that we design. When working with the multilingual learning environment Fronter, I learned the hard way that words in different languages “build” differently. For instance, a typical sentence takes up more space in Norwegian or German than in English. When it comes to languages like Finnish, the order of the words might be so different that just replacing strings in broken-up sentences will not work at all. And where do you place the lefthand menu when the reading order goes from right to the left?
Conclusion
I find that studying languages and being interested in languages is a big plus for interaction designers.
As a UX person in a company with lots of engineers, you need to be prepared to keep explaining what you do and what the words that you use mean. To clarify the words and ensure you speak the same language as your audience – making sure that new team members and the stakeholders know what you are talking about – is part of your role. You have to do your part to help with getting to the common understanding that is necessary to work together in a good and efficient way.
Eli Toftøy-Andersen, team manager, User Experience, Steria Norway
Over the last seven years, I’ve been working as an interaction designer and team manager at one of Norway’s largest IT consultancies. Even the word “design” is a source of misunderstanding at such companies. Architects are designing, infrastructure consultants are designing, and I’ve met project managers and sales people who think it is perfectly OK to ask an interaction designer to “make it look pretty.”
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.