產(chǎn)品經(jīng)理警惕!功能優(yōu)化反成了挖坑

1、我們常常會碰到這樣的情況。功能上線后有一些用戶吐槽：流程太長了，操作不方便，頁面字體看不清.我們根據(jù)反饋者的意見優(yōu)化了功能，本以為這個功能是優(yōu)化得更好了，更完美了。結(jié)果一改完，卻收到了更多用戶的吐槽：為什么改！好不容易習(xí)慣了，又得重新去適應(yīng)。說不定剛適應(yīng)完又改掉了。很多時候，功能的優(yōu)化比新做更令人頭疼。既要兼顧不同用戶的喜好與習(xí)慣，還要平衡系統(tǒng)的復(fù)雜度。所以每一個優(yōu)化都要慎之又慎，謹(jǐn)防變成挖坑。本文就從功能優(yōu)化的增刪改三方面來探討下注意點(diǎn)。優(yōu)化后老用戶的吐槽讓我想起了可口可樂的這個故事。1985年，可口可樂公司正面臨百事可樂日益嚴(yán)峻的挑戰(zhàn)?？煽诳蓸范嗄陙硪恢眻猿止爬系呐浞?，這個配方已經(jīng)使用了

2、99年。此時可口可樂公司受到越來越多的質(zhì)疑，人們懷疑百年不變的口感是不是能夠趕上新時代的步伐，不斷有消費(fèi)者抱怨這種一成不變死氣沉沉的口味太落伍。在大量要求變革聲音的推動下， 1985年 4 月 23 日，可口可樂公司宣布改變他們已經(jīng)使用了 99年之久的秘密配方，推出新配方制成的可樂。新可樂一推向市場，那些曾經(jīng)要求變革的聲音消失了，但是那些一直沉默的，支持傳統(tǒng)可樂的消費(fèi)者發(fā)出了憤怒的吼聲，可口可樂的銷量一落千丈?？煽诳蓸凡坏貌换氐竭^去的老路，新配方計劃在蒙受了重大損失之后以失敗而告終，紐約時報更是將可口可樂更改配方的決策稱為美國商界一百年來最重大的失誤之一。這樣的失誤其根源就在于他們過分注重傾聽

3、反對的聲音，而恰恰忽略了那些沉默的支持者。功能的優(yōu)化也面臨著沉默支持者的問題。當(dāng)功能新上時，用戶更多的是去適應(yīng)，因?yàn)樗麄円膊恢拦δ軕?yīng)該長什么樣，能滿足日常使用，大部分人就可能不會提意見。但當(dāng)我們聽從反對者的建議進(jìn)行優(yōu)化時，就會存在前后方案的對比，也有了 2 種方案的選擇，用戶就會根據(jù)自己的習(xí)慣各有所喜。我也經(jīng)常接到用戶反饋：能不能改回原來的？遇到這種問題時，該怎么處理呢？用戶說什么就做什么嗎？肯定是不行的。我們還是要分情況來處理。我們從原有功能的新增、修改、刪除來分別看應(yīng)對方法。功能新增是三種情況里面最簡單的一種了。錦上添花大概率來說不是一件壞事，對于老用戶來說，如果不需要，不用就可以了。但

4、還需考慮下面這一點(diǎn)。新增功能如果用戶用不到，還直接顯示在頁面上嗎？如果顯示了，老用戶會不會覺得很累贅，特別是B 端產(chǎn)品更加注重效率。哪怕是多了個用不到的字段，用戶都會覺得影響視覺和操作。我就遇到了因多 3 個字段引起的強(qiáng)烈反對。在開處方時，原來是這樣的，醫(yī)生填寫藥品名稱、單次劑量等內(nèi)容。但有一些藥品是要做皮試和輸液的，一些診所提出，需要在開立藥品時標(biāo)注是否需要皮試，皮試結(jié)果出來后填寫結(jié)果，輸液的話填寫滴速。很合理。于是我就在原基礎(chǔ)上加了 3 個字段：我沒有加配置項(xiàng)，我本想不需要的話不填就好了，不影響原功能的使用。但很多用戶提出他們診所不輸液，這幾個字段用不到，不要顯示出來。后來發(fā)現(xiàn)原因，有些診

