Design Rule #003—Go With the Flow

Whenever you start designing something interactive (and by my definition, a ball is interactive), you should start by designing a flowchart.

Especially if you’re building an IVR system.

I just spent a frustrating 12 minutes attempting to navigate a particular one. It was painful enough that I wanted to talk to a human, but was afraid finding the right option would have taken even longer than using the confusing robot.

I’m convinced many of the problems I had were because this IVR’s designers either didn’t draw any flowcharts, or did not let enough different types of people see and criticize them prior to coding the system.

A contributing factor is that their IVR design tools likely suck. The IVR I was battling with is from a very large company all of you have done business with, and I’ve seen the ugly inner workings of one such system used by another large company most of you have bought products from. It’s not even close to pretty, so I feel for the programmers’ who have to use these systems, but they are simply adding to their problems by not diagramming the flow graphically.

(An even more frustrating picture is when you as a tech writer attempting to document a security feature discover that the first and only flowchart about the process is the one being drawn on the whiteboard for you by the key SME.)

Making an accurate flowchart allows you to see problems with the process that would otherwise go unnoticed, and also provides a very good starting point for the structure of the program and the subroutines, functions, and modules needed.

And I don’t care how or where you draw the flowchart—in Visio, on paper, or on a whiteboard—but it must use the standard ISO flowchart symbols so that the flow is unambiguous, and it must be distributed widely.

A flowchart won’t solve all your design problems (how do you include a sneeze in an IVR flowchart anyway?), but it will help you discover many of the needs and problems.

Try it, and tell me how it works for you.