WTD Episode 28: UX writing - Starting and Scaling at your Company, Berlin WTD meetup

The following is a machine-generated transcript of the podcast. Expect inaccuracies and typos from the actual speech.

Richard: [00:00:00] right.

[00:00:13] Natasha: [00:00:13] Cool.

[00:00:17] Yeah. Okay. I feel strange standing so far away by. Okay. Um, yes. So, uh, my name is Natasha or Natalia. If you Google, it will be both. Uh, Natasha is my Russian name, and I actually prefer it. So I'm the extra searcher. I'm the youngest. Um, the, the, yeah, the youngest actually, your extra searcher, fleek spas. Uh, which, um, I will also, um, come up, no, come to like confined slides.

[00:00:47] Um. And because of my background, I was, I convinced the team that you should start UX writing. And we kind of trying to kickstart it. And there are some lessons, not even lessons I would say, but some questions we have for ourselves that we've been trying to answer. And I just want to share how we are trying to answer them.

[00:01:09] Um. So, yeah, I don't know. You might have seen this. It's been going on in the UX writing communities the whole week today. So this is what happens when you don't have your xyd. Yeah. And this is the point when you actually need to hire you. Um, so that we don't want to have a curl on the viewers. Um, yeah. So.

[00:01:35] Nice. Um, I, it made my week, like last week I think I decided to share it with you. So, um, my background, because every time we speak about the exciting day, I always people asking like, how did you come to your ex writing and for everyone? Um, the road is so. Different that I feel like sharing how, how is my world so far also brings a lot of, well, you, um, so I just finished my PhD in literary studies and when I say people think that for the last four years, it looks like this for me.

[00:02:10] Well, kind of the weak bed, most lit looks like this, and it's actually a can be Chou university library. Um, so this is how it looks. It looks like crap. Um, so Dustin books for the last four years, and, uh, when I finished my PhD, I decided that I want to jump out. And, uh, I've been starting to see what are the UX options are there.

[00:02:36] And I got to you, um, be hired as a member of the really cool UX research team we have at fleets bus, which is actually flex mobility, but you know, us as FlixBus. Um, so we have new team, um. Who started all the UX bosses in fleets bus three years ago. So, um, she's, she's a year excuse diner. Um, and I think she's still officially UX designer.

[00:03:03] And then she was joined by Carlina, who's our actually issue. It comes from marketing. Um, and then last year, uh, the team was, um, uh, Petrel joined the team who has a degree in human computer interaction and then joined. I, um, with my linguistics and literary studies degree. So we are very broad and we cover a lot of, it actually helps to cover a lot of topics we have at fleek spas.

[00:03:34] And, um. Just a bit of how we, um, how did we get at this point at, um, in UX maturity where we decided to kickstart UX writing. So we measure our success, our growth, um, through this UX X maturity stages, um, framework. So I will just quickly go through, um. This one to five, so it helps to understand. Um, so yeah.

[00:04:06] Um. Yeah. is a framework that organizations can use to track the movement of UX and it helps to understand their status quo and recognize the challenges and generally helps us progress to another level. So if you start from the left, you have principle based. It is. The first stage is basically like the absence of UX on this stage is usually there are no UX people in the company and all.

[00:04:34] Only developers are building the product. Um, and of course the organization doesn't have an UX expert to, um, show the way. Then the second stage, you start with, you start usability testing. You get to know what is your X. You make other team members where of UX, but it's still like, you know, make it nice.

[00:04:59] This is what UX at this stage. And, um, from making it nice to actually establishing new your X process, you need to go to your third stage, which is called adopting. And I think this is one of the key stages of UX maturity. This is where all the hard stuff is happening, in my opinion. Um, and of course, uh, the last two stages, uh, when you exit informs.

[00:05:28] Product strategy, but also global strategy. Of course, the most exciting ones because you get to be involved in the projects from the very start. Uh, then only when people only have an idea of a, of a project or a product. Um, and in the end of course, you want to be, um. You know, involved at the global level.

[00:05:53] So, uh, we've, we did our evaluation couple of months ago and, um, before I show where we are, um, I think there are a lot of like, okay, who have ever used flex bus. Okay, cool. So you can actually maybe, uh, help me evaluate, like, what would you think which UX maturity stage bus is at.

[00:06:20] Okay. Um, so we've done our own revelation and I think we are at the end of the H, uh, the end of stage three. Uh, we'd been working there I this year to actually establish really cool, really, um, quality. Quality wise, good processes. And, um, we then sat down and thought, what do we need to go? What do we need for us to go to the stage four?

[00:06:49] And this is where we decided to introduce your X writing. Um, it is still very fresh. We're still like learning from our mistakes, which are a lot, but, um, yeah. When, uh, when I talk about DX writing, this is the question I get, like, who the heck is the UX writer? Get it all the time, uh, from every T my GoTo and I ask for your explaining, writing, uh, ex, um, well then it's hard to concentrate.

[00:07:19] Okay. Um. Yes.

[00:07:22] Richard: [00:07:22] So

[00:07:26] Natasha: [00:07:26] instead of, um, instead of explaining it in words, which is my job, I will just show it to we were left. One is when there is no UX writing. So. Um, I'm not a developer, so I ideally don't have any idea what four Oh four means. Um, I'm not given any instruction on how to go back, how to correct my mistake and what is happening here and where am I have no idea and example of great UX writing.

[00:08:02] No on the Northern, you know what to do now to go back to home page, but you also have fun. You know that you are on a Disney site, your brand where, um, you're not at least upset that you ended up on this page. It's really cool. Like, uh, you S you've seen Microsoft ski, now you can go back home and search search again for what you are searching.

[00:08:27] Um. And if I'm to summarize this two examples and to give, so to get something out of that, I would say that the excavator is to this guy, um, silently or not silently in his case, I guess. Um, they're like in visible guides. They are, um, they athlete like. Marketing and PR would grab your attention, right? But you excavators, are they invisible guides?

[00:08:59] They help you use the product. Um, they help you through this journey of using a product and in my opinion, um, shake up like, okay. Um, yeah, in my opinion, good contents, content shows first of all, care care and understanding about user needs. At every step of their journey through your product or app. So I would say that.

[00:09:30] The UX writer, he or she uses simple words to explain things. There is no need to be. There is no need to speak the language that is different to the language of your users. Um, it also shares conversations for me is using the vocabulary of your users. So a will will go, I will go back to to this topic a bit.

