Full Transcript

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Earlier this fall, Des Traynor presented an entertaining but also a very important virtual seminar. It was called "Microcopy that Strengthens your Design's Experience." This seminar, along with 100 others that teach the tools and techniques you need to create great design, is now part of the UIE User Experience Training Library. In this particular seminar, Des showed our audience how to craft clear microcopy that facilitates user interactions without friction. He spoke to the graphical elements on websites or applications that can be improved with plain language or labels. He showed examples of transactional content that further clarifies the user experience without generic marketing fluff. He even shared how you can establish a personality and compel your users to come back for more. Hey, Des. Thanks for coming back to talk more about microcopy.

Des Traynor: Thanks, Adam. It's great to be back.

Adam: For those that weren't with us that day, can you talk about what you covered in the virtual seminar?

Des: Sure. We talked about microcopy as a whole. When we talk about microcopy, I usually mean the small pieces of text that define interactions or relationships in a product or website. What we looked at was the key areas that you should be aware of when you're writing microcopy, how to write effective microcopy, how to spot it and test it and make sure it tests well. Some of the topics we zoned in on were the role of microcopy in current popular websites. A great example of this actually came up after the seminar, which was, on Thanksgiving Facebook changed their microcopy inside their "update status" box to no longer say, "What's on your mind?" which is the normal text, and on that day it said, "What are you thankful for?" As a result, anyone who logged into Facebook saw a stream of "I'm thankful for XYZ"-type messages, which is just one tiny example of how a super-subtle change redefined Facebook for a day. The knockout effect of that is huge, because it means they can do things like Thanksgiving summary emails. Every single Thanksgiving on your timeline will then be so much more meaningful because it's punctuated by this compelling content. That was one of the topics we looked at, which is how popular sites control their microcopy to gather the content that it is that they want. Then we looked at three types of microcopy that, as a designer, you have to control. We identified the interface microcopy, which is typically the labels used on buttons or for form fields or how you define relationships. For example, do you call someone a "follower" or do you call someone a "friend," et cetera? The next type of microcopy we looked at was the blank-slate experience. What happens when you log into a product or website and you have yet to do anything there, so if you have no friends or no projects or no time tracked? And the last piece we looked at was the content definition itself. It's often left till the end for a lot of popular, say, review sites or content sites, travel sites, to define what exactly is, say, a review of a hotel. Yet whoever makes that decision actually makes probably the most important decision for the entire Web product. However, it just seems to be oftentimes phoned-in. People will say, "Well, let's just put a big box here and call it 'review.'" And we looked at how, say, things like the Apple App Store suffer badly from the idea that the only way you can review is on a one-to-five-star scale and a text box. Whereas I believe, if they augmented the reviews with things like "Is this product value for money?" or "How often do you use this product?" you'd get a much more meaningful way to search, browse, and validate the products that are there. The closing piece of the seminar, we zoned in on a framework for writing microcopy and how you can make sure that it doesn't get lost in the process or doesn't happen by accident because no one bothered checking the wireframes. I identified the key questions you ask -- who are you talking to, what are you saying, what's the purpose of the message, how is the message displayed, when is it sent, et cetera. Then, finally, we just talked about how you can apply these principles across all a company's communications, the key idea being that every product or website has a tone of voice, and whether you like it or not, you establish one. It can be an inconsistent mess of 10 different people writing whatever comes to their mind, or it can be a wonderfully branded experience that is constantly reminding the customer why it is that they love the company or product. We just looked everything from transactional emails -- i.e., typical reset-your-password stuff -- all the way through to what happens on day 7 or day 30, what sort of content is sent then. We just talked about how you can capture all of these and make sure that the product benefits from this consistent tone across the board. And lastly, I think we did a few questions.

Adam: We did, but there were some that we didn't get to and others that we thought were worth readdressing, so let's tackle some of those. There were some really good questions, Des, on some topics that feel like they're related, but they're actually very unique and separate challenges -- localization, internationalization, translation. And we were talking about how to circle back on this topic. You told me about an acronym called GILT. Can you just say more about that acronym and how those different pieces come into play?

