From Developer to Tech Writer: How AI, Empathy & Localization Shape Modern Documentation

There is a difference between AI that writes and a technical writer that uses AI to write, right? So yeah, so if you use AI purely for creating documentation, then AI does not understand the product the way a human would. It is really important to put real cases or scenarios, practical scenarios for the users to understand. So in every documentation I put real cases or practical scenarios where a user might get stuck and then what they should do, not just click on the save button. Welcome to the Knowledge Based Ninjas podcast where Gauri Ram Kumar of document360 finds the best SaaS self service knowledge bases in the world and then interviews their creators. Let's get started with today's episode. Welcome everyone to the Knowledge Based Ninjas podcast. Today with us we have Ruthwa Safi, senior technical writer with Gauntner. Hi Rudhwa. Welcome to the Knowledge Based Ninjas podcast. How are you doing today? Hello Gauri. Thank you so much for inviting me for the podcast today. And I'm doing pretty well, thank you for asking. How are you doing? All good, all good. So it's all going great on my side and once again thank you for your support in this episode. So before we start with anything, how did you get into this wonderful journey of technical writing? Who was your inspiration or motivation? Can you shed some lights on that please? Yes, sure. Well, it is quite an interesting story, I would say. My career graph has never been linear and it was something I did not plan at all. So I'm an engineer by trade and I started my career as a developer but soon I realized that I do not have any inclination towards coding. So I moved to quality analyst because I did not want to leave the tech industry as I'm always fascinated by technology. And after being a quality analyst, I then moved to business analyst. I just kept on exploring until I find my passion for what I'm doing, until I like my job, what I'm doing. So yeah, that happened for like one year. And meanwhile I started writing, you know, blogs and articles. I created my own website where I used to express my thoughts and opinions. And that's when one of my friend went through my blog and said, hey Ruth, why don't you combine your writing skills with your tech knowledge? And then I said wow, that's a wonderful idea and I would definitely would like to give it a go or you know. So I ended up in content writing and strategy role at an IT industry, at an IT organization. And that's where, you know, I started writing about different technologies, the next gen technologies like Internet of Things, machine learning, AI, virtual and Augmented reality and I quite enjoyed doing that. And then so when I was working for this organization, we had this technical documentation project that came in that was an in house project. So my then tech lead approached me and said, ruthva, why don't you take up this task of technical documentation because you have got the background for this. I thought I have that utility player experience, experience as a developer and quality analyst, so I can look into a complex product and actually know what was happening under the hood. So that's when I realized that I actually kind of, you know, have this ability, this unique ability to understand the heavy engineering logic and translate it into simpler, clearer words or document, putting it on a page in a way that the user who is sitting on the other side of the screen can actually understand it without any confusion. So that's when I recognized my passion for writing and how much I enjoy writing technical documentation. So from then on I stepped into purely technical writing roles and currently I'm pretty happy to be at Cantner and working as a technical writer. So that is pretty fascinating for me. That's a good combination, right? Engineering background with the technical writing capability, correct? Absolutely. That helps a lot to understand from that Persona and then write it so well. It works pretty well. Great. Now I'm going to start straight away with the concept of AI because that's the hot topic now. So AI is rapidly changing the way documentation is created and consumed. You know this very well right now. How do you, as a senior technical writer, how do you see the role of technical writers evolve in this AI era? Well, that is a million dollar question because right now we see that AI is basically changing, you know, the entire industry, like all these industries, pretty fast and it's evolving at a rate that we would not have expected some years back. So I would say that, I would consider, I believe that AI is like a collaborative assistant, you know, with which you can move ahead and continue work, not just make it faster, but efficient. And you know, I hear in my DMs on LinkedIn and a lot of posts, I see people are just afraid, afraid that AI is going to take the job of technical writers. But I believe that is not going to happen in the near future, you see. So there are two sides of a coin, right? Similarly, AI has two sides. I would say that when you start using AI, then it can help you in a lot of things to generate your document in a way that you want to put it out across to different Personas, basically. And that's how AI can be pretty much helpful to You. Because currently what I do is I have this complex scenario. I want to just break it down into something that is pretty clear and useful for the users. Then I just take help of AI and it just does these things in few seconds other than I have to spend an entire day or something like that. So that is there on the other side. Yeah, on the other side I would say AI is something of like if, if I take an example I just read, you know, on LinkedIn there's this person called Carl Isaac, he writes pretty good about AI and all technical documentation. So I read this line which really touched my heart. It says there is a difference between AI that writes and a technical writer that uses AI to write. Right. So yeah, so if you use AI purely for creating documentation, then AI does not understand the product the way a human would. Right. AI would not understand the empathy of a person who is using that product. So imagine someone sitting on the front desk at an airport giving boarding passes to the travelers and the system is broken. Now that person is in a panic situation and frustrated, you know, like that. There will be a queue of people standing for a couple of minutes if the issue is not fixed. So in this scenarios are not understood by AI, it cannot understand the real scenarios, practical scenarios. So there I would say, yeah, they would say that it is really important for humans to step in. And that's where we come into the picture. We understand the edge cases, the real scenarios and we also, like I said, we understand the product pretty well. We have that empathy factor. So all of this combined with AI would definitely help documentation, you know, to move further in the direction that it needs to be. Right? Very well, very well said. So it's always a combination of human in the loop plus the AI, isn't it? Absolutely, absolutely great. So is your documentation for global audience or what's the nature of your current. And tell me about how your documentation process works. Yeah, sure. So, well, starting with your question, yes, we have a global product. So our documentation pretty much touches every country, wherever our customers are in. So that's when we have the role of localization comes into the picture, which I will like to visit again after some time once I explain explain my process. So let's begin with that. So my process documentation process does not begin with just writing. You know, a lot of people would think technical writers just write, so they start their processes with just writing. But no, that's not the case. I start my process by sitting in on the Sprint calls and that's when you get to know about what is happening in the product. You know, what are the features that are being built in the product and what is changing. So that is your first step, where you gather information, you know, you ask questions to the team in those print calls and meetings. That's where the information gathering step begins with. And then after that I myself play around with the product because I believe that it is really important for you to understand in order to understand the product, to play with it. Right. So if you don't consider yourself as a first real user of that product, then I do not think that we can write the documentation properly and clearly for the users. Yes. So that is the next step. Now, now further, I then I start writing the document and that happens along with the development of the product and not after it. Because I believe that documentation is the part of a product, right? So it is not something that you consider it as an afterthought. So I start writing and when I start writing, I loop in my business analysts and product managers to understand the edge cases because I believe that it is really important to put real cases or scenarios, practical scenarios for the users to understand. In every documentation I put real cases or practical scenarios where a user might get stuck and then what they should do, not just click on the save button, but why do you have to click on the save button? What will do when you click it and what will happen if you do not click on that? I simply take an example of a dummy corporate organization and my company basically is in law firm management. So I take an example of thousand lockers in that organization and then link it with the real cases of the user. So this is my process and my process does not end here because a lot of people would, you know, forget about the part where they have to think about information architecture, where they have to think about consistency of the terminologies in the documentation throughout it so the user does not get confused because somewhere you're using some word and the other way you're using something else. So that does not suffice. So that's and, and, and most important, who you are writing for. Because if you consider in SAS businesses generally, it's not one person which is end user who's going to read the document. It would be end user who wants a solution of task versus an IT admin who would like to know how do I configure the whole system versus developer who just wants to integrate the product with the API via the API documentation. You have to understand different Personas and then the whole process becomes complete quickly coming back to the first point, which was localization, As I said, my product is global. So the cherry on the top is from the beginning, you write your documentation in a way that when it will be localized, then it does not forget or leave the context that we are talking about. Because there is a thin line between translation and localization. We are not just translating our documents for the global audience, but we are localizing it, which means we have to take care of the cultural nuances, we have to take care of the tone and concept. Because, for example, you know, there is this phrase called burning platform. First of all, we don't use idioms in documentation, but even if you do, then it's a bad practice. But to give an example, there is this burning platform idiom that we. In English, it means a dire, you know, situation in which you need to act rapidly. But when it is translated to German or Japanese, then it literally means nothing. And that's when you lose your customers. When. Yeah, so because in European market especially, you know, countries like Germany, France, they are pretty much, you know, rigid about their products being there or the documentation being there in the local language. And they would definitely invest in a product which has all documentation. Right. Localized products. So I think that ends the process. The localization part, along with everything else, ends the process of my process of documenting. So that's. Yeah, okay, Very interesting. You shared a very, very interesting perspective on translation versus localization. Now, just circling back to the same topic. What do you think are some of the common mistakes companies make when creating documentation for global aud? Because you got ample experience in creating such contents catering to multiple countries and customers across the globe. What do you think is a common mistake that most companies do when writing contents for such audiences? Yeah, so that's again, a very good point. And to throw some light on that, I would say that organizations are not. First of all, like I said, many organizations, they do not understand the difference between translation and localization. And the first mistake that they start making is when you are creating a document from the beginning, when you know you have a global audience or global customers, then it starts from the beginning. Like when you start writing the documentation, you have to take care of the tone. You have to keep your document pretty simple. So when it is localized or translated in another language, that then it does not change the meaning. Because I would say you have a customer across the globe. And then I would say if you write a document, a good documentation which does not have this gap, then a customer sitting either in Mumbai, Melbourne or Munich, they can all interpret it correctly if you take care of few things. First of all, I would give you an example. Like I said, do not use any idioms because it is very difficult when it is translated to other languages, it loses the meaning. Right. So customers are confused when it is localized. Then another thing is date, time format. So you may see like in Europe and the USA there is this difference of a date. So if you say 0102 2026, so it could either mean 1st of February or it could mean 2nd of January. Now if you do not mention this properly in the document, which time zone are you talking about? Then someone sitting in the USA will think, okay, it is as per my timing. And that basically could really, really, really goof up. You know, things when they are using product. Because sometimes when they have reports that are scheduled right in a product and if they accidentally think that okay, this time zone means my time zone, but it does, in reality it did not, then they may not even get report schedule on the right time. And that could really affect, you know, their business. So these are the things, you know, we really need to take care of along with the cultural nuances. So when the product goes or the documentation, like I said, documentation is part of a product. So when the documentation reaches the customer sitting any in any part of the world, then I think it should be interpreted in the same way like the source document wants to convey it to the user. Right. So yeah, So I would believe that most organization make this mistake of missing out on these points. But if, if it is taken care of from the first step, then the source document itself is pretty strong that even when it is localized, the customer sitting anywhere in the world would interpret it correctly. Very good. Very, very, very well said. And yeah, I think that's one of the common challenges we do often hear when we have documentation serving multiple multilingual audiences, how to set the context or preserve the context even when your contents are being translated. Yeah. Yes. So moving on to the rapid fire round questions, any useful documentation resources you could recommend to us? Yes, definitely. So I follow this conference's write the docs and GC world which are really good. And then there is there are a few personalities on LinkedIn. One I said Carl Isaac, he writes really good about documentation, technical writing and shares some tips and tricks. And you might have heard of quite common, you know Tom Johnson, his name is quite common. I also see a lot of people following him. So that is quite good. Apart from that podcast, I definitely watch all of your podcasts because quite insightful. Yes. And then There is this, the Not Boring Tech Writer podcast which is also really good. So I also follow them and yeah, these are the resources I would definitely recommend to everybody to go through for enhancing their knowledge. Thank you. That's. That means a lot to us personally and and also to other authors you've just mentioned. And now one question is one word that comes to your mind when you hear documentation. Foundation. Because I think documentation is the foundation of a product. It is like an invisible infrastructure of structure, standards and tools that we use for documentation to make it more reliable and to make it more clear for the audience, global audience, to understand Foundation. They always say lay the foundation very strong. So that is definitely true. Yeah. Last question for the day is a piece of advice you would give to your 20 year old self. A piece of advice I would give to my 20 year old self is keep learning, keep exploring and do not be afraid. Especially in the initial phase of your professional career or your journey. Because unless and until you don't get into the roles you know that you are exploring, you won't be able to think from their perspective. Like being a developer. Do not be afraid to be a developer. Do not be afraid to be a quality analyst and a business analyst. Because all of this will give you the mindset that you need as a technical writer to put everything clearly for different Personas. So I would say just keep going, do not be afraid. It is a part of your journey and just utilize it. That's all. Fantastic. Surudhua, thank you so much for sharing all your thoughts and your great amazing journey with us. And before we say bye to our audiences, anything else I missed to ask you today. I think you pretty much covered everything. All I wanted to say to the audience is just focus on how you can use the AI technology as a friend, as a collaborative support and do not be afraid that it is going to replace us. That is not going to happen. So I would like to convey that message. Yeah, that's great. Yeah, that that message is needed a lot these days. So thank you for bringing that topic again and all the very best for your future and for number of documents you're going to produce to serve your customers as well. So all the very best for your projects. Take care. Thank you. Thank you so much. Gauri. Take care. Thank you for inviting. Thanks for listening to today's episode of the Knowledge Based Ninjas podcast. Please head to itunes rate and provide honest feedback on the podcast. See you next week.