Abby Covert, staff information architect at Etsy, shares with us the strategies and tactics they are using to pay closer attention to language choices they make across both internal and external user experiences.
Kristina Halvorson: I’m really excited to welcome our next speaker to this stage. I’ve admired her work for such a long time. She’s really recognized within the information architecture community, and her work is growing with excitement in the CS community as well. I’ve been informed that her last name is not pronounced like “Cobert”, but it is Covert, right? Nailed it.
Abby Covert is an Information Architect at Etsy. She specializes in delivering a collaborative information architecture process and teaching those that she works with along the way. She is also the author of How to Make Sense of Any Mess, which is a book about information architecture for everybody. So please welcome to the stage, Miss Abby.
Abby Covert: Thanks! Hi Con-Fam. How’s everybody doing? I didn’t get to eat the cake, because I’m going to eat my cake after the talk, so I’m hoping that I can sustain on your sugar rush for now.
I’m here to talk to you about language. It does not actually scare me at all, to stand in a room full of folks that create content and talk about language. I will stop talking about language publicly when we get really good at thinking about language from an organizational perspective. So far, I don’t think we’re there yet, so we’re going to go for it. (My slides are not right on this, just so we’re all on the same page. Tech time. Thank you, yeah, back further, further, further. Okay, perfect. So let’s get into this.)
First, let’s start by thinking about language as a material. The reason that I think this is important is because there is a lot of materials that we use every day in the work that we do, but language is actually one that spans past our work life into our life-life. Language is something that we use every day to communicate with everyone from our coworkers to our loved ones, to perfect strangers on the street. So let’s define language.
If you look up “language” in the dictionary, it’s pretty broadly defined as a complex system used for communication. There are many different types of language, whether that be visual, spoken, written, or even body language. So the key word in the definition of language is “complex.” So whether we’re trying to figure out the right language for us to explain ourselves to a loved one, when we’re discussing something difficult, or determining the right language for a more formal setting, when we’re presenting our work to an executive that’s going to have deciding power on the things that we’re doing.
The way that we think about language really depends on how we understand our context and our experience, and the way that we want that to be related to somebody else. So when it comes to designing things for other people with other people, language is actually the most important material that we have access to. Language can help us get our point across, but it can also be like a brick wall between our idea and someone else’s understanding.
So in my work as an information architect, I have seen organizations of all shapes and sizes really struggle to get on the same page, because they lack the single most important asset that’s needed for consensus, which is a shared understanding of their language.
We often think that if we use language that’s grammatically correct, that we’ve done our job in communicating to others. But in reality, there’s a translation step that’s built into the process of understanding that many people don’t think often enough about.
So this translation step is probably best represented by pointing out the difference between “content” and “information.” Now, in my experience, I have seen these words used synonymously more than differentiated in most circumstances. The problem with doing that, is that we’re making the assumption that people’s interpretation of our output will be the same as our intent for it. This is a really dangerous assumption for us to make.
So content is something that we create. Whether that be words, or pictures, or sounds, and the resulting output that someone consuming that content believes about that content—their interpretation, their perception, however flawed that may be—that’s the information. So we can’t make information for them. We can only make content that we hope gets through that translation process with our intention intact.
The difficult lesson here is really how slippery a concept meaning really is. If you look at the relationship between meaning and language, you can see a “chicken or egg” problem pretty clearly. We use language to communicate what we mean, but we also use our understanding of meaning to interpret the language that others use to communicate to us.
So there are two opposing forces that need to be acknowledged here: context and intention. Our users’ context, when consuming the content we create, is as important as the intention that we have for that content. So a question for you: Have you ever been misunderstood? Has anyone been misunderstood today? Maybe? Yeah. This is pretty common. This happens to us all day, every day. It’s very common to have some moment where you’re in a misunderstanding with somebody.
When we misunderstand something, what we end up with is misinformation. It turns out that misinformation is actually one of the most corrosive materials in existence. Believe me, I know what it is to say that in 2018. Misinformation causes all kinds of metrics that we tend to value in organizations to go down. Misinformation can lower trust, it can lower conversion, it can lower loyalty and customer satisfaction. So in other words, misinformation is the single biggest villain in most organizations. Misinformation can make people believe that you stand for something that you don’t. It can make people believe that you’re really expensive, or that you’re cheap. Misinformation can leave your target user believing that your product is not even for them at all, and misinformation, most importantly, is like a silent killer. It actually takes quite a lot of self-reflection and research to even discover that it exists.
So what causes misinformation? In most cases, I have found the culprit to be language. So I want to point out to you three language mistakes that I see organizations making over and over again that tend to lead to misinformation.
The first is vague language. Now, I want to point out that there is a fine line between being brief, and being vague. Often, when we wish to express something efficiently or we want to communicate something that can be broadly applicable to a lot of context or audiences, we can end up with something that instead, comes off as vague.
I often see vagueness rear its ugly head in things like marketing copy or error cases, as we just heard a great talk about, or instructional language. Also, the use of icons can be incredibly vague. I don’t know if you guys have noticed this. Vagueness can be, also, in the way we phrase things, but it can also be in the way that we classify things. And categorical vagueness reveals itself when we start to find situations that are kind of outliers to the logic that we establish when categorizing.
So for example, if we define a chair as something as you sit on, we might think that we’ve succinctly explained what we mean. But in reality, that means that a bike, a horse, or even an elephant can be misclassified as a chair. How many of you have written the word “more” or “others” into a navigation schema? Anybody? Anybody want to admit to it? I have. Right? There’s always those moments, and one of the most common abuses that I see in vague language is kind of throwaway words. We’re like, “We don’t know what to do. Let’s just call it more.” Or “dot, dot, dot.” That’s the mobile version of “more.”
How about these? Discover. Learn. Explore. Right? There is a rash of really vague verbs that are floating around in digital products. So these are all places where we introduce misinformation. I worked with a client once that had placed their pricing terms under a vague “parent” category. They had started this plague of misinformation that they were a really expensive piece of software, that you had to go to a salesperson to get access to. In reality, it was actually, compared to their competitors, a lower price option.
So when I asked them about bearing their prices, what they told me was that they didn’t want to come off as too forward by asking people for money before they understood the product’s value. This is a great example of vagueness being intentional, but being unintentionally misunderstood. Vagueness can also be a symptom of us not wanting to make a decision on something. I’ll give you an example from a meeting that I was once in.
I was working with a client, and they were trying to establish their customer service program. They had two full-time employees that worked Monday through Friday on split shift, so they could cover 8 a.m. to 8 p.m. Eastern time. They really struggled with what to put in the confirmation that somebody had submitted the request to the help desk. They didn’t want to say, “We will answer your email within a certain number of hours, because it was only true during certain points of the week.” So what did they end up doing? They had a big meeting to decide what to say in the email, and somebody, swear to goodness, was like, “Oh! I’ve got it! Why don’t we say: Someone will answer your email soon.” Right? “Soon.” That’s great. Everybody was like, “Brilliant. Write it up. Ship it.” To them, that was like, the right level of vague. But what they did was they introduced this misinformation that maybe they didn’t care about how quickly they were going to resolve this issue for their customer.
So the next place where misinformation crops up is when we use language that assumes a level of familiarity from its audience—proprietary language. I want to show you a screenshot from my Fit Bit. I just want you to read this. Take your time.
Anybody? Does somebody in this room write this message? Fess up if you did, because I want to know what it means. This thing is actually standing in my way of being able to do something, right? So when we create content that relies on our audience to have this prior understanding of what we’re communicating; we are taking a huge risk. There are times where, of course, it makes sense to use shorthand that proprietary language can provide. For example, if you’re writing an email to your entire organization, you can rely on some proprietary language. Maybe even throw in a couple of acronyms. But there are other times when that proprietary language is used with people that lack that prior understanding, and therefore, it can result in misunderstandings.
So one of the largest offenders is the labels that we give to our products and to the features within our products. So much so on Google’s side, that one of their engineers from the Google OS team, Manu Cornet, has an entire comic series of all the hilarious things that people tell him about using their features, which are not well-named. I don’t know if anyone has noticed that.
This is a real delicate balance. We have to name things, right? It’s part of what we do, but when naming things, we have to strike this balance between wanting creative names that can stand out in a crowded marketplace, and using names that actually make sense to our users that they can use in everyday conversation. There’s a real delicate balance back and forth. You may be pushed to one side, in terms of the creative side.
Then the third trend. Language for the wrong audience. This is the last place where misinformation is bred, but it’s probably the most prevalent when designing things for other people. When we don’t understand our audience, we can develop content that is totally working against us. So places that I see this really suffer from, things like grade and reading level, and just lack of attention. Or the tone and style that you’re using being totally off-base for what you’re trying to get across. Or lastly, the use of metaphors and aphorisms, which really cannot translate well to many different types of audiences.
This is not just about our end users. This ends up being something that we need to pay specific attention to when it comes to our coworkers too. Have you ever received a document from a coworker, where you felt like it was completely unintelligible for your purposes? Let’s be honest, it was probably a spreadsheet. Anybody? Yeah. So that feeling that you get, you open it, and you’re kind of like, “Oh my god!” Close it. Right? That feeling? There’s a word for that. There is a scientific term for that, it’s called, ready? “Linguistic insecurity.” It’s also the feeling that you get if somebody is talking over your head.
This is something that is really important for us to pay attention to, because this feeling introduces the misinformation that a piece of content is actually not for our eyes. Think about the last time that you picked up a prescription, or downloaded a piece of software, or signed up on a social media platform. You were confronted by pages and pages of legalese. Did that give you the feeling like you were supposed to read it, or was it more like the lawyers needed to have given it to you so that they were protecting the corporation that they work for? Probably a bit of the latter. Has anybody ever read the Service and Terms Agreement for a social media platform not to be named? Nope? Okay, cool.
So it turns out, this language thing is actually really messy, and there’s no way around that truth. I have been searching for the easy button, or as Katherine put it, the “plain button” on my keyboard for years, and it just doesn’t exist. So this is something we need to pay attention to. I think that there are a few tactics that I can share with you for my work as an information architect that hopefully help when making decisions about language. Hopefully, this can get us to more successful linguistic discussions with your teams.
The first tactic is to reconcile our mental model. When we want to assure that content we’re creating jives with the audience that we intend it for, the best place to start is with understanding the mental model of those people that you’re trying to communicate with. You can kind of think of a mental model as a big map of knowledge that we all walk around with inside of our minds. Everything you know about the world is actually related to every other thing you know. It’s just a matter of how many steps it takes to make that connection. When we encounter new content in the world, which we do millions of times per day, we look to compare that content to the mental model that we have for the things that relate to that.
So when you’re watching this talk about language, everything that I’m saying and showing you on screen is being compared to what you already know about language and the subjects that are related to what we’re discussing. As we proceed, you’re looking for places where my content lines up with what you already know. But you’re also looking for places where my content is in disagreement with what you already know. And lastly, you’re looking for ways that my content adds to what you already know.
Each of you has your own mental model, and it’s been shaped since the day that you were born. Conference Baby’s mental model is being shaped right now. Right? It’s amazing. This model that we all hold, this is unique to us. If you are sitting next to someone who is watching the same exact talk, you can be taking away two very different things.
I spend a lot of time talking and working with people that design things for other people. So over time, I’ve learned enough about those folks to make my content work for them. But if I was asked to give this talk to a room full of doctors? I would have to start by understanding their mental model, and kind of scrapping everything that I know to be true about to what I’m about to say.
I’m going to give you an example of how mental models matter. This is a little pop-quiz. How many vegetables are on this slide? Nobody say none, because this is all digital and there’re no vegetables. Nobody say that. That’s snarky.
Really? Thank you! So, the answer was no. No vegetables were on that slide. How many vegetables are on this slide? By the way, you missed some really cute cartoons. You can see them on SlideShare.
15? Okay. Another guess? Seven? 11? 12? You guys, this is not just like, “Shout numbers out.” This is counting.
Alright, so let’s look at different mental models on the same problem. Scientifically, there are seven. Linnaean Taxonomic standards dictate that these are vegetables, and the rest are not. I know that some of you are like, “Whoa, whoa, whoa. You just broke the world.” I’m sorry. But it’s true. Now, from a grocery store app perspective, there are probably more like 14, depending on which grocery store app you’re using. They differ slightly. I’ve had many students tackle this assignment of trying to make a taxonomy for produce. I encourage you to do this with your team, just to introduce the idea of why taxonomy is important. But, there’s a reason that there is a difference of approaches here.
If we’re designing an app for folks to look at groceries for buying, why would we adhere to Linnaean Taxonomic standards? Why would we assume that folks think that tomatoes are vegetables? We wouldn’t. But if we’re being smart about understanding the mental model of our audience, then all of a sudden, we can come to the conclusion that 14 is actually a really smart choice here. Not seven.
When trying to understand the mental model of other people, we have to always keep in mind that we ourselves are not unbiased. We have mental models too. So rather than just collecting other people’s mental models in test tubes like specimen, we need to have looked at this process as a reconciliation. We must purposely make ourselves uncomfortable. We have to ask ourselves, “What do we disagree on with our users?” Then we have to create content that is not for ourselves or for people within our organization.
But, coworkers are users too. One of the hardest parts of this reconciliation is that it’s not just our users that we need to better understand. It’s also our coworkers. Each of them has their own mental model, and that impacts the language that will be used in creating the content that we’re working on together. So we have to remember that coworkers are actually a key part of this problem as well.
If you’re interested in mental models and want to go further, I highly recommend this book by Indi Young, called Mental Models, very well named. Very clear, very plain. It has a lot of tools and techniques in terms of digging into the mental models of yourself and also your coworkers and your users.
Now, let’s talk about context. The next thing that I want to explore is the understanding that we need to think about more than just the content. We need to think about the context in which it’s consumed, whether that be the channel that it’s consumed by physically, or the understanding of how people are coming to that content in terms of their intention. Think about the difference between creating content for a billboard that someone is driving past on the highway versus a brochure that they’re handed at a trade show. We’d have to make different choices for those different contexts. By understanding the context that people have when trying to communicate with us, we have an increased chance of our message actually arriving intact. In the design world, I see context reduced to topics like responsive design and mobile first thinking way too often.
In reality, it’s important to understand that context is all of the circumstances that surround that interaction, and it includes those softer signals about what the user is actually feeling, especially as it relates to the impetus of that interaction. For example, if we’re designing a pizza delivery app; we should probably keep in mind that folks might be hungry. Or if we’re designing a video on-demand platform, we might want to think about the fact that they might just want to kick back and relax. Or, if we’re designing a website with information for a recently prescribed pharmaceutical, we might want to consider that folks might be a bit anxious or nervous.
Another deal of context to keep in mind is thinking about things like localization and translation of our content. As the world becomes increasingly diverse and globalized, more and more of our work is going to be recreated in multiple languages and presented in multiple cultures. When we aren’t mindful of the potentials to literally get lost in translation, we can lose our audience or make them feel alienated.
Sometimes, understanding context actually means paying attention to differences in categorization or labels that we develop across different languages. I really like this example, because they’re both English. But a flapjack in the US is much different than a flapjack in the UK. This might seem like a small distinction, but when you’re a UK-based company that’s moving into the US and this is something that you’ve purveyed onto your navigation and onto your packaging design, this is a decision that you’re making about whether or not you’re communicating clearly with your audience.
Another example that we found a couple of years back for Etsy was that the use of overly friendly or familiar tone; something as simple as saying, “Hi, ‘first name’” in an interface can be really off putting, and even considered rude in some languages in cultures. So it’s not just a simple step of translating in some cases. You have to rethink the strategy of how you’re even addressing your audience.
By understanding both the context in which our audience will encounter the content, and the differences between their mental model and ours, we’re setting ourselves up for the successful transmission of information. If you want to go further on the idea of context, there is an excellent book by Andrew Hinton called Understanding Context. It is a very thick book, you can use it as a doorstop when you are not reading it, which is great. It has a lot of exercises in it for you to really dig into the understanding of context past that surface level.
The last tactic that I want to share with you depends on the last two that we talked about to get it right. Once you’ve reconciled the mental models of your users and your coworkers, and spent time trying to understand the context that your work will be consumed in, you can move onto this last, most important step: controlling your vocabulary.
As I mentioned earlier, language is inherently messy. There’s no way around that, but when trying to take a bit of control over that messiness; one of the most effective ways to go about it is to start to define the language that you do and don’t use. Writing definitions is one of the best activities that I can suggest for that, because it forces us to talk about the messiness of language and meaning with our coworkers. You end up having these really important philosophical conversations about what things “are,” and those tend to save you a lot of complexity down the road.
So, starting to take on a whole language of your organization can seem really daunting. But I have some advice on how to start, and it might feel a little bit more manageable, but it’s still a really big task. I’m going to suggest that we start with nouns and then work onto our verbs. I thought it was really interesting how Katherine brought up the point in her lightning talk about how we have to kind of lead with the verbs, but I think when you’re exploring the idea of language, and specifically meaning, the concreteness of nouns tends to be a task that people are not clear on, and then the verbs get messy as they trail behind.
When you’re writing content, I totally agree with what Katherine’s point is. But when you’re thinking about language from that material standpoint, I think starting with the nouns really is the right move. So when I say nouns, I mean the objects. Those are both hard and soft objects within the core of your business. The best places that I found to look for these nouns are things like the people that are involved in your system, the features and places, and kind of what pieces does the system have. And then the paths that people take and what they want to accomplish with the system you’re designing.
Once you have those nouns, you can start to work on your verbs. The reason that I have you start with nouns is because your verbs will almost always be dependent on a noun to exist. Common verbs like “create,” “edit,” or “delete” can’t exist without a noun to attach it. Places I suggest you look for your verbs is in things like tasks and actions. So, what can your users actually do? And their goals, what are they actually looking to accomplish?
Lastly, don’t forget about your opposing actions. This is something that I see in a lot of cases, comes too late in the process, and then you sort of stuff that opposing action in after you think about like, “Oh crap. Once I create something, what can I do to it?”
When we talk about design, it’s tempting to get swept away into a world of adjectives. We say things like “usable” and “useful,” and “beautiful” and “clean” and “clear.” These words are actually the hardest to hang that concreteness off of. So beware of this part of speech. Only after you’ve wrangled those nouns and verbs, can you really safely delve into the adjective world.
Now, I want to shift into a little public service announcement about working with language. Get ready to get messy. It stays messy for a really long time. These are problems that cannot be fixed overnight. These are conversations with your coworkers that I have had clients describe as “brain-melting” sessions. If you get to that point where you feel like if there is one more definition that is spurred by the definition of another word, you are going to scream, you are doing this right. You are giving it the right level of attention. If you get to that point where you’re uncovering deeper language complexity through looking at your language, that is a really good sign.
This is what my screen looks like on a typical day working through these kinds of messes. The reason I like to show this, is because this is not a deliverable. This is not something I would ever subject other human beings to, except in this kind of a talk, where I’m trying to make a point about messiness. This is a tool for me. This is a messy diagram and a spreadsheet of working definitions so that I can work through things piece by piece. I might take pieces of this and take them into a discussion with the right people that need to have the right conversation, but I would never subject somebody to the full onslaught of this kind of mess. It’s not worth doing, you’ll scare everybody away. Don’t do it. I know it seems sexy, but don’t do it.
So once you’re comfortable with dealing with the idea that it’s going to be messy, the next thing you have to do is deal with the idea that the mess is going to stick around for a real long time. You cannot change the language of an entire organization overnight, no matter how small that organization is. It is going to take time. So instead, we want to work on what we can, and establish that vision so that we can move forward towards a shared vision of our language over time, and that means being patient. Patience is one of the most important skills in this kind of work.
I want to share with you some of the exercises that I use with teams to get through some of that messiness, and the first one that I’m going to show you is what I call the “Alien Dictionary.” When I was in grade school, there was this great exercise where they had us write a dictionary for aliens from outer space. So, every term needed to be defined by lots of different other terms. So for example, the term I was given was “tree.” In order to define a word like tree, which seems pretty simple, you actually had to describe ground and sky, and rain and sun, and all these other things.
This is a great exercise to translate into a business context, because often, that complexity that we get to through talking about words actually leads us down a path to unveiling some more important things about our understanding of that concept, but also can have major scope implications. This is an example from some work I did a few years back with Nike. This was something that came up over the course of several meetings over several weeks. I was in all these meetings with merchandisers from Nike and designers from their agency. They kept using the word “flow.” I swear to you, every time the word “flow” happened, the other type of person would just “uh-huh” through it. But over time, I was like, “I don’t think that they understand what each other mean.”
So I asked the designer, “When the merchandiser at Nike says the word ‘flow,’ what do they mean?” They said, “You know. It flows. We’re designing software, man. It flows. It goes from this to that.” I was like, “I don’t think that’s what it means.” So I asked the merchandiser at Nike, “What’s the deal with ‘flow’? What does that mean?” They said, “Oh, well flow. That’s a really important merchandising concept. It’s how we establish, over the course of a season, the way that we’re going to release our products.” And I said, “Do you want your software to help you to do that?” They’re like, “Oh my goodness, yes. That’s like, the most critical thing that we need from this software, is the ability to control flow.” I went back to the designers and I said, “I don’t think you know what flow is. We’re going to have a meeting where the merchandisers are going to teach you about the word flow.”
So we did. We just defined the word flow, and then we got to the definition. We were like, “Okay, cool. So we should probably also define these other highlighted terms: styles, silhouettes, and season.” Just to make sure that we were on the same page. So we defined style, cool. Everybody was on the same page. Season, cool. Then we got to silhouette. In the conversation about silhouette, something truly wacky happened. They started to talk about silhouette type. I was like, “Whoa. Is that the same thing as silhouette?” They’re like, “No.”
And I was like, “Well, okay. So there’s another level.” They’re like, “Yes.” So I said, “This is a data problem. We should probably bring the data architect in here.” I went to the data architect and I said, “Hey. Do you know about silhouette type?” He was like, “Yes. Silhouette.” I was like, “No, no, no. Silhouette type.” “Yeah, silhouette.” I was like, “No, no, no. It’s a different level.” I showed him this, and he ... this is actually his facial reaction.
Yeah. He was very upset, because he had already established the data model. I don’t know if you’ve ever been told that the data model has already been established, but it’s very hard. It’s like they etch it in concrete or something, and you cannot change it. So my point here, is that I love this concept and this exercise because words are actually kind of cheap to use as a tool for scope. And had we had this conversation really late in the game, like, I don’t know, say, user acceptance testing time? We would have been in so much trouble for not understanding what flow was, number one, but also, what about the silhouette type thing? So you have to go all the way down. I often have students ask me, “How do you know when you’re done?” I said, “You know when you’re done when it comes back around.” It’s true.
All right. So our next idea comes from the team at New York Magazine. The idea here is that sometimes, it can seem really daunting to write the list of words that you say, especially if you’re, I don’t know, say, a news organization who changes what they’re talking about every day? The team at New York Magazine took a really smart approach. They decided to write a fundamental list of words that they do not say. This list is amazing. This is New York Magazine, but they are not allowed to say “New York’s Finest.” I love it. Also, if you have a cape, you cannot “don” the cape. You “wear” the cape. I don’t know why. You know why? Because reasons. Right? They got in a room together and decided, that as they’re bringing writers on, whether those be staff writers or freelance, they wanted to have some kind of consistency in terms of their tone, and this list of words was a really simple exercise for them to transfer that knowledge from writer to writer.
The last exercise I can suggest is when the words seem really hard, try using pictures instead. I often have my clients draw pictures, just simple pictures of what things are so that we can talk about it. These are not pictures of interfaces. These are conceptual models of what things actually are and how they relate to each other. Sometimes, this is the thing that helps us to untangle the complexity so that we can come back to the words part and start to really define things.
The result of all of this great language work that you’re doing with your team is best captured in, probably, the most sexy document on the planet: The Controlled Vocabulary! Who has one? Anyone? One person. One person. Okay, I like you. Okay, so a controlled vocabulary is a really critical document because it is the record of truth on all of these linguistic decisions that you’ve made. If you go do all of that great work, and then you don’t put it anywhere for people to reference, they won’t be able to actually keep it over time. It’ll just get crufty and you’ll be having the same conversations in six months when new people are there, or different people are there, versus having a document you can actually rely on.
Now, over time, I’ve experimented with the format of a controlled vocabulary and every project, to be honest, changes. This is kind of like the consistent super set of the things that I tend to put in it. First, definitions. You have to be really specific with your definitions. You have to be concise and clear, and when possible, you want to reference nested definitions. So in this particular example, all of the things that are underlined are actually other words that are further defined in another entry in the controlled vocabulary, so they can connect with one another.
I also think that a great addition to a controlled vocabulary where possible is these visual representations. So some of those little hand-drawn things that come out of those meetings, I like to turn into line art and actually include, so that we have a visual representation of the same word-based definition.
You want to map all the approved synonyms. Know that it is not the goal, necessarily, to have one word per thing. Sometimes, it is completely appropriate for you to have different words that mean the same thing, but you want to document that to make sure it doesn’t get out of control. And by out of control, I mean, I don’t know for example, a company that had 14 ways to say the word “video” in English? That really happened to me, you all. I’m still getting over it. It was really traumatic.
The next part here is historical context. Now, the reason that the historical context is important is because as you start to make changes, if you don’t capture those changes somewhere, people are going to start to question whether or not the process was actually inclusive of everyone and of the decisions that were made. So, for example, in the 14 words for video, if I had sent out the controlled vocabulary with the three words that we had limited it to without the historical context of why we removed the other ones, I would have just gotten a slew of emails and phone calls from people being like, “Hey, you forgot my word in the dictionary. Where is my word?” This way, it allows us to kind of tell that story so that the document travels.
Then you want a place for things like strategic considerations and notes. This is a really good idea, especially if you’re working in say, an agile environment, and things are going to be kind of slow to change as you ship things over sprints.
Any time you can use examples is really, really critical, and trying to vary those examples on what you might experience in the workplace or in the product. You want to model out, how is this controlled vocabulary going to be used when we’re having meetings with each other? And also, how is it going to be used in terms of the ways it’s reflected and what users see? Then lastly, our related terms and how they connect to each other.
So with that, I am almost out of time, but I want to wrap up just by reminding you of four things. Look for and eliminate vague and proprietary language. Reconcile your mental model with your coworkers and your users. Assure that you understand that you understand your audience’s context, and lastly, take steps towards controlling your vocabulary.
With that, thank you very much!