[00:09:53] Like soon. And, um, it also build brand, brand awareness in a non-marketing PR way where it just in your face, but, um, it builds awareness and helps create, uh, create, creating a loyal fence. And, um. This is what we kind of want a UX writer to be. And this is what I want me, me, myself to be. Um, so when were thinking about UX writing, we had, we soon faced, um, five challenges and I'm just going to go through them and I'm telling you guys how we did it.

[00:10:32] It doesn't mean it's the best way, but this is how we are doing it right now. And we're always looking to improve ourselves. So the first question we had was like, how do I users feel and how do they talk about our products? And for that, because we're a team of UX researchers, we have a lot of UX researchers, solution UX research solutions to that.

[00:10:56] And one of the ones that we used was, um, empathy map. . So, um, it's a great addition to UX research that you do, I hope on your users, like user journeys and, um, of course on the goals of your users. So, um, this is one of the empathy maps that was done by one of our UX designers, um, a long time ago. Some, there's more stuff I just needed to, I couldn't show everything, but it was then during user lab.

[00:11:30] So Sofie things, whereas the station, the Sophie things happy and relieved because she likes that there is a baby vegan on the train. So, um, it really helped, um, to know. What do I write? On which point, uh, and what to check because it's already been written. Of course. Um, so if you use empathy map, I hope that one lead to, uh, to this case, it was taken also from one of your ex writing groups or Facebook.

[00:12:03] Um, this is one dating app and this is what you see when you just downloaded there. Just started using it so. No people like you. But that's not surprise to us. Okay. So I'm ogling or something cause I, people can draw such wrong conclusions about the whole user flow just because you didn't, well, hopefully they did.

[00:12:31] Hopefully it was just a mistake. Um, you are not empathetic with your user at this moment. Hopefully they do. But, um, yeah, it can be the case. So, okay. Um, so now we know our users feel and talk about our product, but do we speak our brands language? And I think this is, uh, one of the most important points because, uh, we.

[00:13:00] We work a lot as UX research team was Brendan marketing and we worked with them on, um, we worked with them and their materials and created a West chart. So if you ever finger for a full express brand, and if you ever Google it, this is what we'll definitely find about us. It's our vision that we are smart, um, smart and green mobility for everyone to experience the world.

[00:13:27] And when we take this fusion, uh, and divided in three principles. So the text here is not about Flexbox, they couldn't use, of course, the flux vest, but it's just the WestJet is very. A doll face, you feel bad. It's very helpful because it's just the Tabor was a brand principal, some top and then writing rules for every of this principles.

[00:13:53] So when I need to write something, I would write three copies, um, for each of the principles, and then I will just share it with the stakeholders. Then it is also, uh. A good way to start a conversation. So guys, I have, you know, three, three versions. Let's just pick one and go from them. And of course, it's a lot of ideation after that, but it's still a good way to start talking about the content.

[00:14:23] So we speak our brand brands language, hopefully. Um, but, um, do we speak the same language as our users. And this is for me the most important one because I'm not a native speaker of my primary primary language at flakes buzz. Um, I hope I will get to write in my own language and it might happen soon. But for me, um, conversation mining is the most important thing.

[00:14:52] If I need to write a for the most broad. Audience that we have at fix bus, we need to be sure that we are, the people understand us. So what we do, we use Dropbox customers. We talk to customer service, and we do the thing called conversation mining, which is basically scrawling through, um, Twitter. We use, and we also have rare bitch.

[00:15:20] Um, so this is worse when I was helping my colleagues at lost and found we were just scrawling through every social media we found. Um, it, it was funny at times, sometimes very sad, but it really helps to understand, uh, if we really speak about our product in the terms that are understandable to our users.

[00:15:42] Um. And then, okay, I wrote everything I could. I checked, I did my UX research and my UX writing copy, but doesn't live in make sense. And this is something that I've been using since my school days. Uh, we just do common comprehension and readability scores. Um, we're very. Lucky to have a, um, online user testing platform where you can do a lot of different stuff.

[00:16:12] And I just recently ran my first two Newt close test close test is basically language tests. So, um, uh, by making a close test, you test your copy for comprehension. So you get a comprehension score. And, um, it measures that the user's user, uh, of your targeted audience can understand. They turned the meaning of the text.

[00:16:39] So it's pretty easy. It's like, um, you need to every. Fifth ward, let's say, but microcopy uh, the people who wrote about close testing, they all suggest, um, a bit less than every six word. I used every third word or every fourth word, but sometimes came also to every fifth word. And you just ask people to fill in the blanks.

[00:17:03] As far as, as far as they understand. And it brought very interesting results. Uh, like, uh, one of the copy was written, was didn't score at all. And, uh, we understood that actually the target audience speaks about this product completely differently. And then we of course change it a bit. But when I. Don't have much time to land a close test.

[00:17:27] And I suggested to you all the UX designers, we have to go to the Hammond grey app or any other online readability service out there because it, um, of course, um, there are more UX, UX designers and of course, much more texts that then we can handle. And sometimes UX designers needed very fast. And then we just say, guys, just, they all have spellchecking.

[00:17:52] Uh, plugins at FEMA where we work. Um, but I also always ask him, just do through Hammond gay app. If you really don't have time to come to us, just check it for basic readability. And it,

[00:18:05] Richard: [00:18:05] it was really cool. Like,

[00:18:07] Natasha: [00:18:07] um, we noticed with localization team that, um, the copy got a bit better, so it's very nice. Um, so yeah.

[00:18:18] Um. And the thing that we also try to do, uh, offline. And this is something that we haven't done in a while. I, I admit. Um, but, um, this is what we used to do a lot before we had the online tool is UX question. Um. And your cross on is some, it's speed, speed, dating style, and use a lap. So you have a small power sessions where you have only five minutes to present your topic and get feedback.

[00:18:51] And if we, I'm able to, um, to get the, our users, uh, to, uh. To come, we just did with our new employees. And it's not only researchers, uh, POS or designers, they can also propose their topic and get, uh, evaluated by our new users. Um, and of course, uh, when we check the copy throughout the times, so not just once we try to, uh, check it, uh, every two or three months, uh, we, um.

[00:19:27] Keep asking the same question. So it's a very important for consistency. We have 'em if you have a hard heard about Google Panda questionnaire, it's the 10 basic questions to evaluate this, um, the content with your users and the most important by this, keep asking them continuously. So then you have a better feedback on how your copy's improving.

[00:19:51] Um. So, yeah, this is, uh, yeah, this is our tips, um, as a UX for search team primarily and as a, um, you know, a UX writer enthusiast, I would say, um, is, um, try to do empathy maps. It shouldn't be just you. Sorry.

