Monday, January 28, 2013

Becoming Better Communicators



Go to article

by INAYAILI DE LEON Published in BusinessCreativityProject Management ∙ 20 Comments

As designers, we pride ourselves on being great communicators. We go to extreme lengths to communicate with users in a language they understand, enabling them to engage with our messages and feel like they’re part of a story we built just for them. Yet, we do a poor job of communicating with those whom our work requires us to talk to every day—and we need to, and can, get better at it.
Issue №365

In fact, as much as we consider ourselves designers, significant parts of our working hours are actually spent communicating with one another. At least, mine are. Here’s a list of tasks I perform on a typical workday:

Log onto IRC (the way people at Canonical—the company behind the Linux operating system Ubuntu—communicate with anyone who’s on the clock) and greet my colleagues.

Check my e-mail; reply to some, save some to deal with later.

Log onto Basecamp; check my to-dos, update some notes, and comment on a hot thread.

Make a quick phone call to my manager to get the daily update and clarify priorities.

Log onto Onotate, a tool we use to provide feedback on designs and wireframes; read feedback I received on my designs and provide feedback on others’.

Do a bit of designing based on feedback and planned tasks; upload them again for quick reviewing.
Meet with my team via Google Hangout to discuss a particular ongoing project.

Reply to the e-mails I left for later.

Do some more designing.

Sound familiar? Whatever your specific situation, I’d bet much of your days are spent communicating with other people, too: talking, writing, being silent, smiling, frowning, asking, answering, listening, and, at worst, yelling.

Good communication skills are what allow us to sell our work, justify our decisions, and stand behind our positions. This (along with doing good work) is how we gain the trust and respect of colleagues, bosses, and clients—something every design professional aspires to. And it’s why all these little pieces of communication we constantly deliver are so important.

So what’s so hard about communication, and how can we get better at it?

Digital communication
We hate our inbox, but don’t know what we’d do without it. We have chats on Skype. We have back-and-forth conversations on Basecamp. But most of these communication channels don’t really satisfy us, make us feel better, or dissipate our concerns. On the contrary, they often seem to make us even more anxious about work. Why is that?
People need human contact and interaction to flourish.

Psychiatrist Edward Hallowell calls the interactions that makes us happier “human moments”—being in the physical presence of someone and having her emotional and intellectual attention—and argues that not having enough of them can lead to oversensitivity, self doubt, rudeness, and worry.

Why? Because digital communication makes us miss all the benefits that come from communicating to while being in someone’s physical presence:
The human moment, then, is a regulator: when you take it away, people’s primitive instincts can get the better of them. Just as in the anonymity of an automobile, where stable people can behave like crazed maniacs, so too on a keyboard: courteous people can become rude and abrupt.1

This sounds incredibly familiar. All you need to do is think of Twitter.

Hallowell explains how the human moment increases the release of hormones that promote trust and bonding, which are at lower levels when you’re not in the presence of another person. These hormones make us less prone to worrying or overreacting.

Digital communication removes all the cues that mitigate worry. As more and more people work like I do, alone from home offices, without much face-to-face interaction, it’s important that we’re aware of this both in ourselves and others.
So what can we do about it?

One answer comes from 37signals, which hires great talent regardless of geography and encourages others to do the same. In their book Rework, founders Jason Fried and David Heinemeier Hansson report that meeting in person is important for remote teams.2

I work remotely from my home in Belfast, but I meet with the rest of my team in our main offices in London at least once a month. Then, not only do we have lots of meetings and face-to-face discussions, but we also make time to grab a cup of coffee, have lunch, and basically just interact casually—something that simply doesn’t happen when you have to type out everything you want to say.

Other teams within Canonical are fully distributed, and they tend to meet every few months for about a week at a time. This is usually when a project is getting started or nearing launch, because close interaction and immediate answers are so critical during these times.

