Differences between FLOW CHART and UI FLOW

Many concepts in UI design may seem similar in words, but in reality they are very different. Taiwanese designer @Akane_Lee, who hasn't posted for a long time, took the opportunity to analyze the concepts and elaborated on the functions of Flow Chart and UI Flow~

I haven’t posted anything for almost a month. I was busy writing business plans, making prototypes, and running lab reports. I have to sort out a lot of UI Flow recently, and the more I sort it out, the more confused my mind becomes. Let’s talk about UI Flow and Flow Chart. Flow means "process", UI Flow is the page flow, and Flow Chart is a flow chart. The two are completely different charts.

UI Designers are very familiar with UI Flow, but may not be familiar with Flow Chart. In software development, Flow Chart is usually written by SA, with the emphasis on "judgment"... It is not that difficult, just think of it as a psychological test in a magazine, choose "yes" to go to the right, choose "no" to go to the left.

For RD, before writing a program, they must first know the "logic", which is the operating framework composed of various "judgments". Logic is also very important for UI. Otherwise, what kind of response should be given to the user after the operation?

The most simple member login

Take "Member Login" as an example. If the user enters the account and password correctly, it will automatically jump to the member information page. If the input is wrong, an error message will be displayed...

If you want to draw UI Flow just from Functional Map, you often ignore "what to do if the user makes an error in operation". At the last minute, you will find that there is something missing in UI and you have to urgently add the missing page. RD has to cram in functions, which is not elegant. Error prompts are not something that can be put aside for a stage or added later. Pages and programs are not something that can be drawn or written by mouth...

If you enter anything randomly, I will give you a verification code

Seems simple, huh? But it’s not that simple. When actually drawing, you will find that many things are easily overlooked and not considered in UI Flow. (And how could it be like this without adding any features?)

Sometimes users keep entering incorrect information, and it is reasonable to assume that someone is trying to steal their account. A common blocking method is to ask users who have entered multiple incorrect information to fill in an additional verification code field. So the Flow Chart becomes:

The picture above is just a simple flow demonstration. If you casually say "Hey, help me add a verification code function", the Flow Chart will suddenly become larger. The real member login verification has more tricks and security considerations, such as adding a "forgot password" prompt after three incorrect login attempts, or even more ruthless ones, where the account is directly locked and the user is asked to complain to customer service.

Flow Chart and UI Flow complement each other, and even Flow Chart comes first before UI Flow. If you produce UI Flow without a Flow Chart and don’t know how many judgments need to be processed, the probability of missing functions due to poor planning is very high.

If there is only UI Flow but no Flow Chart, the RD can barely imagine how to set up the Flow Chart and judgment formula based on the screen, but the larger the system, the more likely it is to have bugs, and the probability of bugs will be determined by the RD's experience. But without even UI Flow, relying on just a few wireframes or mockups is like a blind man touching an elephant. RD won’t know how to string together the pages by looking at a single static picture, and it would be strange if it could be done well just by relying on imagination.

If you don't give anything and just throw a prototype to the RD and ask him to copy it and make an identical one, it would be easy, right? The RD has to poke and press every button on every screen and try various errors before he knows how to connect the functions. How much do you hate RD for doing this to him...

References:

Flowchart – MBA Think Tank Encyclopedia

Flowchart Description

From the perspective of a UI Designer, the Flow Chart can be viewed as "how users operate to complete tasks in this scenario and how the software responds", and the UI Flow can be extended to "because the user operates in this way, and we have these functions and information to present, so the pages are connected in this way."

A UI Designer does not necessarily have to be able to draw a Flow Chart, but he or she must be able to understand it. Common flowchart symbols are fixed. Don’t design a new style just because it looks ugly. The RD will definitely turn the tables.

There is a famous saying, "The water that enters your brain before marriage is the tears that you shed after marriage." If we apply it to software development, "The brain that you don't spend enough time on before work is the liver that will be hurt after work." There are as many functions that were not thought of in the early stage as there are hours of work that were not expected in the later stage...