起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識功能優化越做越差？你需要警惕這個問題
功能優化不是簡單的增刪改，需要權衡各方的需求來綜合決定。產品經理不能過于注重反對者的建議而進行全盤否定，也不能固執己見，聽不進建議。文章梳理總結了應對功能優化的3個步驟，供大家一同學習和參考。
我們常常會碰到這樣的情況。功能上線后有一些用戶吐槽：流程太長了，操作不方便，頁面字體看不清…
我們根據反饋者的意見優化了功能，本以為這個功能是優化得更好了，更完美了。結果一改完，卻收到了更多用戶的吐槽：為什么改！好不容易習慣了，又得重新去適應。說不定剛適應完又改掉了。
很多時候，功能的優化比新做更令人頭疼。既要兼顧不同用戶的喜好與習慣，還要平衡系統的復雜度。所以每一個優化都要慎之又慎，謹防變成挖坑。
本文就從功能優化的增刪改三方面來探討下注意點。
一、沉默的支持者
優化后老用戶的吐槽讓我想起了可口可樂的這個故事。
1985年，可口可樂公司正面臨百事可樂日益嚴峻的挑戰?？煽诳蓸范嗄陙硪恢眻猿止爬系呐浞?，這個配方已經使用了99年。此時可口可樂公司受到越來越多的質疑，人們懷疑百年不變的口感是不是能夠趕上新時代的步伐，不斷有消費者抱怨這種一成不變死氣沉沉的口味太落伍。
在大量要求變革聲音的推動下，1985年4月23日，可口可樂公司宣布改變他們已經使用了99年之久的秘密配方，推出新配方制成的可樂。新可樂一推向市場，那些曾經要求變革的聲音消失了，但是那些一直沉默的，支持傳統可樂的消費者發出了憤怒的吼聲，可口可樂的銷量一落千丈。
可口可樂不得不回到過去的老路，新配方計劃在蒙受了重大損失之后以失敗而告終，《紐約時報》更是將可口可樂更改配方的決策稱為美國商界一百年來最重大的失誤之一。這樣的失誤其根源就在于他們過分注重傾聽反對的聲音，而恰恰忽略了那些沉默的支持者。
功能的優化也面臨著沉默支持者的問題。當功能新上時，用戶更多的是去適應，因為他們也不知道功能應該長什么樣，能滿足日常使用，大部分人就可能不會提意見。
但當我們聽從反對者的建議進行優化時，就會存在前后方案的對比，也有了2種方案的選擇，用戶就會根據自己的習慣各有所喜。
我也經常接到用戶反饋：能不能改回原來的？遇到這種問題時，該怎么處理呢？用戶說什么就做什么嗎？肯定是不行的。我們還是要分情況來處理。
二、功能優化應對法
我們從原有功能的新增、修改、刪除來分別看應對方法。
1. 功能新增
功能新增是三種情況里面最簡單的一種了。錦上添花大概率來說不是一件壞事，對于老用戶來說，如果不需要，不用就可以了。但還需考慮下面這一點。
不需要用戶考慮
新增功能如果用戶用不到，還直接顯示在頁面上嗎？如果顯示了，老用戶會不會覺得很累贅，特別是B端產品更加注重效率。哪怕是多了個用不到的字段，用戶都會覺得影響視覺和操作。
我就遇到了因多3個字段引起的強烈反對。
在開處方時，原來是這樣的，醫生填寫藥品名稱、單次劑量等內容。
但有一些藥品是要做皮試和輸液的，一些診所提出，需要在開立藥品時標注是否需要皮試，皮試結果出來后填寫結果，輸液的話填寫滴速。很合理。
于是我就在原基礎上加了3個字段：
我沒有加配置項，我本想不需要的話不填就好了，不影響原功能的使用。
但很多用戶提出他們診所不輸液，這幾個字段用不到，不要顯示出來。后來發現原因，有些診所的電腦分辨率比較低，本來操作欄一頁上能顯示全，多了3個字段后，操作欄需要向左拖動才能看到，造成了極大的不方便。
最簡單的就是懸浮固定操作欄。但在強調不輸液的診所看來，這幾個字段違背了他們的理念，那就要做成配置項了。
這也讓我明白了，功能不是越多越好，用戶要的不是多，他們只想要他們需要的，不需要的最好全都屏蔽掉。功能新增時千萬要注意不用用戶的心理，盡量減少對他們的影響。
2. 功能修改
這是最容易引起吐槽的，也是處理起來考慮面最多的。我們先看會有哪些方面的修改，然后再看常用的解決方法。
改動1：業務流程修改
流程修改的宗旨是：更短，更符合業務場景。
但系統開發時會將模塊微服務化，建議相近內容在不同場景下使用時能夠共用一套，以減少工作量，同時減少系統的復雜度，減少維護成本。
舉個例子來解釋下這2者可能引起的沖突。
零售藥品的操作：選擇藥品，付錢，2步搞定。流程路徑：
但在門診支付時，選擇付費藥品后，需要先確認下待收費信息，如果有會員折扣的，先打折。再進入下一頁使用優惠券，零頭減免等。再進入下一頁選擇支付方式，比如刷醫保，現金，微信支付等，歷經3個頁面才付款完成。
對于門診來說，這個流程是合理的，但對于零售來說，一般沒有優惠，這個流程就太繁瑣了。但都屬于支付，設計時就會共用一套。
如何找到2種場景下的平衡，就是我們需要慎重思考的了。（想看答案請往下）
改動2：交互操作修改
交互的優化往往意味著用戶體驗的優化。但產品經理不是用戶，也不可能去訪談所有用戶，而用戶的體驗感是因人而異的，所以這部分也是可能挖坑最多的地方。
我在用手機銀行的時候就經常會吐槽。本來我的頁面能看到全部余額，信用卡待還金額，為什么要換位置，都找不到在哪里了。
用戶在用我們產品的時候，也有同樣的感受。
比如說我本來在開立處方的上方有個復制處方的按鈕。
但是用戶說，我在側邊欄看到了歷史處方，卻不能直接點擊復制，還非要點擊復制處方的按鈕，去彈窗里找到那條處方去復制，不是很麻煩嗎？
非常有道理，但是如果直接把復制的按鈕換到側邊欄合適嗎？我估計很多用戶就會找不到入口了。即使在進入頁面時做個引導，有些用戶的習慣一時還比較難轉變過來。
這時不妨做個A/B test，下面會詳細的講。
改動3：頁面UI修改
如果頁面的整體布局沒有變化，只是做些間距的調整，按鈕顏色等的改變，用戶感知是比較弱的。但布局的大改，文字改圖標，圖標改變這些就可能引起較大的爭議了。
比較常見的改動：卡片和列表。有的用戶覺得卡片直觀，喜歡卡片。有的用戶覺得卡片信息太少，喜歡列表。很多產品都會做成2者可切換的形式。
針對以上三方面做出的修改，我總結了4點經驗?？偟脑瓌t是：在開發及維護成本不高的情況下，把選擇權交給用戶。盡量少做一刀切。
方法1：靈活自定義
就像上面說的優化改動1中的支付路徑，對于中間頁面，可以做一個配置，零售時不顯示待收費頁，直接選擇支付方式付款。甚至可以把支付方式的選擇做成彈窗，減少跳頁帶來的跳出感。這樣2種場景下都能較好的應用，同時不增加系統的復雜度。
這個方法比較適合業務流程的改動。B端產品中有很多這樣的情況，因為每個用戶的實際場景有差異，導致需求有差異，需要系統更加的靈活，來滿足更多的用戶。我們肯定是照著最完整的路徑做的，如果中間環節不需要，就做個開關屏蔽掉。
比如說很復雜的門診流程，比較正規的是1號路線：掛號->收掛號費->護士預診（量體溫之類）->醫生看診->收費->藥房發藥
但有些診所比較小，也沒有掛號費，像2號路線，掛號完就直接醫生看診了。醫生看診完就到3號路線，先發藥，后收費。
當然這只是舉個例子，實際情況比這個還要復雜，比如夫妻老婆店，雇不起前臺，看病、收費都是一個人做。
需要注意的是，這里面沒有哪一個流程是正確的，當用戶提出他們的建議時，不代表原有的流程不對。我們不能直接改，只能在最全的鏈路上插入便捷點。
方法2：A/B test
就像上面改動2說到的頂部和側邊欄的復制病歷按鈕，就是在做一次測試。
這個方法比較適合交互的小改動。不能有一點不確定就去問用戶吧，用戶到后面就覺得煩了。
B端產品也可以通過埋點的方式來看用戶的喜好。前期先保留2者，后面根據點擊量的數據，來放棄一方，畢竟功能是一樣的，沒有必要重復。而測試階段，也是用戶對新功能的適應階段。在放棄一方前，還能做個引導，讓用戶不會覺得很突然。
方法3：都做，讓用戶選
就像上面改動3說到的卡片和列表的切換，就是在增加選擇項。
增加選擇項比較適合頁面UI的改動。開發和維護2套的成本相對較低。如果是業務流程方面，是不建議的。比如說改動1里面提到的零售和門診的支付做成2套，這個成本就大了，但可以做些適當的簡化。
當我們沒法確定用戶喜歡哪一種時，可以做一次調研，如果結果支持度是1：1，那還是做2套，可以自由切換。
由于一刀切去替換，我踩過一次大坑。
原先的微信H5預約頁面一直被一些用戶吐槽，迫于一位優質用戶的壓力，我們根據他的需求做了一個定制化的優化版本。做完后其他用戶看見了，覺得不錯，就提出要替換原先的。見提出的人還挺多的，而且新版本線上運行了1個多月了，也比較穩定了，我就做了一次全局的替換。
結果當晚就炸了，因為一些用戶的設置比較特殊，導致新版本部分科室無法被預約，只能做緊急回退。后面就給了用戶兩個鏈接，自己選擇用哪一套。
經過這次后，我在做全面替換前，一定會充分調研用戶。
方法4：用戶提前適應
如果改的不是一個點，一個功能，而是整個系統呢？前面說到的三種方法都沒有辦法解決了。我們需要讓用戶提前去操作和適應。
我們對之前的產品做了一個完全的重構。在保留老系統功能的基礎上，對原有功能進行了優化，也增加了很多新功能，當然交互和UI也是變化比較大的。
我們對比之前老用戶提出的無法解決的需求，在新系統里面，大部分都得到了較好的解決。老用戶也很積極的表示想用新系統。但在真的做系統數據遷移時發現，有些用戶開始顧慮了：不知道有哪些細節點可能會引起不能用，不適應。
我們只能提前給賬號試用，讓客服再次培訓，提醒用戶自己多操作，等準備好了再做遷移。不敢想象，如果一下子全部切換過去，會發生多少重大的問題。
3. 功能下架
常說“加功能簡單，去功能難。”雖然加功能都不簡單，有時候做的越多，錯的越多。但減功能是真的難，遇到的也比較少。這也告訴我們，別動不動就加功能。
第1步：數據統計
想要下架功能，首先要看的就是用戶使用量。如果在近一段時間內沒有人在用，且之前用過的人也非常少，那直接刪除就行。
我碰過過這樣一個功能，輔助檢查的外送。一共就2個診所用過，且最后次使用是在2年前。砍的非常的輕松。
但很多時候還是有用戶在使用的，只是量比較少。那要看第二步了。
第2步：給用戶替代方案
如果功能的維護成本很高，但只有十幾個甚至幾個用戶在用，下架前給用戶想好替代方案。
比如說我這個診后滿意度調查的問卷表單功能要下架了，那用戶想發送問卷怎么辦呢？我可以做個更強大的，包含這個的功能，比如完全自定義表單；或者就讓用戶使用問卷星等其他軟件，我們可以支持外鏈。
第3步：做好放棄用戶的準備
如果用戶不接受替代方案，我們又一定要下架，那只能做好放棄用戶的準備了。我們追求的是性價比，不是滿足所有用戶需求，不是追求只升不降的用戶數量。
總結
功能的新增，更多的是考驗產品經理的需求收集、分析、轉化成產品方案的能力。功能的優化，則更多的是考驗產品經理的辨識、權衡、決策的能力。有時候，功能的優化比新增更加的復雜。不僅要考慮反對者的建議，也要兼顧沉默支持者的看法，切勿被聲響大的一方帶偏。
本文只是舉了幾個親身遇到的案例來闡述，工作中還需要具體問題具體分析。當裁定的筆握在你的手里時，你會怎么做呢？
作者：司馬特小隊，丁香園高級產品經理。微信公眾號：司馬特小分隊
本文由 @司馬特小隊 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
感謝分享 舉例有學習到
似曾相識
功能越做越差的原因是因為做功能的不用自己開發的產品，如果你自己也在用自己做的產品就會越做越好
有道理
挺實在的文章~