When I was in the securities company, because the design work was not busy, I once had the role of writing product manuals. At that time, I always wanted to explain clearly to the readers "how our place is designed, why it is designed this way, and what is the logic behind it", and then give them examples of "what they should do". A product manual can be hundreds of pages long and I can feel dizzy just reading it. I was very tired from writing, and the operators were also very unhappy with me. Because they need to skip a lot of my long speeches and directly look at "what should be done". 2. Junchen said: "Effective communication is effective help", but I don't completely agree. I agree with what he said about the “mental gap” between users and designers. It's like the difference between machines and humans. Hence the value of interaction design. But he said he wanted to "tell users how and why I designed it this way", which I disagree with. Because many designs may have complex logic and are very difficult to explain clearly, we cannot expect the "mindset" of users and designers to be consistent. We can only ask designers to get closer to the users’ “minds”. 3. Junchen gave an example: "In Google's Help Center, at the end of each Q&A, there is a sentence like 'Is the above information helpful to you? "For statistics and to improve the content of the help." This is a good example, but this example is not to "bring users closer to the minds of designers", but rather to "let designers better understand and get closer to the minds of users, so that they can solve problems more accurately and directly." 4. First of all, we must say "What is the purpose of users using a product?". "Solve the problem." Yes, it’s “solve problems”, not “understand how your product is designed”. From this perspective, the first thing we need to do is "help users solve problems". When they have problems or questions, the first thing we need to say is "what should be done" and "what can be done" so that they "know the truth". Instead of telling them "because of this and because of that, you should do this and that". Often we only need to let them “know the fact” without having to “know the reason”. 5. It can be said that "effective communication is effective help", but this is not the most desirable help. Perhaps it is because many designers are too anxious or too worried that users cannot "understand the reason" and are too considerate of users that we often see similar problems on many products:
The examples above all make me very unhappy because they are too long-winded. I don’t have the time and patience to read/listen to so many explanations, nor do I have the interest to understand how the product is designed. What is more needed is "Just tell me how to solve the problem." You can adjust it like this:
6. Haha, seeing this, you may say, "For the China Mobile issue above, most complainants will continue to ask, 'Why can't you cancel it directly for me? How can you send it directly to me when you send it!' At that time, wouldn't the customer service have to explain again, 'Because we are not in the same department, we don't have the authority'?" That's right, most people who complain will basically continue to ask. But if you explain the specific reasons at this time, the person who asks will not be annoyed by too much talk. He may only be annoyed because the reasons are made up. (They scolded you for not being able to send text messages, but they could have just cancelled it for you.) 7. Therefore, sometimes we only need to tell users “what to do” without asking them “why they should do it this way”; but when the problem is a little more complicated or the user’s “cost of making a mistake” is not low, we need to first let users “know why they should do it this way” and prepare a set of solutions to let users “know why they should do it this way”. However, even if users need to know “why they have to do this”, it does not mean “telling users how we designed it”, nor does it mean directly telling them “know why they have to do this” right from the start. Because users may never need to know how to design, and they may not necessarily understand the designer’s “mental logic”. |
<<: An article to understand the usage of typeof in js
>>: Full steps to create a high-performance index in MySQL
Table of contents 1. The role of nginx process lo...
This article example shares the specific code of ...
What is SQL? SQL is a language used to operate da...
1. Dynamic query rules The dynamic query rules ar...
1. Node server setup + database connection The op...
Table of contents Written in front Precautions De...
This article describes how to install lamp-php7.0...
Preface The company's Ubuntu server places th...
When the resolution of the login interface is par...
Dynamic rem 1. First, let’s introduce the current...
1. Basic Spring-boot Quick Start 1.1 Quick start ...
This article describes the MySQL transaction mana...
This article uses examples to describe MySQL'...
Table of contents 1. Global Guard 1. Global front...
The figure below shows the browser viewing rate i...