不要過分地信任產品經理，所有需求都要自己了解過后，才開始設計。

筆者在春節期間在被七大姑八大姨問的比較多的一個問題有：

你現在是做什么工作的??？

看著眼前的火鍋實在不知道怎么解釋，就問了他們一個問題“你覺得我們在春節期間怎么能吃上火鍋？”

他們的回答大概可以歸類為：

買材料 —— 火鍋底料燒開 ——-放吃的 —— 完成

而我的回答是：

“如果今天的客人不敢吃辣，而你準備的是辣鍋呢？”

“如果你買的火鍋料大家不是大家想要吃的呢？”

“如果客人太多，而鍋太小呢？”

我目前的工作就是這個，讓客人在各種狀況下都能享受到這頓火鍋。當然我不知道他們是不是理解，會不會以為我是海底撈的服務員。扯遠了，回歸正題。

正是這樣的對話，讓我回想起以前剛做交互設計師（產品經理）的時候，經常遺漏各種分支業務流程和異常狀態。

為什么容易遺漏

1、沒有自發的去了解需求

剛入行的交互設計師一接到需求，就按照需求畫了原型圖，因為原型是按照產品提的需求來的；然而，你對于需求為什么要這樣并不了解，一旦錯誤地理解了需求，產品上線有可能對產品來說是災難性的。

所以，不要過分地信任產品經理，所有需求都要自己了解過后，才開始設計。

解決方法：

（1）可以參考我之前寫過的《產品需求：你真的了解你所看到的需求嗎？》

（2）之前和其他交互設計師討論過一個方法：5W法則

這里的5W并不像大家常說的what、who、when等，而是連續向你的需求問5個Why。

舉個例子：

我現實中接到過這樣的需求：

需求：我需要在首頁新加一個搜索欄！

看起來需求是很明確的，但是真的是這樣嗎？我們來試一下：

第一個Why：為什么要加搜索？

答：方便用戶對想要的進行搜索。

第二個Why：為什么用戶需要進行搜索？

答：用戶可以更高效。

第三個Why：為什么用戶覺得這樣更高效？

答：因為在導航很難找到。

第四個Why：為什么導航難找到？

答：導航歸類做的不好。

那么到目前只用到了第4個Why，其實需求的真面目就已經有一定程度的揭曉了，用戶的困擾并不在搜索，而是在商品的分類上并沒有做好，即使做了導航，也只是治標不治本。所以需求應該是對產品的導航進行重新更人性化的歸類。

所以，不要太相信需求方，要自己去了解需求。

2、沒有自發地了解業務

了解業務很重要！

了解業務很重要！

了解業務很重要！

重要的事情說三遍，在交互方案（原型）設計完成之后，總能聽見產品或者開發抱怨，又漏了考慮某個場景或者業務根本走不通的情況，然后默默地開始各種填坑。

那么為什么，不在一開始就把業務了解清楚，花費一部分精力去整理業務規則下所包含的所有場景和窮舉一些極端情況下的業務場景？

所以，一定要和相關人員了解清楚整個業務流程才開始設計。

解決方法：

避免這種情況最好的方法就是：繪制業務流程圖。

舉個例子：

業務流程圖的作用是表達清楚業務需求在產品線的各個階段中在各個功能模塊之間的輪轉。

業務流程圖的繪制思路一般是：

• 首先將業務按階段劃分，比如電商類可以分為下單和支付，單車類可以分為提車、騎行和停車；
• 然后列出每個階段參與的功能模塊，比如下單階段，就有商品查看、登錄/注冊、信息記錄、個人中心等功能。
• 最后按照時間順序，畫出業務需求在各個功能模塊之間的流轉情況。

為了輸出一份完整的業務流程圖，一般有兩個原則：

• 先思考主干流程，再思考分支流程，主干流程邏輯準確，分支流程全面無遺漏；
• 表達清楚后臺產生的各種判斷及相應的前端展示,這將作為接口設計的重要根據。

比如我們以某個餐廳的點菜系統為例：

（1）先將業務進行劃分：

（2）寫出功能各個部分的功能模塊：

（3）按照時間順序，將業務模塊之間進行鏈接：

以上是一個簡單的業務邏輯圖，但是實際情況可能遠遠比這個例子要復雜等多，因此更需要業務邏輯圖來幫助理解業務。

3、沒有自發的去和相關人員溝通

對于新入行的交互設計師來說，他們總是和愛惜自己的設計成果，總想在確認交互方案的時候一鳴驚人（我一開始也是這樣的），然而往往現實是：

? “這樣設計是為什么，我好像不是這個意思”；

“這個開發起來太麻煩了，換一種方式”；

“Tab很容易實現，用Tab吧，效果好?！?/p>

不要閉門造車，在你涉及到一些交互的時候，可以先和產品、開發、策劃溝通一下，方案好不好實現，有沒有替代方案，有沒有他們認為的更好的展示方式。

所以，要學會多多和其他崗位的人員溝通。

解決方法：

這個方便就是溝通上的問題了，其實只要注意有一些模棱兩可的地方的時候，就去多詢問一下相關人員就不會有啥問題了。

技巧就是：不要擔心自己變成話癆。

交互自查表

這部分是整理了在交互方案設計結束后，檢查自己是否有遺漏的清單，用于幫助查缺補漏，但是實際每個設計師都有自己的歸類習慣，希望這個腦圖能夠給你帶來一些思路，找到最適合自己的歸類方法。

這里只是整理了一個大致的業務邏輯思路，如果往里深究還有好幾層的業務，比如在內容自查的基本狀態中“內容是否完整，如果標題，按鈕的文字狀態等”，那么往下深究的話，標題的限制是幾個字，超過該如何處理？滾動播放？還是用省略號？又或者直接在后臺輸入時進行限制？

這就是交互設計師該去考慮和深究的細節。

當然，還有一些更高層面的業務需要注意：

第二部分可能涉及到知識面要更廣一些，需要交互設計師，平時能夠去積累和了解，能夠在用戶發現問題之前就已經將這些業務都考慮到交互方案中去。

希望對新人有所幫助。

以上。

本文由 @endlishted 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議