3 Microsoft Word template decisions to avoid


Microsoft Word templates can be an incredible productivity tool. Templates ensure a consistent look and feel across your documents. Using a template frees you up to focus on other things about the document you are writing.

Yet, Microsoft Word templates can also be a productivity sinkhole if you aren’t careful. If you don’t put some thought into how you manage and use the template.

Here are three Microsoft Word Templates you should always avoid:

  • Don’t deviate from default style names. It’s OK to create templates from scratch but for styles like headings and others that are common across documents, I recommend not deviating from the default style names. It is ok to modify them to your heart’s content, but deviating from default style names can pose problems later when you want to update the document template like during a rebranding. Sticking to default style names whenever possible means when attaching a new template. Sticking to such style names is also helpful because they are what people are used to working with if they pay attention to style names at all.
  • Don’t forget to attach the template. Working as a technical writer puts me into contact with a lot of legacy Microsoft Office documents — often times with no sign of the original template (*.dot) — raising a number of sundry issues like styles “shifting in flight” thus appearing differently on different user’s PCs. When working with clients encountering MS Word document issues, no template attached to the document is almost always on the list.
  • Don’t “Iron Man” your document styles. One of the marks of a poorly planned document template is missing styles. causing users to make modifications to document styles manually (otherwise known as “iron man”). Such modifications can introduce inconsistencies plus stray styles into your MS Word template that will haunt writers who inherit the document for generations to come. The advice I often give to clients about Word templates is to keep them simple especially if the organization doesn’t have a full time writer dedicated to the project or the documents are being shipped around to non-writers a lot.

What are your tips for managing and using MS Word templates? Share them below.


My name is Will Kelly. I’m a technical writer and content strategist living and working in the Washington, DC area. My current focus is thought leadership and technical marketing content. I got my start writing user guides, administrator documentation, online help, and later moved into SDLC documentation. My articles about enterprise mobility, BYOD, and other technology topics have been published by IBM Mobile Business Insights, Samsung Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.

Things they don’t teach in technical writer school

Photo by Feliphe Schiarolli on Unsplash

I got my start as a technical writer before any formal technical writing degree programs got their start. While college gave me a solid foundation, much of what I know today, I learned by actually doing the work. Regardless of what professors say, there is no substitute for actually being out there and doing the job.

While it’s rare for me to work with junior technical writers anymore, I have had a lot of opportunities to collaborate with non-writers on documents. This got me thinking as to what I learned on the job versus what I learned in school. Understanding organizational dynamics and people skills were something I had to learn once I was out of college.

Here are some things they don’t teach (but should) in technical writer school:

Programmers are lazy (but in a good way)

If I had my way, I would work with programmers all the time because some of my absolute career highlights have been working directly with software development teams. They are lazy. But in a right way mind you. The way many of them reuse code and use shortcuts should be a model for the rest of us mainly technical writers.

Following on the “programmers are lazy” model, technical writers can also learn about program elements by studying similar items in the same program. While this is a simple concept to some people, I have come across some who never considered this angle. Understanding how programmers work including how they design and implement program features can help a technical writer immensely by shortening their learning curve on new projects and help them contribute more throughout the development process.

Microsoft Office doesn’t always work as advertised

As a technical writer, you may have to spend more time just getting Microsoft Office applications to work as advertised especially if you stumble onto a hokey implementation. This means that a fraction of Microsoft Office troubleshooting skills can help a technical writer shine especially if the help desk is more focused on closing Remedy tickets than actually resolving user problems.

Technical writers need a grasp of the concepts they write about

While a technical writer doesn’t need to be a technical expert, they do need to be able to learn new software and technical concepts to write their documents. If technical writers are dependent on drafts from SMEs to do their work, then they are not a writer. Organizations setting this as the status quo for their technical documentation need to reassess the role of technical writers in their development efforts.

Questions should be targeted not broad

Leading off with only broad questions is a waste of time. Question asking can be an art when you consider a technical writer may stumble into some project element that hasn’t been fully thought out by the rest of the team. Asking the right questions can help drive the documentation especially if the technical writer has a grasp of the technology underlying the project.

Artificial barriers to information are just an invitation

If an artificial barrier is put up between a technical writer and information, it should serve as an invitation for the technical writer to work around it. This means a technical writer needs some people skills, charm, and a talent for seeing the angles to work when faced with such a situation.

Meeting Minutes are for suckers

My views on meeting minutes in the workplace are well documented. Technical writers should never volunteer to take meeting minutes or see it as some “key to the inner sanctum.” Once programmers see a technical writer taking meeting minutes, then they automatically equate them with being a secretary. Not that there is anything wrong with being a secretary but a technical writer needs to sit at the same table as the programmers and not let themselves get minimized into what is traditionally a very nontechnical support role.

While I welcome formal technical writing programs to the fold, I’ve never really been very trusting of academia but hope these programs keep their feet in reality and don’t fill their students’ heads with nonsense that has no direct application in the real world of today.

What else do schools need to teach to prospective technical writers?


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, Toolbox.com, ZDNet.com, and others. Follow me on Twitter:@willkelly.

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.

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.