Des: Sure. GILT stands for globalization, internationalization, localization, and translation, and they're all different principles when you decide to make your product work across more than one locale, if you will. At the bottom, if you like, of the pyramid, you've got translation. Translation is literally what happens when you take a word in one form and change it to be in another language. You literally translate everything you see in English to German. Translation can leave some things behind. For example, something that's cute and funny in one language, when literally translated, can be neither cute nor funny. And you see that a lot. It happens when you, say, talk to tourists in certain areas, they don't understand your local sense of humor or whatever. Translation is at the bottom of the pyramid. Unfortunately, a lot of people, when they're dealing with microcopy, they feel it's OK to dump a text file online and say, "I will pay $400 to have all this translated." The two problems are what they get back is neither appropriate from a contextual/locale point of view -- simple stuff like what was funny in English might not be funny in a different language. Also, it's bad from an interface point of view as well, because a lot of languages tend to be a lot longer than English, and a lot of languages can be a lot shorter than English, too, depending on the sort of character set used. What you end up with is a button such as "complete transaction," when moved into a different language, can actually cause a ridiculously ugly 600-pixel-wide button. That's where translation falls short. The next step is localization, which is when you look at what's appropriate for any given locale that you're targeting, if you like, any locality. You go through your same content challenge, but you factor in the locale of where it's addressed. In my framework, we were saying how one of the questions you ask is "who?" A related question, when you're applying localization is "who?" and "in what area?" This is when you will readdress, say you might re-frame a welcome message or a cute joke or a funny sort of message on your home page, or your terms and conditions or something strict and legal. You might re-frame it so that it's more appropriate in the language it's being said in. The next step up, if you like, is internationalization. This is the process of managing how do you maintain a product across an entire suite of languages. And this is where I think things can get a little bit tricky, because it slows down your development process immensely when you can't freely adjust microcopy. Now, that slowdown comes with its own cost and its own benefit. Obviously the cost is everything moves a bit slower. If somebody builds a fantastic, quick feature, it's not going to be, "Let's deploy this today," because you need to actually go through a lot of work to get it across the board. However, the benefit should be that because you're trading in all these other extra countries, you should be open to a lot more revenue. Rolling out one feature can actually have multiplicative benefits because so many different people are experiencing it. At the top of the pyramid, you've got globalization. Globalization really just concerns itself with the process of internationalization, which is like when you're removing every single barrier that actually needs to be addressed for a business to trade across different languages. The biggest differentiator there is, it's one thing to say, "Whoopee! Our site's now available in English, Finnish, Spanish, Portuguese, et cetera." But what happens when Portuguese customers start emailing you customer-support requests? Well, then you're in trouble, right? Globalization is usually when you start to concern yourself with it's one thing to have a business that is represented online in many languages. It's another thing to have an entirely globalized business. And that's the top of the pyramid. I hope that addresses what we were talking about.

Adam: It does. It feels like that's a whole separate seminar in itself. Kathleen wanted to know how you recommend storing and retrieving bits of microcopy for reuse.

Des: The most productive way -- I've never done this -- is unfortunately related to just, it's when you're collocated with your design team and you can all just reference the same white board or the same Basecamp or the same Google Docs spreadsheet or whatever. The key question here is, when we define terms, how do we make sure that they're consistent across the board, I guess? And the best way to do that is to have a good shared repository of these things. I've seen varying solutions here. There's a tool called Copycopter, which extracts all the text from a Web product and keeps it all there. It makes things like internationalization a lot easier. I've also seen simple things like just a Google Docs spreadsheet which just has a section called "confirmation mail," and it just has all the key pieces of text that are used there so that as they're updated they can be replicated across the product. But what you're looking at there is effectively document management, of a sort, across the team. Typically, whenever people ask me that question, there's no tool I can recommend that's going to fit into your work flow any better than something you can come up with yourself. As I said, whatever you find is the easiest way for maintaining text files within a team, so that everyone has access, can update, edit, and view them, that's the right solution for you guys.

