Contrariwise,' continued Tweedledee, 'if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic.”
― Lewis Carroll, Alice's Adventures in Wonderland & Through the Looking-Glass

That's the wrong way to think about it. Don't try to think about it all at once.
- Jeb Rubenfeld

A flow chart is a graphic representation of the logic of a deterministic process that can contain contingencies and repetition.

PREP: # Stoked & Zeckhauser, pp. 9-10
  1. Problems 71, 72
  2. Univ Plymouth, UK: Flow Charts for Simple Tasks: Tutorial with exercises
  3. Univ Plymouth, UK: Flow Charts for Classification: Tutorial with exercises
  4. (optional) Wikipedia Flow Charts
  5. Wirth, N. 1971. "Program Development by Stepwise Refinement." Communications of the ACM, Vol. 14, No. 4, April 1971, pp. 221-227. (OPTIONAL)
  6. About.COM: the IF Function)
  7. MS Excel Help: Switch between relative, absolute, and mixed references

Learning to draw a flow chart of an existing process or being able to read the logic of a process from a flow chart helps you to see the taken-for-granted and invisible structure of a process - the decisions that are built into it. It forces you to be explicit about what choices will be made within a process and to account for all the logically possible contingencies. Hewing to a particular discipline of flow chart drawing forces careful thinking at exactly those moments where the urge to hand-wave is strongest.

The flow chart to the left, for example, represents the logic of "keep writing research grants until you get funded and then do the research." Or, a little more pedantically: write a grant. If you get funded, do the research. Otherwise go back and repeat step one - go back to writing grants.

We will start with simple flow charts of processes with sequences and decisions and using flow charts to model classification processes. Then we move on to the representation of repetition. Then we will introduce the concepts of "black boxing," "step-wise refinement," and "deferring detail" as techniques for managing complexity. Finally, we will add time and space to flow charts to show how they can be adapted for project management tasks.


Imagine you are trying to explain how to do something. Perhaps you need to describe to a funding agency just how it is that your organization processes cases. Or maybe you just want to review with your housemate the steps that are involved in pulling off the dinner party you are having tonight. Or maybe she calls saying she has a flat tire on her bike and you are trying to explain over the phone how to change the inner-tube:

You: Don't worry, it's not that hard. You just remove the wheel and replace the tube. Do you have a spare? Is it the front wheel or the back? Do you have quick release hubs? If not you'll need a wrench. So you take the wheel off first. Then you want to remove the old tube. Oh, you'll also need some tire-irons. These tools should be in the utility bag on your bike. You do have one, don't you? Anyway, start just a short ways from the valve on either side. Carefully put thin end of tire iron under the edge of the tire rim from one side or the other and leverage it up. Then hook this tire iron on a spoke. Now take the other tire iron and do the same about 6 inches further, moving away from the valve, but don't hook this one. Then either slide it along farther, levering the edge of the tire over the wheel rim. Keep going until you reach the other side or the tire pops off the wheel. Then we put the new tube in. Then we inflate. Etc.

Perhaps the most important skill for solving complex problems is slow thinking. To cultivate this skill we need to learn to slow down, think step by step, and avoid getting mired (prematurely) in detail. Flow charts are one tool we can use to develop this set of skills.

Flow charts are also excellent vehicles for communicating the results of good, clear thinking in an unambiguous manner.

Let's get specific: a flow chart is a diagram that can represent a sequence of actions and deterministic alternative courses of action. What should be done, in what order, under what conditions. By "deterministic" we mean that nothing is left to chance - at each decision point, we assume we can ascertain what conditions hold and the flow chart tells us what action to take based on that.

They are also useful as representations of stepwise refinement or top-down design in which details are deferred in order to get the preliminary logic of a process correct without getting mired in minutiae. We'll look at this in the next section.

Examples of the kinds of things flow charts can represent abound: recipes, instructions, protocols, are contingency plans.

If a picture is worth a thousand words, a good diagram must be worth at least a million. Visual diagrams fulfill two important functions:

  1. reduce or tame complexity to permit focus on features of a problem relevant to the task at hand (it stabilizes my model so I know what I am thinking);
  2. externalize our understanding of a problem so that the same model can be subject to multiple cognitions (it permits multiple thinkers to think about the same object).

