Talking about products and operations: What is user perception?

Zhou Hongyi has talked about the topic of user perception many times before. For a product, no matter what technology you use, what implementation architecture, or what process logic you use, what is ultimately reflected to users is user perception. Maybe what you do is simple, but the user perceives it as full. Maybe what you do is very complicated, but users don’t perceive it enough. These are the problems that need to be faced in product operations .

Of course, this topic may easily go off track, such as how to induce user perception and let users experience technologies that do not actually exist.

An example of a grey industry is this: WARNING! Your computer/mobile phone has a virus! Please download the anti-virus tool immediately!

After downloading, it will show how many files have been retrieved, how many viruses have been detected and killed, and it is required to stay in memory to protect your computer/mobile phone at all times.

So you think this thing is good. You see, other software don’t alarm, so this one is the most reliable. So I kept the phone starting automatically, what did it do? It doesn't seem to do anything bad, just some advertising hijacking, adding a tail to all your daily browsing records, selling Taobao 's traffic to Taobao, Baidu's traffic to Baidu, and Amazon 's traffic to Amazon, secretly making commissions from you, and you are still unaware of it and think it is a security tool.

This is a typical case of misleading user perception in the gray industry.

Zhou Hongyi also mentioned an example, which is the 360 ​​router. You said you used new technology to hide the antenna, which can also achieve good signal propagation. When users see that there is no antenna, they think that the signal must be bad, and then go buy a router with four antennas. So no matter what technology is used, four antennas are installed first. This is a case of unconditional compliance with user perception.

I was doing offline technical product communication and sharing about the topic of demand boundaries, and one of the topics was a typical case: if you flip through the pages of Taobao’s search results, you can’t get past 100 pages. The number of search results, whether it is Taobao, Baidu, or Google , if it is a very small number, it is accurate; if it is a very large number, it is estimated.

After I gave this example, I asked the people present during the offline sharing, you have all visited Taobao, right? Who knew that Taobao cannot browse more than 100 pages? Everyone has visited Taobao. If I don’t tell you, no one will know that you can’t flip through more than 100 pages.

What does it mean? Users are unaware of the need to turn pages beyond 100, and are unaware of the numerical estimates of search results. When I was working on CNZZ , there were hundreds of thousands of webmasters using it, covering billions of pageviews every day. I have not kept all the information about the website's source and the interviewees. I only kept the first 1,000 items. No webmaster has complained or raised any questions about this issue. What does this mean? Does not affect user perception.

This is why I proposed the concept of demand boundaries. Without affecting user perception, a lot of cutting can be done to save technical costs. You see, large page turning is a problem that even Baidu, Google, and Taobao cannot solve, and it is also a problem that has no impact on user perception. This example is clear enough.

(By the way, when I was sharing my experience, I found that many technical staff still don’t know why large page turning is a technical problem that is difficult to optimize in terms of efficiency. I think this can also be used as a technical interview question.)

Product development often falls into two extreme misunderstandings :

The first is a mistake that entrepreneurs with a technical background often make, which is that the product will be shaped by the technical architecture. My technical structure and data structure are like this, so the functionality of my page is like this.

Some time ago, I criticized our team's management backend. I said that it was not what managers should see at all. It was just a mapping of data structures. I said that you can just give me a phpMyAdmin and you don't have to develop it.

The second mistake is often made by companies at the entry-level technology level, which is that the technical architecture is based on the product goals. Because I want to do various functions, my code and data structure are written completely faithfully according to this functional design.

What is the problem? There is no consideration of reusability and coupling, no concept of scalability, no concept of possible changes in requirements, and no concept of business development and operations . It was done in the early stage and looked okay, but later on, if we wanted to hold an event or create a new feature, we had to start all over again.

This topic may be a bit far-fetched, but this is the role and significance of the so-called architect.

The goal of a product manager is user perception. The functions and features I want, what the user expects, and what the user's interactive feedback is, all of these things must be closely centered around user perception. I can't just build it based on what the technical architecture looks like. Of course, some things can be communicated. How to reduce technology costs and improve R&D efficiency while satisfying user perception as much as possible is something that can be communicated and negotiated.

The work of technical architecture is to effectively reduce technical costs and improve compatibility with future business and operations while satisfying user perception as much as possible. Of course, the two may conflict a little, but not completely.

Therefore, in one interface view, there may be a mixture of multiple technical structures, or the content in the same data structure may be reflected in different scenarios of different roles depending on different conditions. This is not a problem. There is no necessary connection between product architecture and technical architecture. The most typical example is the search engine , a search box, behind which is an extremely complex and huge technical architecture, but the perception given to users is very simple and clear - what do you want and how can I meet your expectations as much as possible.

So, many entrepreneurs are also seeking how to satisfy user perception at low cost. To put it bluntly, the approach is to "let users think".

This is a trick that has been used too much in the past. Many beautiful female aliases are constantly active on social networks , but they are actually robots. Even before there were robots, it was boys who operated them. Not to mention others, didn’t Ma Huateng do the same thing to increase the activity of OICQ?

Aren’t there many hookup platforms that still use this trick to defraud people of their money? And it actually works. Some time ago, I saw several explosive articles on the Internet. I knew that some people made money from this, but I never expected that so many people would be deceived.

Another type is in games , such as chess, cards or other games, where there are also some robots. When user activity is not high, it can meet the players' needs for combat, but some robots are too stupid and can be easily seen through by players.

Let me tell you a successful case. When the Snake game was first launched, there was no online version, but most players thought they were fighting against online people. And the effect is better than online because there is no lag.

Low cost satisfies user perception. Some things are indeed not very good, such as misleading users to believe something incorrect, or making users pay higher costs for things that "seem to be of high value but are actually of low value."

But some entertainment scenes are not actually that serious a sin. For example, in games, using numerical PK to simulate real-time PK has low technical costs, the effect is good enough, and there is nothing wrong with satisfying the demands of players (of course, some deep players will definitely discover this problem and pursue better products, but the market for shallow players also exists).

In addition, correctly understanding the boundaries of user perception, that is, the boundaries of demand, can save a lot of useless work, which I will not elaborate on.

User perception and user expectations may be the same thing in some scenarios, but may be slightly different in other scenarios. Users are faced with unexpected situations in some scenarios. What do they perceive at this time? I won’t go into too much detail on wording, but I hope the above cases and concepts can help product and operations personnel better design products and communicate with R&D more efficiently.