The phone used to scare me, but since becoming a remote worker, I actually hope people will pick it up to ask me something instead of writing an e-mail. And even better than that are tools like Skype and Google Hangout. My team tries to have at least one “hangout” every week, sometimes every day of the week. Regardless of what you’re discussing, relating expressions, gestures, and a space to faceless e-mails or IRC messages will make a difference.

While many good things come with working from home, such as no commute and being able to truly focus on a task, moments of loneliness inevitably assault me every now and then. This makes it critical that both parties—the remote worker and the main office—try to make those at a distance feel like they’re part of something.

Even if you’re not working remotely, it’s very likely that someone you or your company works with is, or will be soon—which makes it crucial for healthy communication that you consider how to create bonds and develop trust without interacting every day.

Emotional creatures
When dealing with people, remember you are not dealing with creatures of logic, but with creatures bristling with prejudice and motivated by pride and vanity.
—Dale Carnegie, How to Win Friends and Influence People

Human beings desperately seek approval, dread condemnation, and thrive on appreciation and encouragement. Not you or I, of course—all the others.

One key point Carnegie makes is that people are prodigies at rationalizing their decisions and actions. From the most merciless criminals to devoted grandmothers, we all tell ourselves—and others—that it’s not our fault.
The problem, of course, is that as professionals we must be accountable for our own shortcomings—as Andy Rutledge makes clear in his book Design Professionalism:

Perhaps most importantly, professionalism means, in every situation, wilfully gathering responsibility rather than avoiding it.
But our irrationality isn’t all bad. Dan Ariely, a professor at Duke University who writes about behavioral economics, has noted several experiments that prove that humans will work harder when their efforts are acknowledged and their work is appreciated and meaningful than they will for financial gain alone.3

It’s normal for irrationality, emotions, and cravings to influence our behavior in the workplace. Understanding this is the first step to communicating with colleagues. When you see that someone feels discouraged, you can quickly offer a few positive words. When you need to make a point in a meeting, you can avoid remarks that would blame others—remarks that only make people uncomfortable and create animosity. If you do need to point out a mistake, you can choose to do so in private, and also communicate that you trust your colleague to do a better job next time.

Considering others’ feelings might not sound like your top priority, but it’s important to understand that the faintest insight into how we actually think, what motivates us, and what makes us disagreeable will only improve communications and, in turn, influence the responses and value we receive back.

A shared vocabulary
As designers, one trap we typically know how to avoid is assuming that a user understands our jargon. Yet we do this to everyone else around us: other team members, clients, and people in our company who aren’t designers. When these people don’t seem to care about what we’re doing, we write them off and say, “they don’t get it.”

It’s a lot easier to blame other people than to admit the obvious: We don’t really know how to get our point across in a language those different from us will understand.

Sometimes, we can even have a laugh about it.

A few months ago, my team was working on a project in conjunction with another, more developer-focused team within the company. Even though we had prepared several documents illustrating the project plan, which involved various research and discovery steps, we felt this other team didn’t completely grasp our role, as they’d occasionally send us things like “finished wireframes.”

My reaction was the same as most designers’ would be: I brushed it off as failing to understand the discipline of design.
I was wrong. A member of the other team eventually explained that when we showed them research plans filled with words like “IA card sort,” that meant nothing to them. If we wanted everyone’s buy-in, we had to do a better job at explaining our jargon, as Mike Monteiro explains in Design is a Job:

It’s your job as a designer, and a communication professional, to find the right language to communicate with your client. When you say a client doesn’t “get it” you might as well be saying, “I couldn’t figure out how to get my point across. I am a lazy designer. Please take all my clients from me.”
It’s funny because it’s true.

We want people to care about design as much as we do, but how can they if we speak to them in a foreign language? It’s important that, as we do with any user, we find a shared vocabulary and empower everyone else to become evangelists for our cause.

Once we took the time to actually define all of those funny words in our research and discovery phase, we turned the other team into advocates for design—people who, armed with a shared vocabulary, can and will spread the word of design within their own networks. In this case, that network was extremely important to us: other developers within the Ubuntu community whom we desperately wanted to engage with in our design process.
All this takes work, yes. But aren’t showing and communicating what design is all about?

