編輯導語：經常會有這樣的情況，當你自信滿滿地把PRD給開發，自以為十分完美了，然而事與愿違，不一會兒就發現有滿滿的漏洞等著補。要走出這個困境，應該注意分支流程窮盡+元素備要+異常情況窮盡，一起來看看吧。

問：把大象放進冰箱需要幾步？把長頸鹿放進冰箱需要幾步？

答：把大象放進冰箱共需要3步，把長頸鹿放進冰箱共需要4步。

把大象放進冰箱，第一步：打開冰箱門；第二步：把大象裝進去；第三步：關好冰箱門。

把長頸鹿放進冰箱，第一步：打開冰箱門；第二步：把大象取出來；第三步：把長頸鹿裝進去；第四步：關好冰箱門。

把這個順序交給人去干，一般沒問題。然而，把這個步驟直接描述給程序，一定出問題。

因為問題并沒有想象的那么簡單：

• 大象不肯進去怎么辦？
• 冰箱太小裝不下怎么辦？
• 好不容易塞進去，冰箱門關不上怎么辦……

于是交付給程序的實際流程圖需要如下：

這就是在產品設計中常常會遇到的問題。

自信滿滿把PRD給到開發同學的時候，剛出去玩一會回頭就發現滿滿的漏洞等著補。

只有手忙腳亂地，開始各種填坑……

這本質是馬克思所說的事物矛盾的普遍性導致的。解決辦法就是辯證看待，對立統一。

落地一點說，主要得兜住三個方面：分支流程窮盡+元素備要+異常情況窮盡。

一、分支流程

當然我們做設計的時候，主要精力肯定是應該集中在主要任務和流程上，分支流程雖說是小概率事件，但是也要有所考慮，不然方案就會不完整。

解決這個問題，根本上是場景的窮盡。

需要注意：現實業務的場景枚舉，與設計方案的枚舉沒有絕對對應性。也就是窮舉場景可能是四個，但是實際上只需要三個方案就能覆蓋。

但是場景枚舉之間和分支方案之間存在MECE的屬性。

案例：

OMS系統與亞馬遜店鋪對接的前提是：亞馬遜店鋪可用、對OMS系統已授權、OMS系統開啟對接。

成功對接后，來自亞馬遜的某些操作，會導致對接異常。此時通過接口返回錯誤提示，可以展示在OMS系統的店鋪上，提醒商戶處理。

那么這里有多少分支場景呢？

場景一：店鋪被亞馬遜封了，接口返回店鋪異常信息。需用戶在亞馬遜處理。

場景二：店鋪被用戶在亞馬遜關閉了。接口返回店鋪異常信息。 需用戶在平臺處理。

場景三：店鋪被用戶在亞馬遜自行注銷了。接口返回店鋪異常信息。需用戶在平臺處理。

場景四：OMS系統授權失敗或者亞馬遜變更了授權信息。接口返回店鋪異常信息。需在OMS系統以正確的信息重新授權。
這個是第一性的，此后才能判斷功能是否覆蓋到上述場景。

針對場景到功能設計，本質是一種映射：

y=f（X）

映射是分層的。

功能，是將業務進行功能層面的映射；

產品，是對若干業務段在產品層面的映射；

數據層面，設計一個數據表，是對實體屬性的描述，E-R圖 (Entity Relationship Diagram，實體-聯系圖)就是實體到數據層面映射的示意圖；

而字段層面，字段與屬性之間也建立映射關系；

數智層面，數字孿生、VR、AR都是對事物的圖像化映射和展示；

云計算層面，云服務是對實體物理技術設備生產力的虛擬化映射。

一些細致末梢的流程可能會采用放棄，或者粗魯的兜底方案。但這不代表放棄。而是每個流程在方案層面都有所交代。

二、元素備要

如何一網打盡才是重要的。大多數是把每個流程都是按前、中、后進行要素的齊備。

1. 設計前

主要檢查點：用戶類型、帳號體系。

未登錄：登錄和未登錄按鈕權限差別，需要登錄后才可操作的功能是否備注。

用戶權限：需要讀取權限嗎？如何描述讀取內容讓用戶讀？不同權限管理。

2. 設計中

1）框架階段