Adam: Regarding the solution that's chosen, how have you seen them scale when people are supporting lots of products and lots of words associated with them?

Des: Absolutely. This is where it gets a little bit trickier. This is when a white board won't scale, because you're probably not collocated as a design team anymore. You need a way to control the copy or the content of your product independent of everything else. And this kind of feeds into the first question, too. If you're getting to that scale, you're probably also not just trading one set of content, you're actually trading multiple sets. So you have the content of the Web application, and if you decide to change the phrase "welcome to our product" to something else, you have to make that change seven times, update it everywhere, and re-roll out your product across the board. So how do those things scale? Well, the best I've seen tend to be quite problematic solutions where you have a developer or a content strategist/developer who is in charge of the product copy, and what they will end up doing is using a variation of a source code control tool, like, say, GitHub. And what they will do is they make adjustments, merge them in, assign tasks based on the adjustments so it's then localize this word, localize that word, etc., or update this phrase, and they will basically be the governing body for all the content that comes back, and as they complete they will then merge back into sort of the master product which we'll roll out. But that tends to be a big product. The point at which these things are a concern is the point at which you should have people in place who are fully responsible for the content of your product, and, if appropriate, the internationalization of your product. But there's no magic bullet. If you've got that big a product, that many users, that many locales, you have to be investing in this, because the return is significant.

Adam: David wanted to know if you had any views on pronouns in labels, and the example he offered up was something like, "my profile," versus, "your profile.

Des: Yeah, this one come up a lot, and it's kind of whenever we used to work with startups it was always the most contentious question, because everyone has an opinion and a preference. But we tested this quite a bit for a client before just because it was one of those ones where it turned into what we call a bone fight, where everyone thought they had the right answer. You might call it like a [indecipherable 12:37] , but everyone sort of felt that they had a valid opinion, and because there was no science backing up anyone's opinion, it felt good to throw in with anything. So we tested it, and there's no measurable difference. The biggest problem we identified was that whichever one you choose you have to generate all of the copy you're going to write at decision time. Don't say, "Right, we're going to go, "my" across the board," and then later on you might trip yourself up writing your health documentation saying, "To log into your account, click My Account, and then your password into the My Password field" which is when you think about that sort of thing you realize, right, we really screwed that up, like, because that sentence should not be read by any human ever. So if you're going to make these decisions don't do it on a whim, but also just think it through a little bit deeper than just like if you're deciding whether to call it, "My Account," or, "Your Account," it's not just the login box that you're going to make that decision for. You're making that decision for your help, for your seminars, for your frequently asked questions, for your reset password, emails, for everywhere. So just make sure you're able to be consistent across the board. My personal preference tends to be speak to, "My," but honestly it doesn't bother me either way. What you will also notice similar the rule that Jared offered about icons when he said you can swap out icons as long as you keep the positions the same, most people kind of...they zone out for those words, anyway, like as in whether it says, "Your account," or, "My account," what they're actually seeing is, "Account." They kind of...they skip over that. It's not a valuable word for them. So as long as you don't get it inconsistent or trip yourself up with linguistic sort of gymnastics you should be OK.

Adam: What's your take on the value of mouse-over clarification text?

