, in the securities company, because the design of the work is not busy, I once wrote the role of the Product manual.
At that time, I always wanted to be very clear about how we designed this place, why we designed it, what the logic behind it was, and then give them an example of how to do it. A product manual written down a good hundreds of pages, they can see the faint past.
I write very tired, those operators are also very unhappy with me. Because they need to skip a lot of my long speeches, directly selective to see "How to Do".
2, June Chen said: "Effective communication is effective help," I do not fully agree.
I agree with what he says there are "mental differences" between users and designers. It's like the difference between machines and people. So there is the value of the interaction design.
But he said he wanted to "tell the user how and why I designed it," and I don't agree. Because many of the design may be complex logic, it is very difficult to make it clear, we can not ask users and designers of the "mind" to achieve the same. Designers can only be asked to get closer to the user's "mind."
3, June Chen examples "in Google's Help center, each q&a, the end will have a" above information to you to help? "Content for statistics and improved help." This is a good example, but the example is not to "get the user closer to the designer's mind", but rather to "make the designer more and closer to the user's mind, so that the problem can be solved more accurately and directly".
4. First of all, we must say, "What is the purpose of the user using a product?" ”。 "Problem solving." Yes, it's "problem solving", not "understanding how your product is designed."
From this perspective, the first thing we need to do is "help users solve the problem", when they have problems in question, we first have to say is "How to", "what can", let him "know". Rather than tell them "because of what, and because of what, so you should do."
Often we just need to let them "know it", do not need to "know why".
5, it can be said that "effective communication is effective help", but this is not the most desirable help. Perhaps because many designers are anxious or too worried that users can not "know why", too much for the sake of users, will let us often see a lot of products have similar problems appear:
- A Web site does not allow user name duplication, user registration entered user name is occupied, prompted: "Because we have the user name as a unique identity, so do not allow user account duplication." Your user name entered is already occupied, please reset.
- Mobile often to the user to send 12580, 139 free mailbox, Chong Value card recharge and other spam ads, the complainant asked to cancel the spam message, customer service said (the main idea): "I am sorry, sir, because our Customer service center and Technical Center is not in the same department, do not have the right to modify your If you want to no longer accept us to move the spam message sent to you must send SMS Sbyd to 10086 to cancel. ”
- ...
The above examples are very unpleasant to me, because too long-winded, I do not have the time and patience to see/listen to so many explanations, and no interest to understand how the product design. What's more needed is "just tell me how to solve the problem." You can adjust this:
- "User name is already occupied, please reset"
- "Sorry sir, if you want to no longer accept us to move to send you the spam message, you can send SMS Sbyd to 10086 cancellation." ”
6, oh, see here maybe you will say "move that problem, the general complainants will continue to ask ' Why can't you just cancel?" How can I send it directly when I send it? ’。 At that time customer service is not still have to explain ' because we are not a department, no authority '? ”
Yes, most of the people who complain are basically going to ask. But this time to explain the specific reasons, to ask the person will not be because of the words more annoying, only may because the reason is to be fabricated and vexed. (a scolding says you don't send text messages, they actually can be canceled directly to you.) )
7, so, in some cases we just need to let users "how to do", there is no need for them to "Why do it", and when the problem is a little more complex or the user is "more wrong cost" is not low, we have to let users "know why", and prepare a set to let users "know why to do this" program.
However, even if the need to let users "know why to do this" is not equal to "tell the user how we are designed", but not equal to the first to tell him directly "know why to do so." Because the user may never need to know how to design, and also do not necessarily understand the designer's "mental logic."