Knowledge
Home > Knowledge > Content
graphic expression for instant boiling water tap system purpose and usage scenarios
- Jan 02, 2019 -

Iwater instant boiling water tap system application and usage scenarios

"At some time (when), somewhere (where), when something is happening around (with what), a certain type of user (who) has sprouted a certain desire (desire), think of some means (method) to satisfy the desire." 


1.The meaning of the use of the scene In the traditional software development process, the product manager / product planning will first provide a list of functions. The descriptions used for such feature lists are often program-oriented, such as "Product lists support sorting from low to high prices." The downside of this description is that the product manager often concludes that this is because the competitor has the feature, not the real needs of the user. Partners (interaction designers/visual designers/development engineers) cannot directly understand that this function is to help users achieve what goals, and they do not know the value of this function, what changes can be made to real life. By describing the requirements in the way of using the scenario, these drawbacks can be effectively avoided: the product manager knows that the newly developed function is to help the user solve the problem. The interaction designer can learn the details of the usage scenario: "frequency of occurrence, intensity of demand What kind of abilities and tools are available to users? Other partners are more likely to understand the value of this function, to express their opinions in a timely manner, to reject unreliable functions, and to resonate more strongly with valuable functions. 


2. How to judge the value of a use (demand) scenario? According to the psychological knowledge I have learned before, when the user has some kind of demand, he will try to use various means to satisfy it. When there is no solution for the design in the environment, the user will use a variety of things that can be found as much as possible (you know the airplane cup, the inflatable doll, etc.). When it is really impossible to find any solution, the user can only squat. When you can't find a solution for a long time, the user will despair (scientific name is learned helpless), and suppress the behavior of the attempt (no online shopping, no matter how strong you want to buy a wedding anniversary for your wife The gift of the day will not open the webpage). However, once this solution is brought to the user, please try it out. After he has experienced the joy of success, he will love it. (Think of the mood when booking a ticket on 12306, although it is really bad). Therefore, two methods for measuring the degree of probabilistic demand scenes were born: investigating whether users are using a certain product at the present stage, and they are still using it (but think of 12,306 pairs). Make a basic usable solution at the lowest cost, ask the target user to try it out and ask for the experience.


3, using the (required) scene description method and the necessity of each part mentioned earlier, the use of the scene should be described as follows: "At some time (when), somewhere (where), when something appears around (with What), a particular type of user (who) sprouts a certain desire, and thinks about satisfying desire through some means. The meaning of each part of the information is as follows: when, where, with what Information actually describes the environment in which requirements arise. From these environmental information, the conditions that induce demand and the environmental conditions at the time of demand generation can be analyzed. For example, "When you are waiting in the terminal, the user will want to charge when he sees that the phone is running low." Based on this, it can be analyzed that the user wants to charge under the stimulation of low battery information. At that time, he was in the terminal, a place full of electrical appliances, but no outlets developed for passengers. The who uses the scenario also needs to analyze what type of person has this need and what capabilities he has the potential to potentially help him achieve his goals. Continuing with the previous example, mobile phone users who are on the plane may have this need, because they usually contact the family to report their safety when they get off the plane, contact others to pick up the plane, and so on. These people on the plane are generally richer and will bring cash or credit cards. There are some caveats to the description of requirements. There is often a deeper need behind certain requirements. It is just a solution to this need. For example, charging a mobile phone is a requirement. But the demand behind it may be to boring, to keep the family safe, to see the map of the destination city, to contact the travel agency, and so on. Charging your phone is just one of the solutions that users can think of. Continuously analyzing the requirements one level at a time may help you understand more clearly what the user wants. Then, once it is too difficult to meet a certain demand, it is okay to meet the needs behind it. For example, if it is too difficult to provide charging in the waiting hall, you can also provide the user with a TV (passing boring), a public phone that swipes the credit card (to keep the family safe), provide the flight destination map (see the destination city map), and Hotel (contact travel agency). The method method is the user's existing solution. Clearly describing an existing solution can help the product team determine who the competitor is. Such competing products are often not limited to the same industry, as long as the target needs are the same, that is, competitors. For example, for the need to obtain geographic information, the competitors of satellite maps may be paper maps, compasses and guiding aunts. With an understanding of competitors, it is possible to know more clearly whether such user needs exist, how strong, what advantages our new program has, and whether the other party is weak. In summary, based on the use of scenarios to analyze user needs, the product can be more grounded.