Des: It's a valuable question. My pet peeve with like mouse-over text is that it tends to be what people should have said in the first place. So a classic example of this is for so long before humans got used to it, we used to say, "CVD," for a credit card form, and then you have a question mark on the other side on which you would hover, and it would say, "This is the three digits on the back of your card." And I always felt that it's like we're putting the human explanation behind this question mark, and we're putting the machine explanation as the default. That kind of stuff frustrates me. Another thing that frustrates me is when people put really, really data-rich useful stuff like, for example, sample inputs that are valid behind a hover, and they're using a label that's quite arcane or weird. And I remember working on a gambling site where this happened a lot where people, they'd ask questions such like what odds faction do you want? And no one knows. Like we worked with a lot of gamblers, pretty professional guys, too. No one knew what that meant until they put a...they went for the assistive text or the hover text, and it would then explain, "This means do you want 11 to 4, or do you want decimal odds?" And then everyone was like, "Oh, I know exactly what that means now." So there's a lot of value in there, but what frustrates me is that people tend to put the good stuff in there and leave the bad stuff as the field because they feel like they're being in some way more correct or true to labels. In reality the label, like what a business calls something is actually irrelevant to what the users calls something, and it's the user you're serving with these interactions so focus for them first. Secondly like if you find yourself using a lot of these because you simply can't fit the explanation you want to fit in your form, take that back to your UX designer or whoever who laid out the form and explain the problem that the terminology we're using here isn't just username/password. It's quite complex so you need to design us a form that let's us put a sentence for each input. There are plenty of good examples of this done well like where people have long explanations of an input followed by the text area itself, and I find that's a better solution than an arcane label no one understands and then a tool tip that's three paragraphs long to try to justify it. So that's kind of my answer. Yes, use it, but if you find yourself leaning on it or relying too heavily on it -- you can check this kind of stuff with analytics -- but if you do find that it's becoming the default everyone knows then your default design is broken and your backup supportive stuff is what's saving you, and that's not a good position to be in.

Adam: Sure. Sure. How do you help stakeholders or clients from insisting on something that you know to be problematic copy?

Des: This is actually funny because it does relate to the exact previous question, because a lot of times when I see people using assistive text to save themselves it's usually because oh, the stakeholder pounded the table and said that he really wanted to call this the CRX form, and it turns out none of the users know what CRX is. The only way like -- and this is kind of related to order design decision challenges that you come up against as a consultant -- the most effective way is home truth. A great way I once solved this was sitting in a boardroom of a university, and everyone was fighting over what we were going to call this input on a form, and it was just getting ferocious where people were being so passionate about what should be so meaningless, expect for I knew it wasn't going to be meaningless, because if people didn't understand this it was going to fail. So I said, "Right. Well, let's ring all the people who we know are definitely going to use this form and ask them what they would call it." And everyone's looking at me disgusted like, how dare I. Surely we can divine the perfect thing here with this argument. So I started ringing people, and it turned out everyone's guess was totally wrong, because no one knew what the form field was. But I only had to have three or four phone calls before the stakeholders turned around to me and said, "You know what, Des? We don't need to be here for these phone calls. Why don't you ring everyone and then come back to us with the answer, and we'll just accept it." And I said, "OK, thank you." And that's what you have to do. There's no best practice UX for identifying the right copy to ensure a stakeholder won't challenge it. What you really need to do is meaningfully address the challenge of what is the right copy. And there's two ways you do that. It's similar to how if... if any of the listeners have worked this information architect before, it's a similar challenge to identifying what's a good navigation choice. What I would do when I'm trying to identify what the right labels are, and I want to push it past the stakeholders the two things I do is, one is exploration. And I do that through observation of how people talk in the domain. So if you're working on a gambling site you ask people do they call it a bet, or a gamble, or bet slip, or do they call them odds, or do they call them decimal points, or do they call them wins? And you just observe the language that is used, and you make note of what you believe are the right choices or the most frequent choices, whatever particular terms people use most often. That's your exploration phase. So you gather a lot. And then, individually, you're going to take the terms you're considering using and test them. The best way to test these things is just -- you can do it pretty lightweight. It doesn't even need to have a full interface or anything. If you ask somebody, for example, "Do you know what an authorization is?" chances are they'll say no, and you'll say, "OK, we're going to need to explain that one better." Yet if you turned around and asked them, "What would you expect to find in mail preferences?" they'd say, "Oh, I'd expect to find how I can control what email I receive there," and you say, "OK." The observation is to gather all the different candidates that would make sense, and then you can test them individually with users by asking do they understand what these terms mean, do they guess correctly what they would mean. You don't need to do this for an awful lot of stuff. You only need to do it for the contentious ones where the board or the stakeholders are likely to push back. But if you do do it, it's a pretty lightweight involvement. And it does help you -- the wrong word is "railroad," but it does help you ascertain your professional standpoint and, basically, get these things signed off much quicker if you do it.