主要檢查點：層級關系、信息區分、擴展性。

2）流程階段

主要檢查點：角色，入口，目的，操作，離開、中斷。

「我是誰？從哪里來？要到哪里去？怎么去？還有誰？」。

要看流程有沒有短路，如果過程中有中斷，中斷后要怎么提示，如果有不同的權限和角色，還得檢查相互之間有沒有相通和關聯的地方，共同的關鍵節點。以及逆向操作。不同角色不同場景的任務流程一定要單獨梳理。

3）內容顯示

主要檢查點：數據顯示、緩存、內容、狀態（特別是為空、初始）、顯示（各種極限情況）?！笧榭?、初始、極限情況」。

4）反饋通知

主要檢查點：通知，提醒，界面反饋，用戶反饋入口。

「操作的任何階段（前、中、后被中斷）都要防止用戶發呆」。

5）文本控件

主要檢查點：表意清晰、使用一致?！附Y合流程檢查要符合操作的前后情景，符合用戶的常規認知和習慣」。

文本內容：

• 文本長度：是否有限制？
• 文案內容：是否完整、通俗易懂、有趣
• 超過負載時如何顯示？
• 核心詞匯是否統一（如各種用戶角色名稱）
• 重要、復雜的操作內容是否有清晰的解釋說明？
• 瀏覽到內容底部的情感化表達

控件：

• 按鈕類型：主按鈕、次按鈕、幽靈按鈕、虛線按鈕是否按需區分使用（一般一個界面或視窗中只有一個主按鈕）
• 按鈕狀態：默認、經過、點擊、置灰、選中、加載中（提交按鈕）；其中不同狀態下按鈕的置灰，是否有說明為什么不可用？以及按鈕激活條件是什么？
• 鏈接：點擊后顏色是否有變化
• 選擇組件：單選、多選、tab選，是否有默認選中項
• 輸入框：輸入及時校驗，有錯誤時定位；有特殊輸入條件限制的輸入框是否有明確說明

表格：

• 基礎表格：內容項過多時，考慮將次要身份鑒別類信息隱藏，鼠標浮動到對應字段后浮窗顯示
• 表格排序：默認排序和切換排序，核心字段的默認寬度
• 表格操作：考慮在當前表格內完成（頁內編輯）；批量操作時對于互斥的選項處理
• 對齊：一般文字左對齊，數字右對齊
• 折疊、展開：主要內容在列內顯示，更多內容點擊展開顯示
• 分頁：表格內容翻頁展示還是無限加載？若分頁每頁顯示多少條內容？

3. 設計后

檢查點：設備、中斷情況、網絡情況、特殊狀態、刷新方式、異常操作?！付囗撁嫱ㄓ脙热莘旁谝豁撘黄鸶愣ā?。

從A狀態到B狀態：

• 觸發源：操作按鈕在當前界面中是否明確？
• 觸發區域：操作按鈕是否易操作易觸達？
• 未釋放狀態：考慮內容過多或展示過快時支持長按停留內容；是否可以取消，例如發送語音消息，此時是否允許用戶取消發送？

三、異常情況

1. 異常流程

退出、撤銷、重置、返回、不通過、過期失效

• 返回：從哪里來是否可以回到那里去
• 保存：復雜任務流是否支持保存或自動保存；意外退出前保存提示
• 復雜狀態之間的變化關系：子流程梳理輔助說明

2. 刷新和加載

• 刷新：自動還是手動刷新？每次刷新加載多少條內容？刷新失敗如何提示？
• 無線刷新：頂部下拉、底部上拉，安卓有刷新按鈕
• 加載：復雜頁面是否有副列表加載？預覽、保存、提交的完成時間若超過3S是否有加載的過渡狀態？新加載內容是否有高亮底紋顯示？

3. 網絡異常

• 沒有網絡（無網）
• 網絡超時（斷網）
• 網絡太慢（弱網）
• 網絡環境變化：從WiFi到數據流量環境時是否需要切換視圖
• 加載失?。菏欠褡詣又匦录虞d？

4. 操作異常

