The definitive guide to Web flowcharts

The definitive guide to

Web flowchartsFelix Dinghttp://dingyu.meJuly 25, 2012

V2

Felix DingAn old-school Web designer who loves alternative rock, classical guitar, reading and writing.

http://[email protected]@felixding_

Special Thanks To1 / 24

Larry KernEverett, 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.

PrefaceI 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.

1 / 24

PrefaceHowever, 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 contentsThis 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

1Basic 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

2Visual Vocabulary

Visual VocabularyIn 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.

�������������

������������

InterfaceAn 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.

������ ��� �����

�����

�� ���

���

DialogAs 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 PointA 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 BranchesConditional 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-FlowA 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 PointIn 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.

�

DescriptionDescription 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 ActionA 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

���������������������� ���

������ ��� �����

�������������

������������

��� ���������� ������

���

��

�������������� �� ��

��� ������ �����������������������

��������������� �����

���������

��� �������������� ����������������

���������

������������������������������

��������������������������������

�����

�

�����

�� ���

���

3Examples

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

Security CheckThis 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 examplesAs you can see, flowcharts are able to describe how a system works, no matter how complex business logics can be.

4Suggestions and Tips

Based on research,the guide to wireframesUsers 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 comprehensiveOne 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.

�����������

������������

�������������

����!��������� �������� ����������!���!���

��� ��#���� �����#� ����� ������������"�

����!��������� �������������������������� ���

��

�� ����

��

�����������

�

�!������� ��

���������

����� �������������

�����������!����������������������������������������������

��������������� ���

������������"

��������������

����������� ��������������

5Tools and Templates

ToolsAmong 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.

TemplatesAllen 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