Quinn Keast-tone and voice guide

Nobody’s a copywriter, but everybody writes copy – Quinn Keast

Here you find the link to the full recording of the webinar, the slides & my key takeaways regarding the December 2020 Content Strategy Lausanne meetup with Quinn Keast.r.

Introduction by Isaline Muelhauser, host of Content Strategy Lausanne.

Talk by Quinn Keast, Partner & Designer at Caribou, Product Designer at Sourcegrap. Quinn has more than 12 years of experience covering the entire human-centred design process: from research and strategy to interface design and front-end development. Recently, he shared an open-source product language framework for content guidelines and copywriting: uxcopy.quinnkeast.com
Yes, you can copy paste and use as you see fit!

A huge thank you to Quinn. Preparing a presentation and being present to the meetup take a lot of time. Content Strategy Lausanne is nothing without speakers willing to share their knowledge. It was a pleasure to welcome Quinn.

Learning from people is my favorite way to learn! Seeing so many participants connected Thursday December 1st made me happy. Many thanks to you all for you support!

Full Webinar Recording

Recording of Quinn Keast’s talk at the Content Strategy Lausanne, December 1st 2020

Everyone on the team writes copy. And yet, how many are copywriters? In this talk, Quinn Keast shares the hidden challenges of copywriting in product teams, and how you can empower the whole team to use copy to create consistent, usable, and inclusive products.

Join Content Strategy Lausanne

Content Strategy Lausanne is a meetup that aims at promoting and sharing knowledge about Content Strategy and writing for the web. Content Strategy Lausanne organizes events in person and in webinars. 

Content Strategy Lausanne was founded and is hosted by Isaline Muelhauser. Isaline loves SEO and writing.

? ?? Join the community of content strategy and writing enthusiasts by joining the meetup group.

If you have any questions or ideas, contact Isaline@pilea.ch without hesitation.

Full transcript of the webinar with Quinn Keast about copywriting

Transcript created with the help of Kenneth Ongaro. Thanks Kenneth.

Isaline Muelhauser: Hello, everybody. I can see that we have participants coming. We are very happy to welcome you. You can see down here you have, if you over my face with your mouse, you see a chat, and you see a Q&A. If you could say a quick hello in the chat, so I know that you can hear me well, you can see me well, and that you are happy today. And then we feel good when we don’t feel all alone and we know that there are humans. Oh yeah. And in the chat, you can choose to write to the speakers, Quinn and me, and to the speakers, and the participants. And if you choose to talk to the speakers and the participants, it’s even better.

Hey. We are really happy that you are here. And I can see people from Berlin, from Lucerne, from Zurich. Oh yeah. From Lausanne. My God, Vietnam, that’s fun. Whoo, I’m so happy we are so many.

So, as you might know, if I have contacted you over LinkedIn, I have contacted many new people for this meet up because I was really sad that all conferences, were cancelled in 2020, because of the COVID. I felt like networking was really sad in 2020. I’m happy to see many new people here. First of all, let me introduce you the meet up so you know a little bit more about what we’re doing here. I’m going to share my screen, which is here.

About Content Strategy Lausanne, it’s a local meet up, a local chapter of the content strategy meet up that I’ve started about two years and a half ago. It was about the time when I started to work full-time on products. I was working in a web agency, and I was doing like more marketing stuff and then I started really writing for products. I really needed to meet other people who were doing the same thing, and share ideas. As you know, content strategy and UX writing it’s an emerging field in Switzerland, especially in the French speaking part where I am now. There are not many people who have that job titles and very often the companies they don’t even know the difference between marketing and content strategy and UX writing.

This meet up was also a good way for me to sort of share the knowledge and educate a bit the clients. It’s now two years later and we are now online. We are not going to share drink, but we’re going to share a good time. And let me tell you how we are going to do it. I’m going to intro you a few save the dates because we have other speakers coming up. And then we’ll have Quinn’s talk. Of course he’ll share his slides and all and then you can ask all of your questions in the Q&A. You have related Q&A and we’ll answer the questions after the talk. Don’t hesitate to ask anything you need and we’ll just go through it afterwards.

So this is the last meet up for 2020, but we have already a meet up planned for February and we welcome Yael Ben-David. She’s from Tel Aviv and she will talk about the platform like Airbnb, and Ebooker, where you have two different types of clients. You have the person selling something and the person buying something and you have to talk to the two of them. Save the date for February. I know it’s in a very long time.

Also other things I want to share with you if the slides go there. I’m also the co-host of another meet up about SEO. If you are into SEO thing, join me there. Sara, my co host is more about technical SEO, I’m more about on page SEO obviously and so we have little bit of everything in terms of subjects. We have a full agenda and speakers planned until, well until May or even June I think now.

Today, we welcome Quinn, and I wanted to tell you a little bit about him, about how I met him. I met Quinn two years ago, at UX Copenhagen, so you know now that these two years ago was a big year for me. I was busy working on products. Since I was new in this area, I was very much questioning my impact with language, what do I do when I contribute to a project? I went to this conference UX Copenhagen and that was about ethics, something about ethics and products, I can’t remember exactly, but it was an important moment for me because Quinn’s talk and then the few emails we had afterwards, helped me shape my ethics in my work and how I understand my impact when I do the writing, and also how I explain it to the clients.

