All 4 books by Edward Tufte now in
paperback editions, $100 for all 4
Visual Display of Quantitative Information
Beautiful EvidencePaper/printing = original clothbound books.
Only available through ET's Graphics Press:
catalog + shopping cart
All 4 clothbound books, autographed by the author $150
catalog + shopping cart
Edward Tufte e-books
Immediate download to any computer:
Visual and Statistical Thinking $2
The Cognitive Style of Powerpoint $2
Seeing Around + Feynman Diagrams $2
Data Analysis for Politics and Policy $2catalog + shopping cart
Edward Tufte one-day course,
Presenting Data and Information
San Francisco, April 25, 26
Arlington, June 5, 6
Bethesda, June 8
Seattle, July 11, 12
Portland, July 14
Your conference in Palo Alto definitely raised the bar for my own visual representations of information. Quite a bit of my work involves traditional process mapping of business activities (usually multiple department or divisions), and I was wondering if you knew of any good examples of process map layout or design. I'd like to get away from the "10 Visio boxes" on a page that I so often see, in order to present a true map of complex interdependent processes.
-- Melissa (email)
Maybe my efforts to create a process map will help you. In my opinion it is good to create multiple levels in a process scheme. Here you find an simplyfied example of recent work for processes supporting a workflow (extracted from 26 visio files ;-): Mark
-- Mark Geljon (email)
I recently started working on a quality program in my company called six sigma. Process mapping is one of the exercises/tools we use in the discipline & there are many sites that have mapping tool discussions (isixsigma.com). I have my own summary (2minute viewlet) of the key things to identify in a process map & how to actually run such an exercise if you are interested. The key items that the example here are missing are players & phases. In any process (natural or "business") problems in can be more easily identified when the process has "linearity", that is, is as chronological as possible (i.e. the starting circle should be at the top and the ending circle should be at the bottom). Let me know if this helps or not! Take good care. Joel Mackall
-- Joel Mackall (email)
Rarely are processes -- business or otherwise -- truly linear. The more complex the process, the more dependencies and other constraints become evident. The method depicted earlier in this thread, then, seems a bit oversimplified (but maybe that's because this example didn't use real data?).
Generally speaking, to diagram a process, I use a data flow diagram (in acronym-ese, that's a DFD). This kind of design shows a process from the point of view of the data. There are just a few basic shapes: - circles, which represent processes - arrows, which represent data flows - boxes, which represent external entities - open-ended boxes, which represent internal/temporary data stores.
The method is to first create a "context-level" diagram showing all the external entities (i.e., the "actors" or users or other systems), and how the data flows between those entities and the process to be diagrammed, which is shown as a single circle. Further decompositions of that context-level diagram break the high-level process into lower-levels, and each of those can be further delineated on a separate page. Often a small-scale version of the first-level decomposition is included on the "drill-down" layers to help lend context to that particular layer. If I have some time, I can try to find a non-proprietary example.
Of course, this method is well suited to designing software to run systems, but not as useful when designing an interface. The best it can do in that case is to point out where the interfaces are and what data needs to be captured/communicated at that point (actually, that's probably a large part of interface design).
I've seen other diagrams similar to the method I use that add "swim lanes" -- processes are placed in rows depending on the person/system performing them.
-- Scott Zetlan (email)
I would suggest taking a look at UML (Unified Modeling Language) activity diagrams. This notation supports the use of swimlanes to show roles, as well as conditional decision points and parallel processing, which are not supported in standard data flow diagram (DFD). A very simple example of the UML activity diagram can be found on my company's site at http://www.tankainc.com/pages/projectprofiles01.html.
One of my few gripes about UML is its lack of support for diagramming data flow and entity relations for data modeling. In some cases, activity diagrams can be used to suggest data flow. However, activity diagrams, by their nature, express sequence and cause and effect, which may not necessarily be the intent when mapping data flow. Since the UML notation is designed to illustrate process, it also lacks representation for data stores. For this reason, I'm currently using DFDs for mapping data flow and UML activity diagrams for showing process in my work.
-- Brian McGurgan (email)
The design issues here are similar to those in the thread on project management charts. Redesign strategies for the chart above (eliminate heavy boxes, etc.) can be derived from the project charts posted on our thread
-- Edward Tufte