Quickly resolve branch processes and exceptions in the design

Let's first look at an older terrier. How many steps does it take to put an elephant in the refrigerator? I believe everyone knows it.

Open the refrigerator door - put the elephant in - close the refrigerator door

The flow chart is as follows:

This should be the normal and ideal sequence of operations that most people can imagine intuitively.

However, the problem is not as simple as it seems.

The actual flow chart is as follows:

This is also a problem often encountered in design. When making the manuscript, you feel that it is already perfect, and all the process steps have already flown. When I gave the design draft to the developer with confidence, the problem came.

With a real screenshot:

Uh... I'm most afraid of the sudden silence in the air...

Only start to be in a hurry and start to fill in all kinds of pits...

……………………………………………………………………………………………………………………………………………………………………………………

These situations mentioned above are actually the things that are most easily overlooked when designing.

Branching processes and exceptions are poorly considered.

Of course, when we do design, our main energy must be focused on the main tasks and processes. Although the branch process is a small probability event, we must also consider it, otherwise the plan will be incomplete.

Therefore, I specifically sorted out the most frequently missed branch processes and abnormal situations for your reference (also known as the pits filled in those years). Of course, these contents are not omnipotent. More I hope to provide you with some meaningful references and ideas. Only when the thinking is clear, and the thinking angle follows certain rules and steps, can omissions be effectively avoided. (filling the hole is a very painful experience)

However, with regard to the thinking about branch process and abnormal process, even experienced designers cannot actually consider everything in the process design stage in a new project. Therefore, in the self-examination stage after the plan is basically completed, it is necessary to reorganize and check for omissions.

SO...Young man please stay...

1. Applicable people

1. Junior Interaction Designer

2. Students who like interaction design

3. Non-interactive positions, but students who have to involve interaction (product managers, visual designers, test engineers, etc.)

This table is a beta version, which summarizes the various situations that I have encountered in my work. I am still improving and sorting out the content. I hope you will add more points:) Thank you...

2. How to use

A digression first: I have a friend who always gets lost. When he goes out, he either forgets to take his mobile phone or his keys. He is also very distressed. To this end, he came up with a way to put keys, mobile phones, and wallets together in a very fixed box. As long as he finds the box, he will not forget anything. So the focus is on this box.

Back to our branch process and exceptions, I have prepared the box (self-checklist) for you. From the stages before, during and after the design, some points that are bound to be encountered are listed.

You only need to find the structured filling content of this box (self-check form) and you can basically solve most of the problems.

In fact, this is a process of structured thinking. In this process, not only can you clearly organize your own ideas, but also avoid some unnecessary omissions. After filling out, you will also find that this will become a self-check form for your own project, and it will also be convenient for other project members to check and sort out the problems.

Let's first take a look at what the manuscripts we usually give out look like.

This is what our most common design draft looks like, and it is presented step by step according to the most ideal state process, which is the ideal step for putting the elephant into the refrigerator as we talked about earlier.

But in fact, an input box and an upload operation will have so many states and situations, that is, the refrigerator door cannot be opened, and the elephant cannot be inserted.

However, there are certain rules in these situations, and you don’t need to spend too much time and energy thinking about them. You can fill in them according to certain rules, and you can solve most of the problems. First find your box (self-checklist), then let's see what are the areas that are easy to miss at various stages of the design.

1. Before design

1.1 Identify needs and goals

Main Checkpoints: Business Goals, User Goals, Product Goals, Design Goals

Tips: " Second-hand needs obtained from others b2b data often do not have a deep understanding of the nature of the needs "

It depends on whether you have a clear current goal and whether you can describe the goal clearly in one sentence (preferably a measurable goal, such as the product goal of increasing the number of active users by 20% in October this year), so try to figure out your needs as much as possible. .

1.2 Identify target users and user roles

Main checkpoints: user type, account system

Tips: "The connections between different types of users are inextricably linked"

When designing, you can basically know who the target users of the product are, but what is easy to ignore is how many types of users there are , such as: administrators, VIPs, intranet users, extranet users Users, etc., whether each user type needs to have layered processing in terms of experience and content, whether it involves permission issues, and how to deal with it. Can the roles be changed to each other, is the operation clear, and what are the prompts after the change? What is the account system for?

2. Under design

2.1 Framework stage

Main Checkpoints: Hierarchical Relationships, Information Differentiation, Extensibility

Tips: "A good framework doesn't change dramatically as content increases or decreases"