Building a narrative
We like to create stories for our users—narratives that are engaging and compelling, that delight them and make them feel like they’re part of something. We want them to feel invested in us, our products, our sites. We want to bring them along on a journey we carefully curate.

We think, “If I were this person, what would I want to feel once I land on this site? What would I be thinking? What would make me stay?” We consider their point of view.
Then we step into a meeting and expect everyone to consider ours.

Instead of showing your work to your colleagues with a few mumbled words and a shrug and expecting them to get its sheer brilliance, it’s important to involve them from the start, making everyone feel invested and part of the solution. Map out the future you see in front of you, and make them walk the same journey.

My team is responsible for the design, build, and maintenance of Canonical’s main websites, but we also have some involvement with several other peripheral sites—for example, consulting on design or providing front-end development. Because we’re called the “Web Team,” we’re generally the first to hear about problems with any of these other websites, too—even though we don’t manage them.

Instead of quickly dismissing those complaints, I find it a lot more interesting to try to understand where they are coming from. Why do they think something is wrong? What would a better solution look like for them? Clarifying what our responsibilities are and explaining the obstacles my team is facing at that particular time (such as too few resources, impending release deadlines, or technical constraints) also improves the conversation.

Sharing a vision for where we want to be in a few months’ time and how they will benefit from it brings other teams along. And when everyone participates or at least understands the process, they’ll also better understand how and why you got there.

Final words
We know we need other people to do our jobs well. But we often say this—to ourselves and to everyone else—without taking the time to truly listen to, be inspired by, and understand the reasons behind others’ words or actions. We desperately want everyone to understand our motivations, to see that we’re upset and tell us something positive, to listen to us and marvel at our wisdom—yet we rarely bother to reciprocate.

People fail to get along because they fear each other, they fear each other because they don’t know each other; they don’t know each other because they have not communicated with each other.

Also in Issue № 365
Universal Design IRL
by SARA WACHTER-BOETTCHER
—Martin Luther King, Jr.
We already have the right tools to communicate with one another effectively. We just need to put the same effort into communicating with colleagues as we put into communicating with users. When we truly understand our colleagues and respect their needs, we will build stronger, more trusting relationships within our teams and organizations—and better design because of it.
NOTES
1.From “The Human Moment at Work” by Edward M. Hallowell (Harvard Business Review, January 1999). The article is behind a paywall, but you can preview or purchase it.
2.See more in Rework's (Crown Business, March 2010) chapter “Hiring” in the section “The best are everywhere.”
3.In The Upside of Irrationality (Harper, June 2010), Ariely describes an experiment where three groups of participants were asked to solve as many sheets of word puzzles as they wanted, with decreasing compensation for each subsequent sheet. In the first group, participants wrote their name on each completed sheet before turning them in. Facilitators would give them an approving nod, and then place each sheet on a pile of others’ sheets. In the second group, the facilitator would place the sheet on the pile, minus the name and the nod. In the third group, facilitators would take and immediately shred each sheet—no nod, no name. Those in the first group completed many more sheets than the others for the same compensation; the only difference was that their work was acknowledged.

Translation is UX




Issue №366

Go to article

by ANTOINE LEFEUVRE Published in Content StrategyAccessibilityUsabilityUser Research ∙ 16 Comments


Je ne suis pas monsieur Lebowski. C’est vous monsieur Lebowski. Moi, je suis le Duc.
The Big Lebowski, French version
There is a world where Harry Potter’s arch enemy is “Du-weißt-schon-wer,” Facebook users click the “Me gusta” button, and the Dude is named “le Duc.” This world is a translated world.
We—the people who make websites—now study almost every aspect of our trade, from content and usability to art direction and typography. Our attention to detail has never been greater as we strive to provide the best possible experience. Yet many users still experience products that lack personality or are difficult to understand.
They are users of a translated version.
When we pledge to embrace the adaptable nature of the web—to make our websites responsive and even future-ready—we’re typically talking about diversity of devices. But the web’s diversity also comes in the form of different languages and cultures.
Translation affects users’ experiences—and our organizations’ success. It’s time we consider translation part of our jobs, too.

