失傳已久的B端原型設(shè)計口訣秘籍，你要嗎？
字?jǐn)?shù):3660 | 估計閱讀:10分鐘
各位產(chǎn)品小伙伴，在方案評審時，有沒有因為方案考慮不周，而被噴過？如果要挑選一個產(chǎn)品經(jīng)理尷尬的時刻，評審會上被技術(shù)和運(yùn)營伙伴噴，肯定要算上一個了。
究其原因，無外乎是產(chǎn)品方案考慮不周，邏輯不順，漏洞百出。尤其是剛?cè)胄械漠a(chǎn)品伙伴，更是如此。做方案時感覺已經(jīng)考慮的很周全了，一到評審會上，就發(fā)現(xiàn)好多地方確實沒考慮到。
回想我當(dāng)初剛開始入行時，也遇到了同樣的問題。后來做的時間久了，慢慢的發(fā)現(xiàn)容易忽略的往往都集中在某幾類問題上。于是我結(jié)合這些年的經(jīng)驗，編寫了一個方案的自檢口訣，方便記憶。
各位可以每次做完方案后，按照此口訣快速自檢走查一下。
此口訣共計14句98個字，具體如下：
增刪查改顯算傳，異常情況考周全，文案簡潔無歧義，類似場景要對齊。交互設(shè)計符預(yù)期，中間狀態(tài)勿忘記。邏輯漏洞細(xì)細(xì)縷，關(guān)系變化高發(fā)區(qū)。賬號權(quán)限上下游，依賴關(guān)系記心頭。各個環(huán)節(jié)求閉環(huán)，兜底方案保齊全，口訣默念記心里，助你評審皆順利！
下面就展開說明一下：
01 增刪查改顯算傳，異常情況考周全
做過技術(shù)的都知道，系統(tǒng)最基本的四個操作就是對數(shù)據(jù)的增刪查改，再加上數(shù)據(jù)如何展示（顯）、數(shù)據(jù)的計算規(guī)則（算）、數(shù)據(jù)的傳輸（傳），基本上就覆蓋了所有對數(shù)據(jù)的操作了。
增：數(shù)據(jù)的新增。比如我們要做一個學(xué)習(xí)系統(tǒng)，那么需要新增的就是課程、班級、人員等維度的數(shù)據(jù)。
刪：數(shù)據(jù)的刪除。需要注意刪除時是否需要確認(rèn)，是邏輯刪除還是物理刪除？
查：數(shù)據(jù)的查詢。查詢時是精準(zhǔn)查詢還是模糊查詢等。
改：數(shù)據(jù)的編輯。需要考慮誰有權(quán)限編輯？什么時候編輯？具體編輯哪些字段等等。
顯：數(shù)據(jù)的顯示。顯示時的樣式如何，如果數(shù)據(jù)量或者文字太多如何處理顯示。
算：數(shù)據(jù)的計算規(guī)則。比如文章的閱讀量的計算規(guī)則是什么樣的。
傳：數(shù)據(jù)的傳輸。比如數(shù)據(jù)是實時同步，還是定時同步。同步時是增量還是全量等等。
可以看出，針對這七個對數(shù)據(jù)的操作，每一個操作都有一些要注意的細(xì)節(jié),我們可以結(jié)合5W2H來進(jìn)行逐步檢查。
5W2H，即who、when、where、why、what、how、how much 。
who:主要是涉及到權(quán)限。誰能進(jìn)行相應(yīng)的操作。
when:主要涉及什么時候能進(jìn)行操作，比如刪除時，有些數(shù)據(jù)有關(guān)聯(lián)時，是不允許進(jìn)行刪除操作的。
where：主要涉及操作的入口在哪里？展示的具體位置在哪了。
why:為什么要有這個功能，可不可以沒有。
what：操作的具體部分是什么，
how:如何進(jìn)行操作，操作流程是什么？
how much:操作步驟有幾步？可不可以減少？
5W2H不一定每一個維度都涉及到，但可以幫助我們考慮的更周全。
我將七個操作和5W2H整理成一張對應(yīng)的二維表，如下：
以上都是我們按照理想情況去考慮的，但實際執(zhí)行時，總會千奇百怪，所以我們要盡可能的把異常case考慮全面。
所謂異常，就是指程序一旦不是按照我們預(yù)期的情況執(zhí)行時，我們應(yīng)該如何處理。最基本的就是比如名稱重復(fù)了，或者進(jìn)行操作或同步數(shù)據(jù)時網(wǎng)絡(luò)中斷了、查找數(shù)據(jù)時找不到對應(yīng)數(shù)據(jù)了等等。
02 文案簡潔無歧義，類似場景要對齊
我們做產(chǎn)品方案時，有時需要寫提示文案語，其目的是能及時的告之用戶目前系統(tǒng)的狀態(tài)。
提示語簡單來說分為三種：一種是引導(dǎo)用戶進(jìn)行某種操作，比如請?zhí)顚懯謾C(jī)號；一種是預(yù)防用戶進(jìn)行某種操作，比如禁止刪除；最后一種是簡單的通知，告之系統(tǒng)目前的狀態(tài)，比如提交成功、刪除成功等。
無論哪種類型，其目的就是要把文案的信息快速準(zhǔn)確的傳遞給用戶，所以此類文案編寫的兩個原則就是簡潔、無歧義。
快速要求簡潔，準(zhǔn)確要求無歧義。
所謂簡潔，就是用一句話能描述清楚的，絕不啰嗦兩句話。比如刪除的提示語：”確定刪除嗎？刪除后將不可見“就不夠簡——”刪除后將不可見“就有點多余。
這里有一個原則，就是長提示語一般不要超過20個字，否則大概率就違背簡潔原則了，可以嘗試縮減到20個字之內(nèi)。
所謂無歧義就是要邏輯通順，確保每個人看到后，理解的都一樣。
這里舉一個反例，就是個人所得稅APP中，當(dāng)你由于換工作需要修改個稅申報方式時，會讓選擇更換扣繳義務(wù)人原因，這時候你會想選擇”變更工作單位“，但細(xì)看其提示文案時，就糾結(jié)了，因為文案里有一句”原單位繼續(xù)扣除“的描述，這就是一句有很大歧義的文案，讓很多人搞不明白。
還有一點，就是在類似的場景中，文案內(nèi)容、文案所采用的句式都要保持一致，這樣可以保持產(chǎn)品的統(tǒng)一性，給用戶以專業(yè)的感覺。常見的反例就是，同樣是提交的場景，有的提示語是“保存成功”，有的叫“提交成功”。
最后一點，就是文案避免出現(xiàn)常識性的錯別字，比如登錄寫成登陸、賬號寫成帳號等
03 交互設(shè)計符預(yù)期，中間狀態(tài)勿忘記
做交互設(shè)計時，當(dāng)你不知道如何設(shè)計時，有一個原則屢試不爽，就是站在用戶的角度，設(shè)想用戶的預(yù)期是什么？
比如用戶查詢報表，當(dāng)點擊查詢按鈕，遇到數(shù)據(jù)量大時，用戶的預(yù)期是希望可以看見加載的狀態(tài)。比如”loading...“，這時候如果你設(shè)計了，就基本符合用戶預(yù)期了，反之如果沒有設(shè)計，就一直在那等著，用戶就感覺不知道發(fā)生了什么情況，是沒數(shù)據(jù)嗎？體驗自然不好。但如果你進(jìn)一步設(shè)計了加載的進(jìn)度百分比，甚者顯示剩余時間，那么就算超用戶預(yù)期了，用戶就會夸你用戶體驗好。
交互過程中的中間狀態(tài)往往容易忽略，比如同步數(shù)據(jù)時，狀態(tài)一般分為未同步、同步中、同步完成。數(shù)據(jù)量少時還好，可以瞬間同步完成。但如果數(shù)據(jù)量大時，就可能要同步幾分鐘，這個時候要切記得把同步中的狀態(tài)設(shè)計出來，比如用一個旋轉(zhuǎn)的圖標(biāo)代表”數(shù)據(jù)同步中。?！?/span>
04 邏輯漏洞細(xì)細(xì)縷，關(guān)系變化高發(fā)區(qū)
邏輯漏洞是原型方案比較常見的問題，最常見的邏輯漏洞大致分為幾種：
1、狀態(tài)重疊或缺失
即狀態(tài)不符合MECE原則（相互獨立，完全窮盡），要么重疊，要么缺失。
2、前后矛盾
即邏輯不通，想要某個結(jié)果，但前提條件不具備。
比如群發(fā)消息時，在沒有選擇人數(shù)和消息條數(shù)時，就要顯示消息總數(shù)。
3、細(xì)節(jié)缺失
即只描述了大致的邏輯，具體細(xì)分場景沒有考慮，導(dǎo)致邏輯漏洞的出現(xiàn)。
比如群發(fā)消息，當(dāng)消息超出當(dāng)天最高數(shù)量限制時，需要延遲到第二天發(fā)送。這里面就有一個細(xì)節(jié)缺失的地方。假設(shè)每人每天消息數(shù)量是3000條。當(dāng)老師余額還剩5條時，這時候老師要給2個學(xué)生（學(xué)生A和學(xué)生B）發(fā)消息，每人3條，共計6條消息。該如何發(fā)送呢？
如果沒有仔細(xì)考慮，就會出現(xiàn)只發(fā)5條，剩余1條不發(fā)。但從消息的完整性考慮，一個學(xué)生只收到2條消息，顯然是不對的。所以就需要補(bǔ)充這一個發(fā)送的細(xì)節(jié)：當(dāng)發(fā)送造成消息不完整時，該學(xué)生的所有消息都不發(fā)送，也就是只給一個學(xué)生發(fā)送3條即可。另外一個學(xué)生的3條延遲到第二天發(fā)送。
4、對象關(guān)系/狀態(tài)發(fā)生變化
當(dāng)對象的關(guān)系或者狀態(tài)發(fā)生變化的時候，往往是漏洞發(fā)生的高發(fā)區(qū)，需要我們格外注意：
狀態(tài)變化引起的邏輯漏洞：
比如設(shè)計題庫時，當(dāng)題目的狀態(tài)由開啟變?yōu)榻脮r，那么就需要考慮已經(jīng)關(guān)聯(lián)了該題的試卷應(yīng)該如何處理，如果沒有相應(yīng)的說說明，就會出現(xiàn)邏輯漏洞。
對象關(guān)系引發(fā)的邏輯漏洞：
比如設(shè)計CRM系統(tǒng)中，當(dāng)客戶的所屬銷售由A變?yōu)锽時，客戶上面一些個人標(biāo)簽是否要清空。無論清不清空，都需要有對應(yīng)的說明。
05 賬號權(quán)限上下游，依賴關(guān)系記心頭
做B端系統(tǒng)的方案，尤其是在大公司，一般都會有成熟的賬號系統(tǒng)（比如EHR、用戶中心等等）和權(quán)限系統(tǒng)等，那我們在設(shè)計系統(tǒng)方案時，像賬號登錄、權(quán)限設(shè)置就沒必要單獨設(shè)計了，可以直接調(diào)用公司現(xiàn)有的系統(tǒng)。所以一定要搞清楚這些依賴系統(tǒng)的內(nèi)在邏輯和調(diào)用方法。
另外還有考慮到自己所設(shè)計的模塊/系統(tǒng)和上下游系統(tǒng)的依賴關(guān)系：自己從上游系統(tǒng)要拿的數(shù)據(jù)是否能夠正常提供，自己吐給下游系統(tǒng)的數(shù)據(jù)是否能正常兼容。
06 各個環(huán)節(jié)求閉環(huán)，備選方案保齊全
記得曾經(jīng)有一句話來描述方案的閉環(huán)，就是你的產(chǎn)品方案就是裝著硫酸的各種管道，管道必須是閉環(huán)的，不能有漏口，否則硫酸就會溢出，造成“傷害”。
所以我們在設(shè)計方案時，要養(yǎng)成閉環(huán)的思維，方案自檢時，要考慮下每一個流程是否都通順，異常流程是否都考慮全了，如果都失敗了，是否有最后的方案來兜底。
這里就體現(xiàn)流程圖的重要性了，務(wù)必要養(yǎng)成做原型方案前，先畫流程圖的習(xí)慣。
用流程圖可以很好的避免流程不通或丟失的情況。畫流程圖這里不再贅述，感興趣的可以看看我之前寫的關(guān)于流程圖的文章——《大話業(yè)務(wù)流程圖(一)——什么是業(yè)務(wù)流程圖》、《大話業(yè)務(wù)流程圖（二）—如何繪制業(yè)務(wù)流程圖？》
最后需要說明一點，就是我們可以有兜底方案，但切記不要為了低頻的場景來設(shè)計邏輯復(fù)雜的兜底方案。相反，如果是低頻場景，哪怕是用戶麻煩點，兜底方案是手動處理也問題不大。
寫在最后
最后說一下，雖然以上口訣目的是為了讓方案盡可能的完美起來，但遺憾的是，沒有方案是完美的，不要指望你的方案可以解決所有問題，只要方案能解決核心問題即可，其余的不完美都是可以暫時接受。
只有接受不完美，才是走向完美的開始！
以上就是我總結(jié)的原型自檢口訣，很多是根據(jù)自己踩過的坑總結(jié)而來，權(quán)當(dāng)是個1.0版本，各位也可以在留言區(qū)說說自己在原型方案中踩過的坑，我們一起將此口訣逐漸補(bǔ)充完善。
最后，如果感覺此口訣對各位有所幫助，感謝點贊、在看和轉(zhuǎn)發(fā)！
-end-
我眼中的教育 避坑指南：聊聊CRM設(shè)計中常見的坑！ 產(chǎn)品中的經(jīng)濟(jì)學(xué) 一文講透B端C端產(chǎn)品的區(qū)別 教你如何合理拒絕業(yè)務(wù)方需求