 I'm Nancy Frischberg and I want to just say welcome to Kate to Hair because this is your first appearance this year at the Linguistics Career Launch. But Kate and I have been acquainted for many, many, many years from our, I think initially from our relationship to Bake High where you were the dinner coordinator and I showed up at dinner a bunch. And so we got acquainted there and actually have even worked together sometimes in the intervening years and Kate's now been at Salesforce for, wow, more than five years, right? Nine years, yeah. Nine years, wow. All right, Kate, take it away, tell us everything. All right. Well, thanks everyone for coming. Welcome to Right Great Air Messages. This is an introduction for you for linguists today. So, well, today we'll cover what air messages are and how they get to be where they are, why they deserve your attention, your linguistic attention and how to apply our expertise as linguists to air messages. We'll talk about standards and audience, interaction design and process, and then we'll split up into small groups and look at some examples and then get back together and report them what we've seen. My background, I, as Nancy said, I've been working at Salesforce for nine years. I have written thousands of air messages of various kinds and also written a lot of standards and guidelines for over, that are in use by over 200 technical riders at Salesforce. I have a patent on a process for organizing and managing user interface text and that's me in a nutshell. So what are air messages and how do they get where they are? In software, we talk about the happy path. So that's what happens in an ideal world. And before I talk more about that, I'm going to, I want to show you a historical example of an air message from the 1970s. Yeah, so it's arguable and you could argue about whether Hal's end of that conversation was guided. I know some of you have been in the conversation design track over the last few weeks, but so an error is something that knocks the user off of that happy path and just the way the software is supposed to work. It's like any other user interface text, it's part of a, like any other user interface text, it's part of a conversation with someone who wants to get something done, but now the conversation runs off the rails and you have to get your conversation partner, you as the error message writer have to get your conversation partner back on track. So how do error messages come to exist and where do they pop up? Well, first there are a few kinds of error messages. So one is, for example, the validation. So for example, you've left a required field empty and the software checks to make sure that you can't continue without providing that information or you've put the wrong sort of value in a field. Those are validations. Other kinds of errors are exceptions. So for example, the connection, that's the technical term. So for example, the connection between your device and the software server has been lost, even, you know, maybe your Wi-Fi goes down or there's some problem with the server. Those are some of the ways that error messages can errors can happen. So who identifies these scenarios so that you can write the messages? Well, engineers, designers, researchers, you, sometimes it's users, your customers, find problems and report them and the engineers fix them. And by the way, engineers is a synonym for programmers, which is a synonym for developers, so you'll see all those terms used. But the team of people working on software has to, they have to somehow identify these messages. I've worked in places where that's kind of an ad hoc, a little bit random process. And in other places, the process can be really structured and it's paired with test planning for the software. Where do messages appear? What do they look like? Well, they can appear on mobile devices, on desktop computers, they can appear in different OSs. And they can appear in dialogue boxes, which you've all seen, a little window with a title and a body and a button, or they can appear in something called a toast, which is a banner that pops up. That's why they call it a toast. There also are API errors. That's errors that are just seen by software developers making software. And I'll go into that a little bit. More later. So why do error messages deserve the attention of a linguist? Well, linguists understand how language generates meaning and prompts emotion. A lot of companies errors and other UI text is written by engineers and designers. And I think that goes a long way toward explaining why so much software is so hard to use. So good for companies that employ writers linguists to do this work. I once worked with a developer. We were working on a project and I asked him, is there any UI text in this particular part of the project we were working on? He said, no, just some error messages. So that's not the right attitude. So linguists know how to convey meaning. You know how to make sentences work, right? An error message is an interruption and it can worsen the distraction. The message itself can worsen the distraction of the error or it can resolve it. So how are word choice and syntax operating? And for example, this message that you can see on the screen, something to think about, how does your brain respond to an error? Well, your prefrontal cortex is involved in trying to resolve linguistic ambiguity. And those neurons are firing in there and they're engaging you. Like you want to solve the problem. If the message is confusing, your brain's going to be stuck there and those neurons are going to be firing and keep you in that state of confusion. You as a linguist can resolve confusion and sometimes the difference between clarity and confusion is pretty subtle and that's where really we can all come in and save the day. Linguists also understand language's emotional impact at a crucial juncture in the user's experience. So timing is a part of how error messages affect us. Does an error message come up late in the process of something that you as a user are doing? Does the error result in extra work? These are things to be aware of and think about. You may not be able to prevent the error, but you can mitigate its impact on users. Think about the context. Is the user dealing with sensitive information like medical and health information or money, bank data? Another thing is, so then the content is the part that you have control over, is the look and the feel and the tone sensitive and helpful or are they oblivious and inappropriate? No one likes to be interrupted and when errors appear they tend to make users annoyed or upset. So your message has an important role in mitigating that and helping a user get back on track. Let's talk about some dos and don'ts. What should you put in an error message? The main thing is to say what went wrong and how to fix it. It's a map back to where you want to be in the software. So you are here at plus directions for getting back on the trail. So in this message we've got a title. We say what's wrong. You can't run your report. And then there's a body that talks about why. And then there's a button where the user can acknowledge that they've seen this thing. In some cases the button can go to, say what you need to do to fix the problem is to change a setting. So the button could go and open up your settings page. In this case, user clicks got it. The dialogue goes away. And there's the report again with its filter adjustments. And the user uses those and tries again. So that's how this area is resolved. More about what to put in there. To help users recover, get back on track, focus on the solution more than on what the problem is. So on the left there's a zip code field and the message says the zip code you entered is invalid. So like I said, say what users can do rather than what they can't. So on the right it says enter a valid zip code and that's nice and clear. This idea of saying what's wrong and then how to fix it, often you end up with two sentences and two short sentences are always better than one long one. But sometimes you can easily imply the problem in the solution rather than first stating the problem and then the solution. That's what's happening in this message here. Let's look at some don'ts. Be really concise. It's amazing how you can cut back and cut back. It's important to be really concise. Make every word count. And you're a linguist so you've got this. Leave out irrelevant details. Just tell users what they need to know. You may get lots of details, information from an engineer when you get specs for writing an error message and it's your job to figure out just what users need to know and know more. They're trying to figure out how to get unstuck and extra information is just confusing. So think of it as a kind of budget with everything. An error message has to compete with everything that's on the screen, in the room, inside the user's head, all of that is swirling around in a user's brain. So think of this as a kind of budget process. So with each message scenario, you have limited space and time to get the user back to the happy path. So use it well. So examples of irrelevant information are technical information for programmers. If you're writing for a consumer interface, then just developers will tend to give you technical information. It doesn't belong there for users. Unless it's something they don't need and then you need to express it in a way that is going to make sense to them. Another thing is a business process. So raise your hand if you've been in a conversation with a customer service representative who's responded to your problem by explaining how the company's system works. Do you care? No. So yeah, stay away from business process and stuff like that that really doesn't matter to users. That's one of the things that can confuse and annoy them. The overall thing, and this doesn't only apply to error messages, but to user interface text in general, there are English words that have have developed engineering meanings, in other words, jargon. And they show up in these kind of stilted sounding constructions because they come from engineering concepts. So for example, submit, we've all seen a button that says, buttons that say submit. That comes from engineering jargon. Use the English verb that describes what the user is actually doing. So it's save or send whatever it is. Failed is another term that's used in engineering and it has really bad connotations in English. So just talk about what actually is going on from the user's point of view. You couldn't save the task. Insufficient privileges is a term that comes up in applications that involve permission to do something or another thing. Again, just speak English there and talk about permission to access or something like that. Okay, so here's one successfully. And this is not, again, not only related to error messages, but I'm going to talk about it because it's really pervasive. So programmers, the way software development works is programmers send what's called an API. They send a call out and then a response comes back. And it's deemed completed, whether the call succeeds or fails and whatever it was trying to do. So you really see this task failed successfully. Example here is really comes from real life because that's how programming works. But of course, in English, the phrase successfully completed makes no sense because what's the opposite of successfully completed? But this notion of successfully has really propagated all over all kinds of user interfaces I've seen in it, gas pumps and all over the place. So when you see that word successfully, take it out. All right, so let's talk about some about standards, mechanics of writing that probably the most important thing is to keep sentences short. And that's again, an overall rule in technical writing. It's one of the most important ways that you can keep content usable, easy to read. They help everyone. They help non-native speakers of English looking at your app. They help translators translating your material into other languages and locales. And everyone really, it's just easier for everyone to read shorter, simpler sentences. And in general, two short sentences are better than one long one. And that took me a little while to get used to as a writer. But that giving people information in shorter chunks really helps usability. Use the imperative or the first person to talk to users, talk to users with them, don't talk at them. So in the first example, the user should contact their IT person for help. This message is being displayed to the person whose job it is, who needs to contact the IT person. So don't, this is a typical sort of construction that you might see when engineers or people who aren't experienced in writing write messages like this. So just use the imperative. Imagine that you're, again, you're in a conversation with someone, you're talking with them. Couldn't save the document for help, contact your IT person. Take your cues from the UI. Just do what you can to understand how the software works. Walk through each task that you're writing error messages for in a user's shoes. So one point there is to give information in the order users need it. So in the second part of this example, where it's this bullet where it says, select customize on the layout page in your settings. What do you need to do first? First you need to go to the settings and then the layout page and then you select customize. So if you have a sentence like select customize on the layout page in your settings, then users have to read the sentence twice, once forward, and then they need to read it backward again. So don't do that to users in error messages or anything else. In general, use the order if this, then that, rather than the other way around for similar reasons. Every now and then there's something that there's an exception, like for that robot, I'm not a robot check box that we all have to check sometimes to identify ourselves. Check the box if you're not a robot. Works better than if you're not a robot, check the box. There is a, for detecting these kinds of things, if your company has a program like acrylics or something similar that says sort of souped up, those are sort of souped up spelling and grammar checkers. And they can, they flag sentences with if in the middle. So they'll catch your if then, your flipped if then constructions. And oh, and they also will count words in a sentence, which is a super handy feature. So if your sentence is 32 words long, you know, if you run one of these checkers on it, it can catch that sort of stuff for you. You want to echo the wording and capitalization in the UI, especially in an error message, because it helps the user stay on track. It helps them user map what the error says to says to do back into the UI. A couple of notes about internationalization and optimizing content for that. So localization is includes translation into various languages and dial, but also local dialects, local dates and time. So it's not only about the translation per se, but but also about everything is so for if you think of, you know, Montreal versus Paris, there's different versions of French different time zones. And like that. So that's what internet internationalization refers to optimizing whatever you're doing for that process. Again, a plug in like acrylics, flags, modal verbs, which some modal verbs have more than one meaning, for example, may and might to it's best to avoid those. Because again, they can cause problems in, you know, mistranslation or even for English as a second language speakers. You can replace words like may with can, so on. That's probably a whole other workshop maybe next year. The word should can have a whole range of meanings from it's generally best to you absolutely must to this is what happens if everything is working right. So avoid the word should and just cut to the real verb. One more note about internationalization don't concatenate. And so explain what that means. Air messages and other user interface text in computer code are called strings. And if a programmer puts two or more strings together to form one sentence, that's called concatenation. Remember that each string is delivered to translators separately. All they get is one string at a time. So if you divide a sentence in two and one string includes the subject and the other includes the verb translator can't do their job. So don't let a programmer split things up, split sentences up into separate strings and that should be nothing smaller than a sentence. Oh, and a few other tips about internationalization. Translated strings can be up to 30% longer. So keep that in mind when you're writing and work with your programmer and designer to make sure messages fit into this space that you've have. Your developer can put comments in the code to clarify ambiguity for translators. And then the translators will see the comments but the end users won't. So some words can be ambiguous out of context like the word state. Are you referring to Alaska or to the status of something? Some words can be a noun or a verb, order, access. They may be identical in English but not in other languages. They would be different words. So some grammar tips. Well, be precise. Watch for dangling and misplaced modifiers. Again, it's really important in our messages to be precise and concise. So dangling and misplaced modifiers need to go. One thing, one sort of wording construction that I see a lot is acting as if processes were people but a process can't act on itself. So don't say that a setup process didn't complete. Say that it isn't finished. The passive voice, which we are told so often to stay away from, it can be the right choice. There are cases where specifying a subject can just be distracting. So in this sentence, email was sent to Sarah Johnson and three others. Well, where would you, you know, if you put in a subject, you know, the software sent email to Sarah Johnson and three others, you don't really know. I need to know, you know, what the subject is. It's enough to put this in the passive voice. Develop standard phrasing and usage for your app that you're working on because consistency helps minimize uncertainty and it also reduces your workload once you get the standard phrasing down. So, you know, standard messages for common situations like, you know, the server went down or something. Here are some examples of some standard messaging. And then document your standards, you know, whatever you decide on and follow your company's style guide. Consider your company's voice and tone guidelines because error messages should be, you know, consistent with all the other company's other materials and voice and tone. And I recommend if you're a UX writer taking a copy editing course because there's a lot that kind of basic publishing standards and techniques, you know, can contribute to the whole process of, to any process of writing. And let's see, one more thing about standards, please and sorry. Brought this up and we have standards for these at Salesforce and so please we only use when the problem is the software's fault. And sorry, we use only when the user can't continue without help. And this seems kind of like a subtle distinction, but these are the kinds of subtle signals that help users understand what's going on. Okay, audience. We talk about tone and word choice. So who's using what you're making? You know, really understand like I was saying before, you know, understand how the software is used and who's using it. Imagine walking in their shoes. Are you making software for business people, for bird watchers, for kids? Are you making something that software developers themselves will use or just really know, know your users as you know, get to know your users as well as you can. And find out, you can find out about them from a product manager you're working with, product managers are listening to customers all the time. And a lot of companies have user experience researchers who do studies and write reports about how users have reacted to say prototypes or you know, existing software. And they create representative they can create representative personas, different kinds of people and how many this the software in their, you know, daily activities. And just to note about AP, I mentioned APIs before. So if you're, and I'll explain what that means, if you're writing for software programmers developer, if you're writing API error messages, API stands for application programming interface, and this is not for end users, this is for programmers who are building software. The difference in those messages is that API APIs, programmers are just working on in code line, just one line at a time. So the error messages need more information incorporated in them because when when they appear, developers don't have the kind of context that end users have. Like if you're, if you're using, if you're using Salesforce, which is business software, you're say you're a salesperson, and you're using the software, and you're working on an account record, and an error comes up, you're still seeing the account record there, there's a lot of context around the around the message. A programmer doesn't have it can't see the programmer can't see what field we're talking about or what value they might be missing. So you have to specify all of that in the message and that makes the messages more detailed and longer. But just remember, so I don't have a particularly a technical background, but I have written a lot of error messages for developers in Salesforce. And it's just a matter of, you know, asking questions and taking time to become familiar with what the software does as a whole and, and figuring out, figuring stuff out. That's an important skill of a technical writer is just asking questions, keep asking, you know, figuring out how to get the information that you need. And also just remember that developers are people too, you know, they want clear, useful directions just like other users and, you know, you as a linguist can provide that. Should you be funny? Well, it depends. Consider the content and the context because humor can work well in error messages, but be aware of a couple of things. So humor can interfere with clarity because it requires a layer of interpretation. And it can in that way can interrupt the user's thought process. And, you know, just as in real life humor can strike the wrong tone. It can make users feel that the company isn't handling their data securely. Again, think of money or health data. And, and humor is, is more often than not culture specific and tends not to translate well. So if your software is localized, just be very careful about that. And again, remember that errors appear at a crucial juncture and tend to make users feel annoyed or even upset. So just be careful with humor. A little bit on interaction design. How do people interact with your messages to get back on track? Sometimes a developer will ask you to write a message that covers lots of things. And at some point you recognize you, you, this is too complicated. You can't write a clear error message. There are too many possibilities to explain. So on the left here, basically the user can't renew the subscription but for a couple of different reasons. And in this case, I, and, and each, each reason has a separate resolution. So I asked the developer to split the code into so that two separate messages could be displayed. And then each one has a separate resolution. In one case, the user can open the settings and change the settings. In the other case, user can't, it has to click OK and then go and do something else. But it, but at least each message has a specific one single action associated with as the solution. So work, you work with your developer to figure that out. Another way to work with developers is to prevent an error from happening in the first place. So you work with a developer and sometimes a designer to do this. So on the left here, we have you're on a, you're buying shoes and there's a field where you select a color. But right now, the only option is black. So, but you neglected to make a, make the selection for that field. So you got an error says, and then the field is required. So you have to select a color before you can go on. But this is kind of dumb and annoying because there's only one selection. So why didn't it just, you know, decide for you? So on the right, I got the developer to, supposing I was the writer here, the writer has gotten a developer to make black the default selection. So it's already pre-selected and the user, there's no opportunity for an error to happen. You might not want black shoes, but that's a different problem. Different error formats have different writing requirements. So here on the left and right, we have the same message, but it's written differently because in one case it's displayed in a dialogue box, which has a title and a body and a button in this case. And on the right, it's really the same message, but it's written for display in a toast, which was that banner that I mentioned that is called a toast because it pops up. So I'm not addressing visual design here, but be familiar with your company's design standards and work with your developer to make sure that messages are displayed in a way that makes sense. Okay. So sometimes, unfortunately, there are error scenarios where users can't solve the problem themselves, and they need to pass information along to someone else. These scenarios are harder to handle gracefully. So here's an example of one of those where a user has to ask their IT person to do something. And there's really no good way currently of handling this. Maybe in the future, AI will help situations like this. These kinds of scenarios are usually the result of some edge case, something obscure that happened. So just do what you can to make the information transfer from the user to the other party as painless as possible. All right. A little bit about process, collaborating with engineers, researchers, designers, product managers. How do you get started writing, working with all these people? Well, you gather information about each error, and you set up a document or spreadsheet with a template or columns, and I'll have a template that you can copy and take away at the end of the class. So give it these columns, a summary of what the error scenario is, what triggers the error, and how the user can fix it. Another column to indicate how the error is displayed, is it a dialogue box or toast, or is it an API error message? It's useful to have a place to put any existing text or draft that the developer can provide, because even if that stuff isn't written well, it can contain helpful clues for you on communicating exactly what the problem is and how to fix it. And have a space for drafting and finalizing your messages. I suggest color coding it to indicate whether it's in draft or final, and then any other columns that you might want for tracking the work item and so on. So you want a QA, do your own QA of error messages when it gets checked into the, in most cases, writers can't check in error strings themselves, they need developers to do that for them. So companies handle this in various ways, and it can be a manual process where the programmer copies your text into an XML file, these are called label files in ProgrammerSpeak. Your company may have some kind of content management system for user interface text, or there may be a plug into an app that UX designers use, they're different ways. I mean, the industry needs better solutions for user interface text. Some best practices. As I say, you should QA what programmers check in because they can misinterpret your specs, you can't just count on them automatically to get everything right. Everybody makes oversights sometimes, even people who are very good and detail-oriented, and just remember that correction, if you correct something now, right up front, as soon as the error is introduced, it's much less costly than trying to fix it later on, especially if a customer finds it in complaints. And then document your process and use communication channels in your company to reinforce the process so that developers don't just make up their own text and check it in without your knowing. So just a last word. So what about the future of error messages? Will AI be involved in error messages? Voice technology, some of you probably know more about this than I do. Voice technology already can detect a caller's mood and change the voice menu accordingly. I did once yell into the phone and then get a different response back from the bot. That was an interesting experience. So in the future is AI artificial intelligence? Is it going to be used to detect problems and respond to users? Could it walk you through solution? I just think there's a great future for linguists in UX writing. So you're in the right place. Okay. Rachel is going to split you into small groups. And let's see. She's going to share doc with you with a couple of sections. There's some errors, some sample error messages, nine of those, and some sample scenarios plus draft messages. And there's no... So what I'd like you to do is just in your groups, pick a few, one or two, or use the examples that you brought if you brought them. Whatever interests you doesn't matter. And talk in your group about what works and what you might change. And then we'll re-gather in what times it... Let's try to regroup at 1.35 to give everybody time to sort of peruse the messages and discuss things. It's not 1.35 everywhere, but 35 minutes after the hour. Yes. Thank you. Thank you, Nancy. Speaking of localization. Well, we haven't talked about it yet. It's coming up tomorrow morning. And then Rachel will also share with you another file, which is a template that you can copy for gathering information if you go out and get a job as a user experience writer. So that's what this looks like here. So Rachel, take it away. One of the questions that you didn't get a chance to answer earlier from Caroline, do you want to say it, Caroline? Yeah, sure. Thank you. So one thing we actually spoke about in the breakout rooms was, I guess, how common, confusing or ambiguous error messages are in very mainstream programs such as Tableau, R, Latex. And so one thing I was wondering was what types of resistance you've encountered from different stakeholders and in wanting to dedicate time and resources to writing good error messages. And do you have any advice for how to convince particularly non-linguist or non-linguistically minded stakeholders of the value of evaluating error messages in detail and writing good error messages? Yeah, that's a great question. There is research showing that error messages are really important to developers working on how good error messages are really important to them. I don't have it handy if there's a place, Nancy, maybe where I can follow up with information that I can find. If you pass it to us, we can put it in the Slack and we can send it out in the daily email, whichever you like. Okay, thank you. And I'm going to recommend that we not take up Kelly and Trisha's second to that question because the next session will focus on that as well, right, Sue? So, Sue, just make a note of those questions. Okay, sorry, Kate, back to you. Yeah, so for developer documentation, for non-documentation, for APIs, error messages are really a very important part of developers workflow. They need to be clear and actionable. And this same for end users, I mean, if you have, I mentioned user researchers, you know, talk with your researchers and try to get them to do a study on error messages in your company's product so that you can then, you know, and record it, record people struggling or commenting, you know, making negative comments and bring that back to stakeholders. Those would be a couple of suggestions. Thank you. Or we can have a first version of that answer and then go on and do more answers where we have more people. Or Nancy says, or have UX researchers coach you on how you can test your own error messages? Yeah. Other questions? So talk a little bit about what your group process was like and how you helped each other write error messages because I wasn't in a group. We talked about good messages and bad messages rather than writing any messages per se. And I commented that oftentimes no message where one is needed is very problematic. Sure. Right. So I was trying to make a reservation, an airline reservation and put the reservation on hold fair. Unbeknownst to me because there was no information about it on the website, that rule did not let you put hold fair on it. But had there been an error message, I would have saved a lot of time and frustration. So I guess the company didn't have very good UX people involved. Right. They didn't investigate. They didn't lay out use cases. Yeah. Chuk had a question, will I share the answers for the exercise? Because there aren't any answers. This is all just about exploring based on what you've learned. So there's no answer key. Sorry. But I thought you guys were doing great job in your breakout room. So you're on the right track. And Alfonso has raising his hand. How nice. So basically, I just wanted to comment on the role of culture when it comes to error messages. For example, in our group, I find it very interesting that we mentioned humour as a something that for me, that's something that works out well. Like when you're just trying to deal with all this frustration like, oh, technically this is not working. And for Sue and Miriam, humour perhaps is not the best approach to it. But to me, it's always kind of, you know, when I just get a bit of a wink from the computer, it's something that I find very interesting. And I just find it catchy. It just kind of helps me relax the entire process. So I suppose that culture might be something to take into account there. And again, US research might be useful in that regard too. And I think they've both been working on business-facing, business users software rather than consumer-facing software. So that may be another reason that we hold back on the humour in the business context. But yes, a little snark can be very nice on a 404 page, you know. Oh my goodness, how did you get here? I'm so sorry. Let's move you on. Nothing to see here, you know, one of those things. Or a little self-deprecating humour like, oops, we're so embarrassed. Please forgive us and, you know, try this. You know, it just, the humour has to be handled carefully so that the reader doesn't, the user doesn't think we're poking fun at the reader, you know, the user. But poking fun at ourselves as the developer maybe, I think that can kind of diffuse some of the anger that people feel. Yeah, again, keeping in mind, be careful in the context, because you can make it look as if, you just have to be careful, you can make it so that the company isn't taking your data seriously. You don't want to convey something like, what were you thinking? You know, the user is already fairly sensitive right now. Things have gone badly. I think Alfonso, you had a nice example of one in Spanish that seemed very kind of relaxed and not overly wordy, but, you know, still fairly direct, but it was in plain language and you found it comforting. I think comforting is a good feeling to come away from. True, and as you mentioned, it was worded in a very nice way so that it actually blamed the developer, the software or the, in these case days, Mozilla. I was like, oops, we cannot reach that place. You know, so it's, as you mentioned, it's humour but very nicely attached. So I totally like that remark. So yeah. Well, in order to give Sue and Kate a chance to splash water on their face or whatever they need to do in the next 10 minutes, I think we're going to have to close out this session.