The second of these can be especially important when working with informants or clients. You show them a flow chart of your understanding of how a process works and walk through it with them. This often elicits insights on both sides (e.g., "No, it's not supposed to work that way" or "I never noticed that connection.")

Flow charts and their variants are among the most useful diagrams you will ever encounter. They can be used both prescriptively (a a protocol telling us what procedure to follow under different conditions) and descriptively (as when the organizational ethnographer discerns the factors that lead to decisions in practice) and analytically/diagnostically (to identify problems, suggest improvements).

There are three levels of competence in connection with flow charts:

  1. Being able to read a flow chart, understand what it represents, carry out the protocol it describes
  2. Being able to construct a flow chart based on information about a process or in while designing a process
  3. Being able to use a flow chart analytically to understand and manipulate a process

More generally there is a basic skill of being able to think logically about processes that comes with facility with flow charts. The techniques involved in making them are incredibly useful, general purpose heuristics.


A flow chart is a visual representation of a process, that is, a set of actions ordered in time.

The first element of process that it captures is sequence, the order in which a set of actions takes place. A to-do list is not a flow chart and neither is a list of alternatives:


Figure 1. Unordered lists are NOT descriptions of PROCESS

…but a description of how one spends one's day might be:


Figure 2. A sequence of actions can be represented as a flowchart

What makes this a process is that the individual actions are arranged in a definite sequence; this representation of our daily activities is meant to convey the fact that we shower before we drive to work and that we drive to work before we work.

Stop and Think: What temporal aspects of one's work day do the list and the simple flowchart show and what aspects do they fail to represent? (Hover over whitespace below to reveal answer)

By convention, actions, things that get done or happen, are represented in flowcharts with rectangles. The sequential relationship between actions is represented by arrows. Typically, time "flows" downward (or sometimes to the right) in a flow chart. A further convention is to put a small circle at the entry and exit points of a flow chart.


Figure 3. A simple flowchart

Decisions and the "Flow of Control"

Most real world processes involve contingencies: if it's a work day, get up and go to work, otherwise, sleep in. The power of flow charts comes from using them to represent the decision points and the way that alternative "paths" through a process are taken, depending on specified conditions (such as "is today a work day?"). This gives us some insight into just what it is that is flowing in a flow chart: control in the sense of steering our way through a series of connected action steps.

In a flow chart, a decision is represented by a diamond. We almost always work with binary or yes/no or true/false decisions. We call the basis of the decision a "condition." Thus, we say "if this condition is true then do one thing, otherwise, it is false and so do the other thing." A diamond will sometimes be referred to as an "if-then" structure. Figure 4 shows the flow chart for the sequence "Do the first thing and then, if CONDITION is true, do the the ONE thing otherwise (if CONDITION is false) then do the OTHER thing.


Figure 4. IF CONDITION DO the one thing ELSE DO the other thing

A decision like this represents a fork in the road. We come up on it, we evaluate the condition, and we take one or the other tine of the fork. In the flow chart, there is always one flow INTO the decision diamond and two flows out, one for yes (CONDITION is TRUE) and one for no (CONDITION is FALSE).
Our convention will be to always have the out-arrows can come from the side vertices (corners) of the diamond (makes charts easier to read) or from one side and one bottom (often helpful to save space or show the dominant pathway in a process). In either case, these arrows should always be labeled. If they are not labeled we will assume that arrows to the left are "yes" or "true" and to the right are "no" or "false." If we have one side arrow and one down arrow and no labels, we will assume the direction of the side arrow determines its logical valence.

Summary So Far

We have introduced four flow chart components. Rectangles which represent actions, diamonds which represent decisions, circles which are used as entry and exit points, and arrows that indicate the flow of control between entry points, actions, decisions, and exit points.


71, 72, 73, 74, 75 


Stepwise refinement is a term borrowed from computer programing. Briefly, it refers to the practice of designing software from "the top down" or, more accurately, "from the outside in." It is an implementation of the idea that you have to understand the big picture before you can implement the details.

Stepwise refinement is, for most of us, an unnatural act. We want to jump in and DO something right away, we want to be people of action. But when we jump right in we feel the gnawing anxiety of wondering where what we are doing fits in the larger scheme of things (or, at least, we should feel this). And it turns out that that bit of anxiety along with the fact that once you descend to the level of detail you literally cannot see the larger picture, together, lead to inefficiency, error, and failure to complete tasks.

