Writing for the Audience

When I used to write my focus was to make sure I had all of the required pieces needed. I did not think much into who would be reading my pieces and how they might react to them compared to someone else. I had never thought about how big of an impact the audience had on the way an article should be presented.

In RIT’s Technical Writing and Editing class, I learned quickly that the audience has one of the most defining roles on how an article should be written. One of the readings that really helped me realize this concept was one about designing health forms for less fortunate families so that they could easily be understood. Some of the families may not have the best reading level which can make it very difficult to fill out forms. In order to combat this issue, the document could be edited to use very simple language that is easy to read and not too small. These small changes had the ability to help people get the medications they may need by making a document that could be interpreted by all audiences.

Now, every time I write I make sure to understand what I am writing about and who will be the one reading it. If one is to write for the wrong audience, the document could easily lose its purpose and effect. I plan to use focus on the audience every time I write in the future to help my point get across. I believe it will be beneficial in the workplace to help me present my ideas in more effective way.

-Jonathan Dell


Guilty Verdict in Nominalization Case

I was found guilty of nominalization of verbs. I am writing this so it doesn’t happen to you. Maintain clarity in a document by avoiding nominalization. Nominalization changes the subject. A recap from English class, “Nominalization changes verbs, adjectives and adverbs into nouns.” A quick example of normalization, “The tree is tall, we can see it two blocks away.” changes to “The tree’s height can be seen two blocks away.” The subject changed from the tree to the tree’s height. I will tell you how nominalization got me in trouble and why.

How it started

I have been working for a manufacturing company for over a year. My boss and I crossed paths in the hallway, last week. After brief salutations, my boss excused himself to go off for a meeting. While walking away, he said, “Send me an update on the xyz project, thanks.” 

My first thoughts

I was elated. This was my first progress report to my boss. My opportunity to showcase my technical communication skills. I knew what the design and style should be like. I’ve been given these tools, now I just have to use them correctly.

My second thoughts (the subject is italicized)

I felt anxious. The content of my progress report will clearly show “no progress”. 

  • The assembly drawings are being red-lined with errors at every phase. 
  • Management has reassigned resources away from the project. 
  • Materials are slow coming out to the shop floor. 
  • The project needs an increase in cost to complete its scope.

The crime

Unknowingly and regrettably…
I used a passive voice. My verbs were nominalized into nouns.

To be kind to my team and management, I changed the subject in each sentence by nominalization. The actions, in-actions and needs became the subject.

The evidence (the subject is italicized)

  • The errors are being red-lined on the assembly drawings at every phase.
  • The reassigned resources are not available for this project, according to management.
  • Slowly, the shop floor has materials coming out.
  • The needed cost increase will complete the project’s scope.


My boss read the report. He told me directly that he did not ask about the errors, the reassigned resources, the shop floor or the needed cost increase.  He was very clear about my next progress report. The project will be the subject.

My conclusion

When writing a progress report; nominalization of verbs, adjectives and adverbs will get you in trouble. This passive voice could confuse your readers, or worse, anger your boss. For new writers like myself, be careful and don’t change the subject (with nominalization).

Authored by Edward L. Prell.
Please comment with your direct feedback, whether positive or negative. Thank you for reading my blog.

Summary of “How to motivate users to provide feedback: Show that you’re listening to their input”

This week I came across an interesting blog post on I’d Rather be Writing by Tom Jones. The article titled How to motivate users to provide feedback: Show that you’re listening to their input, focuses on how to increase the amount of feedback you receive from your readers. Feedback can be an important tool in assisting writers to improve their websites documentation. Tom discusses his work process of adding and revising a feedback form for his job. The blog discusses three aspects of how readers feedback was increased:

  • The structure of the original form
  • Improved feedback form design
  • His Assessment of the revision

Original Form

Tom starts out talking about the feedback form he added to an Appstore doc he was working on for his job at Amazon. He demonstrates good technical writing basics be incorporating a visual of his original form. This allowed readers to gain an idea of the original design of the form. He discusses how he was not receiving a lot of feedback responses, even though his metrics had shown they receive at least a thousand visitors per day. The message was obvious to Tom, that the readers were not comfortable leaving feedback, needed to find a way to increase their responses

Improved Feedback Form Design

He discusses his desire to improving the form in hopes of improving the amount of reader feedback he was receiving. Carefully reviewing the original form and doing some research on improving feedback, he realized that the visitors low responses could be correlated to their feeling that their opinions would not be heard. This is an issue that I feel we all can relate to. I know when I visit a site that has a feedback page, I usually ask myself, “Do they really read and act on my input”? Or is that page just part of someone’s design idea? Tom realized that his original page design did not have a box for readers to put an email address for a response, so with his legal departments permission an email contact text box was added. This aspect opens the door for him to correspond with his visitor’s to express opinions of the site and opens the door to suggestions. In my opinion it reassures them that their voice would be heard.

Assessment of Revision

Feedback can be a vital tool to keeping innovation sustainable for readers and users. Upon adding the contact email feature to his feedback form, he saw an increase in response in just two weeks. It allowed him to receive important input from users about the Appstore doc, that in turn is creating a trust between him and his readers. Users of the site can have the confidence that their opinions and input will be heard and responded to.


I found this article to be a very informative and interesting read for me, especially since I am pursuing a career in Web Design. Feedback is a very helpful and vital design tool, it can help any technical communicator to sustain their innovative document or webpage. Having the ability to receive input as to how well your document is received, the needs of your viewers, and aspects they would like added, can help immensely in keeping sites and documents current. Isn’t the important aspect is providing the user or reader with a well designed engaging document? I would highly recommend this article for anyone that wants to increase the amount of feedback from their readers.

~Sean Dingle




A Focus on Structure

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.
~Connor Shade

Importance of Plain Language in Information Technology

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