[00:20:12] Richard: [00:20:12] Yeah. Uh,

[00:20:16] Natasha: [00:20:16] yeah. I have two more slides to go. And then you're open to questions. Um, yes. Empathy maps are really nice, uh, um, to a really nice, um, thing to create together with your team or with your designers, with your POS or developers.

[00:20:37] Um, together with. Anything else you do? Personas or user journeys. Then, uh, we also tried to create a, tried creating voice charts and it kind of worked. So I really like to always get back to this word, voice check whenever I have a writer, bladders walk or anything. And, um, customer service are, of course, your big friends if you have it, if you have a 10 year company, if you don't.

[00:21:06] Um, it's throw up on your customers online. It's also a very cool way to understand how they speak about your product and language tests are, they're easy to run. Sometimes it's, you just put in the text and Hammond gap and you have your answer. And. Yeah. If you have time and capabilities, just do a small, very quick user lab, the one that we call UX quests on at flakes bus.

[00:21:31] And of course you can always, always, always ask for advice online. There are a lot of groups out there, uh, at Facebook, Slack or LinkedIn. Um. They're very fast. In that spring week, I can ask them something and it's 5:00 AM in the States and someone will answer me. Um, and those are three books. They're personally RET, and I think they're cool and very helpful.

[00:21:58] One of them is here. Um, um, the worst Jack was taken from the strategic writing for UX. Um, and I found it very convincing. And of course, Erica hall is, um, you know, if you haven't read her other books, just, just enough research, I think you should. And this is a very good, um, addition to that. Uh, so she talks about the future of conversational design, which is not only UX writing, but very helpful.

[00:22:30] Yeah. And, uh, I recently read a very interesting book by Stephen King on writing, and I think it also applies to your ex writers as well, is that you never write alone. Uh, if you can talk to your stakeholders, designers, uh, developers, anyone, the as much feedback as possible is what makes the copy in the end.

[00:22:53] Um, yours, I think like if you, if we talk about brands, um. Yeah. So for right with the doors open. Thank you.

[00:23:08] So

[00:23:09] Richard: [00:23:09] you had a few last minute shifts and changes. So I think what we're going to do since everybody is, we'll take questions in the Taschen now quickly and then we'll come back to . Um, so. I'm not going to expect you to pick anyone

[00:23:28] Natasha: [00:23:28] else here.

[00:23:30] Richard: [00:23:30] If you could repeat the question and, yes.

[00:23:34] Natasha: [00:23:34] So I will repeat the question.

[00:23:38] Richard: [00:23:38] Um, so you mentioned about practice

[00:23:46] communication on social media. Do you think like those five tips are still, uh.

[00:23:57] Natasha: [00:23:57] I think definitely, especially, um, the voice chart. It's, I think super important. I so sorry, I didn't repeat the question. So five tips. Five tips for, um, for like online communication. Yeah. So I think the voice drag is very important because, um. It's very different. It's very different. A tweet will be very different if, um, you are promoting something new in your product update or anything, or a new product and answering a person who, who had very bad experience with your product, the tweet will be, the tweets will be completely different.

[00:24:39] And if you answer. Especially if you answered to your bad tweet in, you know, Hey, you had the problem. Well, you need to, you need to understand that this person is now in your empathy map, in your user journey. You understand that this is, this is the person who is now at the lowest in communication with your product.

[00:25:00] You have to be very careful what you say. You cannot take your one of your brand principles that is a. You know, funny. If, if it's one of your brand principles and you cannot answer funding, you need to answer very. Your name, baby, um, accurately and be aware that the person is now ready to write, you know, hundred reviews about your product.

[00:25:24] So I think Weiss charts and, um, empathy maps are really important at this point.

[00:25:38] Richard: [00:25:38] Act according to that trend, the subject or whatever, hashtag whatever it is. So how do you keep that quite tips, like in an automatic way, an answer then right away, that trending keywords and social

[00:25:56] Natasha: [00:25:56] media keywords that apply to your product

[00:26:01] Richard: [00:26:01] be like, you know, whenever you're talking through, it's like trending things that are happening.

[00:26:05] For instance. Why is now in Australia or so? You know, brands are generally try to catch

[00:26:11] Natasha: [00:26:11] that

[00:26:16] Richard: [00:26:16] connection.

[00:26:22] Natasha: [00:26:22] First of all, I think in this. When you want to react to your Australian far, it's better to confirm with your brand that you are erect, reacting in the right way. And this is one of the, uh, tips is to, um, yeah, exciting is not a marketing writing or PR writing or copywriting and it's all about, uh, helping the users.

[00:26:44] So if your tweet is about helping the users. That are stuck in yesterday. Alien flyer. Then just remember that you need to be also to remember their user journey if, if you're going to promote your product, uh, somehow to help. I know. If it's about promoting your product, then definitely talk to brand before writing it because it's, I think already more in their department and the in UX department, the UX writing department.

[00:27:12] But if it's to help your users. Take a look at your voice chart if it has, if it has something, I think, um, I, I don't know how to do that here, but let's just, no, no. Okay. Um, yeah. If one of your principles is not efficient but reliable, then of course you have a special dictionary up to capitalization, punctuation, grammar, hard to be reliable in writing a tweet.

[00:27:44] But I don't think, um, the,

[00:27:48] Richard: [00:27:48] I

[00:27:49] Natasha: [00:27:49] think that the voice chat is pretty universal. That is its power. I think

[00:27:57] Richard: [00:27:57] the other question in the room, actually, I might take one from the chapter.

[00:28:06] I'm going to speak to this much. So I have a question from Laura. Does the length of the content change how you test or develop.

[00:28:16] Natasha: [00:28:16] Okay. Um, yes. Uh, the length changes and sometimes very drastically. Um, we have a very big localization team and we know that, uh, we, uh, the English copy is the shortest copy.

[00:28:32] Every other copy will be longer. So what we introduced just recently, very, very recently is that, um, localization, take a look at the designers. Um. You know, feed a link or something before it is sent to developers and to localization. And the localization experts, they have like a pager duty. Um, they can already tell you guys this, what you written in English will be unlikeable izable in, um, other language.

[00:29:04] So, um, the lengths of content is something that localization needs to be aware of. If you have a team, if not, just remember that I think English text is like one third of every other text you will get. So, um, I think there is a rule somewhere out there. Um, my localization colleagues will be, of course, the better person to answer that.

