When creating diagrams, you may overlook some tiny, but crucial drawing details. And only after the review, you understand how important these details are. In this article, I will explain some of the most common mistakes when creating diagrams and how to escape them.
A well-drawn diagram communicates a very clear and direct message. You, as an Information Developer, can explain to users the workflow, interrelationship among components, or data exchange through visual assets. Diagrams are not just about cool shapes and trendy colors, but also about the meaning—text. In this article, I will share some important rules how to phrase, format, and position the text in a diagram to make it look more distinct and professional.
How on earth can anyone make sense of this technical review (see figure #1), apply mysterious comments, and deliver a valuable visual?
Figure #1 (Click to enlarge)
For an experienced Information Developer impossible becomes possible 🙂 How? During the technical review, pay attention how your SME corrects the following elements:
Today I want to share with you a brilliant post covering all the basics that an Information Developer should know about how colors work, brought to you by Dave Gash, a Technical Writer at Google.
In a nutshell, it’s a great read—both fun and educational—that explains how colors work. It’s all there – physics, optics, additive and subtractive color systems, hexadecimal arithmetic (!) and, most importantly, demonstration of how it all works together in real life (I mean, in a real-life CSS).
Believe it or not, CSS color codes really are intuitive. You’ll be surprised to see how obvious it is that “#000000 can’t be anything but black“, and “#ff0000 cannot possibly be anything but bright red“. On top of that, there’s a quiz, real-life CSS examples, and links to useful resources and tools, which all adds immensely to the post’s educational value.
Thanks to the author for gathering all this information and presenting it in such a fun and easy way! That’s rock’n’roll, folks.
Look at the following broken-line graph (Figure #1). How much time do you need to create one? 5 – 10 minutes? How about two days?
Figure #1 (Click to enlarge)
Now, if I provide an estimate of two days for creating a graph, my Customer will expect to receive a 3D visualization, in color. Then, where is the problem? Why creating a graph with a few broken lines might take that much time?
User documentation that includes different types of graphics is more effective and easier to perceive than monotonous text. A diagram is just one type of graphics that prevails mostly in technical documentation. When creating diagrams on a daily basis, you eventually learn to overcome such difficulties as: vague explanations, inaccurate SMEs’ drawings, abundance of details, or lack of information. As an Information Developer, you must know how to combine these diverse chunks to create consistent graphics in user documentation. In this article, I will discuss some tips on decrypting SME’s drawings to make the process of creating diagrams an interesting and creative experience.