如果用戶不使用你的“前置功能”,會怎么樣?
如果用戶不使用你的“前置功能”,會產生什么問題呢?本文作者在設計產品的新功能時,想到了幾個關于用戶不使用“前置功能”時會產生的異常情況,并提出了相對應的解決方法,一起來看一下吧。
大家好,今天分享一個最近工作中的小感悟,希望能對你有點幫助。
最近在設計產品的新功能,處于可行性分析和整體流程設計階段。這個方案簡單來說,分為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、用戶遠比我們想象的“脆弱”,他們愛上你的產品也許需要很多因素,但離開你的產品,也許只因為一個功能或細節,而往往我們缺少這方面的思考和覺察。
這幾個問題沒有標準答案,需要我們在日常工作中提升意識,努力探索。
希望,我們很快都能找到一些答案,讓自己的方案更合理,產品更有價值。
專欄作家
不想延期,公眾號:不想延期,人人都是產品經理專欄作家。半路轉行的B端泛金融產品,堅持“以實踐驗證理論,以輸出倒逼成長”的目標。點滴珍貴,重在積累
本文原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!