產品主流程設計中容易出現的乙個爭議

最近在做乙個新產品，其主流程是：使用者來建立乙個廣告計畫，過程中，需要設定廣告計畫的基本引數：**、預算、投放時段、計畫投放的廣告牌等，然後完成付款。

從上面的描述來看，這個主流程其實很簡單，無非是乙個表單，但是在實際的設計過程中，會有乙個問題：

廣告牌怎麼處理。

在國內做過廣告產品的人應該知道，作為廣告的投放者，需要對投放的廣告內容負責，也就是說，如果在**網上投放廣告，那麼廣告內容，需要**負責，乙個基本的邏輯就是廣告牌需要**進行審核，在沒有審核通過前，廣告牌是無法進行投放的。

那麼好，現在的問題來了，如果乙個使用者尚未建立任何的廣告牌，那麼允許使用者去建立廣告計畫嗎？

在邏輯的設計過程中，這個爭議是顯而易見的，我這裡就不說爭論過程，我說一下我現在的結果是：

如果沒有建立審核通過的廣告牌，那麼廣告計畫就不允許建立。

原因有幾個：

如果可以建立，那麼廣告牌的審核就跟廣告計畫直接關聯，那麼兩者的時間衝突就可能發生，比如廣告牌建立後沒有足夠的時間審核，廣告計畫就開始投放了。麻煩

這個系統的分支流程就完全變複雜了，需要引入廣告牌建立過程，乙個簡單的主流程，變成了乙個大的複雜流程。

其實這個case還是比較簡單的，我相信我可以很輕易的說服有不同爭議的人，但是在昨天想到寫這個文章的時候，忽然想起來當年在支付寶，設計支付寶的外部介面產品的時候，也是乙個類似的情況，卻將整個系統高的無比複雜，當然，這是我的錯。

詳細說一下，支付寶的外部支付介面，主流程也是很簡單的。

使用者從商戶介面跳轉倒支付寶付款頁面，然後驗證支付寶帳戶、密碼，然後完成付款。

但是在當時的產品設計中，考慮到，如果到了這個頁面，使用者沒有支付寶帳戶怎麼辦？於是在主流程之外設計了複雜的分支流程：

使用者允許選擇建立乙個新支付寶帳戶，只要輸入乙個email就可以了。但是事情遠沒有這麼簡單，如果這個email是已經存在的支付寶帳戶呢？系統又要跳回來輸入密碼驗證，如果是email是合法的，還需要事後傳送郵件讓使用者補充完整帳戶資訊，比如密碼等。這個乙個小分支引起的**煩啊。

說道這裡，我想表達的意思是，如果可以重新設計，那麼我會在支付寶付款介面頁面上，將新使用者的問題排除掉。這樣我相信開發會簡單很多。系統的邏輯也簡單。使用者操作也簡單，不需要太多的選擇。

當然，有人會問，我就是到了這個頁面上，但是沒有支付寶帳戶怎麼辦？

是乙個問題，我的建議是，這種情況我們不服務，需要有捨棄。在平衡產品的複雜性和使用者操作的「偽使用者體驗好」之間，需要乙個優秀的捨棄動作。

如果你不是支付寶會員，說明支付寶的市場部，會員營銷部還有很大的空間。

建議負責這個產品介面的產品經理，可以呼叫一下資料，看看現在有多少的使用者通過這個介面使用的時候，選擇的是新建支付寶帳戶的模式。我猜想，我現在的想法應該是正確的。（當年，我錯了）

在保持產品主流程簡單的同時，如果遇到複雜的分支流程，是不是可以將分支劃走，不要進入這個功能模組？而不是因為要考慮使用者體驗，而硬生生的將不同的邏輯繫結到一起。如果真的是這樣，還不如清晰的告訴使用者，你要做什麼事情，需要事先完成什麼事情。前置條件弄的明白，並且給使用者清晰的入口去完成前置條件。