[00:29:29] But, um, yeah, the, uh, rules for localizing the content, if it's what is meant by the question.

[00:29:43] Yes.

[00:29:53] Richard: [00:29:53] communication with customers, but also organization communicates better state.

[00:30:02] Natasha: [00:30:02] How did weather, what

[00:30:06] Richard: [00:30:06] example. The board introducing more

[00:30:16] on customers, but also how physicians, so I guess the question does help influence everyone else. Communication.

[00:30:28] Natasha: [00:30:28] Well, actually, I would say 30% of what I write, I write for business. Um, we have an amazing tech to you team. Uh, our UX designers. Um, no, I won't say much less than me in UX writing, and our developers are amazing guys and girls.

[00:30:47] Um, so. I actually do, I would say like 30, 70, 30% business. And, uh, because everyone is very user centric at our company, the business already caught up with UX research at this point and UX design. So when we said, guys, you know, we want to kickstart UX writing, everyone, I have a job for you. And there were like hundred tickets.

[00:31:12] So, um, that wasn't the problem.

[00:31:18] Richard: [00:31:18] But. Um, I take calls from the chat room quite a few questions, but I'm just going to get one

[00:31:29] maybe. Yeah, sorry. Maybe it was maybe thinking the Caribbean. It was a question from Corinne who I notice some copy providing guidelines all go through the UX team.

[00:31:49] Natasha: [00:31:49] Right now. Right now, it's a bit complicated because we're very new to that. Uh, but, um. Well, our plan is to provide guidelines and workshops to, uh, educate, uh, developers to do it, um, mainly by themselves.

[00:32:09] But of course, there should be some quality check if you, because it's not a developer's job. We shouldn't ask from him to be a perfect UX writer. But for now, it's really, it's for now, we try to check. Um, because developers are also working in a different term. Temple is UX writers, but we try to meet every time there is a handoff, um, for localization or between UX designer and developer.

[00:32:37] Um, I try to be involved as much as possible, but it's not always, it's not always feasible, but developers are great guys, so they know that they need to check with someone from UX, at least, know. Cool.

[00:32:54] Richard: [00:32:54] Um, if everybody could

[00:33:09] have some food and be back.

[00:33:20] 35

[00:33:34] Let's see if we can get that straight first.

[00:33:47] Natasha: [00:33:47] Straight to the wall, roughly and touch anything on that one.

[00:33:57] Richard: [00:33:57] move the table over here.

[00:34:06] Alright. Thank you very

[00:34:06] Natasha: [00:34:06] much.

[00:34:09] Richard: [00:34:09] Wonderful. Okay. Welcome everyone. I'm glad you're still here. Um, my name is Roger sheen and I'm here to talk also about UX writing tonight. Um, before I do that, I'd like to thank you Monotech for hosting us, um, for Chris for tirelessly organizing this writer. Doc's meet up. Um, over all these years, uh, and if our, who isn't with us tonight, but, um, was really instrumental in organizing tonight's events.

[00:34:33] So, um, I think, uh, without these people, this wouldn't happen. Um, so thanks for your interest. Um, thanks for sticking around after the pizza and not leaving after you filled your bellies. Um, if there's anyone still left in the livestream, thank you for sticking around even though you didn't get any pizza.

[00:34:49] Um, so here's my take on this. To me, U X wedding is a new word. But it's not a new task. It's something we've been doing for a long time, and UX writing combines aspects of several other related roles that exist in our industry, right? The content strategist might be focused on a little bit more overall corporate strategy when it comes to communication and things, but a lot of people that do this sort of work are called content strategists.

[00:35:18] In fact, the people at Facebook that write UI copy. Have content strategists in their title. Um, information architects also do related work. Uh, and the UX writer needs to have a basic understanding of information. Architecture principles are things like information hierarchy and how people understand the structure.

[00:35:36] Um, so that's a good skill for a UX writer to have technical writers who are usually concerned with providing procedural information and explaining to people how things work, uh, are also the types of people that ended up. As UX writers one day, perhaps UX designers also have related skills. So the notion of how users interact with software is something that makes this work easier.

[00:36:01] And if you have that kind of understanding, um, that will make you a better UX writer. And copywriters also have a related skill. And in fact, many people use these words interchangeably. Many UX writers were cold copywriters before we started calling them UX writers. Um, but to my mind, a copywriter is typically more focused on persuasive content.

[00:36:24] So a copywriter might be someone that writes copy for brochures, websites, marketing materials, where the goal is to convince the user to buy a product or persuade as opposed to assist the user, uh, during the use of the product. So in large organizations, there may be dedicated people in every one of these roles, but not always.

[00:36:49] It may be just be you. So on that assumption, we'll look tonight at how you might go about sort of organizing some of this information. Right. Um, so what is it that the UX writer does. I can't profess to explain that in a definitive fashion. Um, because I have done this myself in the limited context for certain companies, and I can talk tonight about the way we did things at one particular company.

[00:37:17] Um, but, uh, that's just the part of the elephant that I have touched. You've gotten a little bit from Natasha this evening about, uh, her perspective, that flipped bus. And tonight we'll talk about another use case, and that's wire. So I'll talk about the UI copy process. At wire. What is wire? Wire is a secure messenger, much like Skype.

[00:37:40] In fact, um, founded by the initial, uh, inventors behind Skype on many of the original Skype team were behind a wire as well. So we'll take a look at one UX writing journey based on how we did things at wire. And talk a little bit about, um, how that process evolved over time and some of the guidelines and resources that we use to, um.

[00:38:03] Structure, our work there. Talk a little bit about how we handled terminology and localization and then some of the other challenges and issues that we faced. So before we go too deeply into that, let's take a look at what string files typically look like. Like how does copy get into a user interface? So here are three examples from three different platforms right.

[00:38:25] At the top, we see Android's version of a string. Android typically handles your user interface copy in an XML based format. So there's an XML XML element called string that has a name attribute that contains an ID that is used to identify the particular piece of text that the software would like to display at a particular location in the interface.

[00:38:45] So in this place, in this case, we have an ID with a. Super concise idea of people pick her, invite, share text, Bobby, we don't need to care what that is, but the piece of texts that's shown in the user interface says, I'm on wire search for something or visit dot com so this is a piece of string that a piece of text that we might use in the app to let people know that we're using the application and we'd like to connect with them there.

[00:39:12] And the iOS does that a little bit differently. They use a different file format. Different ID. Um, but the same text appears there. You'll see if you look closely at some bits of that texture, a little bit different, right? So, um, Android limits strings to ASCII text. So no proper Unicode characters are possible there.

