如果用戶不使用你的“前置功能”，會(huì)產(chǎn)生什么問(wèn)題呢？本文作者在設(shè)計(jì)產(chǎn)品的新功能時(shí)，想到了幾個(gè)關(guān)于用戶不使用“前置功能”時(shí)會(huì)產(chǎn)生的異常情況，并提出了相對(duì)應(yīng)的解決方法，一起來(lái)看一下吧。

大家好，今天分享一個(gè)最近工作中的小感悟，希望能對(duì)你有點(diǎn)幫助。

最近在設(shè)計(jì)產(chǎn)品的新功能，處于可行性分析和整體流程設(shè)計(jì)階段。這個(gè)方案簡(jiǎn)單來(lái)說(shuō)，分為A、B兩類用戶，而兩者之間也存在業(yè)務(wù)關(guān)系。

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

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

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

發(fā)現(xiàn)這幾個(gè)問(wèn)題之后，很多朋友會(huì)順著這個(gè)思路尋找解決方案，這沒(méi)有問(wèn)題。只不過(guò)，我想表達(dá)的是，問(wèn)題的背后還蘊(yùn)藏著哪些我們值得發(fā)掘的信息？（當(dāng)然也有很多朋友缺少對(duì)于這類異常場(chǎng)景的思考，那就要提升自己的結(jié)構(gòu)化分析能力）。

有人可能會(huì)問(wèn)，現(xiàn)在處于可行性分析階段，有必要考慮這么多異常場(chǎng)景嗎？

我的觀點(diǎn)是，相對(duì)細(xì)節(jié)的異常可以不考慮，但是這類“阻礙性”的異常一定要思考。因?yàn)樽璧K性的異常，如果不能妥善解決，容易讓整個(gè)方案的可行性畫上問(wèn)號(hào)。

針對(duì)上述的幾類問(wèn)題，我們可以采用數(shù)據(jù)導(dǎo)入、數(shù)據(jù)補(bǔ)錄之類的方式來(lái)解決，也可以為B提供前期的1、2、3、4功能。但這樣解決之后，業(yè)務(wù)的連貫性是否還能得到保障？用戶的操作是否會(huì)變復(fù)雜？B是否有意愿去完成A的缺失操作？這些問(wèn)題都是我們需要調(diào)研和思考的。

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

我們以A沒(méi)有按照平臺(tái)要求向B上送數(shù)據(jù)為例。這個(gè)場(chǎng)景正常流程是A向B轉(zhuǎn)一筆賬，由B協(xié)助A進(jìn)行處理，而且A轉(zhuǎn)多少錢，B就處理多少錢。

但實(shí)際場(chǎng)景中，A轉(zhuǎn)賬的金額可能會(huì)超過(guò)實(shí)際需要處理的金額。比如轉(zhuǎn)賬1w，但實(shí)際僅需要B處理9k，剩下的1k是A給B支付的服務(wù)費(fèi)。按照平臺(tái)的邏輯，A不應(yīng)該轉(zhuǎn)賬1w，應(yīng)該按9k進(jìn)行操作，另外的1k服務(wù)費(fèi)要線下解決。因?yàn)橄到y(tǒng)無(wú)法區(qū)分這1w的用途，只能視為全額處理。

但A為什么不分兩次轉(zhuǎn)賬？

因?yàn)锳這樣操作習(xí)慣了，他平時(shí)就是匯總轉(zhuǎn)賬，由B自己來(lái)區(qū)分。現(xiàn)在平臺(tái)新功能上線了，需要A按照平臺(tái)的規(guī)范將一筆分為兩筆，A不樂(lè)意。

用戶就是這么脆弱，也許對(duì)于我們而言，這個(gè)轉(zhuǎn)變似乎很簡(jiǎn)單，只是多操作了一次罷了。但對(duì)于用戶而言，這是增加了他的負(fù)擔(dān)，他不愿意改變，我覺(jué)得以前的方法挺好的。你的系統(tǒng)要幫我拆開。

最后的結(jié)果是，我們?cè)黾恿诉@個(gè)金額拆分的功能。功能其實(shí)不復(fù)雜，只是如果沒(méi)有參與用戶調(diào)研，這個(gè)需求是很難發(fā)現(xiàn)的，產(chǎn)品經(jīng)理不會(huì)自然而然的想到這一步。

最后，這個(gè)場(chǎng)景背后還涉及到一個(gè)問(wèn)題：系統(tǒng)到底是給用戶提效，還是降效？

我舉的例子只是個(gè)例，但這些個(gè)例的背后卻反映著現(xiàn)如今數(shù)字化轉(zhuǎn)型過(guò)程中的困境：數(shù)字化轉(zhuǎn)型的口號(hào)是為了“降本增效”，但實(shí)際上我們的產(chǎn)品、我們的功能真的可以為每類用戶提高效率嗎？

我們每個(gè)人所負(fù)責(zé)的業(yè)務(wù)都不相同，面向的用戶也千差萬(wàn)別，今天的分享，因?yàn)樘囟▓?chǎng)景的原因，我不能說(shuō)的太具體，采用了比較含糊的舉例。但是我希望有幸讀到這里的同行可以透過(guò)含糊的場(chǎng)景，理解我的用意：

1、不要忘記分析關(guān)鍵的異常場(chǎng)景。每個(gè)功能（尤其是核心功能）都要思考用戶是否會(huì)按照我們的設(shè)想來(lái)操作。如果答案是否定的，那我們應(yīng)該怎么做？

2、你設(shè)計(jì)的功能到底能不能真的解決用戶的問(wèn)題？是否真的讓用戶方便了？如果不能，下一步應(yīng)該怎么辦？

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

4、用戶遠(yuǎn)比我們想象的“脆弱”，他們愛(ài)上你的產(chǎn)品也許需要很多因素，但離開你的產(chǎn)品，也許只因?yàn)橐粋€(gè)功能或細(xì)節(jié)，而往往我們?nèi)鄙龠@方面的思考和覺(jué)察。

這幾個(gè)問(wèn)題沒(méi)有標(biāo)準(zhǔn)答案，需要我們?cè)谌粘９ぷ髦刑嵘庾R(shí)，努力探索。

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