Five Best Practices for Building Great Product Communication

If you handed a child instructions on how to tie their shoes, do you think they could tie them?

Could you?

1. Cross the left end over the right end.
2. The left end is now on the right side. Begin to wrap the right end around the front of the left lace to end up at the back of the gap between the laces.
3. Feed the right end through the gap to emerge at the front right hand side. Pull both ends tight to complete the starter knot.
4. Make the right end into a “loop” by doubling it back on itself.
5. Take the left end and pass it around to the right, going behind the right loop.
6. Continue the left end around the right loop to end up in front. Start to feed the left lace into the “hole” that has just been made.
7. With the left lace now through the “hole”, grab hold of both loops and start to pull the knot tight. Continue pulling on the loops until the knot is tied.

We can all agree that it is easier to learn by doing – in this case by experiencing what it is like to tie a shoe.   But if we can’t learn by doing, then having a visual guide with pictures can be a close runner up.  Visualizations make it much easier to understand how a product is used, assembled, or repaired. We are all too familiar with bad technical communication (assembly instructions, maintenance manuals, user manuals, etc.).  The worst offenders are instructions completely text based, with absolutely no visuals.  When I am given these, and I use the term loosely, “instructions” usually just get tossed aside while I attempt to figure out assembly myself.

As a technical communications expert, I try to adhere to five “Principles” for building technical communications, which I’m happy to share with you.

Cliff’s Five Principles for Building Great Technical Communication:

1-     Legos: Have you ever seen a Lego instruction booklet?  Simply sublime. Lego uses no words, and just shows the current design, and highlights the piece(s) being added.  Very Simple, very clear. Even my 8 year old son can build some of the most complex 500+ Lego sets with just a simple Lego instruction booklet.  Principle #1 (the Lego principle): Always highlight the part of interest.

2-     More Pictures, Less Text:  This one is quite obvious, but even I find myself using the images I initially created, then adding in too much text.  A good rule-of-thumb is:  If you use more than 3 sentences, create a new diagram, or image.

3-     Black and White:  I create all technical communications using 3DVIA Composer, so I usually use as much color as possible; however, I remind myself that documents are often copied into black and white, so I find other ways to place emphasis on the parts of the assembly. For example, If I have a part highlighted in a color, I should also add a thicker outline to the part being emphasized, as the color may not be recognizable after being photocopied.

Here is an example, with a part highlighted in blue:

Shaded Diagram

in color                            black and white

Outlined Diagram

in color                            black and white

*As you can see: the different rendering effects used make all the difference when the images are converted to black and white.  The highlighted object is still noticeable with the outlined diagram, but not with the shaded diagram.

4-     More is More:   “Less is More” is the more common phrase, but when it comes to technical communication, you can never provide enough detail (in pictures, not words).  You know the product in-and-out, but the final user will not.  Give them every amount of detail necessary.

5-     Un-biased Test:  I like to think that I can test my own documentation, but this is never the ideal solution.  What is obvious to me may not be for someone else.  Being under deadlines means we often skip this critical step. But do yourself a favor, and the end user one as well, and have several unbiased people test your documentation.  It’s the best way to be sure it is clear.

Obviously I use 3DVIA Composer for technical communication documents. When I speak to SolidWorks users who have not tried Composer, I often hear that: 1) they don’t have the time to learn another tool, or 2) they are fine with the tools they currently use (which are tools which take much longer to produce lower quality technical communication).  I probably thought the same thing before I used 3DVIA Composer, but I would encourage you to give it a try.

For more information on 3DVIA Composer, click on the images below to view 3DVIA Composer videos:

1)     First Look at 3DVIA Composer Video

2)     3DVIA Composer User Manual video series (you will need to register first):

Please share your thoughts or other technical communication principles in the comments below…

-Cliff-