Example 1

Consider this partial brainstormed list of things involved in getting a chicken dinner ready.

Cook. Clean house. Find table cloth. Set table. Get plates out. Choose recipe. Make shopping list. Shop for ingredients. Go to store. Chop vegetables. Preheat oven to 400. Vacuum dining room. Tidy up living room. Put out glassware. Put out silverware. Napkins. Roast chicken. Put chicken in pan.

As is common, the brainstorm has resulted in ideas (actually, things for our to-do list) that are at different levels of "detail" — some of them are "lower down" than others, or, we might say, some contain others. Let's arrange these hierarchically. In other words, let's identify which steps are a part of another step. One way to do this is to think of each action as a set of action:

\begin{align} Clean house = \{ Vacuum \hspace{3 pt} dining \hspace{3 pt} room. \hspace{3 pt} Tidy \hspace{3 pt} up \hspace{3 pt} living \hspace{3 pt} room\} \end{align}
\begin{align} Cook = \{ Choose \hspace{3 pt} recipe. \hspace{3 pt} Shop \hspace{3 pt} for \hspace{3 pt} ingredients. \hspace{3 pt} Roast \hspace{3 pt} Chicken. Do \hspace{3 pt} Veggies \} \end{align}
\begin{align} Set \hspace{3 pt} table = \{ Find \hspace{3 pt} table \hspace{3 pt} cloth. \hspace{3 pt} Get \hspace{3 pt} plates \hspace{3 pt} out. \hspace{3 pt} Put \hspace{3 pt} out \hspace{3 pt} glassware. \hspace{3 pt} Put \hspace{3 pt} out \hspace{3 pt} silverware. \hspace{3 pt} Napkins. \} \end{align}
\begin{align} Roast \hspace{3 pt} chicken. = \{ Preheat \hspace{3 pt} oven \hspace{3 pt} to \hspace{3 pt} 400. \hspace{3 pt} Put \hspace{3 pt}chicken \hspace{3 pt} in \hspace{3 pt} pan. \hspace{3 pt}Leave \hspace{3 pt} chicken \hspace{3 pt} in \hspace{3 pt} 400 \hspace{3 pt} oven \hspace{3 pt} for \hspace{3 pt} 90 \hspace{3 pt} minutes.\} \end{align}
\begin{align} Do \hspace{3 pt} Veggies = \{Chop \hspace{3 pt} vegetables. \hspace{3 pt} Cook \hspace{3 pt} vegetables.\} \end{align}

Level zero is just "Make chicken dinner for guests" (pink in the graphic). Below this, at the first level (green) we have "clean house," "cook," "set table," and "eat drink and be merry." At the next level (purple), things like vacuum dining room, choose recipe, find table cloth and roast chicken. At the third level (orange), we have the steps that go into roasting the chicken: put it in the pan, preheat oven, etc.


Our zeroth order flowchart would contain just the green steps — they are the first level of stepwise refinement.


For our next refinement, we can look more closely at a green step, breaking it down into its purple components.


And, next, we can take a purple level 1 step and break it down into its orange, level 2 sub-processes.



So what did we do here? First we brainstormed — just thinking about having folks over for dinner sets off all manner of task-thinking in our heads and so we don't fight it. But then we notice that there is some structure, some levels of generality/detail in these things. In fact, we can say that some of them "contain" others — some are steps within others. And when we group everything into a hierarchy of collections we can start to describe the process at the very top level (here it was 1) clean, 2) cook, 3) table, 4) enjoy).

We then treated each of these as if it were a "black box" — that is, a process that we didn't need to know the inside of — and we could just arranged these in the right sequence even as we knew that there were details to be filled in, we made the decision that the big prep tasks : cleanup, cooking, set up could be thought of as the three main steps.

Then, when it came time to think about cooking, we broke it up into four parts, one of which, "roast chicken," we knew had some other steps in it and so we just treated it as a black box, deferring details until our next step of refinement.

There are two important "skills" here — one is being able to recognize "levels" and the other is being comfortable leaving things in black boxes until it becomes necessary to unpack them.

Practice Problem