Waiting for C-3PO

“Do you want your forum clean like this?”
I had just set up a user forum in French when I stumbled upon this rather bizarre banner. “What makes the forum so clean?” I wondered. “Do they tidy the code every day?” I had to change the language back to English to understand it: “Do you want your own forum like this?”
In French, “propre” means either “own” or “clean,” depending on how it’s used. The rule is simple; any translator would know it. More precisely, any human translator. Google Translate, the system behind the French version of the forum, obviously wasn’t so sure.
It’s not just Google Translate, either. In the 1950s, Alan Turing, the father of computer science, devised a test to evaluate machine intelligence through conversations. The biggest Turing test ever was held last June to celebrate what would have been Turing’s hundredth birthday. The winner was probably the most advanced chatbot ever created, yet Eugene Goostman—as this bot is named—failed to fool the judges 70 percent of the time. When will machines pass the test? In the year 2029—maybe.
This should come as no surprise. Languages are amongst the richest and most complex systems humankind has ever produced. When machines gain the ability to really speak (and therefore translate), it will be possible to use Google Translate in a professional context—and no doubt we’ll also have Google Design and Google Copywriting by then. But today, Google Translate is to translation what the auto mode is to photography: a quick-and-dirty solution. It comes in handy when you need to get an idea of what’s being said about your project on Weibo (China’s version of Twitter), but it isn’t a good option when you need to translate your website into Spanish.
While we’re waiting for C-3PO, we need professional translators. We must also acknowledge their creativity and recognize them as peers.

Great design deserves great translation


Translating is a respectable, valuable, creative and worthwhile use of a human brain.
David Bellos, Is That a Fish in Your Ear?

Le Big Lebowski is a masterpiece. I would even argue that it surpasses the original. Everything is just perfect: the dubbing, the humor, the dialogue. The translators retained the essence of the film while adapting it for an audience that has no idea what a “dude” is. They managed to translate not just the words, but the Coen brothers’ genius as well.
E-mail service provider MailChimp is a masterpiece, too. Aarron Walter’s UX team has succeeded in creating a unique personality. Much of this personality manifests itself through copy: the greetings from Freddie, the company’s joke-cracking mascot; the always-relevant error and help messages; and—above all—the “funny but not goofy, informal but not sloppy” voice and tone used throughout the application.
Now, if MailChimp were to be translated into Spanish, Russian, or Chinese, what would become of this personality? What does it mean to be “informal but not sloppy” in Japanese? Should the mascot’s name still be “Freddie Von Chimpenheimer IV” in German, or could that be misinterpreted? Can you greet an Indian user with “Hi. You could be a part-time model”?
There are no easy answers to these questions. Translating is walking a tightrope. The challenge is to remain faithful to the original design while adapting it for a new audience, for a different culture.
If you think a machine can do this, take a look at this Google translation of MailChimp’s success message, “High fives! Your list has been imported”:

Cinco años de alta! Su lista ha sido importado.

Show that to a Spanish-speaking friend and you’re sure to get a bewildered look.

The road ahead

The web is home to plenty of innovation. But when it comes to translation, other industries are far ahead.
If we want to reap the benefits of translation, we must learn what it takes to do it well—and why it matters. Let me give you two examples.

LINGUISTIC VALIDATION

The pharmaceutical business may not seem to share much with web design, but it has one best practice that could inspire us: linguistic validation.
Introducing a new drug into the market is a complex and controlled process that includes a long series of trials and reviews. Some of these tests involve the patients themselves, such as Patient-Reported Outcomes questionnaires, which assess whether a drug has actually improved a patient’s quality of life. These questionnaires are written in English by clinicians and then translated into hundreds of languages.
Ordinary translation is usually a two-step process: translation then proofreading (some even skip the proofreading). The linguistic validation of patient questionnaires has a few more steps, such as doing both forward and backward translations and pilot testing.
Why such a complicated and costly process? Two reasons: First, the original version is a precise research instrument. Nothing has been left to chance. Second, it is essential for patients to perfectly understand the questions, because what they report will serve as scientific data. The questionnaire must therefore be intuitive and patient-friendly.
Thoughtfully designed products, user-friendly interfaces—aren’t these what we aim for? If we care equally about all our users, it’s time we start thinking of translation as something slightly more complex than a word-to-word job.

