以前周鸿祎讲过很多次关于用户感知的话题。一个产品，不管你用了怎样的技术，怎样的实现架构，怎样的流程逻辑，最终表现给用户的，其实是用户感知，也许你做的很简单，但用户感知很饱满；也许你做的很复杂，但用户感知不足，这些都是产品运营中需要面对的问题。

当然，这个话题可能容易跑偏，好比如何通过诱导用户感知，让用户体验一些其实并不存在的技术。

一个灰色产业的例子是这样的，警告，你的电脑/手机中病毒了！ 请立即下载查杀工具！

然后下载后显示已经检索了多少多少文件，查杀了多少多少病毒，然后要求驻留内存随时防护你的电脑/手机，那么你觉得这个东西好啊，你看其他软件都没报警，就它最可靠，于是保存手机自动启动，那么，它干嘛了呢？好像也没干啥坏事，就是做一点广告劫持，把你日常行为的浏览记录全部加个尾巴，把淘宝的流量卖给淘宝，百度的流量卖给百度，亚马逊的流量卖给亚马逊，偷偷从你身上赚了佣金，你还一无所知的以为这是个安适工具。

这是灰产里典型误导用户感知的案例。

周鸿祎也提过一个例子，就是 360 路由器的例子，你说你用了新技术，隐藏天线，也可以实现很好的信号传播，用户一看没天线，就觉得这个东西信号必定不行，然后去买四个天线的路由器去。所以不管用了什么技术，先装上四个天线，这是无条件顺从用户感知的案例。

我做线下技术产品沟通分享，包孕我上次网课，关于需求界限的话题，其中提到一个典型的案例，淘宝的搜索结果，你去翻页，你翻不过 100 页的，阿谁搜索结果的数字，无论淘宝，百度，还是谷歌，如果是很小的数字，是精确的；如果是个很大的数字，是估算出来的。那这个例子我举完，线下分享我就问过在场的童鞋，大家都逛过淘宝对分歧错误，谁知道淘宝不能翻超过 100 页的？每个人都逛过淘宝，我不讲出来，没人知道不能翻超过 100 页。

说明什么？用户对超过 100 页翻页需求是无感知的。用户对搜索结果数字估算是无感知的。当年我做CNZZ的时候，有几十万站长在使用，覆盖每天几十亿pageview，我对网站的来路信息，受访信息都没有做完整保存，都只保存了前 1000 条，没有一个站长为这个问题来投诉，或者提出质疑过，说明什么？不影响用户感知。

这就是为什么我提需求界限这个概念，不影响用户感知的情况下，可以做很多裁剪来节省技术成本。你看，大翻页是个连百度，谷歌，淘宝都解决不了的问题，并且也是个用户感知完全不影响的问题，这个例子足够明确了。

（多说一句，我做分享的时候发现，很多技术人员还不知道为什么大翻页是个效率上很难优化技术问题。我觉得这个也可以作为技术面试题了。）

产品研发经常容易陷入的两个极端误区

第一种是技术配景的创业者容易犯的错误，就是技术架构是咋样，产品就长成啥样。我的技术结构和数据结构是这样这样的，所以我页面的功能就是这样这样的。

前段时间我就批评我们团队的办理后台，我说做的根本不是办理者应该看到的，完全就是数据结构的映射，我说你直接给我一个phpmyadmin就好了，你都不消开发了。

第二种是一些技术入门级的公司容易犯的错误，就是产品目标是啥样，技术架构就啥样。 因为我要做功能a,b,c,d,e，所以我的代码和数据结构就完全忠实的根据这个功能设计来写。

这是啥问题呢？没有考虑复用性，耦合性，对扩展性没概念，对可能的需求变换没概念，对业务发展和运营没概念。前期做好看上去还行，后面想做个活动，想搞个新特性，啥都要重新来弄。

这个话题可能扯的有点远，但是这就是所谓架构师的作用和意义。

产品经理的目标，就是用户感知，我要的功能，特性，用户预期是什么，用户的交互反馈是什么，前面的东西，必需紧密围绕用户感知来做，不能说技术架构长啥样，我就做成啥样，当然，有些事情可以沟通，怎么沟通，在尽可能满足用户感知的情况下，如何降低技术成本，提高研发效率，这是可以沟通协商的。

而技术架构的工作就是，在尽可能满足用户感知的前提下，有效降低技术成本，以及提高对未来业务和运营的兼容性，当然，这两者可能有一点冲突，但并不是完全冲突。

所以一个界面视图里，可能存在多个技术结构的杂糅，或者同一个数据结构里的内容可能会按照条件差别，表现在差别角色的差别场景里，这都不是问题，产品架构和技术架构，自己不存在一定的关联。最典型的是搜索引擎，一个搜索框，后面是极为复杂和庞大的技术架构，，但给用户的感知是非常简单和明确的。你想要的是什么，我如何尽可能达到你的预期。

那么，很多创业者，也在寻求，如何用低成本满足用户感知。说白了，很多就是“让用户以为”。