I believe that of all the topics covered in this class, I got the most use from learning about structure. I already knew to use appropriate language and give consideration to the audience, but I didn’t know how important structure would be in a document. A nice structure will lead to a nice outline, a nice outline is just filling in blanks. This only works for some documents, but structure is important regardless.
I will adopt this newfound appreciation for structure by spending more time focusing on it prior to starting to document. I will also be willing to revise the structure to fit the content if necessary – you can’t fit a square peg in a round hole. I see this helping me in the near future because I intend on writing many different kinds of documentation – processes, use cases, alerts, and config files are all things I believe I will be documenting this summer. Having a defined structure for each, and a way that they can all fit together (this is for a single project) will be fantastic when trying to write the documentation.
Honestly, I have learned a lot in this class and they have all changed my writing skills in one way or another. A couple of most important things to remember is to research your audience, keep the piece clear and concise to capture a wider audience, and try to use visuals to capture the interest of readers. I learned new ways to start writing a document, like logical mapping which I have never used before. I learned the different types of documents and which situation demands what kind of solution. I currently work for Information Technology Services at RIT, and if there’s one thing I have learned, never assume what the front person may or may not know. I realized that many end users, irrespective of their technical knowledge, prefer visuals to understand something. For instance, if a user is trying to map a printer, they would rather have visuals (screenshots) showing them an example, instead of just a set of instructions.
Plain language is pretty important in my profession, mostly because people have varying levels of education and technical knowledge. Another thing to notice is that the kind of language you use will vary intensively from how you communicate with your peers, for instance systems administrators and security analysts to name a few, and how you communicate with end users. One rule that has helped me a lot is if you do not know the person at the end of the line, start off with as simple plain language you can, and work your way up to more technical terms if you deem the person has that knowledge and expertise. I sometimes help someone who has performed all basic troubleshooting I would have performed to find what is wrong, and this tells me that the user at least has some technical knowledge.
Overall, using plain language can sometimes be as effective as using very technical terms in order to get your point across to the reader. This class has helped me a lot in honing my writing skills.
– Smayan Daruka
Technology changes fast. When it changes, we must often re-learn how to use it. For example, we had to learn how to use our phones again when smartphones replaced old flip phones. With the Windows 10 update, many people had to learn how to use their computers again. Although the processes may be similar, explanations are still needed so that people may understand how to continue doing what they were doing before. At the IT help desk where I work, I must communicate clearly and effectively so that end users are able to have their problems resolved.
It is very important that I use plain language in order for users to understand me. Sometimes I have to walk people through performing a series of troubleshooting steps over the phone. Not everyone is familiar with every component of their operating system. People can get confused easily when told to “click the Start menu” or “go to Control Panel”. It gets worse when there are acronyms involved like DHCP, VPN, IE, IP, USB, etc. Evidently, there are many acronyms in the information technology field. Avoiding technical jargon is critical to ensure that users do not feel overwhelmed or lost when trying to help solve their issue. Taking a little time to use plain language can end up making a big difference in how quick a problem is solved and the overall experience.
– Jar T
As I continue my education in Civil Engineering, Construction Management specifically, I am realizing just how important plain language is. In the construction field, information gets passed around constantly and it can be sent out to several different parties at any given time. A set of plans will go through at least three separate departments before it reaches the contractor. Engineers and project managers must be able to communicate clearly with clients, peers, supervisors, and contractors. Often times, the project manager serves as the liaison among all groups which is why communication is a vital skill in the construction field. If an unexpected change needs to be made on a job site, it is the project manager’s responsibility to fully comprehend the issue and then translate that problem to the design engineers so that a solution can be devised. The project manager must also inform the owner/client of the change in a way that makes sense to them. This sometimes requires them to simplify the problem because the owner is not always someone who understands construction terminology. Finally, the project manager must update their supervisor on any decisions that have been made or are under consideration. Since project managers must communicate with so many distinct groups, they usually benefit from using plain language with everyone involved; this ensures everyone is on the same page and no information is misinterpreted. As I take the next step toward my professional career, I will be sure to make clear communication a top priority in all my work.
The structure of a document is the foundation upon which its information stands. This is something I learned in this class that changes how I approach work.
I see structure as something that can be implemented just about anywhere. Knowing that it is important for Technical Writing is a bonus, but the real benefit is that any area can be improved with structure. Structuring a to-do list can make it easier to read and act upon. Structuring files can make finding things quicker and easier. Structuring your day can improve your productivity. Structuring free-time can even improve the quality of this time (I read this a long time ago, it was a newsletter from Cal Newport I think). Structuring your day can improve the amount of work you can do (Cal Newport writes about this more than anything else I’ve seen: example).
This relates to work in the following manner: Structure, whether in writing or in life, increases the return on investments. Having a structure for writing will make the work easier to perform. Scheduling may take some time, but knowing the order you want to put things in beforehand will make writing them down easier. Structure also makes reading the writing easier – people like a structure in what they read. This is why books have a plot that normally follows a basic outline. Reading chapter 13 before chapter 3 will leave you confused. Some writing can still take this form, but hopefully using structure will prevent this.
~ Connor Shade