[00:39:32] Uh, in this particular iteration, we need to use a straight quote and back backslash escape that in order to get a proper type of graphic apostrophe. Uh, the placeholder here is the percent, $1 less. Uh, whereas, you know, iOS, uh, we have, uh, access to proper Unicode typography, so we can use the type of Africa apostrophe there.

[00:39:53] Um, this team uses different placeholders. Um, so the same place holder that appeared in Android is here a percent Exxon. Um, and on the desktop platform we have get another format. Um, so proper, proper Unicode bear as well. Slightly different, a placeholder format. But I show you this not because everyone's keen on looking at curb, but to illustrate why we can't just copy and paste across platforms as why there's.

[00:40:21] We're interested in reuse, and we know that copying, pasting things is not efficient, but when the format requirements dictate that we cannot use the exact same piece of text everywhere, we need to be very cautious and cognizant of that. Um, so this presents some challenges that we need to solve. So we'll talk a little bit about how we did things there and how we do things now, or how things were done later when I arrived.

[00:40:47] A lot of this texts and the user interfaces. Um, it was hard coded and mixed in with program source code. So each client was built by a separate team. Uh, there was an Android team that took care of those, uh, that app and an iOS team that built the same piece of software for another platform, or using a separate code base and the desktop team as well.

[00:41:07] Um, and so the interaction between those teams was limited with regard to code sharing, and therefore there was sometimes some drift within the text. So what began perhaps as, as unified texts would sometimes drift as one platform changed things without notifying or without sharing that change with the others.

[00:41:26] And so one of the first things that we did was Chris questions. Ah, we might need some power. There we go. Wonderful. Um, so we don't need to be able to read this stretch spreadsheet that just serves as an illustration that this was sort of one of the initial steps was to do a bit of an inventory to see which text appears where.

[00:41:47] Place them side by side and use that as an opportunity to align those texts and decide where those texts suggested. How would we like to align them? Which of those variants would we prefer to use? But of course, this sort of thing gets quite tedious and involves a lot of manual work. So that was very clear that that would not be our method for very long.

[00:42:06] It was just an initial transition phase. And you might find yourself in this situation if you're tasked with aligning user interface company at your own company at some point. So that's why I mentioned. At some point we, um, were able to convince the developers to extract all of the user facing texts.

[00:42:24] From their source code into strings, files, dedicated bits of text files, text files that we could share and review with one another. Uh, this makes it easier to see all of the texts that appears in an application at once. So you can actually read that file from start to finish and check for consistency errors and grammar errors and things like that.

[00:42:42] Much, much easier than flipping through thousands of files of source code to find a single sentence. So. With that in place. We were able to take these strings files and place them all beside one another in a single repository. So we had one repository that contained all of the texts for the Android application and all of the text for the iOS application and all of the text for the desktop application.

[00:43:05] And that allows us to search and replace our over all of the AR platforms at once. But that was also a stop gap solution and a stepping stone along our way. We knew that we wouldn't do that for very long either, but developers initially were a bit reluctant to give us content, people access to their source code because developers were afraid that content people wouldn't understand the difference between a straight quote and a Unicode quote, a double quote, and a single quote and angle bracket and a Curlew brace.

[00:43:38] And they were afraid that we would forget a semi-colon somewhere and break everything, right? So that's why we had our own copies of their strings files. Made the changes there, and then ask the developers to go and pick up our modified versions of their string files and place them into the wrong repositories.

[00:43:56] And there's nothing that developers hate much more than going back and forth and copying files. So with this little, um, strategy, we were able to convince them quite soon that, look, we're actually not breaking anything. When you copy the files from our repository and place them into yours, they still work.

[00:44:16] And they got so sick of copying things back and forth that they gave us the keys to the car, which means we got access to each of the client repositories, the Android, the ILS, and the desktop repositories. And we're able to then use the same process that the developers use to adjust their source code and to maintain it.

[00:44:38] For the company. So essentially we would use those string files and edit them in place and then submit, pull requests to the teams, to developers to say, we have modified the text. Now please review our changes and accept them into your code base. So that requires a certain level of technical ability on the part of the writing team.

[00:44:57] Um, some writers are a little bit afraid of get, um, but we can take them by the hand and help them to understand how that works. And with a little bit of training, writers can learn that rather quickly. And developers are happier too because their work when we change copy is much, much easier. All they have to do is look at the code, look at the code review and the pull request and press a button to merge.

[00:45:17] So that makes things much, much easier. So the process that we arrived at after these stages that I described is one where product features would begin with the product team, product owners. And um. Um, design team will begin designing a feature and early in this process we try to nail down the basic terminology for a feature because the only thing that's harder than naming something is renaming it later.

[00:45:50] Internal jargon is very, very persistent. Once you start calling something something at the company, everyone will continue to call it that. Even after you've realized that name is a bad idea. Code names stick with us forever. So we tried as well as we could to sort of eradicate code names by using the proper words from the start.

[00:46:13] Um, that doesn't always work, but it's a good thing to strive for. And from that initial. A feature, a draft, the design team would then begin to work more closely on a proper design specification, uh, that would inform the development process. And by those work closely with the design team to nail the copy, uh, for the entire feature.

[00:46:37] So all of the checkboxes and settings, um, they take over screens and buttons that would be associated with a new feature. We're part of their specification that the design team produced. And that specification then is handed over to the develop development team. Uh, and of course during the development process, the developers would take the cat, the, the text, and the, the initial design from the designers, implement that in code and fine, we're fine as necessary because of course.

[00:47:06] Sometimes when things were designed in the context of a design application or a prototyping tool, um, it wasn't entirely clear what the constraints would be with regard to space or something like that. So perhaps the initial copy maybe didn't fit in the, uh, in the, in the dialogues, and we might need, have to go back and refine that.

[00:47:24] Or something about the way the feature was designed, maybe it wasn't implemented or possible to implement exactly like that. So there was a certain refinement process that happened there. And during this process, we would also involve the customer support team who would need to understand how the feature works so that when customers ask about it, they're able to answer those questions.

[00:47:43] So they were involved from the start. Also with the copy, um, so that they understood what the features would be called and could begin providing their support content even before the release went out. And then shortly before the release, um, once that copy was stable and we all agreed between development, design and, um, support teams, um, we would refine that a little bit further and take a look at the localization.

[00:48:09] Um, and now this product, um, was localized into several languages. German was one of them. And, um, of course, Natasha was talking about text expansion earlier, uh, and as, as she said, there are basically, um. Um, sort of average values for each language, uh, where you can expect a certain level of text expansion.