Since then, I’ve been following Quinn’s work. I really like his work especially because his articles are always a deep dive, subjects and very introspective so I can very much relate and it makes me think a little bit afterwards. I always end up a little bit cleverer after that. Last, it was summer or maybe September, Quinn shared this open source guides and it just, again it was serendipity, you know, like the right moments I needed something because in this year, I’ve been working on a few re-launches. I’ve had my work re-read and proofread by the legal team, by the CEO, by the customer team, and each page has different kinds of feedbacks and different kinds of inputs and then the whole website is a mix match of everybody’s opinion.

I thought it was a good time to invite Quinn to talk about this tone of voice, and luckily he was available. Today, we are lucky to have him. Now it’s your turn.

Quinn Keast: Hi, everyone. Thanks so much for the wonderful introduction there. I’m so glad that you were able to get some good stuff out of both the ethics conference, and also when I release this content guideline. I’m really looking forward to talking with everyone about what we’re up to here. I’m just going to share my screen really quickly. See if I got the set up properly. Everything good there? Fantastic, so this is actually the first time that I’m doing a conference in this format. I’m really excited for the feedback and wonderful approach there.

What I’ll be talking about today is a topic called Nobody’s A Copywriter, but Everybody Writes Copy. I can see I have control of it. That’s fantastic. I’m a product designer at a company called Sourcegraph, as well as the cofounder of Caribou, a user experience, strategy and design consultancy. I’ve been doing this for about 12 years now, in all kinds of different environments and contexts. One of the things that I found very consistent is that some of the hardest problem I’ve ever had to solve in my career came about when we were trying to figure out how to talk about things. Now to give you an example here, in one of my previous work, I was working with a meal kit company. And if you’re not familiar with meal kits, the idea is that you, the customer can choose what you would like to order each week, and the company will send you the recipe and all of the ingredients you need to cook that at home, over the course of the week.

We had an everlasting conversation inside the company, about what to call what you see in this picture here and how to describe how many people it would feed. And I never would have thought it would be so hard to design for previous food, for the recipe or a meal. I also didn’t realise that it was so hard to decide if it was four servings or four portions. Now what was interesting here is that it turns out that none of these were exactly like were [inaudible]. But making the choice between these words had a pretty big ripple effect throughout the entire project that we were working on.

The fact is that the current recipe, a meal, are very similar, but they have very slightly different connotations and meanings, particularly in the context of a meal kit company, where a recipe becomes a meal. But when the term they used interchangeably, it creates all kind of issues in the company, particularly when the company has product designer, developers, product managers, but also a culinary team dedicated to inventing recipes and the logistics and distribution team dedicated to acquiring ingredients and handling the delivery, getting it all together. But everybody is using slightly different terms, don’t really have alignment on those concepts and the words that we’re using,, things get really complicated, really fast.

As a product designer, I often wish that I could be a bit more brutal with my copy and just like copy like “Get this and cook it and you’ll be able to feed four of you for supper, unless you’re really hungry, and I know it’ll just feed two of you.” But I guess the reality is that it wouldn’t really fit in the product. But anyway, over the course of my career, I’ve worked with all kinds of different companies; bootstrapped, two person start-ups, big nonprofits with really good history, mature fast food service organisations, early stage tech companies right at the cast of explosive growth. All of these companies, these massive range of different types of companies exactly none of them had anybody dedicated to copywriting for their products or services.

The best case scenario for us involved product management, designers, or developers with a knack for writing, folks who had a breath of experience and a strong sense of brand, voice and tone. That’s interesting, because in all of these companies, and probably in your own company, copy is absolutely everywhere, all the time, in every part of your product or service. That’s really interesting because if nobody is a copywriter in these companies, and yet, copy is everywhere, then that means everybody in the company is an accidental copywriter.

Now we can see this in the language that we use inside the product designers. It can be as small as a single word. Words are some words that evoke a larger contract like the difference between a little clotting bot, and the doctor dentures and stories of a ship. Or it might be the difference between the recipe and the meal. Every member of the team is constantly building and refining a personal vocabulary of words that they use. Think about the product, to describe it and all of its components. And these words then make it into the product itself to the customers. Every line of copy and interface, every interaction helps people to understand the place and context. What’s going on and what they can do next. And there’s often way more copies than anybody realises, because the copy has to be written in the moment of immediate need.

When a designer or a developer or a marketer, write that copy, in that moment, they are accidental copywriters. We also see this in the language that we use inside the team, between each other. It’s how we talk about what we’re working on. What we decide to build, and how we’re going to build it. Every single conversation we have inside the team reinforces concepts, relationships and actions, and ultimately shapes how the team thinks about the product. Every single conversation leads us to be accidental copywriters. And is also the language that we use outside of the product and the team in how we talk about ourselves, how we talk about the company, how we talk about the team itself.

Marketers, executives, hiring managers, everyday, everybody in your company is writing content. Blog posts, pictures, social media posts, job listings, all of this language filters back through the entire experience and affects how the users and team members think about the product essentially. What I’m getting at is that every single person is an accidental copywriter. Now, the thing is, if everybody is writing copy accidentally, it’s quite unlikely to be altogether consistent, purposeful or useful. Before long, we start to deal with all kind of initiatives. Usability debt starts to build up. We find that many of the same things are given different names like recipes and meals. We see that our customers end up confused and frustrated because there isn’t that sense of consistency. Things get harder to use when far away.