• 連續多次點擊給予反饋、統一設備登錄多個賬號驗證碼、統一IP；連續破壞性操作n項內容時是否需要身份驗證。
• 數據相關：進入頁面后服務器獲取不到數據；搜索無結果狀態；數據加載時間較長時預設默認圖片、狀態、內容框架；
• 錯誤提示頁：404頁面、即將上線、頁面失效、服務下線、系統繁忙，考慮出錯頁面內容情感化表達以減弱用戶的受挫感。

四、PRD自查

1. 按功能插件自查

1）輸入框

需限定輸入的范圍，做輸入校驗。

示例：最多輸入10個數值，輸入不合規則的內容，則在輸入框下方紅色字體提示，比如：“請不要輸人漢字！”。

2）下拉框

下拉的同時是否支持輸入搜索，是否支持多選。

3）導入文檔

表頭校驗、自校驗、與系統校驗、寫入邏輯（全部不予導入或部分導入)、下載結果文檔；

4）已有功能的邏輯規則變更

則要考慮舊數據兼容或初始化。

5）基礎數據刪除

則要考慮基礎數據被調用的地方，刪除和編輯怎么處理。

比如：商品分類中維護的“商品類型”被刪除，那么再編輯和刪除該分類下的歷史數據的時候就可能報錯，所以基礎數據維護時候要校驗調用情況。

6）設置規則

考慮規則去重、規則優先級。一般情況下，沒有優先級的話，規則的去重和命中次序校驗起來比較麻煩。（在<后端產品經理寶典>一書中有專門介紹）。

7）列表的數據的排序

一般按照修改時間的倒敘排列，也可以用數據庫id代替序號。用數據庫id的好處是，方便用戶和技術協作追溯數據。

8）異常機制

每時每刻都要有逆向思維，告訴開發人員什么算異常？異常了怎么標示出來。

比如：表1字段A，匹配表2字段B，將匹配成功的數據寫入表3。就要考慮表1中字段A為空的情況該怎么辦。

9）頁面長期不登錄

則給自動退出。主要考慮到后端系統的保密性。

10）凡是帶操作的

一般都要設置頁面權限。最簡單的方式是所有系統的權限都分三個等級：不能查看、只能查看、可以編輯。

11）功能修訂

比如規則變更，需要考慮舊數據是否要按照新規則進行初始化。

2. 按需求類型自查

1）功能需求

需要窮盡功能覆蓋的使用場景，窮盡本功能相關聯的各個系統模塊，窮盡本功能的用戶角色、權限。

2）性能需求

• 數據量較大時的系統壓力、反應速度；
• 批量上傳、下載要考慮數量上限，考慮是否異步處理；
• 考慮瀏覽器兼容性；
• 考慮調用接口超時的備用策略等。

3）安全需求

敏感詞屏蔽（同步過濾和異步召回）、防刷單機制、數據補推機制、風險預警等。

3. 關鍵詞提醒自查

筆者不完全羅列了幾個關鍵詞，可以作為自查的維度。

1）完整

流程是否存在斷頭路。

2）逆向

功能流程是否可逆，如果逆向操作，是否考慮對應的機制：比如退款、退貨操作。

3）異常

即異常機制。各個步驟都可能出現預期外的情況。

4）歧義

需求文檔的語法、功能文案、名詞是否易懂，是否存在歧義。

5）兼容

是否存在兼容問題：不同業務人員對功能都能接受嗎？各個系統之間兼容嗎？新舊功能的兼容嗎（比如歷史數據要不要初始化）？

6）備用

是否有備用方案，次級選項。比如當正常流程無法傳輸的時候，是否可以用導入的機制救急。業務高峰的系統，是否有降級處理邏輯。

7）窮盡

業務場景和可能原因是否窮舉完畢。

默認：是否給予了默認值。

比如設置規則功能業務未設置怎么辦？

8）脫敏

是否存在敏感信息，是否有脫敏機制。

4. 其他

自查的方式還有很多，比如也可以按照“增、查、改、刪、顯、傳、算”自查等。

#專欄作家#

唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產品經理專欄作家，2019年年度作者?！逗蠖水a品經理寶典》作者，藥學碩士轉行互聯網產品多年；熟悉跨境電商業務，醫藥領域；擅長大型后臺體系，社交APP。

本文原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自pixabay，基于CC0協議。