本文將討論如何通過流程化的交互實現用戶目標，并處理好任務相關角色之間的互動方式。

當我們在制定設計方案的時候，可能會經歷下面這些：

挖掘需求（正在渴望未被滿足的地方）->界定目標（解構需求，定義重度、范圍以及可行性）->設計功能（實現目標的方法）->結構化流程（定義控件，布局，頁面邏輯）->測試可用性->優化視覺

從設計功能到結構化流程這一部分，是交互過程中主要的產出階段，我們該如何讓生硬的功能，轉化為用戶可以實現的操作，并最終落地呢？
思考階段需要清楚的三個內容：

特征

設計最終都是為了人而服務，了解你的目標用戶，這類人群的愛好，年齡，性別，教育背景，使用環境都會在設計過程中作為參考。例如搜索功能，老人與小孩可能會更適合語音搜索，而年輕人偏向于關鍵字，那么更多地優化在搜索聯想上。

目標

用戶想要做什么？用戶的目標不一定是表達出來的，但是表達所傳遞的內容卻會映射出真實的目標。
比如一天室友找你借鑰匙，得到鑰匙可能并不是室友的最真實的目標，它映射的或許是室友希望能夠打開寢室的門，又大概他可能只是想取走落在寢室的某樣東西，而他拿東西可能是為了完成另外一件事情。
這種動機和目標可以追溯到很長，那么我們如何確立一個正確的目標？可以依據如果確立的目標完成后，是否能夠很好的撫平當前迫切的需求，同時需考慮自己當前所處的角色；如果角色是“我”，那么我借出鑰匙就能緩解室友的焦慮，而如果我是一位隔壁室友，幫助他去聯系有鑰匙的人也能緩解焦慮。 因為深入地了解用戶的目標，所以快播的單手模式廣受美譽。

方式

當目標被確立了之后，應該思考的是用戶該通過哪些操作來實現設計的功能，達到目標。
在流程上，清晰，高效，繼承習慣，是個人認為比較重要的三點。

• 清晰

清晰的設計能夠避免元素間的干擾，每一個元素都應該與它在行為中的重要程度匹配，包括視覺上的主次和以及信息呈現的先后順序。讓用戶能夠直觀的找到入口，并執行操作。

• 高效

整個操作過程都是一個過渡態，用戶不是來把玩這些控件的，通過更少的操作，更加快速的完成任務并從操作中脫離出去是盡量去達到的目標。現在的模式中提供了許多了方法。
歸類：將復雜的表單中相近的內容歸類
切割：對過長的流程切割分步驟進行
隱藏：次要信息的隱藏
默認選擇：以及為用戶提供默認的選項，從第三方獲取公開數據等
但是不應該盲目，保持清晰，脫節的高效“一鍵完成”并不適用于所有的場景，如果用戶不能給了解到自己會得到什么樣的結果，留下的困惑會失去對產品本身的信任。

• 繼承習慣

我們總是會通過以往的經驗來對事物作出行動，對新事物的認識也是基于先前的認知習慣。就像帶圓角的Button來源于工業界的實體鍵，紙質表單中的Check Box和Radio Button，在數字界面的表單中同樣得到了繼承，更自然的交互方式擴散性和習得性更好，像是手勢和語音交互，就是繼承了生活中對實體的行為方式。
而離構建產品更近的，是尊重平臺，OS，以及同類產品的交互習慣。像是在PC和Mobile上，橫向滑動瀏覽的模式比較少見，但是在TV上，這種瀏覽模式被廣泛使用。（參考閱讀：Designing for the Apple TV）同樣的Android和iOS在設計語言上也有很多的差異，在對不同平臺設計時，必然要考慮到用戶操作習慣上的差異。例如“menu”和“pop”這兩個控件上的定義和使用方法。最后要說的是同類產品的交互習慣，可能會產生一些爭議，因為這多少會被人詬病為抄襲。當下規模前幾的電商網站，導航框架和信息結構也相似很多，但是要去理解背后的動機和成因，和幾種可能性方案之間的比較差異。拍照應用多會在拍完后選擇濾鏡；視頻網站也會在播放完成后提供相關視頻的入口（說到這，就有很多小廣告在右上角加一個假的關閉icon，用戶點擊后并沒有關閉廣告，而是點進了廣告，這也算是繼承了一種習慣，但是糟糕透了）；同樣是語音搜索的功能，瀏覽器的激活方式是tap，獨立搜索應用多是long press，為什么存在這種差異？分別繼承了哪些習慣？將認知上的習慣延伸向更廣的區域，更自然，更易于理解。比如QQ在發送圖片的時候，可以將圖片上滑發送出去，這一個交互方式就點選圖片更加流暢。

