最近在做一個新產品，其主流程是：用戶來創(chuàng)建一個廣告計劃，過程中，需要設定廣告計劃的基本參數(shù)：價格、預算、投放時段、計劃投放的廣告牌等，然后完成付款。
從上面的描述來看，這個主流程其實很簡單，無非是一個表單，但是在實際的設計過程中，會有一個問題：
廣告牌怎么處理。
在國內做過廣告產品的人應該知道，作為廣告的投放者，需要對投放的廣告內容負責，也就是說，如果在淘寶網上投放廣告，那么廣告內容，需要淘寶負責，一個基本的邏輯就是廣告牌需要淘寶進行審核，在沒有審核通過前，廣告牌是無法進行投放的。
那么好，現(xiàn)在的問題來了，如果一個用戶尚未創(chuàng)建任何的廣告牌，那么允許用戶去創(chuàng)建廣告計劃嗎？
在邏輯的設計過程中，這個爭議是顯而易見的，我這里就不說爭論過程，我說一下我現(xiàn)在的結果是：
如果沒有創(chuàng)建審核通過的廣告牌，那么廣告計劃就不允許創(chuàng)建。
原因有幾個：
如果可以創(chuàng)建，那么廣告牌的審核就跟廣告計劃直接關聯(lián)，那么兩者的時間沖突就可能發(fā)生，比如廣告牌創(chuàng)建后沒有足夠的時間審核，廣告計劃就開始投放了。麻煩
這個系統(tǒng)的分支流程就完全變復雜了，需要引入廣告牌創(chuàng)建過程，一個簡單的主流程，變成了一個大的復雜流程。
沒有給用戶清晰的引導，其實對用戶而言，做一個事情，一個入口足以，而不需要讓用戶在多種口子去完成一個事情，比如：創(chuàng)建廣告牌。我的建議是在市場中提醒用戶，先創(chuàng)建廣告牌。
其實這個case還是比較簡單的，我相信我可以很輕易的說服有不同爭議的人，但是在昨天想到寫這個文章的時候，忽然想起來當年在支付寶，設計支付寶的外部接口產品的時候，也是一個類似的情況，卻將整個系統(tǒng)高的無比復雜，當然，這是我的錯。
詳細說一下，支付寶的外部支付接口，主流程也是很簡單的。
用戶從商戶界面跳轉倒支付寶付款頁面，然后驗證支付寶帳戶、密碼，然后完成付款。
但是在當時的產品設計中，考慮到，如果到了這個頁面，用戶沒有支付寶帳戶怎么辦？于是在主流程之外設計了復雜的分支流程：
用戶允許選擇創(chuàng)建一個新支付寶帳戶，只要輸入一個Email就可以了。但是事情遠沒有這么簡單，如果這個Email是已經存在的支付寶帳戶呢？系統(tǒng)又要跳回來輸入密碼驗證，如果是email是合法的，還需要事后發(fā)送郵件讓用戶補充完整帳戶信息，比如密碼等。這個一個小分支引起的大麻煩啊。
說道這里，我想表達的意思是，如果可以重新設計，那么我會在支付寶付款接口頁面上，將新用戶的問題排除掉。這樣我相信開發(fā)會簡單很多。系統(tǒng)的邏輯也簡單。用戶操作也簡單，不需要太多的選擇。
當然，有人會問，我就是到了這個頁面上，但是沒有支付寶帳戶怎么辦？
是一個問題，我的建議是，這種情況我們不服務，需要有舍棄。在平衡產品的復雜性和用戶操作的“偽用戶體驗好”之間，需要一個優(yōu)秀的舍棄動作。
如果你不是支付寶會員，說明支付寶的市場部，會員營銷部還有很大的空間。
建議負責這個產品接口的產品經理，可以調用一下數(shù)據(jù)，看看現(xiàn)在有多少的用戶通過這個接口使用的時候，選擇的是新建支付寶帳戶的模式。我猜想，我現(xiàn)在的想法應該是正確的。（當年，我錯了）
其實以上文章內容想說的是：
在保持產品主流程簡單的同時，如果遇到復雜的分支流程，是不是可以將分支劃走，不要進入這個功能模塊？而不是因為要考慮用戶體驗，而硬生生的將不同的邏輯綁定到一起。如果真的是這樣，還不如清晰的告訴用戶，你要做什么事情，需要事先完成什么事情。前置條件弄的明白，并且給用戶清晰的入口去完成前置條件。
粵公網安備 44010402000282號