CULTURAL EXPERTISE

Raving Rabbids is a humorous party game designed in Ubisoft’s Paris studio. The development team includes a localization specialist in charge of the game’s eight localized versions. She works hand in hand with designers to ensure their jokes, references, and altogether craziness are translatable. For the U.S., Rabbids’ biggest market, a duo of Americans from Nickelodeon even gave the team a little extra cultural insight.
It costs millions of dollars to produce a major video game, and even more to target international audiences. Because playing a game is such an immersive experience, the teams behind Rabbids and many other games have found that localization specialists are critical. They are not given a finished product to adapt—they take part early in the project, as their feedback on cultural matters may profoundly change the game’s design.
The game industry prefers the term “localization” to “translation” because the latter is too often restricted to text. This says a lot about how seriously game studios take cultural expertise. Because they know a cultural misfit can stall a game’s chances of success—and they know for every dollar invested in localization, there’s a $25 return.
Because they know that translation—sorry, localization—is UX.

Translate early, translate often

Most startups employ what could be called the lemonade tycoon approach: Start in your neighborhood, amongst the people you know; this is your best bet. Get it right at home before expanding into far-off lands.
I’m not saying you shouldn’t start in your own country. Local knowledge is priceless. But why wait to internationalize? Unlike lemonade selling, the web is international by nature. From day one, your website will be accessible to any person on this planet.
What’s more, procrastination has a cost. According to Smartling, a translation software company, “it can take companies 12-18 months to internationalize their code and launch their first foreign language site, absorbing much of the company’s engineering resources.”
Companies face the same problem when they develop a mobile version of their site afterward. Good thing many now adopt a “mobile first” process.
Perhaps they should consider “foreign first,” too.

It’s a big world out there

When you come from a non-English-speaking country, as I do, a “foreign first” approach is very likely to mean “English first.” But what if you’re based in New York, Manchester, or Auckland? Which language should you go for?
The answer is actually not to think “language,” but rather “opportunity” and “culture”—as these three companies have:
  • Wufoo is a popular form builder from Tampa, Florida. At the beginning of 2012, it launched Wufoo Español, its first foreign version. You won’t find the Spanish version at wufoo.es, but at wufoo.com.mx—because it saw an opportunity in a neighboring market, and language was a means to reach that market. Besides, Wufoo doesn’t mix up language and local culture: It plans to roll out additional localized versions for Spain and Argentina.
  • CanaDream is a Canadian RV rental company whose website is available in three languages. English and French are obvious choices, but the third one is trickier: German. Again, the company saw an opportunity—Germans love RV travel. But German people generally speak good English, don’t they? Yes, many do—but they will still prefer a company that attends to them in their own language.
  • Bla Bla Car is a car-sharing service born in France. Here we can see that “English first” isn’t always the rule. Bla Bla Car’s first foreign version was in Spanish. The car-sharing market was less competitive in Spain than in other European countries, which gave Bla Bla Car the opportunity to test-run its internationalization before moving on to other markets—which it eventually did. Car sharing is getting more and more popular in Europe, and Bla Bla Car aims for leadership in the region—and in a multilingual area, this has required translation to seven languages and counting.

Bargain-basement market research