[00:48:27] And that, that figure for German tends to be about 1.3. So German text tends to be about 30% longer than German tech have an English text. And that's something we always need to take into account. Um, so once the feature is released, it goes, public users are aware of this now. Hopefully not too many copy changes are necessary after that because it's very difficult for users to understand if we change the words for things after they start using them.

[00:48:52] But of course, sometimes that's necessary. So there, even after the release happens, sometimes a bit of maintenance is necessary as we realize that users may have different terms for things than we initially thought. So what sort of guidelines do we use during this process? The idea here is not to reinvent the wheel, but to point to existing standards wherever possible.

[00:49:16] So with regard to grammar rules and things like that, we don't need to talk about those ourselves. We just say, which ones do we adhere to? Uh, and these are, this is true for language things, but also from any things related to software and user interfaces. There's already standards for things like that.

[00:49:31] So what we needed to document was more our own choices, our own Dell tests. So in order to do that. We put together a little micro site, uh, that we decided to integrate into our own brand site. Many companies have something like this where they publicly provide information on the proper use of their logo and that you shouldn't place a pizza icon over the logo and it needs a certain amount of breathing room.

[00:49:54] And these are our colors and these are our fonts. And we began to think, why not have that same sort of information for our copy guidelines because this copy, this text and the user interface. Well, we were creating it within the organization. There are people writing about our products who are not inside our organization.

[00:50:15] So we have external agencies writing a PR material, preparing articles, journalists writing about our products. Uh, and so we would like them to use the same terminology and the same sort of tone of voice that we do. Um, so we provided this publicly. And pointed people to this wherever possible. So this brand, um, this micro site contains some information relating to our copy.

[00:50:41] Um, we have tone of voice guidelines they have, which are quite common for many organizations, not always public. Sometimes they're private, but in our case, we chose to share them. Um, we include some writing style issues there. Again, not particular things. That could be found in any other style guide, but for things that are particular to the way we use words, so things like, do we log in or do we sign in?

[00:51:03] Right? Um, we at some point introduced a professional version of the product. Initially it was a, it was a consumer version that was free, but then we introduced a pro version which required billing, right? We have monthly billing people can pay by the year. What do you call it when people pay by the year?

[00:51:20] Is that annual or is it yearly? Things like this, both proper words, which one do we use? Those are the kinds of things that we would document here. We provide some translation resources here as well. Um, so that people are aware of existing conventions, uh, for translation. Uh, not necessarily the way we use things, but the way platforms use things.

[00:51:41] So for example, the English word saved. Um, what's the German for that?

[00:51:48] Try him. Right? Two answers. Which one's right? You're both right. She uses a Mac. That person uses windows. You can tell that time. You can tell that based on the answer, right? So, um, when those localizations decided that, uh, that save was a wish bison, um, that's, uh, decades ago, Apple at some point decided to retain the connotation of safety with safe.

[00:52:16] Right? Your stuff is safe with me. . . Yeah.

[00:52:26] yeah. Right. So proper words. But we need to know which ones to use, and we need to know that for our application because we need to understand the context, right? So as writers, we'd like to be consistent and some of us would like to be consistent everywhere. But if we were to use the exact same words for our application, regardless of platform, we would create a new conflict.

[00:52:47] Because our half of them would not use the same terminology as the platform on which it appears, and that would lead to a great deal of cognitive dissonance and confusion among users. So it's most important that we adhere to platform conventions and our own internal consistency is secondary in that regard.

[00:53:03] That was the approach that we took there, right? So we have some sample usage patterns here, you know, when to. When to use certain words, uh, and user interface references, references in this sense, um, references to works of reference that the platform. Uh, owners have put out. So Apple of course, has very extensive guidelines.

[00:53:25] They've had them for decades document called the human interface guidelines. Um, and they have these format POS, they have them for iOS. And these are, you know, three, 400 page long documents that go into great detail about how elements of the user interface are to be referred. Um, even, you know, down to if you have a series of shortcuts of keyboard combination, which symbol appears in which order?

[00:53:52] Does it, is it shift option command? Does it option command shift? These things have all been decided. We don't need to figure that out. We just need to use the conventions that already exist. And, um, we also put up a glossary here. I'll talk about the last way more in a moment. Um, so that people understand why we use certain words and when we use words a certain way, what we mean.

[00:54:13] Um, so we put this up in public, uh, and we also chose to open source this. So for anyone who's interested in putting together something like this for your own, uh, use, if you like and find any of our stuff helpful, you're welcome to, to fork this repository and use it. Now, of course, you wouldn't want to start talking, start talking about your product, like we talk about ours.

[00:54:32] Um, but you might find it useful as a starting place. So let's look a little bit at, um, terminology. Where does terminology come from? What terms have special meaning? What do users find confusing? What sort of internal jargon and do employees use when they talk about the product? What else should a glossary contain?

[00:54:59] Should we keep references to outdated terms or should a glossary only contain our official words? The ones that we really use. We decided to add the deprecated terms as well to specifically say, don't use this word, use this other one instead. Um, I remember our questions about should we be publishing something like this in public?

[00:55:17] Is this somehow showing our underwear or is it setting a good example? Right? So these are the kinds of things you need to think about when, when collecting terminology. Um. You can start simple. Um, even if you're not entirely sure how to present this, even if you're not sure if it's going to be public yet, um, you can just start drafting a basic spreadsheet and you can do this in Excel or something.

[00:55:38] We chose to use a comma separated values file, um, and version that get hub, get hub displays, things like this quite nicely. Um, so this was our very first round of iteration for the glossary with system, a three column, four column spreadsheet that has a term. A preferred term, some usage notes and perhaps some sample copy around how that might be used.

[00:56:02] And then after iterating on that for a while, where to a point where it's stabilized, and once we had internal sign off on the idea of publishing it in public, um, someone would like to get in the back door, perhaps. Um, we even added that to our public site. Um, so, um. That makes things much easier for people who write about our product from the outside world.

[00:56:24] To reference our terminology there and to understand things like we don't answer calls, we accept them, stuff like that. Um, what I find quite helpful about something like this is if you have rules like this terms within your glossary or other usage guidelines, if you give each of them. Or URL, you can actually point people to these explanations.

[00:56:48] So if a journalist is writing about your product and not quite using the terminology that you'd like them to, you can send them a link and say, here, this is why we prefer to use this word over this word. Or your colleague who keeps using that old code name, send them a link and they will be educated. So that's, that's quite helpful, like in the way that on get hub or something.

