The definitive guide to
V2
Web flowcharts
Felix Ding
http://dingyu.me
July 25, 2012

Felix Ding
An old-school Web designer who loves alternative rock, classical guitar, reading and writing.
http://dingyu.me
felixding@gmail.com
@felixding_

1 / 24
Special Thanks To
Larry Kern
Everett, Washington
Mr. Kern is my English teacher. He spent hours helping me correcting this tutorial. I
couldn’t have done this without his effort. I would like to thank him for everything he
has done for me.

1 / 24
Preface
I started to draw flowcharts from the very beginning of my design career. In the early days, the flowcharts I
drew were simple, the number of nodes were limited, and the logics were straightforward. Thus, I didn’t
realize that the complex flowcharts could be so useful until I joined Alipay.com, the largest online payment
platform in China. Here business logics and requirements were so complicated and fast-changing that
understanding the business itself was very challenging. That was when I started to rely on flowcharts to
learn the requirements, and to design the interactions. It worked like a charm. The product manager liked
it, and the engineers used it as a guide to program the Web pages.
In the fall of 2008, I summarized my experiences into a tutorial, titled as "Some experience on drawing Web
flowcharts", and published it on my blog. The article instantly gained a wide attention. Recommendations,
reprints, discussions, and follow-up blog posts emerged online and offline. Someone even created a set of
flowchart templates following the same design style I introduced in the tutorial. Today, the article that was
published almost four years ago still leads a lot of traffic to my personal site.

Preface
However, the tutorial has a major problem which makes the content misleading: It didn't use "Visual
vocabulary" for "describing information architecture and interaction design". Frankly, I wasn’t aware of this
vocabulary when I was writing the tutorial; instead, I created my own vocabulary and presented the idea to
the mass. Therefore, some of the content didn’t follow the convention, which is not appropriate from the
“Don’t Repeat Yourself” perspective. I did write a new blog post one year later pointing out the flaw but it
hasn't drawn as much attention as the original post.
Besides, it's been years already and I have gained new experiences and thoughts that I would like to share
with the community, especially with the English readers.
So here you have it, the English version of "Some experience on drawing Web flowcharts", with updated
content and home-brew templates ready for download.

Table of contents
This guide covers the most important things you should know about Web flowcharts, which include:
• Basic Idea
• Visual Vocabulary
• Examples
• Suggestions and Tips
• Tools and Templates

1
Basic Idea

What is a flowchart?
A flowchart, as its name indicates, is just a chart describing how a system, under different circumstances,
reacts to users' status, decisions and behaviors.

How do flowcharts help you?
In general terms, flowcharts can be useful to anyone who wants to create a flow for almost anything. For
example, a factory can use a flowchart to tell its workers what are the right procedures when someone gets
hurt. However, in this guide, I will only talk about flowcharts on Web design.
A flowchart is an essential tool for interaction designers as well as product managers. It helps you to:
• design the interaction flow of your product
• make sure your product is still friendly to users, even in rare malfunction cases which you wouldn’t
have thought about before
• organize and connect scattered wireframes
• collaborate with your colleagues from different disciplines; for example, guide engineers on developing

2
Visual Vocabulary

Visual Vocabulary
In the following few slides I will introduce the visual vocabulary, as well as the use of these elements.
These elements include:
• Start and End Point
• Interface
• Dialog
• Decision Point
• Conditional Branches
• Sub-Flow
• Jump Point
• Description
• System Action

Start and End Point
A Start Point and an End Point are where users start an
interaction flow and exit.
Every flowchart should have only one Start Point and at
least one End Point.

Interface
An Interface element represents user interfaces such as a window, or a Web
page.
The number in an Interface node is the identifier, which can be very useful in
collaborations. For example, you can reference an Interface element by saying
"Node X" in a conference call.
What’s more, designers can name the wireframes by following the same
convention. For instance, "23.png" for the Interface element 23. It helps
document readers, like engineers, to save some time finding the right
wireframe.

Dialog
As Web apps are emerging, Web interaction is migrating from linear pattern to
state-based pattern. Partial page update and in-page interactions are more and
more common. One of the most common scenarios is to display a floating
message, like form validation errors. However, it’s unnecessary and even
awkward to make two almost identical wireframes. Therefore, I specifically
create a new type of element called Dialog for Javascript-rendered modal or
modal-less dialogs.
Note 1: My friend Cao Xiao Gang (@caoxg), an aged developer and an entrepreneur, uses UML State
Machine to describe the states and the transitions of these states for Web apps. I’m thinking of finding
a way to transform this State Machine into a simplified, designer-friendly diagram.
Note 2: If what are you designing is not a Web app (to be specific, not something that behaves like a
desktop application but runs in browsers), I would suggest that you not rely on Javascript, nor use it at
all! This, of course, is another topic, thus I won’t elaborate about it here. Find the reasons and my
“JapMag” design language at http://dingyu.me/portfolios/dingyu-me .