And we as a team find ourselves wasting our time in circular conversations where we don’t quite understand each other, but it’s not really clear why. And that in turn means that people often go away and write the copy themselves for fear of getting it wrong. The team lacks confidence, providing the customer feedback on copy, because ultimately the feedback is subjective and opinionated, which means more of assertive voices in the room who have an outside impact on the decisions. And of course this often leads to many of our teammates and customers, finding themselves inadvertently excluded, so nothing more than poor diverse choice. That doesn’t have to happen.

The list goes on. I’m sorry my screen is freezing up. There you go. The list goes on. But if anybody is an intentional copywriter, they make the entire product and company data, even if those people are the copywriters. When everybody is writing copy intentionally, it empowers the whole team, ‘cause they feel confident in their ability to make choices about copy. And that in turn improves usability because copy is written with the recognition that even a single word can affect perception and understanding. And that creates this ripple effect throughout the entire product or company, where the product becomes more internally consistent.

That in turn means that users are able to more easily learn how to use the product, get started with it, use it in our day to day work, without having to think too much about it. And my favourite part is that it can also drive positive cultural change, because the language that we use becomes more compassionate and inclusive, in the product and across the whole company. Now, I hope I’ve convinced you at that point that everybody is an accidental copywriter, and that it’s worth turning them into intentional copywriters. But how exactly do we go about doing that?

What I found it that turning accidental copywriters into intentional copywriters means giving them specific and useful tools they can use to write effective content. And it means making it as easy as possible to that and in the context of their day to day work. And third, it also means giving the whole team shared ownership of the challenge. Now this one, you’re probably thinking okay first, Quinn that’s called a style guide. And to some extent, yeah, absolutely. This is a solved problem. There’s so many different resources out there available to us; style guides, content guidelines, books that you can read on micro copy. You can look at Mailchimp, Wire, Shopify, so many different teams that publish their own internal guides for anyone to use.

And sometimes we see that, where the companies do have the maturity and resources to have copywriters on the team, they will often run things like internal training sessions for better copywriting to give everybody a starting point. Despite this, there is a big whopping, unsolved problem that I’ve personally ran into and I see my colleagues and teams across the industry run into again and again. Simply put, useful and effective content guidelines are really, really, really hard to make. And it’s unbelievable. I spent months digging into that in the previous fall, and I kept running into contrast. And when I look back and I reflected, what I found were three specific contracts. First, just creating the guidelines. Huge challenge.

Once you’ve created them, you have to think about how you’re going to share, and use the guidelines. That’s a bigger problem, then is change. And then what we often miss is also the governance of the guidelines. How exactly we’re going to maintain them overtime, who’s making decisions? And I’ve instructed on this, and I noticed there’s some specific things that went into creating really good guidelines for content. First, guidelines really have to be your guidelines. Anybody can do the research onto UX copywriting, into writing style, into then voice and tone, but that requires a lot of intentional action that most accidental copywriters don’t think to think about or they just don’t see it as part of their role.

To be truly specific and useful than to provide effort for instance to turn a team of accidental copywriter into intentional copywriters, the guidelines have to actually be yours. And then they have to bridge multiple converge. Terminology; the specific word they use. The voice and tone they use to communicate the brand. The stylistic conventions; how exactly you format things. And, of course, how to write actionable and useful language in the context of an interface. Copywriting is a combination of many of these factors but together. The same way that a product design balances many different needs and considerations, not just a purely visual governance.

What’s great about combining all of these elements into a single style guideline is that the guidance themselves then become a mix of standards and education. In order to check back in on them to find out the right way, the source is truth. But they can also learn why something happens to be the right way. And even the most perfect and complete set of guidelines on what to do, won’t be able exactly reusable by everyone, unless it’s really deeply woven into the context of your own product or service.

One thing they thought out with that right way was just the truth is. But it’s quite another to see that in action. The better and the more useful the examples in the guidelines are, the easier it is for everyone who isn’t a copywriter to go in and figure out how to write more effectively for whatever it is that they’re doing at that moment. If they’re not in touch with the guidelines themselves and figure out how to apply them to what they’re writing, it’s much harder to get into the habit of referencing the guidelines regularly, ‘cause it’s not providing instant answers.

That takes me to the next point. It’s because the guidelines, if they are fully extensive and everything we need to cover and they’re useful and they have contacts and examples, how is everyone else going to access them? I quickly discovered earlier in my experimentation that if they’re not effortless to accessing you, they just won’t be used. And their bar for effortless is much lower than I would have thought, so either had to fit perfectly into the tour of the team if already using or it had to be instantly accessible with no setup, which usually means it needs to be just a link to a website that they can open and browse.

But when these guidelines always exist and when they’re effortlessly accessible, they can quickly become vital. The more valuable they provide each individual person, the more often they’ll be shared and referenced by everyone else, which means it’s okay to start with a small with this. Most of us had experienced initiative that start with the best of intentions. But as soon as they become a product with capital letters, they get bogged down in process informality. But what’s great is that copy is absolutely everywhere, which means the company is small, we need to get started. And you can probably start them yourself.