Consider your "morning routine" — all the things you need to do to get from being asleep to being in class. Brainstorm and list 20-25 things you do to accomplish this transition. Be deliberately "sloppy" and put things at different levels of detail on the list.

  1. Arrange the items hierarchically. You can use the set technique above, or the circle diagram, or just make an outline.
  2. Draw (on paper) a series of four refinements of a flow chart that represents this process. The first should use three sequential process rectangles. Each successive refinement should "blow up" one step from the previous refinement. You may have to "invent" new sub-processes if your original list doesn't have four levels (note that this is a place where we would use the word analysis — it's original meaning is "to break up into parts").

Example: Get up. Drive to school. Go to class. Start car. Follow usual route. If heavy traffic follow alternative route. Drink OJ. Eat breakfast. Shower. Wash hair. Brush teeth. Make coffee. Fill coffee maker. Perform ablutions.

Stop and Think: (1) Challenges to starting simple and high level, deferring detail? (2) Do you have a consistent level of detail in each version. (3) Where does the information for contingencies — diamonds — come from?

Stepwise Refinement

The thinking process described above can be converted into a deliberate strategy for designing or describing systems. The technique is borrowed from computer science where it was most famously described by Niklaus Wirth in the 1970s1. The technique of stepwise refinement is essentially one of mental discipline that can be expressed this way: "defer details." What we want to do is to think about systems or processes from the top down or outside in. Start with the least focused picture you can — ignore any urges you have to get mired in detail. One strategy is to start with the most generic form a process can have: a beginning, some action(s), and an end:


The usual convention is to draw a flow chart vertically with "time" running from top to bottom — that is, the process starts at the top and goes to the bottom. But it's just as well to turn the flow chart on its side and have things move from left to right:


What we do next is to "unpack" that box that says "action" one step at a time. Let's look at another example.


Suppose that our process is offer hospitality by which we mean to serve beverages — coffee or tea. The simplest flow chart would look like this:


Notice that we are deferring detail here. This might be called a "zeroth order" flowchart. It has an entry/beginning and and exit/end and there is an action step in between. Now let's image we can turn up the magnification one notch and ask what that action step consists of. In plain language: we ask whether our guest would like coffee or tea and then we prepare and serve accordingly.


Again, we are deliberately avoiding going into detail here. This is a general principle: defer detail. Don't worry, we are going to produce several iterations of most flow charts and we'll add appropriate levels of detail as we go along.

Any step of a process is subject to further refinement, of being represented in greater detail. What would be the next level of detail for the process of making coffee?

Some candidates: measure coffee, decide on beans to use, brew the coffee, grind beans, prepare dry coffee, boil water, add boiling water, get filter, add milk, add sugar. But these are not at the same level of refinement or detail. Some of them "contain" others. For example:

\begin{align} brew \hspace{3 pt} coffee = \{ prepare \hspace{3 pt} dry \hspace{3 pt} coffee, \hspace{3 pt} boil \hspace{3 pt} water, \hspace{3 pt} add \hspace{3 pt} boiling \hspace{3 pt} water \} \end{align}
\begin{align} prepare \hspace{3 pt} dry \hspace{3 pt} coffee = \{decide \hspace{3 pt} on \hspace{3 pt} beans, \hspace{3 pt} grind \hspace{3 pt} beans, \hspace{3 pt} measure \hspace{3 pt} coffee, \hspace{3 pt} get \hspace{3 pt} filter \} \end{align}

If we think only about one level of refinement beyond "make coffee" (remember: defer detail whenever possible) we might list

  • brew coffee
  • pour
  • add sugar
  • add milk
  • serve

But do we always want to add sugar and milk? No, only if the coffee drinker wants them. Therefor our flow chart is going to have to represent these contingencies. Here is the above flow chart with the single step, "make coffee," blown up into its next level of refinement:



  1. Start from the outside and move in. Top-down. Stepwise refinement. Defer detail.
  2. Strive for consistent "levels"
  3. Every unit/module has single entry and exit point.

Practice Problem

Draw a flow chart representing the task of getting home from work by car : (1) leave; (2) drive; (3) arrive.

It is easy to get lost in the complexity of nuance and micro-considerations when describing a process, the more so when you know a lot about something. The skilled flow charter is able to defer consideration of detail in an orderly manner. She might, for example, draw a first flow chart of the above process that looks like this:


