3 things technical writers can learn from screenwriters

Photo by rawpixel.com on Unsplash

A few years back I took a screenwriting course through Georgetown University School of Continuing Studies.

It was a challenging course. The professor had a bit of an ego so I didn’t get as much out of it as I had hoped. Recently, I came back to some of the lessons I learned in the course:

  1. Write the picture. Screenwriting is all about telling the story in pictures. After taking this call and reading some screenwriting books, I am definitely rethinking how I approach article writing and technical marketing communications. Heck, for that matter, I may rethink even how I write procedures and product descriptions depending on the document. It’s been a wonderful creative exercise thus far and is pushing to make time for more creative writing into my schedule.
  2. Elicit emotions. Once upon a time, I was a college English Major who won campus wide awards for short stories and poetry. It feels like a lifetime ago after years writing about topics like network architecture, telephone number provisioning, and online collaboration. Technical marketing communications does need to elicit some emotion in order to elicit action from the reader.
  3. Get into the details of the story. It’s no secret that I rail against the so called technical writers who think they don’t need to be conversant in the subject they are writing about. Screenwriters spend time researching at the script treatment and scriptwriting stages so they can tell their story.

I’d like to return to screenwriting at some point and still find myself looking for another course to try.


Hi! My name is Will Kelly. I’m a technical writer and analyst based in the Washington, DC area. I’ve worked with clients like NetApp, Dell, and Neustar to develop technical, training, and thought leadership content. My articles have been published by IBM Mobile Business Insights, TechBeacon, CNET TechRepublic, Network World, Toolbox.com, ZDNet.com, and others. Follow me on Twitter:@willkelly.

Does Microsoft Office need an evangelist inside your enterprise?

Image from Microsoft News Center

Often Microsoft Office suffers from a lack of credit (and support) despite the fact that it’s at the core of many business processes. It’s easy to brush it off as being Office.

It’s important to consider that Microsoft Office as an application suite continues to grow from its humble beginnings as bundled desktop applications to a business front end for knowledge workers.

One of the must humbling projects in my career was at a major federal government agency that was upgrading to a new version of Microsoft Office. I got to see firsthand how Microsoft Office impacts the day to day jobs of workers at all levels of the agency. I saw even a simple change in the product could stop some users cold in their tracks. After that contract, I’ve had to tackle Microsoft Office adoption and user issues on other contracts. I still wonder if Microsoft Office needs its own evangelist

Here are five reasons why Microsoft Office needs an evangelist:

  1. Promote the use of sharing and collaboration tools. The Outlook inbox has been the primary tool for sharing and collaboration in many organizations. Now sharing documents through SharePoint or OneDrive, means many users need guidance for new workflows.
  2. Promote the use of new features in the applications. With each new release of Offices comes productivity enhancements. When a new Microsoft Office release hits corporate desktops, there needs to be someone to work with the users to adopt new features.
  3. Evangelize OneNote and its potential uses in the enterprise. OneNote has a lot of uses inside an organization such as collaborative note-taking. You can even use OneNote for publishing team policies and procedures. While OneNote as part of the Office suite speaks to a bright future for the application, users may still ignore it because of they’. Before, you had to buy OneNote separately meaning it was a rare occasion to see it on corporate PCs.
  4. Standardize templates and macros. The term “template” can get thrown around pretty liberally when it comes to Microsoft Office document. An internal champion for Microsoft Office can assist with template creation. They can also help with template management. An Office evangelist can be a big big help to Office users locked in a vicious cycle of cut and paste corrupt document hell.
  5. Guide mobile users to Microsoft Office. Being able to access Office documents from Android and iOS devices is bound to be a productivity tool for some users. A Microsoft Office evangelist can help lead the move of Microsoft Office users to the mobile apps. They can become a trainer and an advocate for taking Office apps off the desktop.
  6. Ensure Microsoft Office document security. If your organization sends documents to external parties, it makes sense to secure the document data. Somebody needs to educate document writers and publishers about document security.

Do you have a Microsoft Office Evangelist inside your enterprise?


Hi! My name is Will Kelly. I’m a technical writer and analyst based in the Washington, DC area. I’ve worked with clients like NetApp, Dell, and Neustar to develop technical, training, and thought leadership content. My articles have been published by IBM Mobile Business Insights, TechBeacon, CNET TechRepublic, Network World, Toolbox.com, ZDNet.com, and others. Follow me on Twitter:@willkelly.

Do organizations need technical documentation style guides?

Photo by Oliver Thomas Klein on Unsplash

Do organizations need technical documentation style guides? It’s a question that rises on online forums every so often. Today’s ever-tightening workplace budgets should also put the role of the technical documentation style guide under the spotlight.

My answer to the style guide question is “Yes, organizations do need a style guide, but it shouldn’t dominate the documentation development life cycle.”

With the prevalence of online documentation and the web to deliver information plus more iterative development and launch cycles, the style guide should foster productivity and consistency not stand as a roadblock in the way of technical writers and training developers making deadlines.

My Concept of a Style Guide

Over the years, I’ve become a fan of more lean style guides. Cover the basics of product naming, corporate branding, and anything industry/audience specific and leave the style guide at that. The document should be in a quick reference format, and all document authors should be briefed on the style guide before being let loose on a technical writing project. Sure there are many things that such an approach to style guides may leave out, but that is where standardizing on an industry style guide like the Microsoft Manual of Style for Technical Publications or ReadMe First!.