But once you’ve created them, which is great, it’s amazing if they comply with shared ownership. Because then you don’t have to do it all on your own. And it means that the responsibility for decision making can be shared with the whole team. After all, the guidelines themselves reflect really fundamental decision from information architecture mutability in your product or service. And when the entire team of copywriters gets involved, even if the accidental copywriters turn into intentional copywriters, the guidelines will evolve very quickly with a self reinforcing drop as everybody, able to contribute. It help makes the guidelines better over time.

Now all of these parts are the combination of months and months of effort that put together lots of experiments. And at a certain point, I find myself thinking, wow I wish we had a starting point for this so we wouldn’t have to just do it from scratch. When I hear that point, I took everything I had been working on over the years and effort to put it together in one place. And I created a free and open source product language framework and shared it with the world, aimed at providing this exact starting point. It’s like Bootstrap for copy.

Now I’m going to take a few minutes here give you a high level overview of the framework and the approach that I took without going into it too deeply ‘cause I’m doing my best to make sure that this don’t seem like a style pitch. You know, Q&A, after this is over, I’ll be happy to dig into this. This is like a point to me, more detail, talk about from earlier, it’s a little bit more detail. But in keeping it high level, the guideline is really about helping everybody else create their own guidelines. I put together a complete in semi universal set of English guidelines. Unfortunately, I only have English as language. I would love to make it more than just English so if you can help with that let me know but complete guidelines for good copywriting.

And it covers what I think are the crucial areas, it’s a complete guideline. We’ve got the voice and tone. We’ve got how to write actionable language which is a current UI, I meant some context, locations in any product or service. The styling mechanics and a simple example of a word list to get you started. And then since the context is so important in making this a guideline, the entire thing is created for a fictional product, which I call forward. This is an imagining platform for people to share and acts of recommendation for books to it, based on a shared reading history.

The guidelines are then absolutely loaded with examples of what to do, what to avoid, and every example is real, in the sense that it’s for the forward product. But since it’s just a set of guidelines, this means a starting point, so that somebody else can go and replace it with examples of their very own product. And what’s neat is as a food and open source framework unlike other guidelines and other teams published, it might be able to reference, you are completely free to directly copy and paste, and re-use any part of these guidelines.

So instead of spending time trying to write your own from scratch, while avoiding copying anything, copying is absolutely encouraged. All you need to do is go through and update the example to reflect your own product or service so that’s useful for your team, and that become your guidelines. And then, mindful as well, that they have to be incredibly easy access and share. I put them together in two different ways. For starters, you can access them under my course at UXcopy.quinnkeast.com. We’ll share that link separately. You can just use that if everyday reference. Check it out, bon appétit for everyone in your team. But on your own, when you value to make this yours, you can download the entire stretch for this microsite. Customise it, and then launch it into your microsite with no friction at all.

I know that not everybody is comfortable with doing that. We also have an option where you can use an existing Notion template for the guidelines. If your company is using Notion, you can also just go in, duplicate that, add it to Notion. And the last thing here, to make them as easy as possible for anybody to contribute to these guidelines, all of them are just written in markdown, so that means that while you can just copy directly from the microsite, you can also, if you have any experience with that in text, just edit the markdown and contribute to the guidelines process.

Now I know that the guidelines are used as source graphs and planner today, and all these other teams using them, I just don’t know who they are. If you use these and you find them useful, please let me know. I’d love to know what can work for you, and what could do better. To wrap this all up, can go back into this bit of the Q&A. Nobody is a copywriter, but we all write copy and not a lot of it. We can work together, and you can lead the way in turning all these accidental copywriters into intentional copywriters and then in turn, end up with more usable, consistent and inclusive products. Thank you.

Isaline Muelhauser: Thank you. That’s amazing. Well, to be honest, I used much more the UX copy, the Quinn Keast than the GitHub version of it. I write in French, and many of the principles, they are the same, even though they, it’s a different language, I mean we have the same issues with the passive voice, with the not concise languages and very long, long sentences. I think, for me, was a great inspiration to read it and like go back to my own, which are so far, like Google document that sometimes turn into Word document. But, yeah, it was a great inspiration to look at it and just check my documents to make it better. And I’ve included many, many more examples and I really like the two boxes with the check and the cross, and sometimes people agree to writing principles, but they don’t understand what it means. And when they see it written, what it actually means to write in present tense, then they understand and they’re like, oh yes, I want that. Oh, no, I don’t want that, so examples is everything.

Quinn Keast: You know, I’m so happy about that specific example. That writing consistently is very hard. It wasn’t until I took my own guidelines and adopted them for source graph. Then something else that my team came back to me then said Quinn, I think the example of what to do, providing a present tense is actually in past tense. And it turns out they’re absolutely right. Even when I’m trying to write in present tense for that I’ve got in past tense. It’s actually the case.

Isaline Muelhauser: you need the review and the feedback. Even when you write, and you have all of these principles in your head, it’s not enough. I see, we have a question in the Q&A, so you can just use the Q&A and ask all of your questions. I see we have one, and it’s a pretty long one, so I’m going to read all of it. And so it’s Andreas is telling us, so reading now. I realised that it’s important that even back-end developers are aware of the power of words and use consistent wording when creating the data model. I agree.

