A Picture is Worth . . .

Great User Requirements Rule # 4:  Show a picture

Descriptions are great, but process maps can show so much more detail.  They also provide a way to ensure the entire process has been thought through.


The above cartoon has been around so long and there are so many derivations, I have no idea who should get credit for the original.  It is a great reminder that no matter how well a deliverable is described, there will be some critical details missed.  I often wonder what the original description was that led to so many interpretations.  Here is my guess; “We need you to construct a seat attached to this tree with the capability of moving in multiple directions to create the sensation of swinging for enjoyment purposes.”  To avoided the mess above, a lot of words would need to be written to properly describe what the customer needed.  That is not a task I would relish.

Architects use blueprints to confirm the customer agrees with a building design and to guide the work of the contractor.  Implementing a software system should be no different.  A customers needs can be easily reflected in a process map showing how work will be performed in the software.  The things I look for in a good business process map:

  • Business process focused – It does not try to show desired software features.
  • Recognize that rational people perform the process – The objective is not to program a computer.  People with brains, making rational decisions,  will perform the processes.
  • Shows the baseline process – Showing every possible exception is counterproductive.  Show how the process should work and any major deviations that routinely happen.
  • Neatly drawn – Crossed lines, reverse flow of logic, misaligned shapes, and other sloppiness make it difficult for someone to quickly grasp the concept of what is happening.
  • Easily understood – Anyone familiar with the business should be able to pick up the diagram and understand how the work is being performed.  Content that requires the reader to remember something from a prior discussion is insufficient.  Words should be kept brief and precise.  Two words (one verb and one noun) is ideal.
  • Supplemented by text – Text can be used to describe information about what happens in a process step.  This could be how decisions are made by the person performing the task and how exceptions are dealt with.
  • Consistent level of detail – Each process step should be at a similar level of detail.  For example, a process map with steps of “Receive Goods” and “Sign Name” are different levels of detail.
  • Decomposed – Process steps too high-level to fully communicate a concept should have a more detailed process flow to show details.
  • Contains simple shapes – The fewer shapes the better.  The reader will not be able to understand or remember the meaning of many shapes.  I like to stick with five: rectangle, oval (start/end), diamond, on-page connector, and off-page connector.  Sometimes I even drop the diamond decision symbol and have multiple labeled lines come out of a process flow, which is clear that a decision was made within the process step.
  • Logical flow – A properly developed process flow will help ensure the process is fully documented.  All process steps should lead to another stop or a start/end.  Decision diamonds have at least two outputs.


Here is a simple example that demonstrates the above rules.


Notice how everything flows left to right.  When the first line reaches the end of the available space an on-screen connector is used to resume the left-to-right flow.  The lines are straight and boxes are aligned.  Process steps follow the verb-noun convention.  There are no orphaned process steps; “Rejected Delivery” goes to a terminator and “Sign for Delivery” goes to a connector that leads to another process flow.

The process is baseline, only showing major and routine exceptions.  For example, “Look Up Purchase Order” does not try to explain the logic if the PO cannot be found.  The process step “Confirm Delivery Matches PO” could be be either decomposed into a detailed diagram or a text work instruction could be provided.

Thorough process mapping can become complex as the number of flows increase and the many connections between them need to be accounted for.  This requires some organization that will be discussed in later posts along with more advanced process mapping techniques.

The old saying “A picture is worth . . .” is undeserved by the normal ending.  I would argue it should be more like “. . . ten thousand words.”