Most startups can’t afford international market research. That’s why they focus on their home market. But just as Paul Boag taught us about bargain basement usability testing, we can find affordable market research techniques, too.
Once you’ve settled on a country to target, go to ProZ and look for a translator or agency based there. Brief her about your project and send your prototype or an access to your beta. Ask her to translate the key screens. Even at this stage, you can get lots of feedback: “Are you aware your app name can hardly be pronounced—let alone remembered—by Brazilians?” “I’m sure having Acme Inc. as a client is a great reference in the U.S., but nobody knows them here.” “This photo of a blond-haired, blue-eyed guy probably won’t resonate with a Turkish market.”
Then ask your translator to run a user test using her network of proofreaders. You don’t need hundreds of people—with only ten participants, you’ll uncover any major cultural faux pas. You’ll also gain a general understanding of whether people are interested in the project, what their main questions are, and whether they like the visual design.
Finally, discuss your personas with the translator: Maybe Harriet should be renamed María and relocated to Valparaiso. And what about adding Hugo, the typical backpacker from the Netherlands? With localized personas, all your users will be given equal consideration throughout the design process.
Of course, you’ll need more precise data eventually. But this quick-and-dirty research is enough to get you started. You’ll iterate from there.

Your new teammate

When you start translating early, you make the translator part of your team. Chances are this will be a very rewarding experience. At Novius, my company, it’s changed the way we work.
For major projects, we now create and feed a glossary—or as I like to call it, a “style spreadsheet.” CSS stylesheets are understood by both designers and developers and guarantee style consistency across an entire website. Similarly, glossaries are by and for the whole team and ensure the consistency of content. Just like you want a color scheme that’s thoroughly followed, you also want to make sure “module,” “plugin,” and “extension” aren’t all used to refer to the same concept. Le fond et la forme.
We have also learned that a quality translation begins with the code. Developers strive for reusable code, and strings are no exception. Depending on how a developer handles them, he could make the translator’s job straightforward, or virtually impossible.
When dealing with sentences like, “1 person has this question” and “X people have this problem, including you,” translators are often asked to translate strings like: “person has,” “people have,” “this,” “question,” “problem,” and “including you.”
Even with context, deconstructing these sentences is a translator’s nightmare. For languages with gender, the string “this” is untranslatable (e.g., esta pregunta andeste problema in Spanish). In many languages, like Russian, plurals take several forms (e.g., for the plural “persons,” you would say four Ñ‡ÐµÐ»Ð¾Ð²Ðµ́ка, but fiveчелове́к). And the list goes on.
Since language isn’t code, developers and translators have a lot to learn from each other. Translators will tell them the software they use has translation memory, so there’s no need to avoid repetition. They will discuss how to handle variables in text. They will also decide together which internationalization system (such as gettext) and text file format (like XML or PO) to use.

Not a one-off thing

I won’t lie to you. Once you’ve translated your website, you’re in for good. People don’t care that they’re using a translated version. For them this is the only version. So you’ll have to keep translating.
They will hate being considered “second-rate” users. Once you’re out of beta, 90 percent translated is not OK. How would your users feel if every website update resulted in a buggy mobile version? Users of translated versions experience this all the time, with English text suddenly popping up out of nowhere. To make it worse, the newest features—proudly announced and long-awaited—are usually the ones left partially translated. Users do get the message: You’re not important enough for us to prioritize translation quality.
While good localization boosts conversion rates, bad or partial translation may ruin a user experience, giving users an uneasy feeling about the whole company: If they can’t even get their website right, how bad will the customer support be?
In fact, I recently chose not to purchase a service because of a pricing page that proclaimed, “Give a price to these ladders with your growing company.”
Guess what it was selling? Translation software.

A multilingual web


If I am selling to you, I speak your language. If I am buying, dann müssen Sie Deutsch sprechen.
Willy Brandt, West German political leader

The language of the web is English as much as HTML. If the web had a capital, it would be somewhere around San Francisco Bay. Web professionals worldwide use English expressions in almost every sentence: Like, browser, responsive, Tweet, SEO, etc.
However, 73 percent of internet users don’t speak English, and their numbers are growing. We now enter the age of glocalisation.


In our move toward universal design, we must not forget languages and the people who master them. “Translating is writing,” said French writer Marguerite Yourcenar.
Today we can also say, translating is designing.

About the Author