Decision Point
A Decision Point is where users make decisions. Usually at this
point, the interface is waiting for its user to choose where to go
next.
Generally I would flow the positive paths down, and direct the
negative paths right, as shown in the picture on the left.
This convention makes the reading experience much better since
the convention is clear and natural (well, since English is written in
this way).
It also helps designers in planning the flowcharts: the major path
is on the left, from top to bottom, while branches are on the right,
which together extend the flowcharts from left to right, top to
bottom.
Note: I actually have read the book, Decision Points, written by George W. Bush, the
former president of the United States. Writing this slide keeps reminding me about
the book.

Conditional Branches
Conditional Branches look like Decision Points, but they behaves quite differently. In Decision Points, the
decisions are made explicitly by users, while in Conditional Branches, it's the system that chooses the
right branch automatically in the background.

Sub-Flow
A Sub-Flow is a flowchart that is relatively independent and re-usable across the
whole system. For example, you may want to wrap some common tasks, like User
Authentication or Connecting Networks, into Sub-Flows, and integrate these into
larger and/or specific flowcharts.
If the flowchart you are going to deliver contains Sub-flows, you probably want to
deliver all the Sub-flowcharts as references as well, before someone asks about it.

Jump Point
In some highly complex situations, we need our users to jump to another path
directly. That’s when you use Jump Points.
As mentioned before, the number in the circle is the identifier of a node, and it
represents the node that this Jump Point leads to.
Obviously, a Jump Point is the end of a path.

Description
Description is a handy way to save time in your communications. Don't get me wrong, you still need all
kinds of communications with your flowcharts readers, but descriptions can be used as memos and
tips, which, from my experiences, will really save much time.

System Action
A System Action represents a background task done by the system. For example,
we may want to collect the data when a user fails to sign in, and we do this by
putting a System Action titled as "Collect Error Log" on the flowchart.
We, as designers or product managers, of course, don't have to put every
background task on flowcharts. Instead, we only do those that are User
Experience related, or those that are so vital to us that, besides describing them
in the specs or documentations, we need to declare them again to make sure
everyone will remember them.

Elements Wrap Up

3
Examples

Log In
A simple log in flow that describes how a system should respond when someone wants to log in.

Security Check
This flowchart shows how to use elements like System Action and Sub-flow. The flowchart is from a
real project, but changed by me for copyright reasons.

Other real-world examples
As you can see, flowcharts are able to describe how a system works, no matter how complex
business logics can be.

4
Suggestions and Tips

Based on research,
the guide to wireframes
Users and their characteristics are the first thing to consider when drawing a flowchart. Based on the
findings of user research, what are the users’ past experiences and expectations? How about the scenarios
and contexts? This kind of question plays a key role in flowchart design.
A flowchart is also a guide to make wireframes. Most of the time, as soon as your flowchart is done, the
content and even layout of each wireframe is set. This is, of course, what a flowchart essentially does:
connects wireframes.
Research Flowcharts Wireframes
Note: Usually we have other deliverables before flowcharts, such as Use Cases. The chart above does’t include
those because they are not the key points in the slide.

Make your flowcharts
comprehensive
One major difficulty when drawing a flowchart is, you have to cover all the possible situations, which, from
my point of view, is very challenging under complex business requirements. You may encounter many
“What if” questions and some of the situations you wouldn’t know until some engineers tell you! Drawing a
comprehensive flowchart requires you not only to understand users, but also to know business logics, and
even to be familiar with system mechanism behind the scenes!
The best way to solve this is to work closely with Product Managers, Engineers, and others colleagues who
are related to the business requirements. I see so many interaction designers work all on their own, and
then get fierce challenges in meetings. Don’t do that again. Instead, collaborate with the ones who are
involved in the project, work together on your flowcharts (and other deliverables), and eliminate
uncertainties from different angles, so that you can make your flowcharts comprehensive. (No one will
challenge you again because it’s also his or her work)

Don’t forget Meta
From the collaboration and documents management perspective, you should leave at least a name, an
author, a version number, and a date on your flowchart.
Besides, even if your flowcharts followed the conventional visual vocabulary, your colleagues or clients
may still have difficulties understanding the fancy elements. So do remember to add a legend.

5
Tools and Templates

Tools
Among all tools, I recommend OmniGraffle and Microsoft Visio.
OmniGraffle
For Mac users, OmniGraffle was, and still is, the first choice. It has a rich features
set, and most importantly, the best user experience in the crowd. Most designers
I know have already switched to Macs and consequently use OmniGraffle.
Microsoft Visio
Windows users may consider Microsoft’s Visio. It has several templates
built-in which probably can make your work a lot easier.

Templates
Allen Le has created a set of templates for Microsoft Visio based on my origin post. It’s beautiful and I
appreciate his work. You can find it at: http://www.allenle.com/archives/1530.html .
OmniGraffle fans can download the templates made by me on GraffleTopia: http://graffletopia.com/
stencils/905 .

That’s it!
Composing this guide took me almost two weeks, and writing a tutorial fully in English made things even
harder, as I’m not a native English speaker. This is my very first time to write a tutorial in another language,
but I really enjoy doing it. To me, writing is a great opportunity to summarize the past then create
something new, and I would be more than happy if someone else could also benefit from it.
For any questions or suggestions, please leave a comment at: http://dingyu.me/blog/the-definitive-guide-
to-web-flowcharts .
Felix
July 25, 2012