5、所的電腦分辨率比較低，本來操作欄一頁上能顯示全，多了 3 個字段后，操作欄需要向左拖動才能看到，造成了極大的不方便。最簡單的就是懸浮固定操作欄。但在強(qiáng)調(diào)不輸液的診所看來，這幾個字段違背了他們的理念，那就要做成配置項(xiàng)了。這也讓我明白了，功能不是越多越好，用戶要的不是多，他們只想要他們需要的，不需要的最好全都屏蔽掉。功能新增時千萬要注意不用用戶的心理，盡量減少對他們的影響。這是最容易引起吐槽的，也是處理起來考慮面最多的。我們先看會有哪些方面的修改，然后再看常用的解決方法。流程修改的宗旨是：更短，更符合業(yè)務(wù)場景。但系統(tǒng)開發(fā)時會將模塊微服務(wù)化，建議相近內(nèi)容在不同場景下使用時能夠共用一套，以減少工作量，

6、同時減少系統(tǒng)的復(fù)雜度，減少維護(hù)成本。舉個例子來解釋下這2 者可能引起的沖突。零售藥品的操作：選擇藥品，付錢， 2 步搞定。流程路徑：但在門診支付時，選擇付費(fèi)藥品后，需要先確認(rèn)下待收費(fèi)信息，如果有會員折扣的，先打折。再進(jìn)入下一頁使用優(yōu)惠券，零頭減免等。再進(jìn)入下一頁選擇支付方式，比如刷醫(yī)保，現(xiàn)金，微信支付等，歷經(jīng) 3 個頁面才付款完成。對于門診來說，這個流程是合理的，但對于零售來說，一般沒有優(yōu)惠，這個流程就太繁瑣了。但都屬于支付，設(shè)計時就會共用一套。如何找到 2 種場景下的平衡，就是我們需要慎重思考的了。（想看答案請往下）交互的優(yōu)化往往意味著用戶體驗(yàn)的優(yōu)化。但產(chǎn)品經(jīng)理不是用戶，也不可能去訪談所有用

7、戶，而用戶的體驗(yàn)感是因人而異的，所以這部分也是可能挖坑最多的地方。我在用手機(jī)銀行的時候就經(jīng)常會吐槽。本來我的頁面能看到全部余額，信用卡待還金額，為什么要換位置，都找不到在哪里了。用戶在用我們產(chǎn)品的時候，也有同樣的感受。比如說我本來在開立處方的上方有個復(fù)制處方的按鈕。但是用戶說，我在側(cè)邊欄看到了歷史處方，卻不能直接點(diǎn)擊復(fù)制，還非要點(diǎn)擊復(fù)制處方的按鈕，去彈窗里找到那條處方去復(fù)制，不是很麻煩嗎？非常有道理，但是如果直接把復(fù)制的按鈕換到側(cè)邊欄合適嗎？我估計很多用戶就會找不到入口了。即使在進(jìn)入頁面時做個引導(dǎo)，有些用戶的習(xí)慣一時還比較難轉(zhuǎn)變過來。這時不妨做個A/B test ，下面會詳細(xì)的講。如果頁面的整

8、體布局沒有變化，只是做些間距的調(diào)整，按鈕顏色等的改變，用戶感知是比較弱的。但布局的大改，文字改圖標(biāo)，圖標(biāo)改變這些就可能引起較大的爭議了。比較常見的改動：卡片和列表。有的用戶覺得卡片直觀，喜歡卡片。有的用戶覺得卡片信息太少，喜歡列表。很多產(chǎn)品都會做成2 者可切換的形式。針對以上三方面做出的修改，我總結(jié)了 4 點(diǎn)經(jīng)驗(yàn)。總的原則是：在開發(fā)及維護(hù)成本不高的情況下，把選擇權(quán)交給用戶。盡量少做一刀切。就像上面說的優(yōu)化改動1 中的支付路徑，對于中間頁面，可以做一個配置，零售時不顯示待收費(fèi)頁，直接選擇支付方式付款。甚至可以把支付方式的選擇做成彈窗，減少跳頁帶來的跳出感。這樣2 種場景下都能較好的應(yīng)用，同時不增

9、加系統(tǒng)的復(fù)雜度。這個方法比較適合業(yè)務(wù)流程的改動。 B 端產(chǎn)品中有很多這樣的情況，因?yàn)槊總€用戶的實(shí)際場景有差異，導(dǎo)致需求有差異，需要系統(tǒng)更加的靈活，來滿足更多的用戶。我們肯定是照著最完整的路徑做的，如果中間環(huán)節(jié)不需要，就做個開關(guān)屏蔽掉。比如說很復(fù)雜的門診流程，比較正規(guī)的是1 號路線：掛號-收掛號費(fèi)-護(hù)士預(yù)診（量體溫之類） - 醫(yī)生看診-收費(fèi)-藥房發(fā)藥但有些診所比較小，也沒有掛號費(fèi)，像 2號路線，掛號完就直接醫(yī)生看診了。醫(yī)生看診完就到 3 號路線，先發(fā)藥，后收費(fèi)。當(dāng)然這只是舉個例子，實(shí)際情況比這個還要復(fù)雜，比如夫妻老婆店，雇不起前臺，看病、收費(fèi)都是一個人做。需要注意的是，這里面沒有哪一個流程是正確

