Do not forget the following information about interaction:

Although I have been engaged in interactive work for several years, I still often make some common mistakes. I believe this will happen to other designers at work: for example, the interaction description is not detailed enough, leading to higher communication costs with the front-end and developers, higher rework, and lower work efficiency. To solve these problems, on the one hand, we need to strengthen communication, and on the other hand, we also need to consider the forms of interaction instructions from the front-end and development perspectives, so that everyone can better cooperate with each other.

There are also many articles about interaction instructions on the Internet. This article does not cover interaction instructions or how to write interaction instructions, I only focus on some issues that are easy to ignore in my work and some personal experiences. I hope this will help you.

　　1. Try to use authentic and logical data content

In the past, when I was doing interactions, I thought more about the display of extreme situations (for example, each data item was written as a bigger value as possible), rather than the logical correspondence between data, this will cause a lot of troubles for developers. For example, in the figure below, development will produce many problems: What is the relationship between Netease price, discount amount, points, and subtotal? What is the discount amount related? These problems are closely related to background algorithms.

I also helped my friends design a page for ticketing products. At that time, in order to save trouble, the texts on the interface were all casually written and used for demonstration purposes only. Although I think it is normal, the other party looks awkward: without the name of this ticket, what is the content here? Not quite clear ...... Therefore, to reduce communication costs, it is better to use authentic and logical data content as much as possible.

　　2. Do not omit descriptions of special states

When writing interaction instructions, you always consider the normal state, but often ignore some special states (rarely used by users ). However, for front-end and development, various statuses cannot be missing; otherwise, the work may fail.

For example, the operation logic seems simple: "After selecting the name of the above person, the corresponding information will be displayed below ". However, if the interaction instructions only write this information, the front-end or development will go crazy, and there will be countless problems, such as: how to sort common insured people? How many can be displayed at most? What if one row is exceeded? Is there a limit on the number of words in the name? What should I do if the name is too long (foreigners or ethnic minorities? What should I do if three people are selected? What should I do with duplicate names? After selecting a person name, what should I do after I modify the information below ?...... All of these should be taken into account by the interaction designer and written in the interaction description. If the interaction designer thinks more, front-end or development will save a lot of effort.

　　3. Avoid too long

In the above example, we added all the interaction instructions according to the requirements of the front-end. The content was very impressive and I wrote a whole page of annotations, which were very dense. But I was taken back during the review. Why?

I summarized the following reasons:

1. There is a problem with the requirement or design scheme, resulting in complicated logic exceptions

2. Is there a high development cost for this solution? Is it necessary? (In some cases, exceptions occur very frequently. You can discard them to ensure a balance between experience and development costs)

3. If there is no problem with the requirement and design scheme, is there a problem with the expression method? Avoid text stacking as much as possible (For details, refer to the "Avoid sequential account statement" below ")

 

4. Avoid the explanation of the sequential account type

A flowchart replaces the text description. For example, if there is a "add to Favorites" link on the interface, clicking it will trigger a series of operations. In the interaction description, how should we express it?

Some may say this:

Click the "add to Favorites" link to determine whether the user is logged on. If you are not logged on, the logon box is displayed. If you are logged on, you can determine whether to add this item to your favorites for the first time. If not, a prompt box is displayed (with a style next to the prompt box ); if yes, then judge whether the user first collects the product. If not, the success prompt is displayed. If yes ...... Some may say:

Obviously, the latter is clearer and more organized. Of course, in order to make it easier for everyone to understand, I found an exaggerated example, which is generally not so extreme. I just want to explain one thing: Try to display the logical relationship of operations in a more organized and understandable way, instead of using a sequential account-type text, so that everyone will be dizzy.

Table B lists various States in addition to the flowchart, you can also list various state diagrams in the form of tables.

C cleverly organizes text instructions and uses "if, else, Case" to organize instructions. I also like the text, but development prefers it. For example, the following interaction description:

D. Create a dynamic effect. If there is an animated effect, it is best to create a demo effect (axure and other software can produce a lot of realistic dynamic effects ).

　V. Repeated modules

To facilitate reading, many designers are used to directly writing interaction instructions next to the corresponding module on the prototype. However, this may cause a problem: Some modules are repeatedly displayed on multiple pages. If the interaction description of this module is only written once, development may fail to be found; if each page is copied, the development may be confused (is there a difference between the two sides ?) Even worse, if you want to modify all the pages, it will take a lot of work.

For example, this module appears on the shopping cart, personal center, and other pages. To save time and improve efficiency, I isolated this module and named it "Mini favorites". Then I can leave only one blank space on other pages.

For example, if this module is used in the lower part of the shopping cart page, I will leave a blank space here. In this way, it is easy for me to develop and reduce tasks (many Modules seem similar, and it is easy to make mistakes by naming and combining common modules ).

This example seems to be an idiot, but I want to tell you that it is helpful to use modular ways of thinking to deal with complicated problems.

　　6. If the prototype has been modified, do not communicate verbally. Instead, update the interaction description and inform everyone.

The above are some small issues I have summarized. In fact, I think what method is used is not the most important. What is important is that in the process of cooperation, we should not only do what we should, but also consider the issue from the perspective of partners, only by providing more convenience can the team become more and more efficient and more tacit cooperation be achieved.

Do not forget the following information about interaction: