Can Technical Documents Have Flare?

When most people hear technical writer, they automatically jump to “they like to write.” Yes, writing is a large part of the job. Technical writers often have to take complex ideas and break them into digestible chunks for the end user. But this is just part of the document creation process. Our job is to engage the user and only having blocks of words on a technical subject will make a user close a document quickly. They key is to not only inform the reader in a concise manner but also keep their attention through graphical means.

This is by far my favorite aspect of the field. Document and information design is almost an art. What colors to use and when, where to take the reader’s eye, and actually keep them wanting to return to the document when needed. It sounds simple enough: add some colors, screenshots, and boom you are done. I wish this was the case. Let’s look at the Apple Watch. If you’ve ever opened this product, it looks and opens like origami. Even the technical documentation (aka instructions) are minimalist, using a lot of white space, color graphics, and concise instructions. This is a good example of bringing a style of flare to a technical document. Marketing materials for technical products are another example of technical documentation having lots of flare. Usually there’s vibrant colors, multiple fonts, and graphics to catch the eye.

Now flare does not have to be limited to Silicon Valley or marketing products. Even something as dry as virtual machine deployment guides can have flare to them. Here are the steps we take to liven up technical documents:

  1. Could this be a quick reference guide?

    Sometimes information does not need to have six pages in total just for a page or two of content. If the content can fit front and back with high quality graphics, then try out a quick reference guide. Also incorporate corporate colors/logos of your company or the customer. We find customers love these as it’s simple to hand out, less printing costs, and point out the essentials.

  2. Use graphics.

    Nobody likes to see just text, especially when it comes to technical information. Most people would rather figure it out for themselves. Ensure the technical documents have high quality graphics (PNG) to accompany the important/confusing steps in the process. We still come across technical documents from major manufacturers where the menu items are fuzzy and/or too small to read. This will not help a user. If there are a lot of menu items or code within a screenshot, you could always highlight or box out the information being referenced in the steps.

  3. Structure the information.

    As mentioned earlier, structuring information is sort of an art form. With enough practice, however, you can learn what feels natural for eye movement. One consideration is how the language is read. English is from left to right while Arabic is right to left (text), which can affect the placement of content. We have found success by starting in the top-left with text (English readers) and have graphics to the right. After that, each group of procedures alternate almost forming a snake type pattern. Modern designs also include blocked areas using color to differentiate processes.

  4. Colors

    Seems self explanatory but we have seen some interesting color combos here at TechDocs. Companies typically like to their colors on documents, so this is always a good start. Logos can also be used to make the branding complete. To prevent distractions to the eye, usually you will see the headers and footers given the most color treatment. Colors can also be used to point out information like “Tips,” “Warnings,” etc. We recommend avoiding any colors that would be harsh on the eyes….sorry, no unmellow yellow for you crayola fans.

  5. User Tests

    Yes, this is important. No matter how well you think your layout and color scheme looks, the customer might not agree. Remember, technical writing is a very subjective field. It is always best to come up with some drafts of the design and run it by the customer first. This will save everyone time and money. If it is an incredibly quick turnaround—24hrs or less—then we would recommend multiple versions to pick from. You may not have the perfect setup, but at least the customer can determine which way is the path moving forward.

We have mentioned how technical documents can indeed have some flare and provided some tips to do so when you are faced with having to create a technical document. TechDocs always try to make our documentation engaging for the end user as that is the best way to ensure they get the information they need. We hope that others will follow this thought process when creating their documentation and refrain from the blocked text approach.

Have you seen really good or poor documentation? Link us in the comment below. We would love to see what has caught your eye, whether good or bad.