10、的，當(dāng)用戶提出他們的建議時，不代表原有的流程不對。我們不能直接改，只能在最全的鏈路上插入便捷點(diǎn)。就像上面改動2 說到的頂部和側(cè)邊欄的復(fù)制病歷按鈕，就是在做一次測試。這個方法比較適合交互的小改動。不能有一點(diǎn)不確定就去問用戶吧，用戶到后面就覺得煩了。B 端產(chǎn)品也可以通過埋點(diǎn)的方式來看用戶的喜好。前期先保留 2 者，后面根據(jù)點(diǎn)擊量的數(shù)據(jù)，來放棄一方，畢竟功能是一樣的，沒有必要重復(fù)。而測試階段，也是用戶對新功能的適應(yīng)階段。在放棄一方前，還能做個引導(dǎo)，讓用戶不會覺得很突然。就像上面改動3 說到的卡片和列表的切換，就是在增加選擇項(xiàng)。增加選擇項(xiàng)比較適合頁面UI 的改動。開發(fā)和維護(hù) 2套的成本相對較低。如果是

11、業(yè)務(wù)流程方面，是不建議的。比如說改動 1 里面提到的零售和門診的支付做成 2 套，這個成本就大了，但可以做些適當(dāng)?shù)暮喕?。?dāng)我們沒法確定用戶喜歡哪一種時，可以做一次調(diào)研，如果結(jié)果支持度是1： 1，那還是做2 套，可以自由切換。由于一刀切去替換，我踩過一次大坑。原先的微信H5 預(yù)約頁面一直被一些用戶吐槽，迫于一位優(yōu)質(zhì)用戶的壓力，我們根據(jù)他的需求做了一個定制化的優(yōu)化版本。做完后其他用戶看見了，覺得不錯，就提出要替換原先的。見提出的人還挺多的，而且新版本線上運(yùn)行了 1 個多月了，也比較穩(wěn)定了，我就做了一次全局的替換。結(jié)果當(dāng)晚就炸了，因?yàn)橐恍┯脩舻脑O(shè)置比較特殊，導(dǎo)致新版本部分科室無法被預(yù)約，只能做緊急回

12、退。后面就給了用戶兩個鏈接，自己選擇用哪一套。經(jīng)過這次后，我在做全面替換前，一定會充分調(diào)研用戶。如果改的不是一個點(diǎn)，一個功能，而是整個系統(tǒng)呢？前面說到的三種方法都沒有辦法解決了。我們需要讓用戶提前去操作和適應(yīng)。我們對之前的產(chǎn)品做了一個完全的重構(gòu)。在保留老系統(tǒng)功能的基礎(chǔ)上，對原有功能進(jìn)行了優(yōu)化，也增加了很多新功能，當(dāng)然交互和 UI 也是變化比較大 的。我們對比之前老用戶提出的無法解決的需求，在新系統(tǒng)里面，大部分都得到了較好的解決。老用戶也很積極的表示想用新系統(tǒng)。但在真的做系統(tǒng)數(shù)據(jù)遷移時發(fā)現(xiàn)，有些用戶開始顧慮了：不知道有哪些細(xì)節(jié)點(diǎn)可能會引起不能用，不適應(yīng)。我們只能提前給賬號試用，讓客服再次培訓(xùn)，提醒用戶自己多操作，等準(zhǔn)備好了再做遷移。不敢想象，如果一下子全部切換過去，會發(fā)生多少重大的問題。常說 “加功能簡單，去功能難。 ”雖然加功能都不簡單，有時候做的越多，錯的越多。但減功能是真的難，遇到的也比較少。這也告訴我們，別動不動就加功能。想要下架功能，首先要看的就是用戶使用量。如果在近一段時間內(nèi)沒有人在用，且之前用過的人也非常少，那直接刪除就行。我碰過過這樣一個功能，輔助檢查的外送。一共就2 個診所用過，且最后次使用是在2 年前。砍的非常的輕松。但很多時候還是有用戶在使用的，只是量比較少。那要看第二步了。如