And then she might think: "What is the NEXT level of detail here?" and think about the fact that getting home consists of three phases. One is getting to the car, putting books and such in the back seat, turning on engine, buckling up, selecting a radio station, and making her way to the campus exit. Then there is the getting home part. This involves selecting a route, perhaps making some stops, being subject to delays and such thrown at her by the rest of the world. And finally there is arriving at home, finding a parking spot, grabbing all of her stuff, locking the car, finding the car keys, etc. She has just articulated all manner of detail but defers thinking about these, instead refining the task into just three major sub-processes:


And what will be her next refinement. A good practice is to further refine just one thing at a time. Here she selects the "drive home" step because it's the one that has some real variation from day to day. Specifically, it involves listening to the traffic report on the radio and then picking a route home based on where the traffic seems to be worse. She doesn't detail her decision making process yet, but shows where it comes in the sequence of things.


Finally, she'll refine the "take the best route" sub-process. It involves using the information she gets from listening to the radio to decide between one of two routes. The question or condition she evaluates is: "Is 580 backed up?" Her "protocol" is "take highway 13 if it is, other wise take highway 580."


The figure below illustrates these four phases of stepwise refinement. Two things to notice. First, we refined one thing at time. The light blue trapezoids show how a step in a diagram to the left is refined (expanded) in next flow chart to the right.


Second, the new flow chart elements "fit completely inside" the element they are a refinement of. For example, in the third chart, the box "take best route" has a single entry point and a single exit point. At a certain point in the process we "enter" this step and then when it is done we exit. In the third chart, just what happens during the step is not specified; it is a so-called "black box." In the fourth chart this step is expanded, but notice that the "if block" it expands into has a begin circle at the entry point and an end circle at the exit point. These correspond to the single entry and single exit in the previous step.


Here we want to learn how to read and make flowcharts, understand the concepts of stepwise refinement, top-down design, and "black-boxing," and how to translate verbal (and ethnographic) descriptions into flow charts.

Adding (Organizational) Space and Time to Flow Charts

The horizontal dimension does not really represent anything (although we have a weak convention of "yes" to the left and "no" to the right out of decision nodes). We can impose on this dimension, then, our own interpretation. A common use of this is have the horizontal dimension represent "organizational space" — that is, different departments, divisions, or personnel. We create a column for each and then spread the parts of the flow chart out so we see what parts of the sequential process are carried out where.

This example shows a flow chart for making a coffee drink in a cafe.



We have the convention that the vertical (usually) dimension represents abstract time — actually only sequential order, what we might call "ordinal time." There's no reason we can't impose an interval scale on the vertical dimension and spread things out in terms of the time allotted or expected duration of tasks.



  1. Wikipedia articles on Flow Charts
  2. Flow Charts for Simple Tasks: Tutorial with exercises at Univ Plymouth, UK
  3. Flow Charts for Classification: Tutorial with exercises at Univ Plymouth, UK
  4. An overview by HCI consulting in Australia
  5. Gehani, N. 1981. "Program Development by Stepwise Refinement and Related Topics." Bell System Technical Journal, vol. 60, no. 3.
  6. Immigrant Crimes
  7. Life's Big Questions
  8. Wikipedia articles on Flow Charts
  9. Flow Charts for Simple Tasks: Tutorial with exercises at Univ Plymouth, UK
  10. Flow Charts for Classification: Tutorial with exercises at Univ Plymouth, UK
  11. An overview by HCI consulting in Australia
  12. Stoicism Flowchart
  13. An overview by HCI consulting in Australia
  14. Gehani, N. 1981. "Program Development by Stepwise Refinement and Related Topics." Bell System Technical Journal, vol. 60, no. 3.
  15. Wirth, N. 1971. "Program Development by Stepwise Refinement." Communications of the ACM, Vol. 14, No. 4, April 1971, pp. 221-227.
  16. Wikipedia articles on Flow Charts
  17. Flow Charts for Simple Tasks: Tutorial with exercises at Univ Plymouth, UK
  18. Flow Charts for Classification: Tutorial with exercises at Univ Plymouth, UK
  19. An overview by HCI consulting in Australia
  20. Human Subject Regulations Decision Charts at U.S. Department of Health and Human Services (HHS)

Included page "includes:lecture-tags" does not exist (create it now)