How to write interactive output documents for mobile terminals? Let’s see the analysis of experts!

I think a complete and excellent mobile terminal interaction document can include the following parts:

• Business background, product goals, user groups and user goals
• Business rule definition
• User Flow Diagram
• Design principles
• Interaction process annotation

Of course, you can also add content such as product overview and update log. The product overview simply describes the product version number and product-related personnel.

[[341717]]

The update log mainly records what content was updated, who updated it, and the update date after each update, as shown in the figure below.

Business background, product goals, user groups and user goals

As an interaction designer, after we receive a demand, the first thing we need to figure out is the business background that generates the demand. The second thing is to understand the product goals based on the business background. Finally, we need to figure out who the product's user groups are and what their user goals are.

Interaction designers learn the business background of demand production from product managers or other demand initiators to understand why this demand is needed. After understanding it clearly, they trace back to the original essence of the demand.

In most cases in our actual work, product managers will not clearly write the business background in the requirements document. At this time, our interaction designers can output the business background in the interaction document and display it clearly.

1. What is the business background?

Business background usually refers to why we need to develop this function. How will this function help the business? Through business background, we can deduce business demands and get corresponding product goals.

2. What is the product goal?

The product goal is what kind of results the product can achieve and what kind of benefits the product can obtain. Therefore, the product goal should be highlighted in the design of the interaction document. By clarifying the product goal, we can clearly guide us to make an interaction plan.

3. Who are the user groups?

The user population is mainly obtained through the user portraits of existing products, and we can infer what type of people use this demand. By clarifying the user population, we can clearly know who this demand is for during the design process.

4. What is the user’s goal?

What benefits or purposes do users hope to achieve by using this feature?

Next, I will use a fictional case to explain how to output interactive documents for mobile devices.

5. Case: Browser’s guessing and new user acquisition campaign.

The purpose of this activity is to attract new users to interact with the product through the browser's gold coin guessing activity, increase the daily activity of new and old users, and improve activity.

Based on this requirement, how should our interaction designers design and output an interaction document? According to the above: Before designing, we need to consider the business background, product goals, user groups and user goals.

After analysis, we can get the business background, product goals, user groups and user purposes of this demand as follows:

• Business background: Allow users to earn gold coins by completing certain tasks on a browser, and use the gold coins for consumption (guessing activities), thus forming a complete and virtuous closed loop.
• Product goals: Increase browser downloads through activity sharing; increase the time users spend using a browser by having them earn coins; guide users to share through activities to gain more exposure for product activities.
• User groups: users who have used a certain browser and like profit-making activities; users who have not used a browser but like profit-making activities.
• User goal: Complete the guessing game easily and conveniently, and hope to win a prize.

Business Rules

Regarding the business rules of the product, you may need to communicate and discuss with the product manager, business side, and operations. This involves the rules of the entire product business. In actual work, we will encounter two situations in our interactions:

• Situation 1: The product manager will communicate with the business or operation department and then output a set of business rules. At this time, we can carefully read and sort out the business rules. If we feel that they are unreasonable, we can discuss and communicate with the product manager and modify the business rules to make them more reasonable and output them in the interactive document.
• Situation 2: The product manager simply has an idea for a business rule. At this time, we need interaction designers to help communicate and refine the business rules and output them in the interaction document.

The business rules involved in the browser guessing and attracting new users include: activity time rules, gold coin generation rules, gold coin consumption rules, fund pool consumption rules, activity release rules and withdrawal rules. For these, if the product manager does not clearly formulate them, or formulates them poorly and not in detail, then we can interact to sort them out and formulate them.

In the process of formulating rules, our designers need to think through all the activity processes before, during, and after the event, and run the entire activity process. And give a reasonable rule definition. If the rules are not formulated reasonably, after going online, the entire activity will collapse due to rule loopholes.

The following figure shows all the rules I defined:

User Flow Diagram

User flow means that our designers need to sort out the various scenario processes of users during use. Through user flow diagrams, we can avoid missing scenarios and interaction solutions.

For any function or activity, the first question is where is the entrance set? So we need to design the logic of the activity entrance.

The main user flow of an activity is the flow that the user normally follows when performing the activity.

Different from the main process is the abnormal process when there are insufficient gold coins.

If the user wins the guessing game, the corresponding issue is cash withdrawal. Since the browser does not have a wallet yet, it is designed to withdraw cash by binding WeChat.

