我的 UI 課會花一個上午講解微互動，但 Blog 上遲遲沒有分享相關的資訊。應該說我花了很長一段時間去驗證和釐清自己的想法。課程能有連貫的一路講下去，但 Blog 分享內容片段要怎麼寫頗棘手…
首先，微互動一書中第 3 頁就提到「微互動是一個產品的功能、互動細節」。說穿了，這一點都不是「微」，微互動就是互動！ 和主要功能不同點在於「大小」和「範圍」，主要功能通常是複雜的、多使用情境。而微互動偏向簡單、輕薄短小。
互動設計和人機互動交疊的歷史實際上就是微互動的歷史。微互動有個重要的概念是「讓設計師去思考他們能設計到多輕薄的程度，去降低複雜度和簡化原本會很難的功能」。
我認為功能、互動設計、微互動在某些角度上是同個議題，只因時代演進會簡化並注意到更細節的部份。
微互動的架構
觸發 > 規則 > 回饋 » 迴圈和模式##
- 啟動微互動的「觸發」
- 決定微互動運作方式的「規則」
- 解釋規則的「回饋」
- 影響微互動的後設規則：「迴圈和模式」
從 4 大要素來看，和 RD 關心的部份非常相似：做什麼？怎麼做？之後會怎麼樣？規則是什麼？
書裡提到微互動的目標：把選擇降到最低，提供使用者智慧預設值和非常有限的選項。所以問題又回到「了解使用者的需求」上：
- 使用者想做什麼？
- 何時想做？
- 想做的頻率？
再加上一個「使用者是誰」。這些問題得透過使用者經驗研究，訪談或觀察使用者才會了解。
怎麼融入開發過程？
書裡完全沒提到微互動怎麼融入開發流程。要寫成什麼樣子的文件和工程師溝通？思考微互動的前一個步驟是什麼？後一個階段又是什麼？
網路上爬文，大多爬到各式各樣的例子，比如登入可以用這招、下載進度條可以用那個方法。
現在我要做個會員登入，那個輸入密碼的欄位我可以參考 A 產品的登入方式，密碼輸入錯誤的提示我可以參考 B 平台。然後成功登入的過場可以抄 C 文章裡提到的作法。
非常不建議這樣做，表示根本不知道自己要什麼，看到別人有現成的就模仿，沒有思考為什麼要這樣做，也無法依照本身產品需求進行原創。
微互動這領域很有趣，沒辦法靠很多動態展示學習…看那些例子，透過會動的圖片能知道使用者想做什麼、何時想做、想做的頻率嗎？多看點例子增加的是手上可以打的牌，但為什麼要打這張牌、之後的出牌順序怎麼串完全沒有方向只能靠瞎矇。
微互動既然是由 觸發 > 規則 > 回饋 » 迴圈和模式 組成，把「需求」列出來，思考使用者會怎麼操作，你會發現它幾乎就是Flow Chart在探討的內容。同時，因為微互動會考慮「什麼資訊對使用者有價值」，所以會同步製作 Content Inventory 內容清單。
到 Wireframe 階段再來思考微互動、思考使用者怎麼操作功能都太遲了。
想想看 Flow Chart 在做什麼？使用者點擊註冊按鈕 > 顯示表單欄位 > 使用者輸入帳號密碼 > 正確：顯示註冊成功；未符條件：顯示重新輸入…
微互動要能套用那些「例子」，得先把操作任務拆解各個步驟出來，使用者點擊「觸發」了什麼、因為觸發所以看到什麼「回饋」。寫完 Flow Chart 後才有辦法思考「能設計到多輕薄的程度，去降低複雜度和簡化原本會很難的功能」。
用 Prototype 來交代微互動
老實說我覺得微互動很難用 Prototype 測試，開發初期想測的成本很高，但後期再測嫌略晚。做使用者測試是為了想要了解下列狀況：
- 有效性：系統能否做到它該做的事？
- 效率性：系統支援使用者完成工作的效率。
- 安全性：保護使用者遠離危險狀況及不預期的情況。
- 功能性：系統是否提供了正確的功能類型，以便使用者可以做他們需要做或是想要做的事情。
- 易學性：學習此系統的難易程度。
- 易記性：使用者在學習一個系統之後，可以多快速及多容易回想起用法。
單純點擊觸發、顯示回饋、加上簡單的過場動畫這種程度沒什麼問題。但若要套入「規則」，比如註冊的帳號欄位，帳號不可使用符號、帳號長度太短、已有此帳號…等等，根據使用者輸入不同會出現不同的回饋。這種狀況不到寫程式的 Prototype 根本沒辦法測試。如果不測規則，那微互動的概念也被廢掉大半個了吧。
