Mariana, I'm curious. Tell me about the last time you had to fix product copy. On a website. Yeah, absolutely. So the picture for me. Yeah, I mostly work on web applications. And the last time that we did we started actually kind of noticing inconsistencies, right? Whenever we are you know, acquiring a, a set of ui or product pieces, right? And you are noticing inconsistencies and you're maturing as a design team, right? Or you in our, in our case, we're getting ready also to translate all our all our copy in our interfaces. And that it came about right as a business to translate of a design need to be consistent and and just the fact that you know, our internal audits were showing that it wasn't consistent, right? So what a great opportunity to just mix everything together. So we started the problems together. So we started with, auditing, right? What we had in terms of many things, right? Auditing, in terms of lowercase and writing style guides. Or including it's type of voice, right? The voice that we have in the product. And so we created a whole audit to identify some issues. And at the same time, we got to pair up with the brand team, right? Who was also in charge of websites per se, where they would talk about our company. And understand what's the style, right? That it's been established over there, right? The style that goes is very visible to all sorts of prospects and customers. And in between that process of auditing the product experience, understanding what is in terms of writing style guides and voice on the other website. Then we decided, right, that we needed to establish a style guide before we could move forward with any translations. We needed to fix what was there. And so that's kind of where the journey of, like, most recent, like, where copy kind of came to a head of, like, how important it is for the user experience, and at the same time, a critical aspect in order to get a very important business imperative, which is translated, translate our, our our interfaces so that we could go into new markets, right? Europe over that time. So how how, when did this happen? Was this this week? Was it this month, quarter? Like how long ago did this process? Yeah, this happened. I want to say almost like a more than a year ago, for sure. More than a year ago, like a year and a half ago, we did that and we were preparing to and Acquire more customers in Latin America. And so we needed to have our, our, our interfaces ready for the personas who use them in Spanish and in Portuguese. And yeah. Got it. Yeah. So a year ago, you know, this, you were sitting at your desk and these inconsistencies were brought up. How, how did someone even discover this? If you even remember what happened maybe a year ago, I know that's been a while. Yeah, absolutely. So it was more of a design exercise. It was looking at what we had and understanding that we had more designers than ever, right? Creating input for the product. And kind of noticing through internal audits. Heuristic reviews are a good way that we use to understand this and see the inconsistencies from there. Right? And this is all in preparation, right? This is not even even thinking yet of are we using the right words that are translatable to other languages, right? Are we aligned with the voice with a particular personality or voice in our products? That we can extend to, to other languages as well, right? This is just us auditing, noticing the influx on designers that we had kind of gave it away as well, right? Because everyone was, how do I write this? And how come we have now five different ways to sustain the same error, right? Just depending on where it got implemented in our product experience. So it was becoming, becoming very evident. But heuristic evaluation was one of the ways that we saw it. And then the other way is that we just downloaded all the code and we got into the JSON files and we notice like now you can see everything right without necessarily waiting on different experiences. When you search your content, then you kind of know that you can see the inconsistencies right away. So you downloaded the JSON, but what even triggered any of this to happen? Like, was there some sort of a I don't know, I'm just, did a customer bring it up to you? Hey, you said this in one place and this other thing in another place, or just someone? Did someone just notice it? And even if someone just noticed it internally, there are problems sort of around us all the time. Why was this a problem worth solving? Like, why, what's the severity? What, like, what's the worst that would happen if say you use one word here and a different word there? Like, what's the worst that would happen? Absolutely. So this was mostly noticed internally. Okay. I think we're very proud of our product, right? And even engineering, right? Like it wasn't only the designers, like engineering engineering and designers were just like seeing it. Right. I think it was evident when when basically we're doing QA reviews, right. And it just comes up. So really the first time where we really noticed, like, we have to do something about it. Is because of this internal discovery thankfully, it didn't really come from the customer because that would be like a little like, oh, no, if if they're noticing, and we are oblivious about it, then that's a real issue. So, thankfully, it was the other way around. Now why did this come to a head? What was so important? It was because of the need to translate. Translations can be expensive. Translations can be very manual and time consuming to make sure the quality of it is there and that you're actually able, right, to communicate the same and make an intuitive experience in another language, right? And so that's really why it was so important to make sure that we're not translating text that was incorrect. Or that we had five translations when of the same situation in the USA experience when you should have had one, right? It's just made it more costly and more time consuming to make sure the quality was there. Well, that's interesting. So the trigger was this expansion project. You mentioned Latam. So the trigger was needing to get the website in Spanish, Portuguese, let's say, and that being expensive. Is there an example you remember of maybe the same thing being said in two ways and why translation is now expensive as a result of that? Absolutely. So when it comes to translations, you want to be very consistent because Because first, you have to make sure that the translators understand your product and, and when you have things that in English, we might like mix words for the same thing in software, right? We software for some of that but when it comes to kind of understand and having a translator understand your, yeah, your Your product right in order to be able to help you in these languages that you don't know anything about. You have to make sure that the consistency is there. The other examples that you can see is, for example, let's say we called. refer to our own product in different ways. That was a real example, right? Where you say, Oh, we have you know, we use console a lot in software, right? So you have X console and the console for this and this. And so it's the same thing that you're saying in three different ways. And so that makes it hard to make a consistent translation that is learnable, right? Across different languages. The other aspects were things like sometimes very playful. With our language and we say, and let's say there's a message for an error and the message says. Oops, right? Something like that, right? Oops we've encountered an error. Please wait, right? But if you have the same, the same exact situation where it's like a system error, for example, in that in that case, and you have three different messages of the same thing. Then that becomes like that, that costs and that is not cost efficient. It's not time efficient for quality. Plus, you know, it really can confuse folks, right? If you're seeing three different errors, it's really hard for me to then call support or ask for help when, when the errors is, is explained in three different ways. So those are kind of the examples that we would find when we translate, for example, there's a, there's some terms that shouldn't be translated, right? Because those are the names of your product, for example, or there are certain industry specific things that just, there's no other word. So you have to keep it to the industry specific so the user know what it's about. And sometimes that means that if, even if you're translating in English to Spanish or to Portuguese in our case, the, the The word needs to be consistent, even if it's in English. It's actually the correct way to talk about it in most languages. And so you had to identify that too. So if in your, if in your content, you don't have identify, you don't have that consistency, then again, you lose meaning in other languages, right? That's, that's some of the examples. Got it. No, that's, I love it. So some words I think what stuck with me there was the translator needs to understand the product. And easier, what makes it harder for them to understand the product is if that product's been described in multiple different ways, you know, it becomes even harder for the translator to sort of get the tone and style over. So that makes sense. What surprised me is that you haven't had to visit this a since a year now. So help me understand what, help me understand what happened next. So you you did the, you had to translate the website, you did the audit, you found variations in the way a console had been mentioned. What, what happened next? How did you fix this? Yeah, absolutely. So in order to we needed to play some rules. I'm sorry, I'm making you recall stuff from a year ago. No, no worries. We, we basically had had to place rules right to in order for the content coming in the future to align right to the style guide, to the voice, to the tone, et cetera. And so one of the things that even before translations, we actually set down. And created that style guide and we tested that style guide right with old text and even the new designs that were being built at the same time that this process was happening. And so in order to to really make sure that I didn't have to revisit this this topic every year. It's essentially kind of establish the rules, right? And in our design quality and assessments and all, all the designers, right, still have to follow that style guide. And if there's any changes that happen, it has to trickle down to the content that is existing. And so that's, that's really kind of putting rules behind it, making it consistent moving forward and also making sure it scales. So thankfully, like we have, we have been testing actually once we. Once we trust updated all the content before any translation, we needed to update all the content. We tested it. We ran user testing, we ran it internally as well to make sure that, you know, it, it resonated and, and it was, you know, it was good for some time. And so before then, then came the translations, right? So that kind of gave us kind of that, that check in. And so in reality, our style guide in the company hasn't changed from the website, from the kind of marketing side. Hasn't changed on the product side either. We constantly kind of check on those with our own heuristics just to just to see and in our testing and consistently, right? The designers just have been able to add to it rather than go on kind of different directions. So yeah, so I haven't had to revisit it. What can happen in the future is there's always some rumblings of. Adding new languages, adding new languages sometimes that are way more complex than, than what we did before. And so those are also opportunities where we can say, okay, well, now we have the style guide, can we make sure, right, that it continues scaling to those, you know, countries and those contexts that we are trying to go. And that could be another opportunity to check everything, right, and make sure that it does still scale and it's all up to date. But that hasn't, opportunity hasn't, hasn't arised yet. Right. I see. So got it. So you came up with a style guide as a solution for that problem. And how did that happen? Like, did you just sit down, look at that JSON that you mentioned, see that it was called console in one place, dashboard in a different place? And, and a third thing in a third place. Mm-Hmm, And in the style guide, did you basically what help visualize that for me quickly, if it's even possible. Yeah. Would you say only use the word console and don't use the word dashboard? Or is that how that works? That's a lot of it. So there is a, there is a stag style guide on the marketing side, and part of it was evaluate that one and sit down with marketing and understand it and be like, okay, what. What of that translates to product? What of that needs to be either one to one with our product or where is it that there's some some freedom in the product side, right? Based on the person that we serve on that side to maybe the tone which is it? I think it's the voice, I think it's consistent, but the tone can change based on, on the context. So we, we established that even with, with marketing. Okay. So where is it that we can, you know, the opportunities for the product. And if you look at the style guide, essentially is a set of hey think about the tone in a particular way, right? Like, is this, this is basically humanizing the voice would be like, these are the characteristics of how we should speak. And there's also instructions on what to do and what not to do, right? So, for example, if instead of saying, Oops this happened, right? There's another alternative, right? And so we gotta give definitely some examples of do's and don'ts. And then in terms of the of the content that shouldn't be there, right? Like you gave an example, that's actually a real example. We had dash for some places and console the other places, but the correct way, let's say it was console. And so in, in our process, we also kind of make sure that to list those right things not to use things to use. But it's very often you can imagine it's very manual. And then the other aspect was once we got into our translation provider, as part of the process of operationalizing that translations, we had to make a list of D& D do not translate. Wording, right, and that wording consistently across the board, then that would be a way to kind of catch it automatically so that we didn't like translate console to consola, right. For example, in Spanish. That's it. So the so the style guide became your source of truth and where did this live? Like was this literally a Word document or? It wasn't a Word document, but it's in our wiki. It's a page in our wiki. And anyone in the company can find it, right? Especially when it comes to comparing one, one like an interface from the marketing side. You can find both style guides. And it's very visual as well. You know, it's like red and green when what you should do, we should don't. Right. And it's a way to make it sure it's learnable and, and memorable for the designers using it. Mostly the designers using it, but. The front end team is knowledgeable about it. So when we put that out there, especially in the process of QA, the front end team is very knowledgeable about it because they had to clean up all the code for us right. Like find a substitute for the correct wording. And also the PMs it's like, Hey, this is what's behind our design. So it is a style guide. So whenever you're looking in the quality of our products, right. If you catch certain things like that, so they needed to understand that as well. But yeah, it lives in our wiki so the whole company can see it. And so since that time, when you did the audit a year ago and came up with the wiki that now everyone went either in Figma and putting a page together or front end developers writing code. That's the wiki that they're referencing as they put copy down. Absolutely. And in reality, it comes pretty natural nowadays. Whenever we're reviewing, we know where to cap and where to not cap, right? We know that we have these type of errors. The front end library already contains the error. So we don't have to create a new error for the same situation. We just, in the design, we spec out this type of error and it maps to To the content that front end already has for those situations. And that way we're not kind of committing the same errors as before, right? We're reinventing everything, but it definitely is an exercise of pattern matching, right? As, as much as it is the libraries we use and the buttons we use, right. And then how that becomes a pattern and design language also does, right. And content also does. Interesting. So when you I thought I heard something that you said that sounded cool. I want to just clarify, confirm. Are you saying that front, the front end code has a built in error checker? So if someone were to write dashboard, it would highlight it now? No, that sounds awesome. It doesn't really have that. That sounds great, right? That's a great product opportunity, but no, it's in the, it's in the way that we map. Errors that they have right in the front end to the ones that are coming in the design, right? Any design needs to account end to end, right? For, for errors. And so we're not kind of inventing a new error, which was happening. It was happening a lot. We have so many errors and so many ways to, to do, to express those in the so, so essentially that's what I'm saying. How do you know errors haven't crept in? So you've put, so there was a, there was an issue, you put a fix in place, the style guide. How do you know that that now is working flawlessly, as it should, yeah, as it should. Yeah, that's a great question. So in terms of applying our style guide to our designs. It's the designer's job and design process patch it up in critique, patch it in design reviews, right, and at the last minute, catch it right during QA. So no, a few things slip in, right from time to time and it's definitely in, in critique, I catch a lot of it. It's like, ah, this is, this is capped or you know, situations like that, right? So no, we don't have a flawless way to keep it going, right? It has very much. Kind of embedded in our review cycles in your example, Mariana, the language translation one and the trigger for it. It seemed like the severity wasn't that high. And maybe I'm And when I say that I've heard that sometimes that could be legal issues, say with wrong copy. That seems to me like a bigger issue than someone internally finding an inconsistency in the way something was said, and maybe a slightly off stone website in different language. Has there been instances in your experience where there's been higher severity issues for acquiring copy to be consistent? Because if, say, with this fix in place, things are still slipping through. Would worse things happen or, or is this the extent of it? Like maybe there's a website in Portuguese that's, that's got like consola in it. And someone says, Hey, what's consola? And you're like, I'll fix it. And you go and fix it a console and you're done. Yeah, no, that definitely from our industry point of view we don't have the situations where let's say for accessibility purposes, right. If we were serving if we were serving public that needed. B should be an inaccessible way or yeah, legal content of sort. We don't have those situations, right? Not in the product experience, right? The rest of the company does have You mean you don't have those extremes, like the high severity situations? Yeah, got it. Just the example that you said right now, it has happened where it's like, Oh, this customer noticed that this word is translated oddly. Oh, no, never mind. Let me fix that, right? Let me fix that, got it. And that's the extent of it. I see. That doesn't sound too bad then, like, you've got a nice fix in place and yeah, maybe every now and then something slips, but that's kind of the extent of it. Absolutely. Absolutely. There's other parts of the company that does, but do also have to translate like our contracts are, I believe there are some parts of the contractual process that are translated. And in marketing, of course, we have terms of service that are translated, right, as well. So, so there, there must be some nuances there, right? Especially when it comes to if you're translated in a particular Spanish, it might not be the correct translations for, let's say, Mexico versus the ones that you would do for Spain. But that's gonna, that's the biggest thing that in, in, in the marketing or in the legal side of our company, that is where that happens in terms of the user experience, because we like our metrics really are satisfaction effort, right? So make sure that's easy to use. And so we actually don't have a lot of that, right? Our, our, our style guide and our content is pretty streamlined so that it fits in, in, in those usability Constraints, yeah. Like, dumb question. Now, these other sites in these other languages, Spanish and Portuguese, how do you know that there aren't inconsistencies? in those languages themselves? Sure. Absolutely. No, that's a great question. Doesn't this problem compound now at the more, we're on the topic of translation because that was your trigger the last time for doing the static audit. Great. Now we're past the translation problem. You've got your sites in their own languages and now you've got, say, designers who understand those languages. Maintaining those pages. Now, haven't you just tripled the problem because now you've got three languages, English, Spanish, and Portuguese? Absolutely. You are absolutely right. So, what we do in this situation is, you know, our provider translation provider, Okay. Add services, right? To automate translations and also do manual translations. That's why I mentioned it's so important that our, your translator understands your product.'cause if not, they can't help catch those. Right? Aside from like a dictionary, so what we provide, the translators are a dictionary about what all it means in a product terms not to translate, as I mentioned before. And they actually also have access source style guide. And so with those three, right, basically, we do trust, right, our translators in that sense that they can help the QA, right, end to end of our, of our products in those other languages. Thankfully in our company, we have people who are Spanish speaking. Including myself in, in the different languages sorry, in different countries that we are in, and also Port, Portuguese, particularly in Brazil, because that's, that's our LATAM, right? We don't actually have qualified our Portuguese translations for Port Portugal, right? So that's also another layer that we add. So in our process, we had internal reviewers, aside from the ones provided by the, by the third party. We had our own committee that I, I basically early on showed the translations and they played around with it and they told me this doesn't work, this is not the right one. And we had like different opinions between the small group and then we concluded that no, that's the right one for, for our industry, for the market. And so that's how, right, again, very manual, but, but those layers of reviews and quality is what keeps us. you know, in confidence, right? That is still working within, within the constraints of the style guide or, or, you know, with the parameters that we set there. Interesting. No, this has been hugely informative. We have like four minutes here. I wanted to change the topic just a little bit to understand when was the last time, Mariana, that you introduced new tooling? into your team. And how could you just go in and swipe a card and introduce that tooling? Did you have to go ask someone else? How does it, how does it work with your team? Absolutely. Well, it was as recent as the second half of last year in 2023. We actually introduced three, I think it was two, at least two or three different ones. We changed providers for some of them and, and then another provider was added. Right to our tooling. No, I don't get to swag cards. Nowadays, with the size of the company, I don't get to do that anymore. I used to, but not not anymore. And so what we do to acquire any services, we make a business case, right? And why we need it. If we already have it in the business case can be reviewed rather than start from zero. But essentially, we do some due diligence, right? We make sure to understand the need. And we go through providers and we review it. Do not only demos and calls of such right. We try to do some POC or some kind of trial. If we can we actually it's not if we can. It's like we it's almost like a must. We need to try it out. Right. So that's what we try to do. And of course, like our typical, you know, sponsor for this will already kind of be on board. That means okay to to evaluate new new solutions, different triggers for it. It could be that we are having issues with the you. With the service, it's not getting us to what we need. And so the trigger would be, we need to find a substitution. Rarely is the case that is about the price at this time or the recent ones, but in other occasions has been about. Price, right? And lowering costs. But what we did most recently was acquired a user research platform to gather all the data and to create all the testings. And then we changed providers for in app messaging because it wasn't working for us to survey around CSAT and other types of in app surveys and messaging. And so yeah, basically that's kind of the summary of it. Yeah. We do the end to end. So, but if it's a free tool, you're able to try it out yourself, maybe quickly install it, just give it a spin. And maybe that's how you come up with the business case, yeah. Business trial, business trials that are, are free are very helpful, right? We quickly can determine if it's it's going to work or not. And so, yeah, I think that's a very important part of, of, yeah, of our journey to find out. One last question. One minute ago, just one more question. This has been hugely informative, Mariana. So thanks a ton for walking me through that awesome translation kind of a journey that where do you even discover? So what are the websites you're browsing and where are you discovering new user research platforms and in app messaging tools? Where are you even discovering this stuff? How do they appeal to your data? Different ways. We've had leaders in different service, we've had leaders recommend it. It's like, Hey, I saw this in the news. Can you check it out? The other way is a whole team. Our whole team kind of goes out and, you know, research do some research and sometimes it's LinkedIn or sometimes it's just the, the great Google search that allows us to find all of the, and then we compare, right? On G2, you know, what's, what's this good for? What's that in comparison to this and that, right?