In order to increase exposure, you need to focus on designing sharing functions and entrances. When a user has won a prize, you need to remind the user who is using the product that he has won a prize. When an activity expires, you need to design a corresponding expired activity interface.

After the above simple analysis and in-depth user flow diagram summary, the following 7 types of user interaction flow diagrams can be obtained:

• Where is the entrance design for the guessing activity?
• Sufficient coins-main process of guessing activity
• When gold coins are insufficient
• Withdrawal Process
• Activity sharing process and all entrances
• Winning scenario
• Activity expiration scenario

Design principles

The design principles here are not some common interaction or visual design principles, but the principles that need to be followed in designing this activity interaction plan. The design principles here are closely linked to the business.

Before designing this activity, we need to clarify what principles should be followed in the design process. In this way, when designing various scenarios for the entire activity, we can clearly follow the established principles for the interaction process and page layout, which will give us a more holistic view.

The product goal of this activity is to gain exposure and downloads of the product through the activity. The principle that needs to be met is to guide users to quickly find the activity entrance and provide an overview of the activity to attract users to participate and participate smoothly.

The user goal of this activity is to complete the guessing activity simply and conveniently, and hope to win a prize. Therefore, the design process should be simple and easy to understand, and users should not have any cognitive or operational costs. In order to give users a chance to win and make them feel fair, it is necessary to provide timely feedback to users about the winning users.

Because the activity is only temporary, it is necessary to reduce the disturbance or disgust caused by the activity to the vast majority of non-target users.

Based on the above analysis, the following design principles are formulated after summary:

• Guide users to quickly find the activity entrance and participate smoothly
• Provide an event description to attract users to participate
• The guessing activity page is simple and easy to understand, and users have no cognitive and operational costs
• Minimize the disruption or annoyance this activity may cause to most users
• Ensure fairness and impartiality, and promptly provide users with feedback on the number of winners

The above design principles are to determine the ideas and design guidance for the subsequent interaction process.

Interaction process annotation

Based on the user flow diagram above, we can get 7 user operation processes, that is, 7 interaction process annotations.

At present, I think the best way to display interactive process annotations is to display them in the form of a site map/drawing board according to a main process. When there are several branch operation processes in a main process, they can be displayed in a site map/drawing board respectively. At the same time, use titles to distinguish and explain the operation names of the branch processes. As shown in the figure below:

When it comes to abnormal scenarios that can be reused globally, only the global component description is required, and there is no need to display the abnormal scenario components or pages for each process.

Global components refer to components that are common to the entire product, such as global disconnection, operation success, operation failure, loading, empty data interface, 404, etc.

• Global disconnection: Tips are usually used on the home page. When users click on other interfaces, toast feedback will also appear to prompt users. Some apps also have dialog boxes appearing when users enter to prompt users that the network is abnormal. Compared with dialog boxes, using tips is less disruptive to users.
• Operation successful: Generally, successful operations will be indicated by corresponding prompts based on the specific usage scenario.
• Operation failure: An operation fails due to an abnormal situation. In this case, a unified prompt is required, usually using toast. Some people also use dialog boxes to strongly prompt users.

• Loading: It involves global loading and local loading. Global loading should be explained uniformly in the design. For example, if you click on the previous interface to enter the next interface, the global loading used needs to be explained. If it is the loading of some small scenes, then special instructions are required. For example, pull-up loading, pull-down loading, local small area loading, etc.

There are three types of empty data types:

• Definition of initial state: The initialization state has no content and requires the user to perform some operation to generate the interface of content.
• Definition of clear state: By deleting or other user operations, the current page content is cleared, resulting in an empty interface. At this time, there needs to be a clear prompt to inform the user how to handle it.
• Definition of error state: When the content cannot be loaded due to network, server or other reasons, an empty interface is generated. At this time, there needs to be a clear prompt and tell the user how to deal with it. The no-result interface of user operation feedback can also be designed with this idea.

The following figure is a diagram of the interactive process annotations of the H5 guessing and new customer acquisition activity:

When listing the process, try to go to the end of a line and avoid crossing lines. The result of interlacing various lines between interfaces is that the reading is very messy, the experience is particularly poor, and the logic is prone to problems. At the same time, write the corresponding annotations under each interface.

Conclusion

The above is an explanation of how to output interactive documents for mobile terminals. It is for reference only. You can make reasonable additions, deletions or modifications according to the actual situation of your company to make the document more suitable for your own company/project team.