How To Make A Fantastic & Informative Flowchart

For anyone who has ever needed to make a flowchart, they can seem like a daunting task, especially when they become harder to read as they become more complex. If you need to make a complex flow chart, below are some guidelines for how you can make them easier to read for your audience.

These are not hard and fast rules, but they should generally be followed as well as possible. These rules do not necessarily apply to things like technical diagrams, but many of them can be used for technical diagrams that can get quite messy.

Rule 1. Multiple Arrows:

When multiple arrows originate from one shape, they should come from a decision point, which is typically indicated by a diamond AND when they come from a diamond, efforts should be made to make them come from multiple sides. If they have to come from one side, they need to come from the same point. This is the longest rule, so don’t worry, they’ll get shorter as we go.

So let’s chat about these rules. The reason we create a decision point even when we don’t necessarily need one, is to prepare the viewer to know that we will be branching into different directions. You will have spots where something asks, “How do they log in?” and then you can proceed to show each of the ways in which a user will log in.

The reason we have them come from multiple sides rather than the same side is that it makes it visually easier to come back to when you have multiple arrows, and it makes it easier to give yourself breathing room while making the flow chart. In the event that you need to make them come from the same side, then you need to make them come from the same point. Why? Because it looks messy and unprofessional if they are just slightly off from each other.

Rule 2. Words on Arrows:

When words are entered on an arrow, they should be close enough to the point of differentiation that you don't need to move your eyes to see them. Oftentimes, when you have a point of differentiation that says something like, “Did the payment succeed?” followed by a yes and no scenario, you will place the Yes’s and No’s on the arrow instead of wasting space with a whole box.

Any time that you need to do this, your Yes’s and No’s should be as close to the point of differentiation as possible, ESPECIALLY if you have more than two options. Like “What color did they pick?” Red, green, blue could be the options. Red means the bomb explodes, Green means the timer on the bomb in the action movie speeds up, and blue means you successfully diffused it.

In this scenario, red, green, and blue on the arrows close to the point of differentiation makes it so that I don’t need to go searching for what choice was made along the flow chart. That being said, in the scenario of color choices, I might just make the arrows red, green, and blue.

Rule 3. Shape Assignment:

Tasks should always have a designated shape associated with them. As mentioned before, I use diamonds for decision points, and I also use this quadrilateral shape to indicate an action that someone took, like “I click on the submit button.”

I tend to use this wide cylinder for any type of database entry, and I use rectangles for processes that happen, like “a timer appears on the screen.”

If you’re going to use a quadrilateral for user actions, then always use the quadrilateral for any user action, and if you want to designate different users performing an action, then you can use another color rather than using a separate shape. The other part of this is that you don’t want an event to be listed on an arrow. If I ask the question. “Did they type the correct password?” then Yes and No can be listed on the arrows as designators, but you wouldn’t want the next action taken to be listed on the arrow. That action, event, or task should get a shape.

Rule 4. Shape Rules:

The role that a given shape has should be consistent across a given diagram and the audience. To make information absorption as easy as possible, on a given flow chart, your shapes need to be consistent to the action or process they represent. Various blogs will claim that one shape should be used to indicate one thing or another, but ultimately, they just need to be consistent across a given diagram and the people to whom you show your flowcharts.

At some point last year, I went from user actions being rectangles to making them quadrilateral. It’s relatively insignificant to pretty much everyone except for me, but if someone new is looking at one of your charts, then they should be able to distinguish between the various actions and processes at a glance.

Rule 5. Don’t cross lines:

If your lines cross, then you need to rearrange your diagram. This is simple. It’s better to have an arrow that takes a slightly wacky path than it is to have crossing lines. Crossing lines are hard to follow, and they create noise. When I use the term noise, I mean all of the extra junk information that does not lend directly to the information that you want to convey. Crossing lines are a distraction, and while some pieces of charting software have started to show a mini graphic that shows the line jumping over the other, it is still distracting and can create confusion where there shouldn’t be any.

In the top left image, we are crossing lines, and it adds a distraction to the flow without adding valuable information. In the bottom left we have an overlapping line. Now it is hard to tell if the top left line is multi-directional or if information is going in only one direction. The reader can’t know without asking the creator of the chart. In the right chart we have separated that line so it doesn’t cross anything, and I will often use a dotted line to convey to the reader that we have a looping scenario. Each added piece of information should be deliberate, and no noise should be added unless that noise is also adding valuable information for the person who is viewing the chart.

Even as we get into more complex charts we are able to follow all of these rules so that the diagram is easy to follow. None of these rules are hard and fast, but doing your best to follow them will make sharing and explaining flowcharts significantly easier for you and anyone else who may need to access it.

If you run into any other issues when creating flow charts, feel free to email me with questions and keep an eye out for my next series of rules where we will dive into the finer details that will make your flow charts stand out in spectacular fashion.

Zack is a product strategist here at Echobind. Email him for tips, tricks and assistance at zack@echobind.com any time.