Technical Writing: Getting Started

1. Introduction: So hello everybody and welcome to this introductory course to technical writing. My name is Kat. I'm a German writers specialized and UX writing, copywriting and technical writing. So basically, all forms of writing that are concerned with presenting information, explaining inflammation, and giving readers the instructions that they need to perform a certain task. I'm very happy to see you here because that means that you are interested in technical writing, which is a great discipline because it helps people to understand and use technology in a safer and more efficient way. So this is a beginner's course. So what can you expect to learn? Here? Basically, I will show you the most important principles and concepts and rules of technical writing, which of course includes the formal definition of technical writing. It will include the quality criteria for technical writing that will help you to tell good writing realm, not so good writing. We will also talk about the writing process and its single steps. And we will talk about the most important skills a technical writer it needs in order to perform the tasks of the single steps. So this course is probably best suited for writers who would like to get to know the field of technical writing. It is also well suited for managers and engineers who need to perform technical writing tasks in their everyday life and would like to know about the underlying concepts of technical writing. And of course, it is suited for everybody who is just interested in technical writing. So one final remark before I leave you with the course. Please give him, keep in mind that writing, no matter the exact discipline is all about practice. So I would kindly invite you to do all the exercises that I put together in this course. Drone, draw away from them but rho yourself into them and enjoy them. And I will promise that you will get a very good impression of what technical writing is. So that being said, I wish you lots and lots of fun and a great time learning. See you then. 2. What is Technical Writing?: So I would like to welcome you to the first lesson of this course. And as I said, this is a beginner's course and we will talk about the very basics of technical writing. This course is the perfect choice for you if you want to get a structure at all of you of the topic, or if you want to get started with the discipline of technical writing. So if you're ready, let's do this. As I said, it's a beginner's course and that means we have to start with the most important question. What is technical writing and what exactly do we mean when we speak about technical writing? And let me tell you, this is an especially crucial question to answer for the field of technical writing, because this field has changed a lot throughout the last couple of years. On the one hand, I hear many people talking about certain pieces of writing, calling it strategic writing, customer writing, even UX Writing when what they actually mean is technical writing. And on the other hand, I, for example, ask participants of my workshops to name just some examples for technical writing and they can't come up with any classic technical writing document. So let's get something straight here and start with this question. What is technical writing? Like many other disciplines, there are several definitions for technical writing. This right here is a classic standard definition that you will find in many, many courses and textbooks. It says, technical writing is the practice of documenting processes such as software manuals or instructional materials. So this is practically the second slide of this presentation and I already have a question for you. Take a second and think about this. Without me telling you anything more about technical writing. Do you think that's enough? Does it hit the nail on the head for you? Let your intuition or prior knowledge come up with an answer. I'll give you a second and then I'll tell you my answer. So this is my answer. Absolutely not. Since you will probably come across this definition a lot when you go ahead and dive deeper into the field of technical writing, I want to put it into context for you. This is a standard definition of technical writing that has been established some years ago. It has actually kind of outdated. 30, 20 or even 10 years ago technical writing was understood as a niche and writing a niche that was responsible for explaining very complex technical things to a very, very small target group. However, times have changed and on the one hand, technology makes its way into our lives. And as it reaches every part of our lives, our professional lives, our private lives, the way we meet new people, the way we learn and we study, the way we cook. Just like so many parts of our life. It means that most of us have to engage with technology on a daily basis, which forces us to learn about new technology and its features regularly. And as all of us are challenged to engage with technology that has completely or partially unknown or new to us. We need technical writing that helps us understand and use this new technology effectively. And on the other hand, as the field of technical writing advances and grows and becomes more defined, we understand that some forms of writing are actually technical writing. So in order to get a little closer to an appropriate definition of what technical writing is, let's take a quick look at some forms of technical writing. As we've learned, user manuals are a typical example of technical writing, just like lab reports in which weeks plane, for example, how we set up and conduct lab experiments helping other people to understand what we did and how we exactly did it. We got package inserts which are often categorized as medical writing, but they are actually a form of technical writing. Just like Dissertations and study works in technology and engineering disciplines that explore and explain technical systems. And same goals for journal articles. We got pitches in which we tried to convince someone of the functioning and the benefits of a certain technical system or procedure. We got research proposals and engineering and science fields, which are also a form of technical writing. We got brochures and products backs, which also explain the technical facts of certain technical systems. And of course, we got style gods which give instructions on how to use, for example, certain design elements. And of course, there are far more examples for technical writing like training instructions or onboarding material, manuals. And as you see, they go far beyond the forest definition. So the Society for Technical Communication came up with a new and more accurate definition of technical writing. And it says, technical writing is any form of communication that communicates about technical or specialized topics. Communicates by using technology and provides instructions about how to do something. And as you see, this definition is far broader. It does not only include Britain inflammation, which is very interesting, but speaks of communication in general, which this is very interesting, crucial because as we all know that there are also audio and video material that give instructions or explains technical systems and procedures to us. It is important for us to understand that the term technical writing does not define a way of writing. It describes a way of communicating certain kinds of information to a certain kind of audience for a certain kind of purpose. So this is the definition we will be working with, the definition that our understanding of technical writing is based on. And as I said, it is very broad, so it applies to many forms of communication. As you have seen the examples that I showed to you, they are very different from each other. For example, the lab reports seemed to be very different from a pitch or a sales brochure. So let's take a look at the typical characteristics that all forms of technical writing share. So first of all, technical writing documents help users to solve a problem. For example, it is Monday morning, you are in your kitchen. You need to brew a cup of hot fresh coffee. And you've got yourself a new coffee machine on the weekend, but you have no idea how to use it. Now this is your problem and the user manual is supposed to help you solve that problem. Second, they address a specific audience. This coffee machine user manual addresses the users of the coffee machine, not the people who sell this machine and not the people who are repaired this machine. And last but not least, they use layout and structure to increase readability. Now, the last aspect might appear a little strange here, but let me explain. Unlike many other forms of written communication like block writing, creative writing, or even academic writing. Technical writing is not necessarily a linear stream of storytelling, but it is a composition of chunks of texts that explain single steps of her procedure or single parts of a system. And the overall document should be designed in a way that allows readers to understand the information architecture of it, to navigate through it, flip through it, and find the information they need. So readability and usability are super important factors and technical writing. And I promise we will dive deeper into this aspect in another section of this course. So now we know what technical writing is and we understand what different forms of technical writing have in common. Now, let's move a little forward. Let's try to further enhance our understanding of technical writing by taking a close look at what it can do for us. Well, first of all, it helps us making well-informed decisions because it describes and explains technical systems and procedures to us, which helps us, for example, to decide whether or not to invest in certain machinery. It reduces risks and prevents accidents because it tells us how to use a certain product or apply certain procedure and warns us about the dangers of use along the way. And now this is very important. Doing a good job with your technical writing and actually save you money. Because if you provide grade onboarding instructions for your product, a perfect user manual grade FAQ sections. And then this will actually reduce support requests. And as we know, users calling your support hotline in order to request individual help with their problems can cause your organization high costs. Of course, if we're talking about a product context, great technical writing will also help users to understand the features of your product, which will help them benefitting from this features, which again allows them to review, rate and recommend your product correctly. Technical writing also enhances the quality of your technical system or procedure a product, because it helps other people to understand it. And then other people can build upon that on the standing and further improved that procedure, a product. And this is kind of related. It pushes scientific progress by helping us comprehend technical processes and systems. This applies, especially of course, to lab reports, research reports, dissertations, and so on. So forms of writing that explain the functioning of a procedure or system. So others can use that understanding, ask their own questions, and explore these procedures further, for example, by applying them in another contexts. So a lot of ways in which technical writing can be helpful. And this is also somewhat innovation for you to keep going with diving into this exciting field because it really does a great job in supporting users, managers, and researchers and many other kinds of target groups. Well, now that we're about to finish this first section, congratulations if you've stuck around this long because it means that you have already gained a certain understanding of what technical writing actually is. So I would like to finish this section with an exercise, just a little one that will help you reflect on what we just learned. So I would kindly ask you to take a moment and ask yourself, can you think of a technical writing document that has made your life easier lately? As I said, it can be the user manual to your coffee machine. It can be a YouTube tutorial on how to use certain software. Are, it can be a style guide that you might have applied in your job as a designer. Take your time, think about it, and then I'll see you in the next session of this course. 3. Some Common Misconceptions: So welcome to the second section of this course, the second lesson of this class, probably one of my favorites. You remember when the first section we were taking a look at a definition of technical writing that does not seem quite adequate anymore. It has helped us to understand that the field of technical writing has evolved over time. And that against common belief, the definition of technical writing NAS not only comprise manuals and user instructions. The second lesson of this class is supposed to deepen our understanding by once again turning to those common beliefs that many people have about technical writing, but which are not true. So we will be talking about some common misconceptions about technical writing. And I promise this will not only teach us even more about technical writing, it will also be great fun. So let's get started. One of the most common misconceptions about technical writing is any engineer can just do it. This is also why in many organizations, it is the engineers who do the technical writing because people think, hey, you built this thing. So it should be quite easy for you just to write down what you know about that product or process or procedure or whatever. Just do it and a few extra hours we give you here and there and then get us some writing done. However, technical writing requires more knowledge than just product knowledge. For example, it requires knowledge about the target audience, audience, and it requires lots of skills that are not an essential part of a typical engineer's professional profile, such as qualitative research skills and writing skills. But we will learn this throughout the rest of this class where we dive deeper into what actually makes a great technical writer. So this is one misconception. Just let the engineer's do it. They will intuitively know how to do technical writing because they are technical experts. This right here is another one. Any writer can just do it. Because technical writing is writing, right? And since it is also about combining words in the correct, incoherent, prom, comprehensible manner. It can't be too different from other forms of writing, right? Well, many people think that technical writing is called technical writing because it means that we write about technical stuff. But this is not the case. Technical writing, a certain form of communication, following a certain procedure, a certain pattern. And it has its own quality criteria, which in some ways differ from quality criteria in other fields of writing. So it is not just like you can ask your marketing writer to do technical writing and they just know how to do it because they are writers. Just like engineers. Writers are also well advice to make sure they got the knowledge and the skills it takes to do technical writing properly. Which takes me to the next slide. Because another common misconception is. Technical writing is writing. Don't get me wrong. Of course, it is a form of writing, but writing is only a small part of producing technical writing. Other parts are finding your way into understanding the product or process you are going to write about or understanding your audiences needs, experience, contexts of use, and so on. So if you think that for technical writing, you just sit down and explain a product or process to an audience and written form, then that is a misconception. Even when you think you already know enough about your target audience or about the product, you are going to write about. The last part of the lightest part of technical writing is actually research, testing, communicating, and editing. Let's head over to the last misconception I want to discuss with you today. And this may be kind of a harsh truth to many of us, even though deep down inside we all know it's true. A common misconception is people will want to read your writing. I see a lot of technical documents, especially style guides, which are written in a funny manner, using emojis to make the document more enjoyable, even using inside jokes off the designers or developers community. I feel it. But keep in mind in the field of journalism and blogging or creative writing and even in nonfiction writing, readers consult your writing because they have a certain interest in the topic, and especially in creative writing, readers will even read your writing for entertainment. This is not the case for technical writing. Technical writing is usually consultants when people need to solve a problem and they want to solve that problem efficiently. They don't want to read metaphors that hit the nail on the head or brilliant puns. They want to quickly scan your product or your document for the specific piece of information they need in a specific situation. This is why many writers have a really hard time finding their way into technical writing because most of the time it is all about efficiency. Now, let's start from here and ask ourselves the question, what does all that mean for us? Well, it means technical writing must be user-friendly. It is not about the engineer's just jotting down their knowledge. It is not about the writers just putting their writing skills to work. It is all about the needs of your documents readers, and it's all about translating the functioning of a product or process for them in the comprehensible and efficient manner. So your technical writing should be user-friendly. But what exactly does that mean? In the context of technical writing? What does it mean? I think you already got a little bit of an idea, but let's dive deeper into answering this question in the next section of this course. 4. What Is Good Technical Writing?: So welcome to the third lesson of this class. We will talk about quality criteria, what is good technical writing? This chapter will actually help you a lot and deciding whether your technical writing is already super good or is still need some improvement. And it will help you to check your writing in a structured way. But if you're completely new to the field, you know this is the Beginners Course. Then it will also give you a brief overview of what technical rising writing is actually all about. So let's go. I will introduce to you the six main quality criteria that we will be working with. There are other sets of quality criteria that may differ from this one slightly, but overall, they are basically all the same. So this is the one that I worked with and that has proven very valuable to me in my writing practice. So first of all, the information in your document should be correct. Your document should be complete. It should be easily usable for your target audience. Your writing should be clear. It should be concise, and your writing, as well as your documents should be consistent. Now, let's dive a little deeper into what these quality criteria actually mean and how exactly they ensure the quality of your writing. Let's start with the first one. Your writing should be correct. Of course, this is kind of a no-brainer, but what exactly are we talking about here? Of course, make sure that all the information you give are correct. That means you have to fully understand the product or process you are writing about. And if you're writing involves the explaining of a certain chemical reaction or a mechanical principle or physical law, makes sure you got that right. The second is, all information should be honest. So don't attribute any features to a product that this product actually does not have. Be honest about the risks and dangers of using it. And be honest about common mistakes that are made when the product or procedure is put into practice. Of course, check your grammar, spelling, punctuation, especially because sometimes technical writing documents or official documents or sales and marketing documents and from the mistakes will affect your credibility in a negative way. The same goes for language, especially because many non-native English speakers, speakers just like myself right there, technical documents in English. So it's probably best to have that proof fret and checked as well. The second quality criterion is complete. Your technical writing documents should, of course, include all information that target audience needs in order to fulfill their tasks in a professional, efficient, and safe way. However, choose your level of detail wisely. Ensuring completeness of information does not mean that you have to include all the information you can possibly find on the topic right about. But that you should carefully decide what your readers need and then include all of that inflammation and exclude all irrelevant information. And of course, double check your document for all formal elements that ensure readability. For example, page numbers, headline numbers, and make sure you include it. Additional resources and literature and many other important formal elements of a technical writing document. So this is an important one because it makes technical writing a little different from many other forms of writing. And we have already scratched on the surface of that quality criterion because your text should be usable. So you ask the responsible writer should ensure the usability of your text. What does that mean? You should ensure there use the readability and the skin ability of your document. It should be easy to read, easy to scan for your target audience. That means you should organize the information and logical chunks that allows your readers to just scan the document for relevant information. You should choose a clear structure and layout that helps readers to flip through the document and read exactly the parts that they need to read. And you should involve into active elements such as tax or links. So when readers find a relevant topic in your table of contents, they can just jump right to that section. And when they need a certain paragraph and they want to find out about a certain detail that is mentioned there. They can just click on the link, you include it and it will take them to the explanation of that certain detail. So unlike the last quality criterion, usable, this quality criteria and right here should be well-known to probably all writers out there. Your writing should be clear. And touring clarity is super important, especially when your readers don't look for a long read, but for a solution to their problem, to make sure your writing is clear, you should of course, use easy to understand language. Avoid ambiguity and confusion, and always assign only one clear meaning to especially technical terms. You should definitely use graphs and images if they can explain things more efficiently and more effectively than your text could. And you should definitely make sure to give the chapters or sections of your document very clear headlines, very clear names, so readers know exactly what they will find in that section. So the next one is another quality criterion that should be especially well-known to nonfiction writers and UX writers. It's concise, so make your writing as efficient as possible. Therefore, you should use efficient grammar and syntax. So built your sentences in a way that keeps them short and easy to understand. For example, choose active voice or passive voice whenever possible. Same goals for your choice of words. Short words are easier to read, easier to skin, so you should always opt for shorter words when possible, use simple vocabulary. Don't get complicated and complex with your language. Just sound formal. I know that many technical writers would like to do that because they think that Mary formal language is actually a part of technical writing, but of course it's not. And of course, technical terms should not be traded for everyday vocabulary room and this is not suitable, but you should keep it as simple as you can whenever possible. So, and you choose, you should choose an efficient form of presentation. Technical writing does not have to consist of lengthy sentences only. So you can offer bullet points instead of long-running texts and sections when it does not affect the clarity of your writing. So in the last one, but not least, your writing and your document should be consistent. This will not only support the clarity of your writing and increase the readability of your document because it helps readers navigate through your texts. It will also make your document appear more professional, more trustworthy, and more readable, which will encourage readers to use it for their problem-solving. To ensure consistency in your document, you should, of course, use a consisting naming system for your headlines and a consistent logic for your chapter numbering. You should use terminology in a consistent way. You should choose a consistent designed for your document. As I said, this will help readers navigate through a text and increased credibility. And you should make sure that you document fits the standards of your organization and your field. This will have read us to accept and use your document. So this was a lot of theoretical stuff. I know a lot of me telling you how to do things right? But keep in mind, writing is all about practice. Practice will help you to get you know yourself as a writer. It will help you lose your fear of the blank page and we'll help you judge the quality of your own writing, which I know many writers struggle with. So in the next section of this course, we will put this knowledge into practice, which I promise will be great fun. So see you in the next sector of this course. 5. Creating Good Technical Writing: So welcome back to the fourth lesson of this introductory course. We will continue talking about quality criteria. And this will be a very hands-on lesson which I hope you enjoy. You will probably remember these from the last chapter, The most important quality criteria for a technical writing. These are actually a pretty intuitive I think, but I also think that this structured overview helps us all to keep them in mind and to check our own writing in a very structured way. And this is kind of what we will do in this chapter. It will actually be all about an exercise. And for this exercise, I would like you to do the following. Please take a look at the following example and identify which quality criteria are not met. A childhood friend of yours moved to a remote island where fire grows on trees. By the time you return to your neighborhood, he had forgotten how to make fire with tools. Since he loves reading by candlelight, he would love to learn how to light a candle with a match. You support him by writing an instruction for him. And this is your first draft. Now, little disclaimer, I know this is a very absurd example. But what I wanna do here is take you away from the classic content of technical writing as we know it. Because I don't want to focus on the content, I want to focus on the principles. So we will work with an example that is very close to our everyday life and we will move away from the classic contents like describing a technical process, describing machinery, because I want you to understand the underlying principles. So this is your drafts. Let's read this together so we can all follow the match, which is usually made of popular Walnut or similar kinds of woods can do to it's easily flammable phosphorus code at its top end, B menu ideally lit by the match user, more precisely by the match users striking the top end of the match against a rough surface. You can just use the rough surface on the Matchbox. Your match is now on fire, and you can light a candle. When the match is on fire, it is super important to make sure that you don't burn your fingers while holding it. Just drop it once the flame reaches your fingers, this way, you won't get hurt. And keep one thing in mind, the flammable top cold will only get lit if you hold the match Brealey tightly and strike the match against the rough surface swiftly. So you can just pause here and take your own notes which about which of the quality criteria are not fully met here and y. And once you're done, you can press play again. I will guide you through this just in a minute. So good luck and all the best with this exercise. So I hope you enjoy doing this exercise. Let's take a look at it. Take a look at our findings. I will guide you through this. Let's start with the first quality criterion. Correct? Is it correct? So it seems like we have written this from our own experience, basically from reading it, the overall information seems to be widely correct. Well, except for this part here, it is probably not a good idea to just drop a burning match just anywhere. So we can say the inflammation is partially incorrect. We also probably don't know if this is a 100% correct right here. So we don't know about the exact kind of word that is used for matches and whether the material that is used for the top code is really phosphorus. So we can say, probably we need to do more research right here. And we have to find out whether all Mencius actually work like this because it might be that our friend bought different ones from the ones that we are familiar with. So we have to check on that as well. Next up is the quality criterion of complete. Is this writing complete? Well, we see that the process starts with the user striking the match and it ends with the user just dropping the match. We probably should ask ourselves, is this really the whole process? Or are there any preparations needed, any precautions to make? And does the process really end like this? Or wouldn't it be better to tell our friend how to correctly and safely dispose a match after using it. Also, this is about fire and there are many risk and potential dangerous for inexperienced users here. So what about the risks and dangers involved in using a match? And just another thing, let's ask ourselves, do these instructions really draw a realistic picture of using a match, especially with cent, especially with sentences, sentences like this. Just drop it and you won't get hurt. Not a big deal. Well, if you drop it on, you're easily flammable cotton socks. Dropping it will probably not prevent you from getting hurt. So this ons very easy here, very casual when in reality there is a certain danger. So let's go ahead. Is this writing usable? What do you think? Take a look at it. Well, obviously the layout, it is not easily scannable because it is just written as a long-form text. There is absolutely no visual guidance, no highlighting NOW numbering, no headlines in here. And there are no images, for example, of a person actually lighting a match or using a match to light a candle. These kinds of images may have helped to actually illustrate the process in a clear way. So talking about it, what is about clarity? Let's take a look. We find a lot of information right here in the beginning that does not necessarily, necessarily seem relevant to our friend. And if we include this inflammation in our text, our friend might be confused about why we considered this inflammation important, you know, about the material and the top code and about what kind of woods are you, what kind of wood is used? So this kind of unnecessary information is rather confusing. It sets a wrong focus. But let's take another look. As I said, we got this part where we recommend to just let the burning match drop. And of course we don't mean that our friend should just drop it just anywhere. But you know, maybe just put it on an ashtray or blow it out before you put it down, et cetera. So this information is kind of unclear. Just like this where the instruction says, hold the match really tight. What exactly does that mean? Should the match? Should we enclose the match in our fist should be rep, all our fingers around it. What actually does that mean? So another rather confusing section right here. So we can say that wrong or unclear inflammation is absolutely confusing. And unclear information leaves readers absolutely clueless, et cetera, wrong focus. But let's take another look. We got this inflammation in the end. Hey, keep one thing in mind. The flammable top coat will only get lit if you hold the match really tightly, tightly and strike the match against this rough surface swiftly. Well, this inflammation is obviously marked as important because the text says, hey, keep in mind, but it does not seem to be in the right place here. A better location for that information would be right in the beginning where we learned that we have to strike the match in order to use it. So we got the wrong order of inflammation, which makes the text harder to use as an instruction because we have to jump back and forth by reading it. And it is confusing for us because we have to locate the relevant place for that additional information ourselves. So we got two more quality criteria to go. These are the ones for clarity. But what about conciseness? Is this text concise? Let's take a look. Well, you might have guessed it. It is not asked concise edit could, as it could be, which we can see right here. As I said, we got this additional unnecessary information about the chemical characteristics of the match right here, which makes the text quite long, and in this case it also makes the sentence quite long. So we've got unnecessary information that creates length Venus, but that's not all of it. Just let us check the texts one more time. You'll probably notice that we've got an incredibly long and complex sentence right here in the beginning. This sentence takes up almost half of the entire texts. So you don't have to be a professional writer to know that this is just way too long and way too complex. And when you read it, you'll notice that it's just overly complicated. And this kind of inefficient grammar or syntax makes sentences hard to read and the information becomes hard to absorb, hard to process, hard to memorize for the reader. However, we're still not done. So let's turn back to the text. Reading this text. You might have also noticed that there are repetitions in the information and wording right here. Since we describe a process, we do actually not have to repeat the description of the process phase over and over again. So we could have just left that out, or we could just have left out the second highlighted part here, because repetition simply disturbs the reader's focus and we're still not done with a text. So a lot of things to do here. Taking a look at the texts, you will notice we got this kind of decorate of sentence grading. A little personal touch here because it appears really conversational and friendly. It really sounds like we're really talking to our friend. Of course, this is nice, but it would have been more efficient and helpful for our friend if we had just put this in the right spot and didn't mark this as an additional hint. So we can say that these declarative sentences may confuse, may confuse us, may cause frustration because they just consume the redoes valuable time. So a lot of things going on in terms of conciseness in this text. Let's move on to the next and the last quality criterion, consistency. Is this text consistent? Let's take a look at MIT. This is a little bit tricky, but right here, you can actually see that we mix active and passive voice. So first we say the match can be lit by the user. Then we say you can just use. And we also notice that this causes an inconsistent addressing of the user. So mixing active and passive voice is just irritating. It drags the reader's focus from the content to your language. And the inconsistent user addressing just appears rather unprofessional. Seems like we have not put much effort into this at all. But again, let's look a little closer. If you read this text carefully, you probably noticed a change in tonality because right here in the beginning we sounded super formal, okay? And later on we used expressions like super important, which sounds rather informal. It really sounded later on like we were talking to our friend personally. And inconsistent, varied, varying tonalities simply creates confusion. It either sounds like there were many different authors in Bolton writing this, or like we have no clue about who our target audience actually is and how to address that target audience. So this is actually it. I know there are many other flaws in this text probably and we could have gone on and on over again. But this is just to give you a little impression of what we can do here. So thank you for sharing this exercise with me. As I said, there are probably many other points of critique that would've been appropriate here. But this was just to give you an idea on how to analyze a technical writing document and how to do quality assurance for your own text. Now, what can we learn here? Well, keep your eyes open. Read other writers, texts and your own texts carefully. And pay attention to the details. Because when we ride we often focus either on the content or on the style. So getting some distance between us and our texts can help us pay attention to other aspects as well. So letting it sit might help you to revise it more effectively. Use a checklist for your editing and proofreading process. As you might have already noticed, I put up such checklist and you can find it in the additional documents that I uploaded right here. And it comprised comprises the whole process of writing and it includes also the quality criteria you should keep in mind when editing and proofreading your text. And last but not least, ask, ask someone to check your texts prefer but experts in the process or products you're writing about and readers who fall into your target audience. And of course, you can ask a professional proofreader or editor about proofreading your language. I hope you got an idea of what actually is good technical writing and what makes technical writing goods. I hope you enjoyed this little exercise. And if you're ready to dive even deeper, I'll see you in the next session of this class. 6. The Writing Process: So welcome back to the fifth lesson of this introductory course. And I'm very excited for this mom because we will get right to the heart of technical writing, which is of course the writing process and its single steps. So these are the four steps of the technical writing process. Planning, the information collection and drafting, the revising and editing, and the proofreading and testing. In literature and in other courses you might find models that differ slightly from this one, just like I set for the set for quality criteria that we discussed in the previous lesson. There are other concepts of this, but most of them only differ slightly. They really similar actually. So if you're ready, let's find out what these single steps are all about. Let's start with the first part, of course, which is the planning of your document. And this stage of the process, you will define the purpose of your of your documents. So what goals should read us reached by reading your document? You will also define your target audience. Who are your readers? Who are they not? What kind of needs, preferences, demands, fears, experiences do they have? And based on the purpose and the target audience of your document, you will define which topics you would like to include and which topics should be excluded because they're not relevant. And last but not least, you have to plan your writing like a project. When should it be finished? Which stakeholders need to be involved? How much time do I need, how much financial resources do I need, and so on. And this is something that I always Siegel missing a practice because in many cases it is just the engineer or the writer who was asked to just go and write. However, planning your writing will help you move forward in a structured and well thought out way. So a very important task to do in this first step of the writing process. The next step of the writing process is a big one. It is inflammation, collection and drafting. In this state, you define the outline of your document. That means you write down the topics that you want to cover and put them into an order that appears most logical to you. You can adjust this outline throughout your working process, but it is very important to work with one from the beginning on. Then of course, plenty of research. There is no technical writing about without research, you at least always have to talk to your target audience to find out about that technological knowledge and needs and prior experiences and so on and so forth. So plan what kind of data you need and then plan your research. You can either collect primary data or secondary data. You can collect primary data by conducting interviews, surveys, user tests, or experiments yourself. Or you can collect secondary data that was gathered and collected and analyzed by others and that you can read and journals or books or brochures. And after you've done that, you can then analyze the relevant secondary and primary data. And then structure the information that you found in the data according to your outline and based on that structured information collection, you can then create your first draft of texts. And I recommend to, first of all, just write it down. Write it all down intuitively, this is okay for the first draft and then you can make your text correct, complete, usable, concise, and so on in the upcoming editing process. So this is the editing process, it's the next step. And this is what we do right here, the third step which is revising and editing. And this step, you review and edit your first draft based on the quality criteria that we discussed in the previous stepped up. And of course, you always double-check the language, the contents, the style, the structure, and the layout of the document. By this, you create a first, final draft that is ready to be tested, which will happen in the next step of the writing process. The proof reading and testing step. And I know this is something that is rarely done in many cases of technical writing out there. But you should actually never publish a technical document without having a tested with your target audience. So this state is super important. But first things, first half, your document proof read by a professional proofreader. There are also highly specialized technical proofreaders and editors with a specialization in technical writing that you can consult for that. When that is done, it is time to run a user test or a survey with your target audience. So you can find out, do these people find your document helpful? Do they find it useful? How do they actually use your document, right? And use this new knowledge to adjust and improve your document accordingly. And of course, you can repeat the process of testing and improving on a regular basis because target groups may change the context of use of your document may change the process of product you describe may change, and so on. These are the four steps of the technical writing process. And as you may have guessed, rather than this, it probably looks more like this in practice because a technical writing document is almost never fully finished and always need some adjustment, improvements, and changes. Alright, so again, this lesson has been very theoretical and I have another exercise for you guys where you can put that theoretical knowledge to work. And this exercise is actually very special because it is our class project. Yes. So let's get back to our friend. Your good friend actually just found out about lighters and asks you to write instructions on how to use them. And this time, you wanna get it right, right from the beginning. So your exercise is this goal through the planning phase and do all tasks that are important here. So I will put the details of the stage of the process right here. And you can pause here and do your exercise and keep in mind to be as specific as possible. What exactly is your friend supposed to do with your document and what are his needs? His knowledge, what infants should you include in the text? What info does your friend not neat. And what do you think? How much time it will take until you get this duck finished? Plan, all of this as detailed as you can, and also at all of the open questions that you are unsure about and all the information that you might need from your friend or that you might find out about lighters in order to start your writing. Since this is the class project, I will not discuss this in detail here. I will provide a sample solution for this exercise that I uploaded, which you can read to get an idea of how well you did on it. And of course, you can also share your assignment with the other students here. I will be really happy about this because then we can discuss about it and you can ask questions and we can see how others have fulfilled this task. So, good luck. Have fun, and I'll see you in the next session of this class. 7. What Makes Good Technical Writer?: So welcome back to the sixth lesson of this introductory course, almost the last one. So let's put some energy into this, especially because this lesson will be about you, the technical writer, because we will try to find an answer to the question, what makes a good technical writer? And we will talk about the knowledge and the skills that you need in order to become a great technical writer. Let's start with the knowledge. There are actually four types of knowledge that are relevant for every technical writer. The first one is technical knowledge. The second one is product knowledge. We got user knowledge, of course, and we got language and writing knowledge. So let's take a closer look at these types of knowledge in order to see what they're all about. And let's start with technical knowledge. For a technical writer, it is super important to know the context of the product, a process that we describe. So what are these kinds of products and processes usually used for? For example, this helps us to classify and characterize them in an adequate way. In many cases, it is also necessary to understand the basic chemical, physical and other mechanics that explain the functioning and functioning of the product or process. It may also be important to know the products or processes relation to other products and processes. And of course, technical knowledge will help you to use technical technological terminology correctly. And having technical knowledge probably means that you are familiar with the standards and norms of describing technical products like, for example, machinery in a correct way. We got product knowledge, which is the knowledge about the product, a process you as a writer want to explain to your target audience. This knowledge is important because it includes the functioning of the product, which is what you need to know about in order to actually create great technical writing. It also includes knowledge about the shape and components of the use of that certain product or the steps of the process you write about. So also a very important knowledge to transfer to your readers. This knowledge also includes being aware of the specific use cases and the context of application of that certain product, a process, and it includes knowledge about the product's history and organizational context. So how and why was that product built? Why was that process designed? Who is responsible for it, etc.? If that knowledge is relevant for your documents purpose and for your target audience, the third kind of knowledge you need is a good technical writer in which is oft neglected is the user's knowledge. So knowledge about the user's needs and preferences, knowledge about the user's level of text business, which is very important because it tells you how much you can go into detail and what kind of language you want to use. This knowledge also includes knowledge about the uses, prior experience with the product, a process you plan to write about the user's knowledge of terminology and the uses, reading and learning capabilities and habits, which also have a great impact on the language and layout you should choose. Last but not least, we got language and writing knowledge. This means you should have proficient knowledge about the grammar, punctuation, syntax and other elements of the language you write in. You should know the correct use of the vocabulary of the language you use. You should also be aware about the fact that there is efficient and inefficient language and grammar and you should know how to write efficiently. The same goes for clear language. You should know about it, you should be aware of it and you should use it. And the same goes for comprehensible, easy to follow language, because after all, your technical document is a form of communication, as we learned from the official definition of technical writing. So language and writing plays a major role. Now let's head over to the skills of a good technical writer in order to gain and apply knowledge. We need certain skills, right? These are some of the most important ones for technical writers. Regards research skills, writing skills. We got interpersonal skills and learning skills. Now, let's explore this a little further as well. As I have said many times before, in this course, research is absolutely crucial. If there's one takeaway from this course there, you should keep in mind no technical writing without research would be it. This means you should know how to interview a so-called subject matter experts or short Samis. These are the people that have expert knowledge about the process, a product you write about. It can be, of course, a subject matter expert yourself. But please always consult another E to double check your perspective on the matter. You should also know how to interview a different user groups. In order to fully understand your target target audience, you should know how to design and conduct user tests because testing your document will help you optimize it. And in some cases, it may also be helpful to run user tests for the product, a process you write about because it will help you understand the pain points that appear for the target audience when they use that product or process. You should also know how to design and run surveys and you should be able to analyze primary data as well as analyze secondary data proficiently. So remember, you don't have to have all these skills right in the beginning of your writing career to become a technical writer. But I would definitely recommend to learn some of these skills along the way or as soon as you can. Next up are writing skills. Technical writing, of course, is a form of writing, so you should know how to write correctly, clearly, efficiently and user centered. For this, it might be super helpful to dip a toe in the basic principles of your writing, where you can learn a lot about user centered writing but good writing skills to not only include writing persay, they also include the skill to structure and lay out a text efficiently and to involve. Just charts and illustrations to support your writing. So then we got interpersonal skills, many people imagine technical writers to be like little hermit's, withdraw from social life to produce huge amounts of text in complete isolation. But this image couldn't be further from the truth because you actually have to talk to people and communicate effectively in order to produce great technical writing. That means you need to ask, listen and translate a lot of the time. To be more specific, you should know how to ask experts and users for certain information. You shouldn't know how to ask stakeholders for their expectations, which is super important for the definition of the purpose of your document. And you should know how to translate user needs, experience and knowledge into clear writing. And you should know how to encourage users to work with the document. So let's hit the last one. Learning skills. Being a technical writer means that you have to deal with new products and processes all the time new principles, new mechanisms, new user groups and so on. So the capability to learn is an important part of the skill set of a good technical writer. This includes knowing how to fully understand products and processes, knowing how to analyze structure and make sense of data, knowing how to learn and apply new terminology, knowing how to continuously improve and update your skills and writing research, technology and any other relevant fields and how to be open for criticism and critique. Because you write for others, not for yourself. So many crucial skills that are important to do a great job as a technical writer. So we are almost at the end of this course, there's only one lesson left in which we will talk about classic pitfalls during the writing process. And I share with you some of the things that will make your life easier as a tech writer. So see you there. 8. Things That Make Your Life Easier: So welcome back to the seventh and last lesson of this introductory course. This last step TO supposed to give you a little heads up about the pitfalls that might occur throughout your writing process. And I also wanna talk about some things that make your life as a tech writer easier. This lesson will basically summarize the knowledge we have learned in the previous lessons. And it will present that knowledge in a very structured and hands on ways. So let's go. What's our typical pitfalls that may occur during the writing process? Spoiler alert, there are quite a few. One is, your purpose is poorly defined. Some technical writers define the purpose of the document as, for example, helping all designers apply the design principles. This is actually far to bake. Same goes for your audience. All designers are, all developers, is far too broad. So definitions like this will not allow you to assess and understand the specific needs of your target group. For example, are you talking to very experienced senior designers? Or are you talking to Newby designers? I you talk into UX designers, graphic designers, or UI designers? Or are you talking to a back-end developers or front-end developers, but programming language and so on. Of course, sometimes we write for ourselves, not for our audience. So we just assume that the reader has the same technical knowledge that we have on the same reading habits, that we have, all the same needs of preferences and so on. Here, of course, research can help you to get a better perspective on your audience. And a classic one, you use lengthy sentences and complicated words, bots, and there are even more pitfalls. For example, your page layout may lack structure or you're using consistent naming and your chapters, your headlines and so on. Or your document contains useless information, for example, because you mentioned details that are irrelevant for the purpose of your document or the goal of your target group. And there are even mark pitfalls. For example, that might be too many authors working on your text. This is actually typical pitfall that I come across all the time when I teach about technical writing. Some writers invite everyone and their team to edit and comment on their texts. And in the end, they are very confused about which piece of critique they should include in their editing process. And of course, you should invest some time in choosing the right writing tool. This is something that we have not talked about yet that will actually be the subject of my second corps of technical writing will be get a little more into detail, a little more practical. But this goal is actually for every technical writer invest some time and the right tool, don't just write using the tool that you're already familiar with. And of course, last but not least, you know, research and you don't test. These are some of the most risky pitfalls that technical writers can step into. And I'm sure they will help you to remember. Some of the lessons that we have learned throughout this class. Okay, so again, this was a lot of theoretical knowledge. So I would like to do another exercise, but only a very small one. Did you ever catch yourself stepping into one of these pitfalls? Now, before you pause to answer that question for yourself, let me tell you why it is important to answer that question. Each and every one of us has strength and weaknesses. As a writer and as a writer, each and every one of us slightly tends to repeat the same kinds of mistakes over and over again while we intuitively avoid other mistakes. So this might be your chance to become more aware of your specific mistakes and get to know yourself as a writer a little more. I personally can tell you I am very guilty of writing for myself instead of others, because for quite a long time I did not take the need for conducting research very seriously. And I always assumed I knew enough about my target group. But great editors and prove readers have made me very aware of that problem. And sometimes I even learned this the hard way. For example, when I wrote an article and it got published and read, those were leaving commons on it that clearly showed that I had not managed to get my point across effectively. So this has been one of the pitfalls that I stepped into irregularly and sometimes I still do. So being aware of that has helped me a lot. So you can now pause this video and take some time to think about this question, this question for yourself. So see you in a minute. So I hope you had some great learnings from this last exercise. Let's continue. I wanna end this main part of the course with giving you some advice on things that make your life as a tech writer a little easier. So first of all, show authentic interest in your audience. Careful their problems and needs. Listen to them and bond with them. Keep in mind as you work, flip them. Not for your boss, not for yourself, you work for them. And then as I set null writing without research because we tend to think we know enough about our product or process or target group when we actually don't. Next thing is collaborate wisely. Because as I said, Choose your expert, experts and editors wisely and decide carefully went to consult them, doing your writing process. Then invest time and sometimes money in the right writing tool because it can make your work much easier and more efficient. I know that many work with confluence of us work with Google Docs or Adobe frame maker. Whatever you choose, choose wisely and take your time before making a decision. Then of course, work on your skills because the field of technology is highly dynamic and changes rapidly. And so does the field of technical writing. Treat the writing of your dark like a full-blown project, not something that you can do on the side or during lunchtime or whenever you find it a little time. That actually works best when you treat your writing document like a product that you work on, that you need to finish, that you need to sell, and that needs to be used by a customer. And last but not least, you've heard at a 1000 times before, tests and improve continuously, of course. Now I promise if you keep these things in mind, your life as a technical writer will be much easier. Okay, so wow, actually we've come to an end here. Congratulations if you have stuck around until now. If you're interested, you can now join me on some last remarks, some final remarks and my altro. All you can just finish here, reflect on what you've learned. Celebrate your new knowledge, and start out with some nice projects. Thank you for joining me in this class and have a great time. 9. Final Thoughts: So congratulations if you have made it this far, be proud of yourself for completing this course. Now before leaving you with all of that new knowledge, I would like to make some final remarks here. I know that we have learned a lot of rules and principles and concepts in this course. But keep in mind, writing is always a service for the reader. So all of these rules and concepts and principles are very important. But in the end it's all about your readers and their preferences and their needs and their fears, and their beliefs, and so on and so on. So go out and ask them about all of these things and develop a genuine interest in your audience. And of course, in July, creating a document, enjoy the process and be proud of yourself or being a technical writer. Because as I said in the intro, technical writers help people to understand and use technology in a safer, more efficient, and more satisfying way. And that is a good thing. So thank you for joining me in this class. All the best for you and your writing and see you soon.