Decision Making about Styles

Indecisive decision making over stylistic issues is boorish and counterproductive, and in the end, there is no benefit to the document, project or end client. Running with a lean style guide means the occasion may arise where a stylistic decision is made on the fly.

This only works when a senior writer or editor is given ownership over stylistic decisions. Any stylistic decisions must be documented in a style guide update. Having one “keeper of the style guide” avoids dragging out stylistic decisions by committee.

Know Thy Audience

Just like writers need to understand their audience for the documents they are writing, this understanding needs to carry over to the style guide. If the style guide serves up too many items that are lost on the reader of the end documents, then the style guide is ineffective.

Likewise, if the writers tasked to follow the style guide have issues understanding it then the style guide also fails. If the style guide is full of contradictions, it fails again. The style guide is a supporting document, and when that is forgotten, the style guide fails.

The style guide should be a guide not an obstacle to publishing documents.


Hi! My name is Will Kelly. I’m a technical writer and analyst based in the Washington, DC area. I’ve worked with clients like NetApp, Dell, and Neustar to develop technical, training, and thought leadership content. My articles have been published by IBM Mobile Business Insights, TechBeacon, CNET TechRepublic, Network World, Toolbox.com, ZDNet.com, and others. Follow me on Twitter:@willkelly.

Is “3” the answer to many of your document problems?

Photo by Tobias van Schneider on Unsplash

I’ve spent the better part of my professional career as a contract technical writer. During that time I got the chance to examine why some organizations struggle with their technical documentation. With limited resources and budget, it is sometimes too easy to shortchange technical documentation and other written communications. With some realistic planning, this doesn’t have to be the case.

Recently, I was talking with a marketing consultant friend of mine, and we were discussing documentation problems and how small companies could get past them. The number “3” kept resonating for some reason.

  • Three drafts because in the end any more drafts like that aren’t going to improve the document much and anything beyond that can dunk a project schedule underwater unnecessarily.
  • Three document review cycles before declaring the document final because beyond that mean splitting hairs over minor issues that may not be picked up in the final product anyway.
  • Three sets of eyes on the document because even two sets of eyes can miss something.

Granted our discussion centered on developing technical documents on small project teams but do you think “3” is the answer to many technical documentation problems?


Hi! My name is Will Kelly. I’m a technical writer and analyst based in the Washington, DC area. I’ve worked with clients like NetApp, Dell, and Neustar to develop technical, training, and thought leadership content. My articles have been published by IBM Mobile Business Insights, TechBeacon, CNET TechRepublic, Network World, Toolbox.com, ZDNet.com, and others. Follow me on Twitter:@willkelly.

My Microsoft Word template manifesto


For reasons that continue to elude me, I’ve come across a lot of Microsoft Word template issues in my time. Some templates were so bad that what should be a simple productivity tool ends up hobbling documentation efforts. Finding template issues is a never-ending source of disappointment for me. Perhaps it’s because I usually create templates in the early stages of a project and keep the fuss to a minimum.

Though along the way, my Microsoft Office experience and published writing credits on the subject got me put on some projects where I supported the rollout of Microsoft Office and saw how end users (who weren’t technical writers) used the applications and their varied levels of understanding.

These experiences got me to put together what I am calling my Microsoft Word Template Manifesto:

Templates are a productivity tool

Word templates are productivity tools. They should never be an obstacle in the way of creating and publishing documents. A proper template does the driving when it comes to document design and formatting so the author can focus on writing and editing document content. Templates should never stand in the way of author productivity.

Templates should govern styles

The Word template is in place to govern styles in a given document format. Take the time to ensure that your template also has the necessary style formats, so users don’t have to format anything in their documents manually.

Templates should be lean with few extraneous styles

Keep your templates lean with only the styles that are needed in the document. Additionally, factor in the time to maintain the templates over the long haul, so they remain a productivity tool versus

Templates should include a job aid

Using document templates isn’t second nature to everybody. I’ve long been a proponent to include a job aid or cheat sheet with templates I create so everybody is using the template styles in the manner they are intended.

Styles guides should document template usage

There can be nothing more irritating to new and grizzled document authors alike than document templates not matching up with the documentation style guide (provided your organization even has one of these!).

Templates are *dotx files and installed on the local hard drive

I’ve inherited templates of varying shaded and interpretations so I long ago came up with my own rather unoriginal and vanilla standards for template usage which first and foremost is that a template is a *.dot file that is installed locally on a hard drive.

Templates are for novice users too

It’s easy to think; it’s just Microsoft Word. I was guilty of falling into that trap because working as a technical writer means I live in Microsoft Word most days (and evenings). Templates need to be easy to use and follow so users of different Word skills can use them independently. When users get frustrated with a template, they may attempt to iron man their styles thereby introducing inconsistencies that may or may not get picked up in the editorial process or by a reader farther down the line.

Templates need love too

There needs to some ongoing maintenance and monitoring of any templates an organization uses for documentation. This ensures that no issues have cropped up and authors are correctly using the templates.


Originally published at willkelly.blog on November 12, 2017.


Hi! My name is Will Kelly. I’m a technical writer and analyst based in the Washington, DC area. I’ve worked with clients like NetApp, Dell, and Neustar to develop technical, training, and thought leadership content. My articles have been published by IBM Mobile Business Insights, TechBeacon, CNET TechRepublic, Network World, Toolbox.com, ZDNet.com, and others. Follow me on Twitter:@willkelly.