For example, not that the users sees recipe, but in the database, it’s called mean. Do you have a story how you could make back-end developers are aware of this and make them ask for good words, already when they create the data model. Oh yes, this is so often that the words used within the team, end up in the product for the users. So Quinn any good input?

Quinn Keast: This is an amazing question. Thank you for that. This is actually the perfect example of how the language that the team is using ends up in the product. And I don’t think I can give you an exciting story about specifically that, but what I will say is that it comes down to the process and how we create language as part of the design and product development lifecycle. Too often what we will see is that we’re using things like [inaudible] When we are coming up with ideas and we’re talking about how these relationships work, and we do wireframes and figure out what the flows will be and in my view, when you’re working at those very, very early level, when you’re dread pouring as I call it, with just words and drawing quick connections between things when you are doing wireframes.

At that point, you need to keep language hypothecically. At that point, if you took a shortcut and saying this will be me over here and that’s Peter and not really thinking about what those connotations are, then that’s where things get encoded very early on in the wrong way, and you end up with usability debt. What I will say at that point is that the important thing is that we’re involving as many different disciplines in this initial design process. And we specifically call out, that the language that we’re using here is important. If we get to like cram everything up make sense later.

If we shortcut here, then we’re going to run into issues very quickly. What’s much harder is coming back after these things already encoded in figuring out how to make changes. That one is checking, because it doesn’t necessarily make sense to claim things in the data model, because that is not what you assume when users are using it. But what you will find if the data, us going to understand the importance of this language and they understand why you need a new tem, need to change the term. For example, this question here talks about the user’s investment but in the database that’s called a meal. That’s just how something changed around how the team understood the product at some point, and we don’t necessarily need to change it back but you do need to say exclusively that you’re using this new term in the product now. And please refer to that in the conversation. Please make sure not to put that in the context of product.

And what you can do is you can use the terminology with a word list to really give a structure, truthfully. And what I can give you right now actually, I’m going to share my screen again with you. Hopefully you can see my screen okay. But in the word list here, you can specifically call out terms that you’re no longer using anymore. And in this case here we have an example. Run is replaced and now being called series. We might do this in different ways. In this guideline I’m trying to keep it very lightweight. But at first glance, we actually have an explanation for why one term is now used instead of another. And as soon as people identify, hopefully a developer, that we are using different terms between the data model, and the product, then we can start a conversation and say, what is the discussion? What is the term that we need to use as they were and then stick to that.

Isaline Muelhauser: Thanks for the question Andreas and thank you Quinn for the answer. I see we have another question here. Aha, that’s a good one. How do you make the case to create guidelines, when everybody says, ah, we don’t need this we already have words, right?

Quinn Keast: That’s also hard, and that’s something I’ve had to deal with and I think it comes down to the production of the size of the project. And like I said earlier, as soon as it becomes a project with capital letters, that implies that you need to involve many different stakeholders. You need to make sure that you have a plan in mind for how you’re going launch it, how you’re going to build up, and it becomes so much more work. And the fact is that the guidelines, when complete and fully useful, will have that first, the terminology, the voice and tone, the actual language.

The fact is, you don’t need all of those to get it started. Chances are you already know where there are some challenges in how the team writes copy. If you simply say, hey, this seemed like something we could use to show the truth around us so that we can make this easier. Then you can use whatever tool that makes the most sense at that moment, to create the starting point for these guidelines. And then if you follow everything off that we’re talking about today, about showing it, making it easy to access, referencing it consistently, then you will find that they start to grow and advocate will grow to have more extensive guidelines.

Somebody will come in and say, hey, I was looking for this and I couldn’t find it. And so that’s a great moment. You can go in, you can update it, you can tell everybody, hey, we just made the guidelines even better, and at some point you will find that you have a living, useful style guidelines, and you didn’t know you have to make a big effort to get there.

Isaline Muelhauser: So you would say the guidelines are more of a living document that is going to evolve with the company, rather than something very prescriptive that says, from above all, here is how we decided now you do it everybody.

Quinn Keast: Yes. I do think it’s very important that the guidelines are seen as a source of trust but that doesn’t need to be commanded, so to speak. But rather in to be the result of a mix of aspects, best practices, existing company knowledge, and collaborative decision making. If your team together have to figure out that this word works better than that word, that’s something you can say in the guidelines. And then it’s not somebody saying what to do, but rather it’s a way of capturing what works best.

Isaline Muelhauser: It’s rather like a set of recommendations than sort of rules?

Quinn Keast: I feel that’s exactly right, although I do suggest that it’s good for it to be seen as a source of truth but a source of truth that can change and evolve.

Isaline Muelhauser: Great. Thanks for this answer and thank you for the question. And we have another question from Annie, who is saying that she’s also creating language guidelines at the moment. And that’s a lot of work to cover all aspects, so her question is, when you create guidelines Quinn, do you collaborate with marketing when creating the guidelines, and how do you roll them out within the company and make sure it’s actually used, and not forgotten in a drawer or just forgotten documents? So two questions here.

Quinn Keast: Great question. Collaborating with marketing is absolutely something you should do, particularly when it comes to voice and tone because voice and tone as part of copywriting is ultimately how you express the brand character and identity. And that is something that often companies have and is documented separately in more specifically defined brand guidelines. But something that the company doesn’t really understand, and they kind of evaluate whether or not something is like the brand. But that’s quite subjective.

