After getting feedback about the procedural nature of visual communication, the problem really became a "how" problem - best shown with a flow chart. Rather than realize that at the time, I just tried to adapt my original graphic, and to complicate it, I had mind maps, um... on my mind. So, I just provided a good example of using the wrong kind of graphic to communicate something. Doh! Oh well. Live and learn.
So, version 3 below is an attempt at more of a procedural "how" depiction. I suppose a true flow chart should conform to little boxes representing each process and arrows between the processes. But I've done so many typical flow charts in my former corporate life that I wanted to go with a more graphical depiction (plus I'm feeling lazy and want to recycle elements from the previous versions). I've also shown it as cyclical to try to show the iterative nature of it.
1 comment:
Hey Jeff,
I think this is a pretty useful model. You'll see in VizThink's soon to be released Visualization in Learning report that we use a very similar 3 steps. We actually add a 4th that talks about measurement. After all, how do you know if you've been successful or not, unless you measure (even informally). The 3 steps remain substantially the same.
As far as flow charts go, there aren't really any rules (except in specific domains). If you're a programmer communicating to other programmers, then an a standardized format is important so that people can quickly digest the information and start to recognize patterns (which aids in re-use) and illuminates potential problems (increasing quality). Outside of a specific domain like programming, the only requirements of a flowchart that I can think of are that you must have nodes, links, and the nodes and links must go in an order (or flow). So, by that definition, this is a perfect flow chart. Nice job!
Post a Comment