走出實驗室，了解實測的重要性
使用者測試落實在很多團隊的開發環節中，完成 Mockup 後製作簡易的 Prototype 就開始跑使用者測試，看看使用者對於整體的使用流程、轉場與架構有什麼反應，蒐集足夠的反饋之後再修正功能的方向。
但使用者測試真的準確嗎？
看過 UI Confusion Almost Sunk a US Destroyer 後我對於使用者測試有不一樣的想法。
作者 Justin Baker 從美國驅逐艦在新加坡撞擊貨船的事件切入了解實測的重要性。這次撞擊事件的起因是船員對於介面的不熟悉與困惑，指揮官將維持航線與控制速度的職責分派給其他人，人員調度後其他單位並無收到通知，因而導致整體船艦的運作出現瑕疵，最終與貨船的航道相交導致撞擊事故。
雖然最後導致撞擊的原因是人員調度後的溝通不良，但事情的原點回到了船艦的操作介面上。
雖然我認為文章的標題和實測沒有太大關係，但從撞船事件可以深入了解介面實測的重要性，為什麼介面的功能沒有問題，但最終還是造成意外發生了？
因為介面是給人操作的，而人會創造無限可能（包括最壞的情形）。
如何避免這類事情發生呢？這取決於使用者測試做到什麼樣的程度。
使用者測試與實測
舉例來說，轎車在出廠之前都會通過壓力測試，從輪胎的耐久、車軸的堅固程度等等都會進行詳細的測試。
然而這些車體架構與零件夠強韌就代表車子的安全性夠高嗎？
不同的駕駛，不同的開車方法，搞不好車子以某種角度衝撞，車體就會立刻變形，駕駛的安全堪憂啊…
做使用者測試就好像轎車出廠前的壓力測試，沒有處於現實世界進行測試。
當我們拿 找車子代駕 app 的 Prototype 給使用者把玩時，使用者可以就他使用的情形分享他對於使用流程的看法，然而忽略掉中的部份其實在於 app 的「真實」使用情境，為什麼會強調真實，因為在辦公室裡面、咖啡廳玩玩不就好像車廠的實驗室，缺少使用情境。
姑且不討論找代駕 app 在台灣有沒有市場，找車子代駕的 app 通常會在什麼時候使用？通常都是酒後需要找代駕，那麼是喝酒的人找代駕還是喝酒那個人旁邊的友人會用 app 找代駕？
其實只要跳入情境中，就會發現使用者測試會很不一樣。
當在咖啡廳或辦公室進行使用者測試時，使用者很清醒啊！但喝酒後使用者可能會茫，那麼使用者對介面的需求又會是如何呢？
或許做完使用者測試後的到的結論是，因為使用者很茫會找不到 app，所以決定新增酒前設定自動找代駕，並且修改按鈕顏色，把按鈕放到螢幕一半大之類的（開玩笑）。
使用者測試要真實到什麼程度
剛剛的酒後找代駕只是一種極端的例子（酒後代駕難道要找使用者先喝酒嗎…），那麼使用者測試到底要做到什麼樣的程度才不會與現實差距太大呢？
我認為要先弄清楚產品要解決使用者什麼問題，進而想到在什麼情形下使用者會使用它，在那個情形下使用者的身心狀況。
或許要考量到那麼細節會有點困難，況且極其符合使用情境的測試也是需要相當大的成本，但我認為只要抓住使用情境，讓使用者浸淫在那個使用情境中，就會有很多不同的新發現。
如果成本與時間不允許做太深入的測試，最快的方法就是將產品推出吧！建立完善的使用者回饋機制，讓使用者在實際使用後給你血淋淋的回饋吧。
總結
先前的手機電池過熱會爆炸，就是從實驗室檢測到真實世界實測的差距展現。相信廠商在研發時一定對電池進行很多測試，然而卻沒考量到組裝後實際使用的情形。
很多時候看到 Youtuber 摔手機、拋手機會覺得無聊，但想想，他們只是把現實生活會遇到的極端狀況都實踐了一遍，這也是一種實測啊！當然，放入果汁機的那種不算（笑）。
