我的 UI 課會花一個上午講解微互動,但 Blog 上遲遲沒有分享相關的資訊。應該說我花了很長一段時間去驗證和釐清自己的想法。課程能有連貫的一路講下去,但 Blog 分享內容片段要怎麼寫頗棘手…

首先,微互動一書中第 3 頁就提到「微互動是一個產品的功能、互動細節」。說穿了,這一點都不是「微」,微互動就是互動! 和主要功能不同點在於「大小」和「範圍」,主要功能通常是複雜的、多使用情境。而微互動偏向簡單、輕薄短小。

互動設計和人機互動交疊的歷史實際上就是微互動的歷史。微互動有個重要的概念是「讓設計師去思考他們能設計到多輕薄的程度,去降低複雜度和簡化原本會很難的功能」。

我認為功能、互動設計、微互動在某些角度上是同個議題,只因時代演進會簡化並注意到更細節的部份。

微互動的架構

觸發 > 規則 > 回饋 >> 迴圈和模式

  • 啟動微互動的「觸發」
  • 決定微互動運作方式的「規則」
  • 解釋規則的「回饋」
  • 影響微互動的後設規則:「迴圈和模式」

從 4 大要素來看,和 RD 關心的部份非常相似:做什麼?怎麼做?之後會怎麼樣?規則是什麼?

書裡提到微互動的目標:把選擇降到最低,提供使用者智慧預設值和非常有限的選項。所以問題又回到「了解使用者的需求」上:

  • 使用者想做什麼?
  • 何時想做?
  • 想做的頻率?

再加上一個「使用者是誰」。這些問題得透過使用者經驗研究,訪談或觀察使用者才會了解。

怎麼融入開發過程?

書裡完全沒提到微互動怎麼融入開發流程。要寫成什麼樣子的文件和工程師溝通?思考微互動的前一個步驟是什麼?後一個階段又是什麼?

網路上爬文,大多爬到各式各樣的例子,比如登入可以用這招、下載進度條可以用那個方法。

現在我要做個會員登入,那個輸入密碼的欄位我可以參考 A 產品的登入方式,密碼輸入錯誤的提示我可以參考 B 平台。然後成功登入的過場可以抄 C 文章裡提到的作法。

非常不建議這樣做,表示根本不知道自己要什麼,看到別人有現成的就模仿,沒有思考為什麼要這樣做,也無法依照本身產品需求進行原創。

微互動這領域很有趣,沒辦法靠很多動態展示學習…看那些例子,透過會動的圖片能知道使用者想做什麼、何時想做、想做的頻率嗎?多看點例子增加的是手上可以打的牌,但為什麼要打這張牌、之後的出牌順序怎麼串完全沒有方向只能靠瞎矇。

微互動既然是由 觸發 > 規則 > 回饋 >> 迴圈和模式 組成,把「需求」列出來,思考使用者會怎麼操作,你會發現它幾乎就是Flow Chart在探討的內容。同時,因為微互動會考慮「什麼資訊對使用者有價值」,所以會同步製作 Content Inventory 內容清單。

到 Wireframe 階段再來思考微互動、思考使用者怎麼操作功能都太遲了。

想想看 Flow Chart 在做什麼?使用者點擊註冊按鈕 > 顯示表單欄位 > 使用者輸入帳號密碼 > 正確:顯示註冊成功;未符條件:顯示重新輸入…

微互動要能套用那些「例子」,得先把操作任務拆解各個步驟出來,使用者點擊「觸發」了什麼、因為觸發所以看到什麼「回饋」。寫完 Flow Chart 後才有辦法思考「能設計到多輕薄的程度,去降低複雜度和簡化原本會很難的功能」。

用 Prototype 來交代微互動

老實說我覺得微互動很難用 Prototype 測試,開發初期想測的成本很高,但後期再測嫌略晚。做使用者測試是為了想要了解下列狀況:

  1. 有效性:系統能否做到它該做的事?
  2. 效率性:系統支援使用者完成工作的效率。
  3. 安全性:保護使用者遠離危險狀況及不預期的情況。
  4. 功能性:系統是否提供了正確的功能類型,以便使用者可以做他們需要做或是想要做的事情。
  5. 易學性:學習此系統的難易程度。
  6. 易記性:使用者在學習一個系統之後,可以多快速及多容易回想起用法。

單純點擊觸發、顯示回饋、加上簡單的過場動畫這種程度沒什麼問題。但若要套入「規則」,比如註冊的帳號欄位,帳號不可使用符號、帳號長度太短、已有此帳號…等等,根據使用者輸入不同會出現不同的回饋。這種狀況不到寫程式的 Prototype 根本沒辦法測試。如果不測規則,那微互動的概念也被廢掉大半個了吧。

comments powered by Disqus