[00:57:08] Um, you know, every conversation has a URL in the form of a, of a, of a per request or an issue or something like that, or even a comment in an individual, um, issue thread. Having each of these things, um, directly addressable with the URL makes it much more easy to point people to them. So localization is always an issue when it comes to copy and strings in user interfaces.

[00:57:31] Um, and there are platforms that can help to make this a little bit easier. Um, things like crowding or phrase used to be called phrase app, um, will allow writers and translators to review and update the copy without having to do any coding or understand the source code. They can integrate changes quite easily.

[00:57:51] And the developers can integrate changes quite easily via pull requests or some other automated process. The screenshot, here's an example from Crowden, which was a localization app, a platform that we used at wire, and as the name suggests, crowd and is designed actually for crowdsourcing translations.

[00:58:08] So you can actually publish. In public, your applications code or a copy and allow people in the community to propose translations for that. Now, that doesn't preclude you from reviewing them officially internally and having your own people check to make sure things are okay. But this also allows you, if you like to have an additional numbers of localizations for which perhaps no one at your company even speaks a language.

[00:58:35] I back Mary, of course, present some issues of its own. If there's no one at your company that can vet the Estonian as Estonian translation of your product, does that worry you? We thought about it for a bit and came to the conclusion that the likelihood of someone spending 400 hours to do a complete Hungarian translation of our product that is malicious.

[00:58:59] It's very unlikely, um, because it's a lot of work. Um, so we chose to accept that and we basically chose to say, we have several, and these are the official translations of our products. There are community translations available. We're not entirely sure that they're great, but maybe they will help you to use our product.

[00:59:18] Right? So some of the challenges and issues that we faced, first of all, when you're trying to do this sort of work. Start with a content inventory. This is not particular to UX writing. This is of course, similar for, uh, you know, any sort of web based work or any, uh, any kind of writing task where you have a body of content that you need to align.

[00:59:39] You need to understand what copy and what content exists in order to align it. The copy is everywhere, right? When we talk about UX writing, we're talking about usually microcopy that appears on the user interface, but there's also the website. The blog, some sales and marketing content. Perhaps your company sends out client emails that when something happens in the app, an email is generated to say, here, click this link to reset your password.

[01:00:07] It's not strictly copied that appears within the app, but it's integral to the user interaction process with your product. And so the copy there, of course, should agree with what you use in the app. Um, you may have document templates and other sort of corporate identity documents. Um, that would probably also benefit from being consistent with your product itself.

[01:00:27] Uh, and then then maybe things like documentation, um, uh, API documentation, maybe even a developer portal. Um, ideally, all of this content should be aligned with what appears in the user interface. So how do we ensure that. These things stay in sync. First of all, as I said at the start, one of the main prerequisites for this is to ensure that all of these are facing texts in your app is stored in strings, files, and not hard coded within the source code of your product.

[01:01:00] This will allow you to compare and review at text all at once. A writer can read all of the words that appear in the product at once. And you can use internationalization then to verify your design. So if you have a strings file that has all of your copy, you can do a pseudo translation of that and translate it into jibberish right clicking on or something, and produce a cling on version of your app just to find out which parts of the dialogues will cut off text that is longer than you expected, right?

[01:01:30] You can validate whether you're. Dev ops developers have coded the application in a way to support, um, hi by languages. So does as your application source code even support, uh, Chinese, Japanese, Korean text, maybe they didn't code it in a way to support that. Doing a sort of sweet pseudo translation is a way to find that out so you can even translate into.

[01:01:53] You know, fake Chinese, um, just to see whether things work. Um, so that's a, that's an advantage of, uh, storing texts separately is you can manipulate that text outside, put it back into the product and make sure nothing breaks, include writers early in the process. Uh, as I said during the, the, the overview of the process that we use there, the sooner writers are involved, the sooner we can ensure everyone is on the same page and using the same words for things.

[01:02:23] And like any other sorts of content. One part of the work is creating it, but perhaps the far greater task is maintaining this content over time. So bike for any other kind of content, you'll need to define some sort of governance, governance process for your UI copy. Who owns it? Who maintains it, how will it be changed?

[01:02:44] How will we know when it needs to be changed? Um, one way to ensure that that process stays in sync with development is to align your collaboration flows with the collaboration processes that the developers use. So typically this is some sort of version control. This is some sort of pull request based workflow where as the developers change their source code, there was some trigger in the system that's has, Hey writers, we've changed this bit.

[01:03:10] We need you to look at it again, right? So that, that. As an automated part of the process there so that when something on one of them changes, the other stakeholders are aware that they need to change their bit too. If a developer decides to reduce the size of a field in the user interface, writers need to know that because they may need to change the copy to fit with an initial new constraints, so it needs to be some kind of a flag there that goes up.

[01:03:36] Right. And when it comes to processes, it's important to design your processes for reuse and automation as much as you can, because the last thing you want to be doing is copying and pasting things back and forth, because that's a recipe for disaster. To ensure that things drift over time. So the more automation you have, the more you can make yourselves aware of the things that needs should need to change and allow people to focus on the things that they need to do manually, uh, and let the computers do everything else.

[01:04:07] So the resources that I can kind of skip, because Natasha, I already listed both of these books, which is great. She also, she also took the time to actually put screenshots of them and they're good. I have a physical copy of one of these books. So if you'd like to look at the physical copy of this book, you're welcome to do so.

[01:04:21] Um, I didn't think to bring, um, my copy of, um, of conversational design by Erika hall. I should done that. I don't have a physical copy of toys book, but you're happy to peruse that at some point. Um, so yeah, there's, um, there's more information about this. Um, a lot of people have written, um, a good bit of work on this.

[01:04:38] It's an emerging discipline, so there aren't that many books yet. Um, but the microcopy book here, um. It's quite helpful if you're looking for some very specific examples of like, how do I write copy for empty States, or how do I read the error messages or something like that. That's the sort of thing you'll find here if that's the sort of thing you were hoping to find in my talk.

[01:04:57] I'm sorry, but is there anything else you'd like to know. Thank you, Roger

[01:05:12] They also have a copy of Eric

[01:05:19] Thanks very much. It's amazing

[01:05:28] when it comes to naming things. So I guess you do desktop, iOS user that uses your app on iPhone. It's different. Namings when they use them, vote yes or no. So to repeat the questions are for the benefit of the streaming audience. The question was, um, um. Does the user of an, of this application who uses the, the, the product and multiple platforms, if we defer to the platform, conventions for text have to contend with different phrasing in each version.

