談談產品和運營：什麼是用戶感知？

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

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

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

然後下載後顯示已經檢索了多少文件，查殺了多少病毒，要求駐留內存隨時防護你的電腦/手機。

那麼你覺得這個東西好啊，你看其他軟體都沒報警，就它最可靠。於是保留手機自動啟動，它幹嘛了呢？好像也沒幹啥壞事，就是做一點廣告劫持，把你日常行為的瀏覽記錄全部加個尾巴，把淘寶的流量賣給淘寶，百度的流量賣給百度，亞馬遜的流量賣給亞馬遜，偷偷從你身上賺了傭金，你還一無所知，以為這是個安全工具。

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

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

我做線下技術產品溝通分享，關於需求邊界的話題，其中提到一個典型的案例：淘寶的搜索結果，你去翻頁，你翻不過100頁的。那個搜索結果的數字，無論淘寶、百度，還是谷歌，如果是很小的數字，是精確的；如果是個很大的數字，是估算出來的。

那這個例子我舉完，線下分享我就問過在場的童鞋，大家都逛過淘寶對不對，誰知道淘寶不能翻超過100頁的？每個人都逛過淘寶，我不講出來，沒人知道不能翻超過100頁。

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

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

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

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

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

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

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

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

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

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

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

所以一個界面視圖裡，可能存在多個技術結構的雜糅，或者同一個數據結構里的內容可能會根據條件不同，體現在不同角色的不同場景里。這都不是問題，產品架構和技術架構，本身不存在必然的關聯。最典型的是搜索引擎，一個搜索框，後面是極為複雜和龐大的技術架構，但給用戶的感知是非常簡單和明確的——你想要的是什麼，我如何儘可能達到你的預期。

那麼，很多創業者也在尋求，如何用低成本滿足用戶感知。說白了，做法就是「讓用戶以為」。

以前被用爛的招，很多美女馬甲不斷地在社交網路里活躍，其實是機器人。更早沒有機器人的時候，就是男生在裡面操作，不說別人，當年馬化騰為了OICQ的活躍，自己不也干過這事么。

現在很多約炮平台不還是用這招騙錢么，而且居然很有用。前段時間我看到網上幾篇爆料文，我知道這東西有人賺錢，但真沒想到居然還有這麼多人會受騙。

另一種是遊戲里，比如棋牌或其他遊戲，也會存在一些機器人。在用戶活躍度不高的情況下，滿足玩家對戰的需求，但有些機器人太傻，很容易被玩家看穿。

說個成功案例，當時貪吃蛇大作戰剛開始是沒有聯機版的，但是大部分玩家都以為自己是跟聯機的人作戰。而且比聯機的效果還好，因為不卡啊。

低成本滿足用戶感知，有些東西確實不太好，比如誤導用戶相信一些不正確的東西，或者讓用戶為「看上去價值很高，而實際上價值很低」的東西付出更高的成本。

但有些娛樂的場景，其實也算不上多大罪過。比如遊戲里，用數值PK來模擬實時PK，技術成本低，效果做得足夠好，滿足玩家的訴求也沒什麼不好的（當然，一些深度玩家肯定會發現這個問題，並追尋更好的產品，但淺度玩家市場也是存在的哦）。

另外能正確理解用戶感知的邊界，也就是需求邊界，可以節省很多無用功，這個就不贅述了。

用戶感知和用戶預期，在某些場景可能是一回事，某些場景可能會有一些區別。用戶在有些場景是無預期的，這時候他感知的是什麼？咬文嚼字的事情就不多說了，希望以上的案例和概念能幫助產品、運營人員更好地設計產品，以及與研發更有效率地溝通。