So what you can actually do is you can use the guidelines including the voice and tone guidelines as a starting point for figuring out what that brand character is. In the guidelines that I’ve put together, I advocate pretty strongly for just having a thought of three very simple character attributes. And three, is usually must capture the idea of the brand. And if you have doubts, then you can figure out okay, so how do we apply that voice to everything else in the guideline. And some people are better at this than others. And involving the people that are great at it which is often marketing folks, is a great way to get more cross disciplinary involvement in the guidelines.

However, much like I said earlier, you don’t need to get it all done and perfect before you launch it, but rather get with the cannon test and keep going from there. The nice thing about voice and tone is unlike a lot of other things in guidelines, it tends to be shorter and not easier to do, but less work to create overall, unless of course you’re using the framework as a starting point. And learning about in the company and used by all would like some copy. The first thing I say there that I don’t think it’s realistic for everybody to use them. And instead, what you really need to do is make people aware that they exist and that they are effective and make them as easy as possible to share that difference. And so as an example, if you are in a position where you can review copy in GitHub, pull requests as an example, then that is a perfect place to suggest changes to what has been written in the product and tie those references directly back to the framework.

And I do this in my own work. I say that this could be rewritten in line with the guidelines referenced here. And then what that means, if that is telling people you got to use this, people discover, hey, this is useful. I could just go here and save some time and make a better start, and they become more and more aware of what is available through those guidelines.

Isaline Muelhauser: so basically it would be identify the moments, all the people where you can share the guidelines and not trying to share it with everybody at first and finding moments where you can show the added value and the fact that it’s easier to use them. Good point. Thank you, Annie for the question and thank you Quinn for the answer. And we have a question, so aha, the old and good question, what is tone and voice? And then, what’s the best way to approach to finding the voice and tone? So that’s a question we have very often in companies, so what is the tone and voice?

Quinn Keast: So the easiest way to say the difference is that voice is the brand character. It is personification. It is the personality of the band. And then tone is, I’ll actually look at my own guideline here to make sure I’ve got it ‘cause this is so hard to explain to people, but tone is how you express that personification of the character in different situations. If you think about how you would talk to somebody if you’re in an upbeat mode, versus when things are very serious. You are the same person in both of those situations, but the way you express yourself is going to be different. And that is the difference between voice and tone.

You will always sound like you but you will have a different way of letting that come across, depending on the different approaches. In terms of defining the voice and tone, I will say that tone itself is more of a formulaic type of thing. In the guidelines, you will find a great reference from NMG about the four dimensions of tone. And these are looking at these here but it kind of goes between funny, and serious, far more casual. Just check this out. But the idea here is that you can push and pull the levers to track the tone for any given situation. You can look at that, you can adopt that straight up and figure out how that applies to your voice. The tricky part is defining what the voices and that comes back to the broad topic again.

Now, keeping this really open ended, that goes beyond something you can easily do on your own. If you want to get to collaborative buying for these guidelines, if you want people to agree that this is cracked. If you already have brand guidelines that reflect that voice, great. Use them, figure out what that means, put suggestions for. If you don’t have those, what you can do is you can run workshops with key stakeholders who understand the brand, have been around for a long time, have a deep understanding of what that abstract brand thing is. And you can use different techniques to get the language done with you to talk about the brand, to understand the brand.

And ideally, aligning what attributes best reflect the company. Now this is a much bigger topic that I can really dig into on this call, but I can share separate results around this when the with Josh, no less than the talk is done to dig into that topic.

Isaline Muelhauser: so voice is more about the personality, and the tone is more the situation. I remember one of my colleague often using the example of the hotel to explain the tone. You know, when you get into a hotel, everybody’s really warm and saying welcome, how are you doing and then when you start checking in, usually the people get more serious and when it’s the moment to pay, or when they talk about the rules, then they get even more serious and then it’s a bit more understandable for a client who has no idea to visualise the situation and understand that it’s the same person talking, but really the tone and the type of explanations are different.

I’ve used that example again. I found it really useful. Thank you for the explanation, and let’s go to the, oh, next question. Goha has a question. She’s browsing the framework and asking, do you have a section and increasing language in there as well?

Quinn Keast: I do. If you happen to be browsing the framework in the section about tone and mechanics, there’s a section about writing about people. And this comes down to how we write about other people in a way that’s compassionate, inclusive and respectful. And I think about this for a while to figure out where to put it in the framework, but ultimately I believe that writing inclusively is a baseline for writing well. In the same way that you need to know grammar, punctuation and so I’ve included how to write about people as everything else with a very clear set of examples what to do and what to avoid.

And if you have suggestions on how to keep improving this, please let me know. I would love to hear the feedback.

Isaline Muelhauser: Thank you for the answer. And we have a question from Peter. When might a word list require definitions, more like a glossary, or a dictionary?