關聯與邊界

在剛開始做項目的早期，我常犯的錯誤就是在做割裂式交互，認為給上原型圖，控件布局，標注下button的來源去向，填充內容的規范，就完事了。
單看這一個也沒毛病，可用戶并不是盯著一個內容轉的。他會在整個應用中來回的跳轉，犯錯，反復操作，成功或失敗。過于單薄的交互如果沒有覆蓋到足夠多的場景，會讓產品顯得乏力，體驗欠佳。
注重行為的整體性，交互行為是連續的操作，信息的接收與反饋。當前用戶與平臺的交換，與其他用戶的交換。從發起動作到完成離開的每一步都構想好，才算是比較完整的交互流程。

舉一個例子：如果在游戲中，A玩家想要組隊，他的流程應該是怎么樣的？
可能他會看看周圍有沒有合適的：

查看附近隊伍->申請加入隊伍

如果附近沒有合適的，可能會不組隊，或選擇自己發起：

發起組隊->邀請玩家

發起組隊->接收其他玩家申請

這是A玩家可能需要執行的動作，但在設計的過程中，你需要考慮更多的場景邊界，和關聯信息的互動。

如果附近隊伍很多，是翻頁還是滾動加載？

如果附近沒有隊伍，該不該引導用戶去創建隊伍？

讓用戶對列表主動刷新？還是按固定時間刷新？

申請成功了該怎么提示？

申請被拒絕了該怎么提示？允不允許再次申請？加不加限制？

怎么提示有人申請加入隊伍？提示呈現的方式是什么樣的？

隊伍成員已滿時該不該自動拒絕？

邀請列表怎么排序？列表中顯示哪些內容？

有人邀請了該如何提示？

有人申請了該如何提示？

有人加入后如何提示？

成員離開后的提示？

與隊伍相關的其他操作會不會出現干擾？

上面這些列舉了很多“提示”相關的問題，給予用戶一個正確及時的反饋是一件重要的事情，是希望在設計的時候能夠關注到這些場景下，是使用toast，dialog，亦或者action sheet等組件類型都有商榷的地方。將場景盡量的豐富，邀請和被邀的關聯角色狀態，才可能構建一個清晰的交互。

場景的邊界，用戶可能會在產品中漫無目的的操作，使用方式可能并不全會按著預想的那樣做，雖然這可能會誕生一些有趣的事情，但還是希望產品能夠明確自身的作用，做什么與該怎么做。

邊界場景是為了讓用戶處在一個可控，并且可知的環境中。就像當我滑動到了文章列表的末端，顯示一條“沒有更多了”可以讓用戶明白繼續滑動是無效的，不會有新的文章加載。如果沒有這條邊界，用戶該怎么去辨別是自己滑動位移過小未加載，還是正在加載更多內容呢？

可能邊界場景不太容易去體驗，但是雙11的時候，有朋友特意去觀察淘寶天貓京東這些電商的崩潰頁和崩潰提示，這也是操作失敗的一個邊界。邊界會將我們彈回到一個可控的地方，比如返回上一頁，或者回到首頁，確保我們仍在一個安全的環境中。

極限是很多邊界場景所處的狀態，比如長按發送語音超時。還有全局場景，失去網絡連接，未獲得權限，操作失敗，程序異常（程序異常不算是一個很好的提示，因為用戶只會覺得你這個產品真糟糕）等等。

拓展閱讀：[UX Patterns of the Future: Anticipatory Design](UX Patterns of the Future: Anticipatory Design)

當你考慮的越多，用戶就會思考的考少。

(碼字到最后自己都暈了，233)

:)