Everyone likes a diagram. Diagrams often help make an issue clear—except when they don’t. There are plenty of diagrams that really do not convey information to the viewer, and that is a sad state for any diagram to find itself in.
Maybe, just maybe, not everyone has the proper temperament to create a useful diagram? Before composing a diagram, the diagram-builder needs to be clear about what viewers of the created diagram should gain from viewing it. Data flow diagrams explore how data moves and is transformed by various processes that either exist or are planned. Viewers should gain an understanding about the processes and what data is moving. Similarly, a flow chart can articulate, in a very detailed fashion, the specific decisions and processing needed. These decisions should help an engineer know exactly the logic to be composed (or what was composed if it already exists).
These days, almost any formal diagramming technique is seemingly on life support. Folks prefer to simply grab a tool and put together what is on their minds without any restrictions. Composing a freeform diagram is not, in and of itself, necessarily a bad approach.
A freeform diagram may be fine, even great. For the circumstances, for the needs at hand, for the audience—is the freeform diagram expressing what is needed? Does the diagram express the correct message upon a first view? Or does a diagram only “work” if someone is there to talk the viewer through the intended meaning? Is this diagram something that will only be used when someone is there to talk the viewers through it?
These are the kinds of thoughts that must be considered if one wishes to determine whether a freeform diagram is successful. A freeform diagram allows people who are afraid of formal rules for diagrams to jettison their fears of doing something wrong: If there are no rules, then nothing can be wrong. However, that same freedom in symbol usage can be a problem. What the diagrammer intended may not be the same thing as what a viewer comprehends.
The viewer is the important element in any diagram. In whatever way that the viewer may perceive a diagram, that perception then becomes what the diagram means. Uniformity in understanding a diagram across a group of viewers is the true measure of success. And it is in this uniformity that more formal diagramming techniques shine. There are many varieties of diagrams, each of which is quite specialized for a specific circumstance and a specific kind of information conveyance: entity-relationship diagrams, data flow diagrams, flow charts, Nassi-Shneiderman diagrams, state-transition diagrams, and on and on. The “rules” of what symbols to use, what kinds of connectors are used, and the meaning behind each and every symbol are intended to help provide a uniformity of understanding across the IT community. Naturally, if the audience has never learned the rules for a certain kind of diagram, that shared understanding is lost. However, many diagramming approaches have only a few symbols to learn and are so focused in purpose, that teaching someone the rules can often be done quite quickly.
Both freeform diagrams and formal diagrams can be useful artifacts in describing solutions. One must play into the strengths needed to help drive how one approaches a diagram.
Freeform is more a fuzzy approach that will likely have a fuzzy reception by the viewers. For understanding a high-level concept, these more ambiguous elements may be perfect and useful.
When one needs to be more precise—as in defining how a process must make decisions, how several processes work in concert, or anything at a detailed level—a more formal diagram may be a better choice, as its standardization can help prevent miscommunications. Try to use an appropriate tactic, and don’t be afraid about learning and following a more formal technique, as many are far simpler than you may imagine. Try not to be fuzzy when you need to be precise.