Quinn Keast: It’s become very important. Definition are very important when you have a product, where you need specialised understanding, where there is the more technical understanding. I have an example, my company right now, Sourcegraph is a code, universal code search, and for the people that are using it day by day, are very technically grounded. They have a strong understanding of how to use these tools, they use technical language in their day to day work. And the fact is that you have quite a range of expertise on that scale. And I myself don’t even understand the full vocabulary that we use in the produt. And that means everybody who is in the company, he needs to really understand what it is they are talking about, what they’re working on, has a way to easily get the correct estimations in a familiar time.

What’s nice about that as well and something I would like to update the framework to include, is that when somebody new joins to the company, they can shortcut a lot of their understanding, what they are working on. If they can just look at all those words that they don’t recognise, you know, is early on in conversations.

Isaline Muelhauser: thanks for the answer, and thank you Peter for the question. Barbara, we have a question. How do you avoid using pretty much the same guidelines, or even copy through the different products you work on? Yes, good question like, do you have … Is your style of writing on everything you create?

Quinn Keast: Ultimately, it comes down to patterns. If you look at frontend UI frameworks like Bootstrap or Tailwind or any of these terms, they all establish the baseline elements that exist in all platforms but headlines, link, all these different elements that are shared. And I strongly believe that copy is very much the same especially in like microcopy in the product. What that means is that the guidelines structurally could be pretty much the same. You can have the same sections, you can have exactly the same content, but actual examples, and the actual voice and tone expressed in those examples had to be your product.

The simple fact is punctuation is most clearly shown between every product. But the examples that you use to display that punctuation should reflect the product you’re actually working on. And if you do that, the fact that those are structure is pretty much the same, it’s totally fine. In fact, it can make it even better because there’s consistency between guidelines. If you happen to start working on a new one, you know exactly how to use these, you know exactly how to update it so they reflect the product you’re working on. Doesn’t need to be totally unique for you.

Isaline Muelhauser: Good. Thank you for the answer and thank you, Barbara for the question. And we have a question from Katie. How do you think the best way to resolve disagreements between writers when working on style guides if it’s developed by multiple writers? Good question.

Quinn Keast: Well, my initial answer is always use the [inaudible]. There are some disagreements that I think that come down to personal preference around style and that is difficult to deal with, because then you start looking at the subjective side of it. And at that point, I think it should be without like any other context you might disagree about at work. Yeah, if I’m a designer and I disagree with the design outcome, I would ask, can you tell me how you got to this outcome? What informed it, what decision went into it? What trade off do we have to think about? And ultimately sometimes I’ll go, okay, understand what’s going on here. The solution is actually just fine for what it does and ultimately it’s a subjective preference.

At that point, somebody has to stay okay. If it is a bigger issue, and I’m going to call out specifically terminology, as in somebody is not sure whether it should be a recipe, or a meal. Then that’s a sign that there’s some ambiguity around something important in the product. At that point it should probably go beyond just dividers. That point we need to start talking to the people that are involved in the product in other ways like designers, developers, product managers. We understand how those terms came about in the first place and you need to understand how people are looking at using those terms. And in the case of something like recipes and meals, that’s a good sign that it might be time to do as much as doing user testing before getting some kind of guideline around which one is the right one to use, so it depends. Depends.

Isaline Muelhauser: I really like the questions you provided because very often we feel like, oh, it’s a subjective preference, but I really like the idea really to go beyond this and ask the person, oh, how did you get to this preference and what are the tradeoffs? So I think it’s good to step back sometimes from preference and discuss it in a very equal ground. Thank you for the questions and thank you for the answer.

And we have a question. How do content guidelines fit in with design system, or are they two separate things?

Quinn Keast: That’s a hard one or easy one. What I think is the content guidelines or product design and design is part of content and ultimately what you’re talking about is guidelines for the entire product or service. And I think the best possible guidelines that you can get are those that act as a resource for anybody that needs to answer your question about building the product or service in the best possible way. And so, honestly without nuances, combining content with brand, with product, with whatever other resources are useful for the team. I think the problem is when we create hard distinctions between them, especially when it comes to things like actionable language because actionable language specifically applies to interface elements and things that users are acting on in somewhere. And that cannot be separated from design implementation.

The content, sorry, the product language framework that I created is a really focused thing around the content itself. But if your company get to the point where they can have a mature design system documentation, where they include examples of things like no confirmation dialogues and messages then tying them together in one place, or even creating a single set of guidelines in one place is the best possible way to deal with them. But that’s a big project. Again, capital letters, a project, so do what you can and then find ways to bring them together.

Isaline Muelhauser: so again starting small and building step by step. Thank you for the answer and thank you Jane for the question. Do we have another questions? We have a few minutes left so if you have a question. No, so I’ll just ask mine. I was thinking when you are in a company that is very much a beginner about languages and still writing with a very formal written tone, like which part of the style guides, like which writing principle is most important because often there is no way you can start applying all of the principles. Like so which, where do you start? Do you start with short sentences and not long sentences with commas, or do you start with present tense, or avoiding passive or what is the most important part?

Quinn Keast: I’m personally biased as a product designer. But I will say the most important place to start is anything that affects user action. There’s copy absolutely everywhere. There’s copy in the product, there’s copy outside the product, it is larger than that and you simply can’t go through all of that and get it done. But what you can do is prioritise the types of copy and where it’s used. I would say that anything is related to cause to action, conversions, confirmation, dialogues, or dialogues, error messages, those kinds of things are probably the most easy isolate and say, we’re going to address whenever we can in this instance.

