如果用戶不使用你的“前置功能”，會產生什么問題呢？本文作者在設計產品的新功能時，想到了幾個關于用戶不使用“前置功能”時會產生的異常情況，并提出了相對應的解決方法，一起來看一下吧。

大家好，今天分享一個最近工作中的小感悟，希望能對你有點幫助。

最近在設計產品的新功能，處于可行性分析和整體流程設計階段。這個方案簡單來說，分為A、B兩類用戶，而兩者之間也存在業務關系。

大致流程為A做前半部分，B做后半部分。

我們通過一系列的分析，大致設計出一套可行的業務流程，在我思考下一步執行方案時，突然想到了幾個異常情況。這幾個異常情況歸根結底都是一個原因：用戶不使用你提供的“前置功能”。

• 比如A的操作分為1、2、3、4，四個步驟，B的操作分為5、6、7、8四個步驟，正常按照流程設計從1-8沒有問題，但如果A不愿意配合呢？B應該怎么辦？
• 或者如果A只想從第三步開始做，如果前面兩步的產出數據缺失，第三步如何發起？
• 再比如，從A到B之間，存在一個業務數據的連接，如果這個數據，A沒有按照平臺的要求上送怎么辦？B能區分清楚嗎？

發現這幾個問題之后，很多朋友會順著這個思路尋找解決方案，這沒有問題。只不過，我想表達的是，問題的背后還蘊藏著哪些我們值得發掘的信息？（當然也有很多朋友缺少對于這類異常場景的思考，那就要提升自己的結構化分析能力）。

有人可能會問，現在處于可行性分析階段，有必要考慮這么多異常場景嗎？

我的觀點是，相對細節的異?？梢圆豢紤]，但是這類“阻礙性”的異常一定要思考。因為阻礙性的異常，如果不能妥善解決，容易讓整個方案的可行性畫上問號。

針對上述的幾類問題，我們可以采用數據導入、數據補錄之類的方式來解決，也可以為B提供前期的1、2、3、4功能。但這樣解決之后，業務的連貫性是否還能得到保障？用戶的操作是否會變復雜？B是否有意愿去完成A的缺失操作？這些問題都是我們需要調研和思考的。

順著這幾個問題，我建議再往后思考一步：用戶為什么不愿意使用你的“前置功能”？

我們以A沒有按照平臺要求向B上送數據為例。這個場景正常流程是A向B轉一筆賬，由B協助A進行處理，而且A轉多少錢，B就處理多少錢。

但實際場景中，A轉賬的金額可能會超過實際需要處理的金額。比如轉賬1w，但實際僅需要B處理9k，剩下的1k是A給B支付的服務費。按照平臺的邏輯，A不應該轉賬1w，應該按9k進行操作，另外的1k服務費要線下解決。因為系統無法區分這1w的用途，只能視為全額處理。

但A為什么不分兩次轉賬？

因為A這樣操作習慣了，他平時就是匯總轉賬，由B自己來區分?，F在平臺新功能上線了，需要A按照平臺的規范將一筆分為兩筆，A不樂意。

用戶就是這么脆弱，也許對于我們而言，這個轉變似乎很簡單，只是多操作了一次罷了。但對于用戶而言，這是增加了他的負擔，他不愿意改變，我覺得以前的方法挺好的。你的系統要幫我拆開。

最后的結果是，我們增加了這個金額拆分的功能。功能其實不復雜，只是如果沒有參與用戶調研，這個需求是很難發現的，產品經理不會自然而然的想到這一步。

最后，這個場景背后還涉及到一個問題：系統到底是給用戶提效，還是降效？

我舉的例子只是個例，但這些個例的背后卻反映著現如今數字化轉型過程中的困境：數字化轉型的口號是為了“降本增效”，但實際上我們的產品、我們的功能真的可以為每類用戶提高效率嗎？

我們每個人所負責的業務都不相同，面向的用戶也千差萬別，今天的分享，因為特定場景的原因，我不能說的太具體，采用了比較含糊的舉例。但是我希望有幸讀到這里的同行可以透過含糊的場景，理解我的用意：

1、不要忘記分析關鍵的異常場景。每個功能（尤其是核心功能）都要思考用戶是否會按照我們的設想來操作。如果答案是否定的，那我們應該怎么做？

2、你設計的功能到底能不能真的解決用戶的問題？是否真的讓用戶方便了？如果不能，下一步應該怎么辦？

3、用戶的反饋，是否真的通用化？是否真的可以以功能的形式做到產品上？如果不能，如何解決這部分用戶的實際訴求？

4、用戶遠比我們想象的“脆弱”，他們愛上你的產品也許需要很多因素，但離開你的產品，也許只因為一個功能或細節，而往往我們缺少這方面的思考和覺察。

這幾個問題沒有標準答案，需要我們在日常工作中提升意識，努力探索。

希望，我們很快都能找到一些答案，讓自己的方案更合理，產品更有價值。