以前周鴻祎講過很多次關于用戶感知的話題。一個產品，不管你用了怎樣的技術，怎樣的實現架構，怎樣的流程邏輯，最終表現給用戶的，其實是用戶感知，也許你做的很簡單，但用戶感知很飽滿；也許你做的很復雜，但用戶感知不足，這些都是產品運營中需要面對的問題。

當然，這個話題可能容易跑偏，好比如何通過誘導用戶感知，讓用戶體驗一些其實并不存在的技術。

一個灰色產業的例子是這樣的，警告，你的電腦/手機中病毒了！ 請立即下載查殺工具！

然后下載后顯示已經檢索了多少多少文件，查殺了多少多少病毒，然后要求駐留內存隨時防護你的電腦/手機，那么你覺得這個東西好啊，你看其他軟件都沒報警，就它最可靠，于是保存手機自動啟動，那么，它干嘛了呢？好像也沒干啥壞事，就是做一點廣告劫持，把你日常行為的瀏覽記錄全部加個尾巴，把淘寶的流量賣給淘寶，百度的流量賣給百度，亞馬遜的流量賣給亞馬遜，偷偷從你身上賺了傭金，你還一無所知的以為這是個安適工具。

這是灰產里典型誤導用戶感知的案例。

周鴻祎也提過一個例子，就是 360 路由器的例子，你說你用了新技術，隱藏天線，也可以實現很好的信號傳播，用戶一看沒天線，就覺得這個東西信號必定不行，然后去買四個天線的路由器去。所以不管用了什么技術，先裝上四個天線，這是無條件順從用戶感知的案例。

我做線下技術產品溝通分享，包孕我上次網課，關于需求界限的話題，其中提到一個典型的案例，淘寶的搜索結果，你去翻頁，你翻不過 100 頁的，阿誰搜索結果的數字，無論淘寶，百度，還是谷歌，如果是很小的數字，是精確的；如果是個很大的數字，是估算出來的。那這個例子我舉完，線下分享我就問過在場的童鞋，大家都逛過淘寶對分歧錯誤，誰知道淘寶不能翻超過 100 頁的？每個人都逛過淘寶，我不講出來，沒人知道不能翻超過 100 頁。

說明什么？用戶對超過 100 頁翻頁需求是無感知的。用戶對搜索結果數字估算是無感知的。當年我做CNZZ的時候，有幾十萬站長在使用，覆蓋每天幾十億pageview，我對網站的來路信息，受訪信息都沒有做完整保存，都只保存了前 1000 條，沒有一個站長為這個問題來投訴，或者提出質疑過，說明什么？不影響用戶感知。

這就是為什么我提需求界限這個概念，不影響用戶感知的情況下，可以做很多裁剪來節省技術成本。你看，大翻頁是個連百度，谷歌，淘寶都解決不了的問題，并且也是個用戶感知完全不影響的問題，這個例子足夠明確了。

（多說一句，我做分享的時候發現，很多技術人員還不知道為什么大翻頁是個效率上很難優化技術問題。我覺得這個也可以作為技術面試題了。）

產品研發經常容易陷入的兩個極端誤區

第一種是技術配景的創業者容易犯的錯誤，就是技術架構是咋樣，產品就長成啥樣。我的技術結構和數據結構是這樣這樣的，所以我頁面的功能就是這樣這樣的。

前段時間我就批評我們團隊的辦理后臺，我說做的根本不是辦理者應該看到的，完全就是數據結構的映射，我說你直接給我一個phpmyadmin就好了，你都不消開發了。

第二種是一些技術入門級的公司容易犯的錯誤，就是產品目標是啥樣，技術架構就啥樣。 因為我要做功能a,b,c,d,e，所以我的代碼和數據結構就完全忠實的根據這個功能設計來寫。

這是啥問題呢？沒有考慮復用性，耦合性，對擴展性沒概念，對可能的需求變換沒概念，對業務發展和運營沒概念。前期做好看上去還行，后面想做個活動，想搞個新特性，啥都要重新來弄。

這個話題可能扯的有點遠，但是這就是所謂架構師的作用和意義。

產品經理的目標，就是用戶感知，我要的功能，特性，用戶預期是什么，用戶的交互反饋是什么，前面的東西，必需緊密圍繞用戶感知來做，不能說技術架構長啥樣，我就做成啥樣，當然，有些事情可以溝通，怎么溝通，在盡可能滿足用戶感知的情況下，如何降低技術成本，提高研發效率，這是可以溝通協商的。

而技術架構的工作就是，在盡可能滿足用戶感知的前提下，有效降低技術成本，以及提高對未來業務和運營的兼容性，當然，這兩者可能有一點沖突，但并不是完全沖突。

所以一個界面視圖里，可能存在多個技術結構的雜糅，或者同一個數據結構里的內容可能會按照條件差別，表現在差別角色的差別場景里，這都不是問題，產品架構和技術架構，自己不存在一定的關聯。最典型的是搜索引擎，一個搜索框，后面是極為復雜和龐大的技術架構，，但給用戶的感知是非常簡單和明確的。你想要的是什么，我如何盡可能達到你的預期。

那么，很多創業者，也在尋求，如何用低成本滿足用戶感知。說白了，很多就是“讓用戶以為”。

標簽：林芝 東營 烏魯木齊 鹽城 九江