[01:06:10] Yes and no. So we try to be as consistent as we can across the platforms wherever possible. But where there is a platform convention. We stick to that platform convention. So for example, when it comes to, let's say, capitalization of buttons, right? There's a button that says, okay button, it says cancel button that says, yes, I really want to do this, whatever.

[01:06:30] On Android, that button would use all caps because the Android style guide says all caps for buttons. On iOS, that same button, we should have the same words, but those words would be entitled case because buttons on iOS use, title case. So it's not always about using different words for things. It's just about deferring to the platform conventions wherever possible.

[01:06:52] So something like, you know, like a saved command, as we said, that's something that kind of comes from the operating system anyway. So that's usually not the kind of copy that we have to write. Um, so wherever possible they're seeing the same thing. But. As a, as a, a user that might have the desktop version and an Android version, they want to see the app in both of those contexts in a way that is not going to disturb them or find that they would not find a surprising, let's say, um, it's perhaps less important.

[01:07:26] That connection between iOS and Android, because not everyone uses both, but there are, and we should be aware of that. Android users that may have an iPad or something like that, so it's entirely possible right.

[01:07:41] Excuse me. space, right?

[01:07:48] The platform also, we mirror that, right? So if you were to look at the settings dialogue, uh, for this application, uh, on Android, you would find the capitalization of each of the options in the settings dialogue, um, will adhere to Androids convention. For those. And on the iOS, the wording would be the same, but the capitalization would differ.

[01:08:10] Because iOS conventions for things like this different. Yeah.

[01:08:17] What about the app itself? Does the features, those things, then of course, that are not operating specific system specific. We can do however we want. So in that sense, it is consistent across the platforms. It's just the certain things that are platform specific. We make sure to adhere to that. Right? Yeah.

[01:08:37] Yeah. Yes.

[01:08:39] Natasha: [01:08:39] So you spoke about differentiating between official and community translation

[01:08:44] Richard: [01:08:44] for your

[01:08:44] Natasha: [01:08:44] official translations. Do you also maintain a glossary or where translators can say, okay.

[01:08:52] Richard: [01:08:52] Yes. Yes. So, um, the, the, the question was, is there a glossary that, uh, is available to translators, um, uh, who, who translate our stuff?

[01:09:02] And the answer is yes and no in the sense that yes, there should be. And yes, we began one, um. It was never completely finished. And it's certainly not as complete as the other ones. We don't have, we don't, we don't, we don't have a translated version of the entire glossary for everything. And the glossary itself is actually quite meager.

[01:09:21] It's, it's, it's just a, it's a start basically. Um, but the, the, the, the, the platform that we use to, um, to, as an interface to the, to the, uh, localization process allows us to augment, um. Uh, the strings with a glossary, so that where a word appears in a text, and if there is a glossary entry for that word, it will be auto suggested.

[01:09:46] And it may be underlined or highlighted in a way with a tool tip where the translator can then mouse over that and see what is meant by that. We can provide screenshots to, to give context for the translators. Um, so, um, yeah, we, we try to do that. Um, . I should probably be fair and say that I've been speaking in present tense.

[01:10:06] Um, I no longer work for this company at the moment. So I've been talking about something that was a project for a very long time in, in, in, in my career. I've since moved on, but I still thought it would be interesting to share this. I don't know exactly whether they still do things exactly this way or whether they too have moved on.

[01:10:21] Um, I just find it, it's, it's, it was a part of me for so long that I still kind of used the present tense so.

[01:10:30] Yeah. One other question. How does your content in country look? Could you explain the detail? Probably not in detail. Maybe just a summary of what I meant by content inventory in that when I'm, when I used that word. Was a rather limited sense of the term. Um, content. Inventory is a very, I'd say, almost loaded term, right?

[01:10:56] There's, there's, there's a notion of a content audit, which is typically the process. The content inventory is typically the. Byproduct of the audit process. So it's an inventory is a deliverable. The audit is the process. Um, when I use that term, what I meant was the process that we went about to figure out which bits of text each platform uses and list them all side by side.

[01:11:20] So that was what I meant by inventory. What is all the texts that the iOS app uses? What is all the texts that the Android app uses? What is all the texts that appears on the desktop application? Place them side by side and look at where they differ and decide. Do they differ for a reason because platform conventions or do they differ?

[01:11:40] Although they should be the same. So that's what I meant by inventory in this particular case is get it side by side somehow so that you can compare it and make choices about whether it's aligned as well as it should be or whether there are differences that are justified. Yeah. What else in the room?

[01:11:59] Okay. I have another one. You mentioned, you mentioned Jonah was assessed as one of the target.

[01:12:08] Because my experiences, journalists don't care, and if they care, they will use your normal style, right? That depends entirely on your relationship to journalists. Right? If you have a sort of hostile relationship with journalists and very critical journalists are writing about your product, of course you're not going to be able to influence them at all.

[01:12:32] Um, if you work with PR agencies who solicit, uh, contributions to major magazines or major publications about your product. To the degree that you have a good relationship with your agency, you may be able to influence that process and your agency may be able to then seed journalists with some information that they may be able to integrate into their review.

[01:12:57] And this isn't about telling them what to write, but journalists generally are quiet. Um. Thankful for input, right? They'll do the work of writing, but if they know more about your product because you give them good information up front, then that increases your chances of them writing about it in the way that you would like them to.

[01:13:19] They may still have an opinion that you don't like, but they'll use the right words in their nasty opinion

[01:13:29] in the chat room,

[01:13:30] Natasha: [01:13:30] in the room.

[01:13:31] Richard: [01:13:31] Yes. Okay. Actually, just one quick question then the answer as well. And should we share the mic

[01:13:41] because a varying degrees provided her with resources. The repository is the templates, the workshops, but how do you hook in, uh, decision makers is a good idea to do it.

[01:14:05] Natasha: [01:14:05] Um, I think for us, uh, we can do, of course, a lot of for Whiteman workshops and we just annoying, we just go and say that you need to have this work and this is how you, it sort of started all over.

[01:14:23] Uh, we were just annoying people and now I only wanted them as well. I think this, there is, there is no other hope. Like when you start, there is only way of starting in a very user centric company that tells you, we have a, let's do this where you, anyway, that's where I feel like it's part of my job.

[01:14:49] Richard: [01:14:49] I can agree with that. I think, um, I think actually many of the people that

[01:14:53] want to.