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

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

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

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

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

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

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

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

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

這就是在產(chǎn)品設計中常常會遇到的問題。

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

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

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

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

一、分支流程

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

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

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

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

案例：

OMS系統(tǒng)與亞馬遜店鋪對接的前提是：亞馬遜店鋪可用、對OMS系統(tǒng)已授權(quán)、OMS系統(tǒng)開啟對接。

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

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

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

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

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

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

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

y=f（X）

映射是分層的。

功能，是將業(yè)務進行功能層面的映射；

產(chǎn)品，是對若干業(yè)務段在產(chǎn)品層面的映射；

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

而字段層面，字段與屬性之間也建立映射關(guān)系；

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

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

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

二、元素備要

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

1. 設計前

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

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

用戶權(quán)限：需要讀取權(quán)限嗎？如何描述讀取內(nèi)容讓用戶讀？不同權(quán)限管理。

2. 設計中

1）框架階段

主要檢查點：層級關(guān)系、信息區(qū)分、擴展性。

2）流程階段

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

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

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

3）內(nèi)容顯示

主要檢查點：數(shù)據(jù)顯示、緩存、內(nèi)容、狀態(tài)（特別是為空、初始）、顯示（各種極限情況）?！笧榭?、初始、極限情況」。

4）反饋通知

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

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

5）文本控件

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

文本內(nèi)容：

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

控件：

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

表格：

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

3. 設計后

檢查點：設備、中斷情況、網(wǎng)絡情況、特殊狀態(tài)、刷新方式、異常操作?！付囗撁嫱ㄓ脙?nèi)容放在一頁一起搞定」。

從A狀態(tài)到B狀態(tài)：

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

三、異常情況

1. 異常流程

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

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

2. 刷新和加載

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

3. 網(wǎng)絡異常

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

4. 操作異常

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

四、PRD自查

1. 按功能插件自查

1）輸入框

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

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

2）下拉框

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

3）導入文檔

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

4）已有功能的邏輯規(guī)則變更

則要考慮舊數(shù)據(jù)兼容或初始化。

5）基礎數(shù)據(jù)刪除

則要考慮基礎數(shù)據(jù)被調(diào)用的地方，刪除和編輯怎么處理。

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

6）設置規(guī)則

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

7）列表的數(shù)據(jù)的排序

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

8）異常機制

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

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

9）頁面長期不登錄

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

10）凡是帶操作的

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

11）功能修訂

比如規(guī)則變更，需要考慮舊數(shù)據(jù)是否要按照新規(guī)則進行初始化。

2. 按需求類型自查

1）功能需求

需要窮盡功能覆蓋的使用場景，窮盡本功能相關(guān)聯(lián)的各個系統(tǒng)模塊，窮盡本功能的用戶角色、權(quán)限。

2）性能需求

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

3）安全需求

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

3. 關(guān)鍵詞提醒自查

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

1）完整

流程是否存在斷頭路。

2）逆向

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

3）異常

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

4）歧義

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

5）兼容

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

6）備用

是否有備用方案，次級選項。比如當正常流程無法傳輸?shù)臅r候，是否可以用導入的機制救急。業(yè)務高峰的系統(tǒng)，是否有降級處理邏輯。

7）窮盡

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

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

比如設置規(guī)則功能業(yè)務未設置怎么辦？

8）脫敏

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

4. 其他

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

#專欄作家#

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

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來自pixabay，基于CC0協(xié)議。