Adam: Felicia wants to know if there are principles for writing error messages.

Des: Yeah so, there are a lot. It's an area we're quite familiar with because we used to work on an error-tracking application, and we've seen an awful lot of terrible error messages in our time. There are different categories of error messages, but the key idea here is, "What has gone wrong and how do I fix it?" is what people want to know. The most frustrating versions of this you'll see is, I'm sure every one of the listeners has had the experience of clicking on a menu item only to see it faded out. It's probably the most frustrating experience when you're first using a product, that you can see what it is you want to do but for some reason it's faded out, and they don't explain why. That is the worst version of an error. "You can't do this, but we're not going to tell you why." What you need to do is, basically, every error message has a state of what has happened or what can't happen that you want to happen, and then a resolution, which is, "What do you do about this to make this go away?" Sometimes you will end up with a frustrating one such as "Please reboot your computer," or it could be something like, "Oops, the application has crashed. We're working on this right now. We'll be back as soon as we can. Please check our status site for further information." The key idea is you can't leave people lost. When they see this error message, it has to be clear and unequivocal, as in, "This process did not happen." And then it also has to give you a next step, which is, "Here's what you should do now to make sure that this never happens again." That's the core principles. In terms of tone on language, different people get away with different things. Twitter tends to be quite cute about it. So does Gmail and Chrome. They use things like, "Oops, our tab crashed," and they give you a sad face and stuff. I don't think that stuff helps or hinders. I think the key idea and what most people want to know is, "If this didn't work, tell me what to do now." That's a core tenet in customer experience anyway. If you tried to go for dinner in a hotel and they just said "No" but they didn't explain why, it'd be pretty frustrating. In software, if something didn't happen, the user wants to know why, and they want to know how can they fix that. As long as you get that right, you'll be OK.

Adam: John makes a comment that he sees a lot of development efforts that involve user-experience people at the beginning but not necessarily a writer, and he wants to know if you have any tips to help get writers involved in the design process earlier.

Des: This is a higher-level question. John's correct in that these days UX is now understood and valued, and it wasn't always the case. If you trace back to maybe even 2004 or 2005, UX people still had to argue their case, because everyone felt, "Well, we need software developers, sure. But why do we need these guys? All they do is draw pictures, right?" The question is, why don't people now say, "Well, you know what? We need a writer involved early"? The challenges here are, there has yet to be an iPod of content or content strategy. There are a few great examples, but there has not been the mainstream, widespread one. And when I say an iPod, I mean an iPod or an iPhone or even particular products on the iPhone. They're all great champions of design and they show the real commercial value of excellence in design. When people hold aloft the new iPad Mini on stage, everyone -- executives, top stakeholders, et cetera -- they get that this product is succeeding because it is designed really well and it is marketed really well. What they've yet to see is "and the copy or content or micro-content throughout the product is that excellent." It becomes harder for the content strategy team or the writers to get their foot in the door in these early meetings, which means that they tend to still be an asset that's tapped into on demand but not a driving force in the product. I think it will remain that way until you see more and more examples of people like your MailChimps, like your OkCupids, et cetera, where their interface is so good and so effective because it's so well-written. When you see more of that, I think you'll see people start realizing that there's a serious commercial value with having well-written products in early. The other sort of danger they fall into is that writers tend to often get lumped with the tasks that business doesn't value particularly highly, so things like knowledge bases and FAQs. An awful lot of businesses and products tend to regard these things as a necessary evil rather than a massive commercial advantage. There's no reason for that. We published a piece on the UIE blog recently, saying all content is marketing, and that if you do these things quite well, they can deliver intense commercial value. But until that becomes the standard, I think writers will always have to fight extra hard -- harder than, say, designers or developers -- to get involved in software. That's my feeling.

Adam: Awesome, Des. Thanks for coming back and joining us for a little bit more talk on this topic.

Des: Thank you so much for having me, Adam. It was great fun.

Adam: To our audience, thanks for listening in and for your support of the UIE virtual seminar program. Goodbye for now.