Product Manager Core Tool: A drawing guide to Web Flowcharts

The author of this article is designer Felix Ding, Ding Yu's. In the early days of the author's design career, it began to contact the flowchart. A good flowchart that can be used to understand requirements, parse complex business processes, and also help with interactive design.

In order to maximize the value of the flow chart, the paper focuses on the analysis of the beginning and end tag, interface, dialog box, decision Point, Conditional Branch, sub process, jump point, description, System behavior and other visual terms.

Objective

In the early days of my design career, I began to draw a flowchart. In the beginning, I have drawn the flow chart mostly simpler, the nodes in the diagram are not many, the logic is straightforward. So until I joined Alipay, the biggest online payment platform in China, I realized that the complexity of flowcharts was of great use. In Alipay, the complexity and rapid changes in business requirements and processes make it a challenging task to understand themselves. It was at this point that I began to rely on flowcharts to understand the requirements and to use this method for interactive design. Gradually, the flowchart shows its allure: the product manager likes it, and even engineers use it to guide development.

In the fall of 2008, I summed up my experience as an article titled "A Little Experience in drawing Web Flowcharts", published on my blog. The text immediately drew wide attention. Various recommendations, reprints, discussions and follow-up articles are frequently appearing online, and even people follow the method I mentioned in the article to create a flowchart template. Today, this article, published four years ago, still brings a lot of traffic to my personal homepage.

However, the above article has a more serious problem, making its content misleading: it does not use a visual glossary for describing information architecture and interactive design. To be honest, I did not notice the existence of such a well-known glossary, but rather created my own vocabulary and introduced it to the public. As a result, part of the article does not follow the Convention, which is not appropriate from the point of view of DRY (Don t Repeat yourself, don't repeat yourself). A year after the article was published, I did point out the problem in another article, but unfortunately this time it did not attract as much attention as it did last time.

In addition, it has been several years since the article was published, and I have accumulated a lot of new experiences and ideas that I wish to share with you, especially English readers.

So now, as you can see, I have completed the English version, with the latest content of the "painting the Web flowchart of a little experience," and provided a homemade version of the template download.

Content Overview

This article covers some of the most important guidelines you should know about Web flowcharts:

A. Basic ideas

B. Visual glossary

C. Examples

D. Recommendations and tips

E. Tools and templates

1. Basic Ideas

What is a flowchart?

Flowchart, as the name suggests, is used to describe a system in different situations, how to respond to the user's state, decision and behavior of the diagram.

What kind of help can the flowchart give you?

Typically, flowcharts are useful for anyone who wants to create a process, no matter what process is created. For example, a factory can use a flowchart to tell its employees what the correct first aid process is when someone is injured. Of course, in this article, I'll just give you an example of a web design flowchart.

For interaction designers and product managers, flowcharts are a core tool. It can help you:

2. Visual Vocabulary

In the next few pages, I'll look at the visual vocabulary and how they are used:

A. Beginnings and ends

B. Interface

C. dialog box

D. Decision-making points

E. Conditional branch

F. Sub-process

G. Jump Point

H. Description

I. System behavior

Start and end

A start and end point is where the beginning and end of an interaction is identified, and any flowchart must have a starting point and at least one endpoint.

Interface

Interface elements are used to represent various user interfaces, such as forms or Web pages. The number of interfaces can be used to make identifiers that are useful in the collaboration process. For example, in a conference call, you can use "Node n" to express the interface element you want to indicate.

Moreover, designers can also use this rule to name Wireframes. For example, "23.png" wireframes correspond to the 23rd interface. This greatly saves the reader of the document-for example, the engineer-to find the time for the corresponding wireframe.

dialog box

With the advent of Web applications, web interaction has been transformed from linear to state-based patterns. Local page updates and single page interactions are becoming more common, and one of the most common forms is floating messages, such as error prompts that occur after a form validation error. However, it is not necessary or even awkward to make two almost identical wireframes. So, for this javascript-rendered modal or modeless dialog box, I specifically created a new element called the dialog box.

Note1: My friend Cao Xiaogang, a senior technical person and entrepreneur, uses the UML (Unified Modeling Language, Unified Modeling Language) state machine to describe the state in Web applications and the transitions between these states. I'm trying to turn this state machine into a simpler, more designer-suited icon.

Note2: If you're not designing web apps (specifically, not the ones that look like desktop apps running on browsers), I suggest you don't rely on JavaScript or even use it. The specific reason is of course the digression, and I will not describe it in detail here. If you want an answer and know my "japmag" design language, please visit: http://dingyu.me/portfolios/dingyu-me.

Decision Points

A decision point is where the user needs to make a decision, usually when the process comes, and the interface waits for the user to decide where to go next.

As the figure shows, I usually let the positive selection ("Yes") flow downward, while the negative selection ("No") points to the right.

This rule provides a better reading experience because the rules themselves are clear and natural (as is the case in English).

This rule can also help the designer to plan the flowchart: the main line of the flowchart is left, the top is flowing, and the branch is on the right, so the whole flow chart structure is automatically left to right and up to the bottom.

Note: In fact, I have read the autobiography of former US president Geoge W.Bush "Decision Points" (Chinese version is "The Choice Moment"). Therefore, writing this page always reminds me of this book.

Conditional Branch

Conditional branches appear to be similar to decision points, but they accomplish distinct functions: decisions are made explicitly by the user at the decision point, and for conditional branching, the appropriate path is automatically selected by the system in the background.

Sub Process

Sub-processes are relatively independent processes that can be reused throughout the system. For example, you can package some of the same (frequently used) tasks-such as user authentication and access networks-into sub-processes, and then integrate them into larger or specific flowcharts.

If your flowchart contains a sub-process, it is best to submit all of the relevant sub flowcharts before someone asks you to do so.

Jump Point

In some highly complex situations, we need the user to jump directly to another path, which requires a jump point.

As previously said, the number in the circle points to a node, which is the node that the jump point directs.

Obviously, a jump point is the end point of a path.