編輯導語：很多時候業(yè)內的行事準則都是“數據導向”，然而數據好的產品，就一定好嗎？其實不一定。本文作者通過幾個案例，分析了產品的“體驗”“口碑”和“數據”之間的關系，感興趣的小伙伴們一起來看一下吧。

自KPI、OKR、AB實驗等理念流入互聯(lián)網后，長期以來業(yè)內的行事準則都是“數據導向”，想必日常工作中你也經常被產品規(guī)勸“哎呀～這樣做數據一定會好的，不要在乎這些體驗細節(jié)”，或者你也有過試圖說服產品“體驗好的話數據就會好呀”。

但往往有些時候，在項目規(guī)劃和設計階段自信滿滿地認為可以帶來數據收益的項目，上線后卻不理想，這是為什么呢？本期，我們來說一說項目上線后數據復盤和體感差異的原因。

我們先厘清幾個概念，體驗好、口碑好和數據好。

在這里我們暫且先定義「體驗好」為項目執(zhí)行者認為的好體驗，諸如減少一步操作、更容易獲取關鍵信息等業(yè)內理論上認為的體驗好；「口碑好」是項目實際上線后用戶的正向反饋；「數據好」是項目上線后觀測指標達到或超出預期。

如果照這么理解的話，我們通常的思路是「體驗好」帶來「口碑好」，「體驗好」和「口碑好」共同帶來「數據好」。

接下來我們通過幾個案例來詳細講講實際發(fā)生的，不符合模型的情況

01 口碑差，數據好

寫這個議題的時候，首先映入腦海中案例就是19年訂閱號的一次改版，改版的主要優(yōu)化點是把原先進入時為賬號列表改為進入文章信息流，如下圖所示：

從產品設計思路上來講，用戶進入是來消費文章的，原方案用戶需要先選賬號（文章來源），再選擇想要閱讀的文章，改版后直接把文章呈現(xiàn)在用戶面前，屬于設計思路中常見的“減少一步”帶來的“體驗優(yōu)化”。

然而項目上線后卻遭到用戶的強烈不滿，用戶意見諸如：“越改越亂”“我現(xiàn)在都不知道哪些公眾號有多少條消息沒看”“逼著我取消了好幾個公眾號”，當然，其中也不乏一些贊美之詞，但不習慣/不喜歡/體驗差的聲量還是占據了反饋的絕大部分。

在這樣的罵聲中產品還是堅持這樣的方案，想必數據應該給了產品相當大的正向反饋。這是一個理論上體驗好，實際上口碑差但數據好的案例。

我們將用戶反饋進行一些歸類處理，就能發(fā)現(xiàn)這次數據復盤與體感差異不符的原因。

負反饋的用戶大多是有深度閱讀習慣的用戶，習慣是先尋找今日想鉆研的領域（對應某個賬號），然后一次性地認真閱讀吸收文章，改版后對這類用戶來說，首頁的劣質內容搶占了太多視線，導致尋找合意的文章變得困難。

假設一下你是一個歷史系的學生，你每天會去學校圖書館里的歷史區(qū)閱讀相關書籍，但你也喜歡看雜志和小說，歷史書讀累了偶爾也會逛逛其他圖書區(qū)。

現(xiàn)在圖書館突然跟你說，反正你來這里都是看書的，我發(fā)現(xiàn)你會看歷史書、雜志和小說，我把所有的雜志小說都和歷史書混在一起給你，省的你在這些區(qū)里走來走去的，你會因為圖書館讓你少走了幾步而感謝它嗎？顯然不會，這樣你每天讀書之前就得先把歷史書篩選出來，而篩選歷史書的成本遠比多走幾步路的成本大得多。

當然，肯定不是所有人去圖書館都是去讀專業(yè)書的，也不是所有使用該功能的用戶都有深度消費習慣，但是用戶對功能的依賴程度不同，導致用戶愿意為功能發(fā)聲的意愿也不同.

當深度用戶的體驗折損遠遠大于非深度用戶的體驗升級，帶來的必然是負反饋強勢碾壓正反饋。

而為什么數據會好呢？深度文章的生產和消費成本遠遠大于非深度文章（成本可以理解為需要付出的時間&需要掌握的知識儲備），原來先找賬號后找文章的方式，用戶會主動去尋找深度文章來閱讀。

而現(xiàn)在是非深度文章占據了首頁百分七八十的版面，假設你每天花100分鐘閱讀，閱讀一篇深度文章需要25分鐘，閱讀一篇非深度文章需要5分鐘，那么改版前你每天可以閱讀4篇文章，改版后你每天可以閱讀20篇文章，數據這不就上去了？

再舉例假設，全校1000個學生，只有50個學生每天泡館，200個學生經常去，其他學生比較少只看一類書，甚至有的同學不愛看專業(yè)書，覺得去圖書館麻煩就不常去。

但是圖書館改版后，所有書你隨便抓一本就可以開始看，50個每天泡館的學生不愛去了，200個經常去的學生里100也不愛去100個覺得差不多，但是剩下750個學生里有600開始抽空去圖書館看一看了，這圖書館的生意不也好起來了。

02 體驗好，數據差

我在幾年前做過一款國外產品，針對的是非發(fā)達國家地區(qū)的摩的市場，可以簡單理解為國外打摩的軟件，用戶在軟件上呼叫摩的后，摩的師傅來接送你，你需要在軟件上輸入摩的師傅的號碼完成旅程并付款，簡單流程示意如下圖：

