Summary of “Chatbots are not the future of Technical Communication”

A recent post on the TechCommGeekMom blog contained a link to an article titled “Chatbots are not the future of Technical Communication” (, written by Mark Baker. 

TechCommGeekMom provided her own summary of the post, saying that she “didn’t think chatbots were really that much of a tech comm thing either”.  I was intrigued and decided to read the article for myself.  If I had found Mark’s blog when I was looking for blogs to follow, I would have added it to my list.  I am following it now!

A ‘chatbot’ is a computer program designed to simulate conversation with human users.  In its simplest form, it will scan for keywords in the user input (text or auditory), then pull a reply with the most keyword matches.  I would strongly suspect that the calls I get from perky “Heather” at “Account services” (company unknown) are more than likely some form of a chatbot program.

Mark lays out a thoughtful argument that even though “every tech comm and content strategy conference seems to be about getting your content ready for chatbots”, they are not the future of technical communication.  He points out that chatbots may be great at ordering something online but they are not even close to being able to help with troubleshooting a technical problem.  Chatbots are not smart in the sense that they don’t have common sense, they are simply a command line interface (CLI).  All they can do is respond to the user’s input, and sometimes the responses they give are wrong.  It cannot listen to the user’s explanation and suggest alternate solutions.  A chatbot cannot show the user anything, and it cannot see what the user is doing.  The user has to tell the chatbot what they are doing, but the user cannot tell a chatbot what the problem is because the user is only seeing the result of the problem.   Making the chatbot smarter will not solve this. 

Mark argues that text is the most meaningful way to deliver content to the user.  Text is the type of content most amenable to the various ways in which users search for information.  As Mark says “Nothing else lets you speed up and slow down, go straight or turn left with anything like the same ease”.  He includes ancillary media – maps, graphics, animations – as playing a valuable role, but points out that it is ultimately text that leads to these.   Text allows the insertion of hyperlinks, which can instantly expand the search and allow the user to follow leads.  Interaction with a chatbot will limit the user’s ability to change pace or direction at will when looking for information.    

I found it sobering to consider that the hope of some of the current boosters of AI is that the technology can be developed to the point of “delivering the right content in the right format to the right person at the right time”: a Nurnberg funnel*.  If it was even possible that technology could be developed to that level, it would mean that the user would no longer have to search for information or learn new tasks.  But I believe it is essential that users be allowed to seek information in the way best suited to them.  Every individual has their own style of learning. 

I agree with Mark and TechCommGeekMom (Danielle M. Villegas) that chatbots are not likely to replace the traditional sources for technical communication anytime soon.  A chatbot can be a useful tool but it cannot replace human interaction, or replace (as Mark states) the form of information most suited to creating a navigable, searchable field of information – text. 

Debbie Churchill

*A legendary funnel through which knowledge could be poured into the head of the learner.  It was said to make people wise very quickly when the right knowledge was poured in 


Summary of “Don’t twist the prose” by Larry Kunz

In this blog post, Larry talks about the importance of writing clear instructions. He talks about overthinking things usually makes for a more complex and difficult to understand scenario. As Larry mentioned, it is better to come back to something later with a fresh mind to effectively get your point across to the reader. Larry continues to back up his point by describing the importance of translation. He mentions how important it is for the person translating to have the background knowledge. He concludes the post by talking about the importance of verifying information before it actually gets released to the general public. He talks about the usability of the instructions and how nice it would have been had they verified their instructions with one English speaker.

Overall, I found this blog post really informative since it highlights the basic and most important concepts of technical communication/writing. It is important to keep in mind the target audience for technical communication, or for that matter, any piece of writing. I will continue to keep these things in mind as I improve my skills to become an effective communicator.

Smayan Daruka

Summary: “The Problem with FAQs in Documentation” by Tom Johnson

Frequently Asked Questions (FAQs) are not Frequently, nor Asked, nor Questions. According to Tom Johnson, FAQs are annoying and a bad idea.

FAQs start out as a collection of random thoughts someone on the team has about the software. These questions do not need to be about the use of the software, some may be better served in an “About Us” Section. Once testing starts, more input from actual users leads to more questions cluttering the FAQ. After launch is when companies should be making FAQs, but this time is when the team doubles the section. Where this leads is a monolith of “documentation” that is unmanageable and unhelpful.

Much of Johnson’s critique of this model in the first section is on the effort it requires. An important quote is “The team member…cranks out quick responses to these random questions with about the same effort as typing an email.” From the standpoint of a technical writer, this is not the correct way to write documentation. The proper way, in Johnson’s opinion, is to analyze the user’s goals and weave them into a story-like structure.

This is something that the FAQ format ignores, and is one of the main points in the second section. Proper documentation should start with a goal and provide a walk-through on achieving it. This would avoid Johnson’s second complaint, which is: As the list grows, it becomes less manageable and ruins the user experience. This is a direct consequence of throwing all questions together into one list, as he says, “…the trivial questions dilute focus from the more important questions.” Point four says that the questions are only miscellaneous questions, while point five points out how they are rarely from the actual users.

Combining all these points shows the following: the questions are not frequent, as they could have occurred once (or not at all); the product team could have imagined them, meaning they were not asked; and because the product team wrote them, they aren’t even questions.

The reason that product teams use FAQs instead of proper documentation is because they are easy to write. In this section, Johnson ties back to the point he made in the first – the effort required for FAQs is not enough for actual documentation. He also suggests a pattern to use instead of the Question and Answer pattern: Goal and steps required to accomplism it. This goal-driven narrative is required for proper documentation, but as Johnson states “…the difference is that the answer to these goal-oriented questions will entail a heck of a lot more information and detail than the random FAQ,” which is something that project teams may not want to invest.

Overall, Johnson believes that there should be a switch from FAQs as documentation to user stories in the form of goals and steps. FAQs can be added after the actual documentation, but if a question makes it to an FAQ, the actual documentation should change to account for it. FAQs should be reserved for 5-10 questions that are frequently asked by users – not places to put the story of your company.

~ Connor Shade

Blog about Blogging

I have been thumbing through all the blogs that I am to follow to find something to write about.   I have decided that the very first blog I should write would be about a blog that talks about how to write a blog.  Not sure exactly how this is supposed to be written but I would like to explain the basic idea of the blog I read.

The blog was created and written by Cheri Lucas Rowlands about a blogger named Giles Jordan and what he learned in his first year of blogging.  In the post she explains that he found that having a decided time to post is important.  By being regular in your posts you can attract more readers.  Also having a good style of writing is important as well.  Making sure that you flow your desired information in an easy to read format so that more than just you would like to read it.  Writing for yourself is important but, if you want people to read it you need to write in a manner so that others would enjoy it.  Another important piece of information that she divulges is that in order to have a popular blog you would want to read other bloggers posts to get an idea of what they are writing about.  Having a successful blog to read can be a good training tool for you to follow to write a better blog yourself.  Reading other successful bloggers posts allows you to get a better idea of what works for you to get other readers to follow your posts.

One of the last things she hits on is the fact that just like writing a book you sometimes run into a point that you just can’t think of anything to write about.  Because this happens to most writers,  she recommends that you have a pool of ideas that you can go to for inspiration.  These ideas can be things you have written down in the past as notes or just ideas or other blogs that you may have started but just never finished.  This pool will allow you to pick up where you left off or even get your creative juices flowing so that you can start to write again.  This will also help you keep your blogs posted on a regular basis without big breaks in between.  Followers don’t care for the extended periods of time between posts and will eventually stop following you.

Overall, I found this post to be very helpful for someone that has no idea what blogs are even for.  The style was easy to read and follow.  Maybe someday I might think of actually writing a blog, although I might not get to many people interested in following it.

Richard L Battaglia

Summary of blog post “Don’t Twist the Prose”

Summary of blog post “Don’t Twist the Prose”

Leading Technical Communication By Larry Kunz


“Don’t twist the scissors in use. If the scissors are in the city Figure C in the way the clock pointer, the two shear bodies will squeeze each otherDamage: if it is twisted to the look of the clock in the opposite of the A, the time of the clockWill produce a gap between the two sides of the plane, and can not ensure smooth trim. Correct useShould be shown in figure B.”

Mr. Larry Kunz is planning his next years garden and just purchased a new pair of pruning shears. The accompanied illustrations and instructions introduced(seen above) in the beginning of his post are downright baffling. Kunz’s own words after the text is “Yeah. Wow.” Honestly, I am there with you Mr. Kunz, those instructions are a mess!

Although the instructions are confusing and unhelpful, an important point is identified. Kunz points out that “someone wrote this, honestly thinking they were conveying useful information.” It is true that no author sets out to befuddle and lead their reader to incorrectly use the instrument. Why then, would someone create this set of images and instructions to be printed on every package? Kunz believes, and I agree, the writer has “overthought the whole thing”. If the original message of the text is revisited, these instructions can be edited and updated to be of actual help to the reader.

Mr. Kunz points out the author’s message should have been ”For a smooth cut, always cut straight on. Don’t rotate the shears right or left.” This example is not only short, it is really easy to comprehend and follow. There is not confusing text clouding the reader from the main message.

Another important point that is addressed is the fact that this piece was most likely translated from another language. The most obvious clue is the confusing and jumbled text but the second clue is in the odd formatting. The words that are missing punctuation and a pace between are the result of two different word processing programs were used by the translators. When converting and opening files, the formatting of the document can be compromised.

It’s interesting that this piece was not reviewed and verified for clarity. Kunz assumes this could be the cause of too much expense, an inconvenience, or someone may just not care and ship the product anyway. The ultimate question for this product is do the instructions really matter? Will this confusing set of instructions affect customer loyalty or sales? The answer is most likely, no. The customer will continue to purchase the product, regardless of the instructions clarity.

Many of us have come across less than helpful instructions for the products we have purchased. Every time I purchase a piece of furniture that I need to assemble, I am faced with a similar issue. It is frustrating to try and translate the translation. A couple years ago I purchased an over the toilet cabinet from walmart. When I unpacked the box I was faced with a similar set of frustrating instructions. Because of the instructions, I built the piece of furniture incorrectly. This then has a chain reaction of lots of swearing and having to take the entire thing apart to start over because I screwed up step one.

I think that instructions are often an afterthought for many products, especially those that are needed to be translated into English. When creating instructions in my professional life, I always consider my audience and their level of understanding/education. At times it is important to create instructions from the perspective that the reader knows absolutely nothing about the topic. This is helpful for me in current projects as it covers every level of reader.