We’ve all been there. You have to get a job done fast but you don’t have the tools you need. So you improvise with what you do have. Often you end up spending more time than you want to on a result that’s barely good enough.
And that’s understandable. If you really need something done, there’s no choice. As someone said to me recently, giving the old quote a sharp pragmatic twist, “If a job’s worth doing, it’s worth doing badly.”
It’s something that, at Canvas, we hear about a lot in relation to the creation of technical documentation. Some of the accepted workflows out there are just plain scary.
The good news is that there’s always a way to improve things, and you don’t have to tolerate awkward and clumsy workarounds and sub-standard visual technical communication.
So we put together a list of what we consider to be some of the Worst Workflows we’ve seen in technical documentation out there in the real world. As I said, this stuff has to get done. So no blame, no shame.
This is a big one and we hear of it often. Creating high quality technical documentation requires a range of content. Text, photographs (or raster images), vector graphics, tables, callouts and annotations, visualizations of 3D models and so on. We’ve met people who have been using Photoshop to edit raster files, Illustrator to manage graphic elements, Word to manage text, and so on.
All these applications are great – but none of them are designed specifically to create the best possible technical documentation. Worse still, working with multiple applications is time consuming and can be unnecessarily expensive
End to end technical content creation is what Canvas does
Err – no. To describe scanning old hard copy manuals and inserting the resulting images into word documents as sub-optimal is an understatement.
This is not the most effective way to communicate essential visual and textual data. But it’s something we have encountered more than once, and at some surprisingly large and critical organizations.
3D CAD models hold a wealth of illustrative potential, both in terms of model visualization and the associated model metadata. So relying on screengrabs from CAD packages as a way of visually representing models is fraught with problems. Separate screen shots for every view, from every angle, of every possible configuration of rotated, exploded, ghosted, and hidden parts soon mount up giving you folders of images to wade through. And if you don’t have exactly what you need, it’s back to your CAD colleague to get another one.
This is a huge time-waster, often involving two or three people stood around a single machine, debating views for various purposes (which is hardly good social distancing etiquette), and tying up expensive CAD talent unnecessarily.
Nothing against PowerPoint, it’s great at what it’s designed to do. But it’s not a technical documentation tool. To expand upon the previous example, we’ve seen people using screengrabs from CAD packages and then annotating them in PowerPoint using lines and text boxes and, in some examples, manually creating magnified lens views of particular parts of the screenshot in a bid to call attention to a specific area.
Think about what that involves: You import and place the image. You copy the image, expand and crop it. You fit it into a circle or a square to mimic a lens. You mess about making sure it doesn’t distort when you apply it to the shape. Maybe you Google how to fix that. Then you place that new image, draw a line, add some text, play with the positioning. Colleagues nearby begin to wonder why you’re cursing under your breath… But it has to be done.
See how to create instant annotations with Canvas
These are just four examples we’ve come across of people working harder than they need to, for longer than they need to, to create critically important documentation. All because they aren’t using tools which have been designed for the job.
It doesn’t have to be that hard. Just use Canvas. Technical documentation is what it was designed for.