當時二維碼已經在國內盛行起來了，國內用戶已經習慣了使用二維碼做任何事，包括付款。我們認為使用二維碼會比輸入一串數字來說更簡便，體驗更好，所以決定把輸入「摩的的編碼」這一步優(yōu)化為「掃描摩的上的二維碼」，并向摩的師傅們發(fā)放了專屬的二維碼貼紙。

我們自信滿滿，覺得這樣的優(yōu)化一定能夠帶來用戶體驗的升級，拉新促活不在話下。然而結果卻背道而馳，改版后平臺成單量顯著下降了，我們不得已做了一次當地用戶調研和訪談。

原來，因為當地經濟情況和技術水平都較落后，二維碼對當地人來說十分陌生，人們很難下決定通過這樣陌生又迅速的行為去執(zhí)行付款操作。用戶對二維碼表現(xiàn)出的強烈不安全、不信任感直接影響了用戶放棄成單付費。

相反，輸入數字串（俗稱PIN碼）雖然流程相對繁瑣，但對于付款這種慎重的行為，恰好留足了時間做思考和決定。

與此相似的案例在國內產品上我又碰到了一次，這次是開設房間時需要對房間設置權限，起初我們的版本是作為選擇項，用戶開房時可以選擇所有人可加入或者只有朋友能加入。

有一次，我們覺得這樣的設計似乎有些繁瑣，只需要一個權限開關就可以了，打開開關就是僅朋友能加入，關閉開關就是所有人都可以加入（這層含義較隱晦，需要用戶額外去思考和理解），我們又一次自信滿滿地上線了，結果又一次與預期背道而馳。

第一個例子與第二個例子有一個相似之處，是對用戶來說，這都是一個“謹慎的操作”，對于“謹慎的操作”，傳統(tǒng)理論上那些「體驗好」的方法（更快一點，更簡單一點）不太受用，這些「體驗好」的設計僅僅只是從行動上幫用戶減少了一兩步，卻沒辦法幫助用戶減少執(zhí)行行動前的思考。

舉個例子，你本來需要親自開飛機空投炸彈，優(yōu)化到你只需要按一個按鈕就可以發(fā)射炸彈，對你投炸彈這個行為的影響大嗎？不大，因為「要不要投炸彈」在行動前的思考遠遠復雜于「投炸彈」這個行為。

反而可能因為我們有時間在飛機上了解清楚“炸彈”，而沒辦法在按鈕上對“炸彈”有理解，而導致面對著按鈕猶猶豫豫，最終放棄。對于復雜且謹慎的行為，設計清楚（幫助用戶在思考節(jié)省時間）遠比設計簡單（行動簡單了但思考不會簡單）來得更重要。

03 體驗不好，數據好

• “我在這里放個按鈕/入口！”
• “這里不符合使用場景呀”
• “我知道，但這里流量大（os：我需要流量把我的功能戴起來）”
• “按鈕/入口要設計得大一點，再大一點，顏色要鮮艷的，最好是大紅色，能來點動效就更棒了”

不知道這樣的對話大家熟不熟悉，我早期的職業(yè)生涯中經常能遇到這樣的項目需求。但往往這樣又大又紅的設計還總能拿到很好的數據供人吹噓，明明用過的人都覺得這樣的設計體驗很不好，為什么卻在數據的驅使下越來越猖狂呢？

以上圖的例子做展開，在這樣的需求下，我們可能會被迫作出這樣的設計：

上線后，項目負責人發(fā)了一封郵件：需求上線后「算命」功能使用pv/uv上漲顯著，證明這是一個合理的需求，非常好的設計，我們要朝著這個方向持續(xù)優(yōu)化！

但你真的覺得這是一個合理的需求、好的設計嗎？

這就是典型的把數據當目標，以片面下結論的情況。

首先我們必須明確一點，做需求做設計都是為了更好的體驗或服務新的產品階段，數據只是輔助我們判斷有沒有達成目標的工具，切莫盲目服務數據。

其次，在做需求做設計的時候應有全局觀。就以上述所舉例子展開，需求的目標應該是在用戶想算命的場景提供算命服務，如果我們判斷消息頁是用戶想要算命的場景，那么我們上線后觀測的數據除了算命功能的pv/uv，還需要補充退出率，以及頂部新增算命入口后，對聊天頁的折損數據（聊天pv/uv，收發(fā)消息數……），把這些考慮進去我們很可能得到不一樣的數據結論：

看完真實的復盤后，首先應該能判斷消息頁不是用戶想算命的場景，此時如果你的產品策略不是把這個軟件轉型成算命軟件，就可以下掉這里的入口了。

如果你正要轉型算命軟件，非常需要消息頁來帶量，那么你也能看出來在這里加入口對聊天體驗的折損有多大，此時你就得思考一下，「帶起來的量」值不值得聊天功能「折損的體驗」？

如果不值得，你也可以開始考慮換種方式帶量了；如果值得，那繼續(xù)做大做強就沒什么問題了，祝福這個產品成為算命一霸。

04 總結

項目上線后數據復盤與體驗有差異是很常見的，包括但不限于上面所述案例表現(xiàn)出來的原因。

總之，還是要牢記數據是工具，不是目標，如果發(fā)現(xiàn)數據復盤結果與預期有不符，可以嘗試：給用戶分層，更細致化地分析用戶行為；通過用戶調研了解用戶真正的使用場景和流程，真正幫用戶解決難點而不是“偽體驗好”；以及，用更全面的視角、結合更多信息來看待項目是否達成目標。

“數據說謊”的現(xiàn)象還有很多，將來再繼續(xù)討論。

本文由 @白話說交互 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自unsplash，基于CC0協(xié)議。