And that could be multiple things. It could be, you know, how conversation orders, it can be device, it could be the punctuation, it can be all those things together, but instead of trying to get like a holistic first style, you’re focusing on specific applications. And what’s neat about that is that you should see usability improvements pretty quick, because you’re essentially saying that the areas that usability matters most are the areas we have to fix first, and then you can do everything else around that.

Isaline Muelhauser: That’s a really good approach. It means that it’s not about choosing one principle of writing over another, but rather, choosing where you apply the writing. I’ve got my post it’s written down. That’s really a good point. Thank you. And I see that when I was talking we had another question from Paging. She says she started creating as much alignment as possible, glossary language et cetera, on Google Sheets, and she noticed it’s been sort of a pain to get people to even look at them. Oh, yes. These are the tools that the writers, translator use. As a product designer, did you learn GitHub Bootstrap because it felt like the most practical tool or was this something you already knew?

Quinn Keast: Great question. This is very familiar. I only knew how to use these tools myself, so it was just an option that I had. However, I started trying to do these things with other tools, like you say, Google Sheets, Word documents, Google documents and I never found the factors for exactly the same reason; people don’t even look at them let alone read them. And I thought about this from the perspective of a product designer, and I believe part of the reason for that is because Google Sheets, Google Docs, these tools create a working context, while a microsite creates a reference context. And it is a lot easier to jump around on a microsite than it is to find a specific Google Sheet, which is necessarily a different type of data being used in different way.

So for me it’s an accurate statement to just go ahead and create a microsite ‘cause that was easiest way to get this done and built and launched. And I think it really comes down to the way people feel about using it, whether it’s work or reference.

Isaline Muelhauser: Yeah, it’s true. Every time we look for information, we open a browser, we don’t look into a document or search a folder. Thank you for the insights and thank you Paging for the question, and we can take a last question. We have few minutes, so Daniel is asking something. Would you recommend to apply to copywriting roles as UX writers? In other words, if a company does not have a UX writer yet, what are the things to look out for when applying blindly, a team that has UX designers, maybe.

Quinn Keast: Okay. I think it comes down to expectations for the role. At a very personal level, I will always be afraid of applying as a copywriter and ending up doing marketing copy, and nothing against marketing copy, I love writing marketing copy. It’s just a different day to day focused than UX copywriting. I think it’s a matter of saying okay, I want to be a UX copywriter and I’m going to apply my previous experience doing that well. And I think that you can go seamlessly between them. It’s just a matter of having the right mindset method, and with UX copywriting in specific, going beyond just the copywriting. I strongly believe that a good UX copywriter also has to have same skills that are very similar to product designers, like being able to do lucid research, being able to iterate and test different versions of what you’re writing, being able to bring together the users’ perspective with the business needs in achieving specific goals, and being able to work with better product development.

If you are copywriter, and you want to UX, go for it. Like I absolutely believe you can do. Just make sure that it’s actually a UX copywriting role and not a marketing copywriting role. And vice versa, if you love writing marketing copy, and you’re not interested in writing error messages you’re probably not going to enjoy being a UX copywriter. Just make sure that you have clarity on which one is which.

Isaline Muelhauser: I think I can relate to Daniel. Daniel if you live in Switzerland too, there are very few roles and I think in private companies, the tasks of the copywriters are often hidden in the many activities in a marketing role or in a digital marketing role. It’s like, it’s not differentiated and what I have seen is that it was easier to do copywriting in a web agency, although it’s difficult to create a role because when you are around developers, I mean, they don’t always see the value of the copy, so there is a little bit of education. However, says it’s still easier to do UX writing in a web agency than in a private company. But this is my personal experience so far, because in the agency life, they are much more projects building, and for different clients. Even if with one client, they may not be so interested in having a UX writer in the team, for another client, there will be another opportunity. You get like also a more diverse experience on diverse projects like, you know, and you don’t only work for one.

However, it could be awesome to work on the same project, I mean, so, but if you’re looking for a job, good luck. We wish you the best. And if I see something around, I’ll make sure to share it. We did one hour, so it’s now the end of the webinar. If you have someone, someone has a very last question. No, but thank you. We had so many questions. Honestly that makes me happy. I’m really happy you enjoyed having Quinn with us, and really enjoyed the opportunity to ask him questions. And I’m pretty sure that if you have anything coming to mind, you can write to him.

Quinn Keast: Absolutely. I’d love to hear from you.

Isaline Muelhauser: And in case you don’t find him, which I doubt, but you can still write to me and I just transfer the message. Really, we are here, if you have anything, we are happy to answer. And well, thank you for joining us tonight and I’m hoping to see you some other time, either follow you on social media and maybe sometimes face to face, again, because it’s a bit still strange to meet you, not see the participants with webinars, but I’m still pretty happy to see your name, and to see your interaction. And also thanks to me and Quinn, for being here tonight. I know that preparing a presentation, it takes a long time to prepare the slides and the subjects, and also your energy just to be here tonight, and share your experience and take the time and this meet up would be nothing without you willing to share your experience, so really, thanks million. I really appreciate.

Quinn Keast: Thanks so much for having me. Thank you everyone for joining.

Isaline Muelhauser: Thank you everybody and have a good night. Bye.