如何考核產(chǎn)品經(jīng)理的基本功如何？不是看他的原型設計得多么漂亮，交互多么炫酷，應該看看其對異常流程的處理能力如何。異常流程處理得非常漂亮，基本功也不會差到哪里去。

果然，異常流程才是檢驗產(chǎn)品經(jīng)理基本功的試金石。趁著年底，我也參與一下這場對產(chǎn)品的試煉，總結一下我目前對異常流程的認知，希望對同樣初級階段的你有幫助。

異常流程往往千奇百怪，這里我盡可能地通過抽離共性進行總結，偏向于產(chǎn)品設計中基礎層級的異常流程。

一、空狀態(tài)

• 初始狀態(tài)。一般為首次進入系統(tǒng)時。
• 無結果。輸入查詢條件后無匹配的結果。
• 內(nèi)容被清除。消息提醒、通知被一鍵清除等場景。
• 網(wǎng)絡問題。無網(wǎng)或超時。
• 無權限。一般沒有權限查看時需要缺省頁面。

二、進行中的操作離開或中斷

例如用戶在表單填寫時未保存或提交就切換其他菜單，此時需要考慮自動保存或保存確認彈窗。

三、上游環(huán)節(jié)/信息的缺失

對于這一類問題我目前遇到兩種具體場景：

一是歷史數(shù)據(jù)的缺失。例如之前我們?yōu)橐粋€能耗監(jiān)管系統(tǒng)（to G）設計了一個根據(jù)上年能耗數(shù)據(jù)給出預測和決策建議的模塊，但是在產(chǎn)研主管那里被PASS了。

原因是政府用戶最初使用系統(tǒng)的一年中，這個模塊都無法使用，因為沒有歷史數(shù)據(jù)可以做計算（當然其實站在我個人的角度，我會覺得如果沒有更好的替代方案，其實這個設計也可以保留，只是在沒有歷史數(shù)據(jù)時需要給用戶一定的缺省提示）。

二是配置環(huán)節(jié)的缺失。例如，在能碳系統(tǒng)里有一個碳核算的功能，碳排放=排放因子*活動數(shù)據(jù)（活動數(shù)據(jù)即能源消耗量），活動數(shù)據(jù)由用戶自行輸入，排放因子是由我們配置的。

同時部分排放因子區(qū)分行業(yè)或地域，盡管我們的數(shù)據(jù)庫覆蓋了我們主流用戶所屬的行業(yè)和地域，但后端提出仍有極小的可能性接入的企業(yè)沒有相匹配的排放因子。這時候我們考慮三種做法：

• 提供默認排放因子
• 進入頁面報錯，告知其原因并提示其聯(lián)系管理員
• 從源頭上限制對這個頁面的查看

此外，這種上下游配置因為某一環(huán)節(jié)的缺失導致的異常流程，可能我們第一想法是在上游配置環(huán)節(jié)就進行限制，不做好配置就無法進入下一環(huán)節(jié)。但在實際工作中我發(fā)現(xiàn)，這種上下游往往不是單一的線性，而是多頁面多任務協(xié)同，所以發(fā)生異常的概率還是很大的。

四、信息輸入中的邊界和限制

想必這條大家應該都不陌生，一般在入門學習prd撰寫的時候幾乎所有的經(jīng)驗貼都會提醒新人注意這條。但由于涉及的類型眾多，在實際工作中可能難免會有漏網(wǎng)之魚。

我指的“信息輸入”泛指一切往系統(tǒng)中輸入信息的過程、組件，不止輸入框組件，還有選擇、導入等。

• 是否必填
• 是否有默認值。如有，值為多少。
• 支持單選或多選。如多選，是否在可選性數(shù)量上有限制，如“最多可選3項”，或支持全部可選。
• 邊界。在這里我主要分為兩類，一是數(shù)值的邊界，包括數(shù)值范圍、字符長度限制等，處理時可以通過限制輸入（如“文本框僅支持輸入>0且<100的整數(shù)”），或者點擊【保存/確定】按鈕時校驗，校驗不通過標紅并提示等；二是按鈕等交互組件的邊界，如新增多少行后【新增】按鈕禁用。
• 數(shù)據(jù)類型。一般在表單中也可以通過限制輸入的方式處理。
• 排重。一般在填寫“XX名稱”時常見，比如“設備名稱在租戶下具有唯一性”。
• 時間。一是可選多遠的時間，對歷史年份/未來年份是否有限制；二是能選多寬的時間，即時間跨度，如“最多跨選7天”。
• 上傳附件。支持的附件類型和大小等。

寫到這里突然覺得把這部分列到異常流程里不太合理，因為本部分是正向流程里的基礎。但由于本部分確實繁瑣，很容易遺漏。

此外，再提醒一點，與其等事后校驗讓用戶“改正錯誤”，不如提前告知用戶填寫規(guī)則，減少錯誤。

五、不影響主線的異常流程

寫下這個小標題，略顯敷衍，讓我覺得些許羞愧。有一類異?？赡苁怯捎诙啻蔚仍蛟斐傻?，積重難返。如果出現(xiàn)了一些不影響主線、優(yōu)先級較低的異常，我們有一個下下策的處理辦法：告知用戶繼續(xù)操作會發(fā)生的異常問題，其他的隨他去吧……

請注意，這已經(jīng)是下下策了。產(chǎn)品設計往往牽一發(fā)而動全身，越往后越明顯，這也提醒我們迭代前應從整體出發(fā)，對本次迭代的全局影響和聯(lián)動進行充分考慮。

囿于個人經(jīng)驗和筆力，本篇只對產(chǎn)品設計中相對共性的異常流程進行了分析。這部分相對基礎，其實只要做到對各類注意事項心中有數(shù)，往往就能避免。

但事實上對異常流程來說最難的恰恰是無法抽離出共性的那部分，一般在業(yè)務層面，這部分可以說是真正的千人千面，在社區(qū)中也看過一些經(jīng)驗貼，終極解決辦法總結起來仿佛只有一條——“窮盡”，窮盡各種業(yè)務場景。

一人之力往往有限，在產(chǎn)品設計中我們需要和開發(fā)、測試多多溝通，尤其是測試，他們的測試用例也是盡可能地覆蓋各種場景，對異常流程的設計很有助益。

最后，對異常流程，送給大家也送給自己一句《盜墓筆記》里的話：前走三，后走四。意為做事之前至少考慮三步，做事之后至少考慮四步。

那么，下一篇再見啦！