TIPS: Drawing web Flowchart

Document directory

• 1. perform their respective duties
• 2. Legends and flowchart Information
• 3. Flowcharts
• 4. Evaluate the flowchart
• 5. Others

From: http://dingyu.me/blog/posts/view/flowchart-howtos

 

A buddy told me on MSN that their company's Interaction designers only output flowcharts and asked me what standard I used to evaluate the flowcharts. His statement completely shocked me-this division of labor is too fine! I don't know whether they should be nice or not.

But I did not think carefully about the flowcharts. I just took this opportunity to summarize myself.

1. perform their respective duties

In My flowchart, the shapes for different purposes and functions have their own specific specifications. So far, I have defined the following shapes:

(1) start and end

As the header and end of the entire flowchart, you must specify the specific page to avoid ambiguity in the future.

(2) webpage

As you can see, a webpage is a rectangle with a beautiful light blue transition effect. Its border is dark blue, and the purpose of the webpage is clearly stated in the middle, the numbers in the brackets represent the name of the demo file corresponding to this shape (such as 2.html). I sometimes output the flowchart as a webpage and link each webpage shape to its demo file, this makes it very convenient to view. This is a piece of cake for omnigraffle. If you are forced to use Visio, um ......

In addition, all the lines from the shape have the same color as the border of the shape. This method not only looks beautiful, but also easily shows the relationships between shapes in complicated flowcharts. I have never seen a similar practice, so it may be my first effort.

(3) Background judgment

A common shape. One difference in my usage is that I almost always let the branches of 'yes' flow down and the branches of 'no' flow to the right. Because Flowcharts are generally drawn from top to bottom, from left to right, following the above rules can not only enable the painter to worry about the direction of choice, but also facilitate readers to read.

(4) Form Error Page

Since there is a form, of course there will be an error message. In fact, this information is very important. When a user makes an error, the user is worried, and the problem is solved by the error prompt. When do you not show the error page in the flowchart or provide the error page in the demo? Some programmers directly write an "error, please check" on the webpage ", therefore, the UI Designer must pay attention to this item.

But in general, there is no need to express each type of errors in the flowchart, because there are three kinds of errors in the form containing two text boxes, not to mention more. Therefore, I change the error page to the secondary page of the form. For example, if the number of the single page of the table is 2, the number of the error page of the form starts from 2.1, each type of error is put on an affiliated page, so that programmers can understand what they mean when they get the demo.

Combined with the shape of the webpage and form, a form verification flowchart is like this:

(5) Background actions

Not all background actions are drawn into the flowchart (otherwise the flowchart will become a giant). This shape is used only for background actions that require special emphasis (directly related to the user experience.

(6) Multiple branches

Multiple branches refer to several parallel situations, and each case may occur. Which of the following depends on the judgment result at the beginning of the branch.

(7) dialog box

Sometimes some operations can be completed using the dialog box, which is generated by JS and displayed on the parent interface.

(8) Comment

The detailed content of this shape (such as the page), the business logic that needs to be explained, or even the user's situation here, will be put in the comment, which reduces the communication cost, it can also be used as a memo.

(9) Jump Point

In a complex flow chart, it is often possible to jump to another distant node. In this case, if a line is directly connected, it makes the flow chart look messy and solves the problem with a jump point. Mark the number of the jump shape in the vertex, which is easy to draw and looks clear.

In addition, you can also use jump points to separate a huge flow chart, Yahoo! This is the case.

(10) subprocess

It is better to use sub-processes to separate a huge flow chart.

Note that if you use the subflow In the flowchart, you must attach the subflow chart to eliminate the uncertainty that affects the project quality. In addition, the subflowchart can also indicate the relationship to which the subflowchart belongs.

(11) process block

You can use the process block to separate the entire flowchart into several parts and name each part separately (for example, "process block 1 ). The purpose is to make the complex flowchart clearer visually and more convenient during communication.

2. Legends and flowchart Information

In teamwork, the legend is required. Otherwise, no one knows what you have drawn. Even if the flowchart is only visible to you, it is best to develop a good habit of marking the legend. In fact, this is a bit similar to the annotations in the program.

Flow chart information is also necessary. The content should at least include the author, time, flowchart name and version (for example ). In this aspect, readers (other colleagues) can easily find the author and you when there is a problem, which also plays a role in Meta.

3. Flowcharts

In Mac, omnigraffle is preferred. In Windows, apart from Visio, it seems that there is no better choice (although it is difficult to use Visio ).

4. Evaluate the flowchart

I think a good flowchart should at least achieve the following:

1. It closely caters to the user's psychological status and faithfully reflects the user's operation habits. The flowchart guides the UI design and serves as a reference for the UI design. If the flowchart itself cannot correctly describe the user's situation, there may be problems in the UI;
2. It covers various possible situations and details. This is very important. Any uncertain factors will become mines that can be detonated at any time in the project, which will directly reduce the quality of the final launch UI. This is not uncommon. At the same time, it is difficult to achieve this because it not only requires the designer to be familiar with the user, but also the designer to fully understand the commercial logic of the product, but also to understand the operating mechanism of the system and fall behind any of the above aspects, will be left in the flowchart. I don't know if there is a better solution to this problem, but it is an effective way to communicate with Pd and Department repeatedly;
3. Consider the design and affordability of the system. The operating mechanism and affordability of the system must be taken into account in the process of drawing the flowchart, so as to avoid the case that the flowchart is shot by developers. My habit is to frequently communicate and communicate with system analysts when drawing flowcharts to ensure that every link is feasible;
4. Make sure that others understand your flowchart. Others cannot understand it now, and you will not understand it in the future. To reduce the communication cost, draw the flowchart clearly.

5. Others

(1) Try to make the flowchart more beautiful. Who doesn't like beautiful things?

This is some of the flowcharts I have done, and of course all the text is blurred (I hesitated for a long time before the figure is shown-I don't know if this will damage my professional ethics. I specially asked fenng, and he thought it was okay. If anyone thinks there is a problem, please tell me bluntly ).

(2) If you are not a one-click character in the company, you need to manage the version of your documents. The flowchart is no exception. When to release any version should be clearly marked, and "newest" is a useless word.

 

That's all I have to say. Let's look at it!

Oh, by the way, do you think every time I write an article is too long?