Upskilling in Technical Writing

What is technical writing? Simply put, technical writing is the form of writing that takes complex information and breaks it down into easy to understand straightforward, clear and accurate content using plain language. Often when people think of technical writers then think only in the realm of software, or engineers, but technical writing can appear anywhere that step-by-step instructions appear. Think of cookbooks, gaming guides, and Ikea furniture setup manuals. Someone wrote those. More specifically, someone wrote those in a way that the audience could follow without confusion.

Part of my job as a Design and Delivery Consultant is to create job aids and update curriculum in addition to training. This is something that I have been doing for years without realizing I was 'writing technically'. I just knew that I had to take the steps I know, write them using the correct language, and present them in a way that a busy healthcare worker would be able to take, scan, and understand what they were supposed to do in a short amount of time.

Why Technical Writing?

While I think I am a good technical writer, I am not perfect and there's always room for improvement. Thus, the second topic I chose to strengthen my knowledge in was technical writing. I want to become more confident in my abilities to take and parse knowledge to various audience, so I spent the last few weeks learning the tricks of the trade. I watched various YouTube tutorials, read numerous blog posts, read through some of Microsoft's recommendations for writing user interface content, and even started a course on Udemy. All of which gave me great insight into the world of technical writing including dos and don'ts. I used the knowledge gained to update a training outline that is currently being used.

The Design Artifact

For context, Epic is an electronic health record, I have been a trainer for this system for the past ten years. However, I am new to my current organization, so I am in the process of learning their materials. They have a different way of writing curriculum than I am used to so I decided to use my previous experience and knowledge gained from upskilling in technical writing over the past few weeks to rewrite their outline and turn it into a proper training guide. My artifact has been created in Google Docs and has been presented in a before and after format. The first tab is their original outline while the second tab is my updated version.

Key Takeaways

• Always consider your audience, what do they know already?

  • This is perhaps the most important thing I learned and what kept appearing during my research. Throughout this process I was working on other documents, and I realized that I tend to over explain or infantilize my instructions. For me this process taught me to pause and reflect, what level of understanding my reader already has from their day to day role and what are areas I need to explain a bit more.

• Keep a consistent structure throughout.

  • One of my pet peeves in documents is incorrect/inconsistent formatting. It's the first thing my eye is drawn to. Technical writing has a good amount of formatting and hierarchy recommendations and while it doesn't matter the path you choose, you must be consistent.

• Instructions should be in active voice.

  • Direct language is key. The writing should focus on what actions the user/reader needs to take and what they can expect. In most instances the research I found recommended instructions starting with the verb.

Reflection

This process was affirming as well as enlightening. To begin with, I was pleased to know that I have been on the right track when it comes to technical writing. However, there were elements that I still yet to discover. For example, the biggest recommendation I saw was to create a list of agreed terms for the teams to refer to. In most software there's the correct terminology and there's what everyone calls it. I always try to use the Epic terms when writing material for Epic, but that's not always the case for everyone. Creating a terminology list allows everyone to be on the same page and forces consistency in writing when there are multiple authors.

Additionally, in writing this training guide, I had multiple rounds of edit due to me changing the audience. Eventually, I chose to write it for me. A trainer who is well versed in Epic and knows background knowledge without having it written on the page. While key callouts are important the items that would naturally always come up as someone who trains didn't need to be written down, in my opinion. I wanted this guide to be as straightforward as possible. Perhaps in some areas I went too far, but it's a process and I am still trying to find my voice. Which is something I hope to establish soon.

References:

What is plain language? (n.d.). Plain Language Association International (PLAIN). https://plainlanguagenetwork.org/plain-language/what-is-plain-language/

‌

Wikipedia contributors. (2026, January 21). Technical writing. In Wikipedia, The Free Encyclopedia. Retrieved 00:16, March 16, 2026, from https://en.wikipedia.org/w/index.php?title=Technical_writing&oldid=1334035415