[心得]結構化互動流程

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

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

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

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

特徵

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

目標

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

方式

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

• 清晰

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

• 高效

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

• 繼承習慣

我們總是會通過以往的經驗來對事物作出行動，對新事物的認識也是基於先前的認知習慣。就像帶圓角的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)

:)