你一定遇過這種情況。
看到一扇門，直覺想拉，結果上面寫「推」。
網站上有一排文字，看起來像標題，點下去才發現其實是連結。
填完表單按送出，畫面完全沒變，你開始懷疑到底有沒有成功。
又或者，一個按鈕明明可以按，卻長得像普通文字。
使用者遇到這些情況時，很容易先怪自己：「是不是我不會用？」
Don Norman 在《The Design of Everyday Things》中一直提醒設計者，很多所謂的「使用者錯誤」，其實可以往回追到設計本身。
如果一個介面反覆讓不同的人在同一個地方卡住，就不該只叫大家多看說明書。
第一個問題：使用者看得出「這裡可以做什麼」嗎？
這牽涉到操作可能性（Affordance，常譯為可供性）。
它指的是物件和使用者之間，實際存在什麼可操作的可能。
例如門把可以被握住、按鈕可以被按、文字欄位可以輸入內容。
但對數位產品來說，更容易出問題的是「使用者有沒有看出來」。
畫面上的所有像素其實都可以被點，但只有一小部分真的有作用。
所以光有操作可能性還不夠，還要讓人看得懂該怎麼操作。
操作提示：讓人知道該在哪裡、怎麼做
Don Norman 後來特別強調操作提示（Signifier，也常譯為指意）的重要性。
操作可能性回答的是「能不能做」；操作提示回答的是「我要在哪裡做、怎麼做」。
例如：
按鈕有清楚的形狀、底色與滑過狀態。
輸入框有邊界、欄位名稱或提示文字。
可以展開的區塊有箭頭。
可拖曳區域會出現拖曳把手。
這些都是在告訴使用者：「這裡可以操作。」
當網站為了追求極簡，把所有按鈕做得跟純文字一樣、把連結底線拿掉、把互動狀態全部取消，畫面可能變乾淨，但操作成本也可能一起上升。
好的設計，要讓人一眼看懂下一步
在網站上，最常見的問題之一，就是「主動作不夠像主動作」。
例如一個銷售頁同時放五個按鈕，每個顏色、大小、層級都差不多。
使用者有很多選項，卻看不出哪一個才是主要下一步。
如果免費下載、立即購買、聯絡我們、加入社群、看更多文章全部搶同樣注意力，就等於把決策責任全部丟回給訪客。
好的操作提示不只要讓人看得出可以按，主次關係也要夠清楚。
對應關係：控制方式要和結果連得起來
對應關係（Mapping）指的是控制方式和結果之間，是否符合人的直覺。
最經典的例子是爐子。
四個爐火排成正方形，控制旋鈕卻排成一條直線，而且沒有明確標示，你就必須每次停下來想：「這一個到底控制哪一個爐？」
網站也有相同問題。
例如「編輯」按鈕離它真正會修改的內容很遠。
表單錯誤訊息出現在頁面頂端，但真正出錯的欄位在最下面。
課程章節按鈕順序和學習進度完全不一致。
這些都會增加理解成本。
好的對應關係，會讓控制項和它影響的內容靠近，順序與方向也符合人的預期。
回饋：按下去之後，要讓人知道發生什麼事
回饋（Feedback）是數位產品最基本，也最常被忽略的一件事。
使用者做了動作之後，需要知道系統有沒有收到。
例如：
按下儲存後，畫面顯示「已儲存」。
付款處理中，有清楚的處理狀態。
表單送出成功，出現成功訊息或跳到下一步。
檔案正在上傳，顯示進度。
如果沒有回饋，人就會開始猜。
最常見的後果，是使用者重複點按鈕。
一次沒反應，再按一次、再按一次。
如果這是付款或建立訂單，沒有設計好甚至可能造成重複動作。
回饋要剛好足夠，讓人看得懂目前狀態
每個小動作都跳出視窗，也會讓人煩躁。
所以回饋的重點，是把系統目前的狀態說清楚，不需要一直打擾使用者。
小動作可以用很輕的視覺變化。
重要操作才需要更明確的成功、失敗或確認訊息。
長時間處理則應該顯示進度，讓人知道系統還在工作。
使用者需要的是能判斷目前狀態，而不是被通知轟炸。
限制：先讓錯誤不容易發生
限制（Constraint）的作用，是減少使用者走錯路的機會。
例如日期欄位如果只接受日期，與其讓使用者自由輸入任何文字，再等送出後告訴他格式錯誤，不如一開始就提供日期選擇器。
如果某個選項目前不能用，可以暫時停用並清楚說明原因。
如果按下一個危險操作可能刪除大量資料，可以增加確認、撤銷或其他保護。
這種設計比「等使用者犯錯再責怪他」有效得多。
網站表單最常犯的錯，是把防錯全部丟到送出之後
很多表單會讓使用者一路填完，按送出後才突然出現一大串紅字。
更糟的是，錯誤訊息只寫「資料有誤」。
這時使用者還要自己找是哪一欄錯了。
比較好的做法，是在欄位附近直接提示，並告訴他怎麼改。
例如：
「Email 格式不正確，請確認是否包含 @。」
「密碼至少需要 8 個字元。」
「這個日期已經額滿，請選擇其他時段。」
清楚的錯誤訊息不是只有指出問題，也要給下一步。
概念模型：使用者會自己理解「這東西怎麼運作」
概念模型（Conceptual Model）是使用者對系統運作方式的理解。
就算你從來沒有解釋，人仍然會自己推測。
例如看見購物車，就會假設商品先加進去，之後一起結帳。
看見垃圾桶，就會猜這是刪除。
看見步驟 1、2、3，就會認為應該依順序完成。
如果系統行為一直違反這些預期，人就會開始迷路。
設計者腦中有一套完整邏輯，但使用者只能從畫面、文字、按鈕與回饋去推測。
因此更重要的是：介面傳達出來的「系統形象」，能不能幫助使用者理解它實際怎麼運作。
執行鴻溝：我知道要做什麼，卻不知道怎麼做
執行鴻溝（Gulf of Execution）發生在使用者有目標，卻不知道如何把目標轉成操作。
例如：
我想修改付款方式，但不知道入口在哪。
我想下載發票，但找不到按鈕。
我想取消訂閱，卻不知道要進帳號、訂單還是付款設定。
這種問題通常需要更清楚的操作提示、較好的資訊架構、自然的對應關係，以及符合使用者預期的名稱。
介面如果讓人一直問「我要去哪裡做？」，執行鴻溝就太大。
評估鴻溝：我做了，卻不知道有沒有成功
評估鴻溝（Gulf of Evaluation）則出現在操作之後。
使用者需要看見系統目前狀態，並理解結果是不是自己想要的。
例如：
我按了送出，資料到底有沒有存？
我取消訂閱了，下個月還會不會扣款？
我上傳檔案了，現在是在處理中還是失敗？
我改了密碼，需要重新登入嗎？
這些問題都指向同一件事：系統有沒有把目前狀態說清楚。
Nielsen Norman Group 對這兩個鴻溝的整理也很清楚：一邊是讓人知道怎麼採取行動，另一邊是讓人理解行動之後系統變成什麼狀態。
七個行動階段：使用者一直在想、做、看、判斷
Norman 把互動拆成七個行動階段（Seven Stages of Action）。
大致可以理解成：
先有目標。
形成計畫。
決定要做哪個動作。
實際執行。
看見結果。
理解結果。
判斷結果是否符合原本目標。
這個模型很有用，因為它會逼你去找「使用者到底卡在哪一小步」。
有時功能明明存在，只是入口看不懂。
有時候入口很清楚，但按完之後沒有回饋。
把互動拆開看，比一句「這個頁面不好用」更容易找到真正問題。
不要先怪使用者，先分清楚是失誤還是理解錯誤
Norman 會區分失誤（Slip）和理解錯誤（Mistake）。
失誤是「我知道自己要做什麼，但手上做錯了」。
例如想按編輯，卻誤按到旁邊的刪除。
理解錯誤則是「我一開始就理解錯了，所以照著錯誤方向做」。
例如以為某個圖示代表下載，實際上卻是分享。
兩種問題需要的設計解法不同。
失誤常可以靠按鈕間距、限制、撤銷、確認來降低。
理解錯誤則更需要改善命名、概念模型、說明與資訊架構。
「使用者一直做錯」通常是一個設計訊號
如果只有一個人偶爾按錯，可能真的是偶發。
但如果客服每天都在回答同一題，很多新使用者都卡在同一步，那就值得把它當成設計證據。
這時最沒有用的一句話，就是：
「這很簡單啊。」
因為設計團隊已經看過這個介面幾百次，當然覺得簡單。
第一次使用的人沒有你的背景知識。
好的設計要服務使用者目前已經知道的東西，不是要求他先學會設計者的腦內邏輯。
應用到網站：先看「使用者能不能自己走到下一步」
把這套方法放到網站，可以從五個問題開始。
第一，訪客一進來，知道這個頁面是做什麼的嗎？
第二，他知道現在有哪些可以操作的地方嗎？
第三，主要 CTA 看起來像主要 CTA 嗎？
第四，按下去之後，有沒有立即而清楚的回饋？
第五，做錯時能不能復原，還是只能重新開始？
如果這五題有兩三題答不出來，問題通常已經不只是美感。
它直接影響可用性、信任與轉換。
應用到銷售頁：不要讓「漂亮」蓋過可理解性
有些銷售頁設計得很有質感，但互動線索太弱。
例如所有按鈕都和背景融在一起。
價格方案看起來像三張裝飾卡片，不知道能不能點。
FAQ 的展開箭頭太小。
手機版 CTA 固定在底部，卻蓋住重要內容。
這些都會增加執行鴻溝。
如果網站正在做轉換優化，可以延伸閱讀 轉換率優化不是改按鈕顏色：一套完整的轉換流程診斷方法。
應用到課程平台：學員最怕「不知道下一步在哪」
課程平台常見的問題，是功能一多，新學員反而不知道該先去哪裡。
首頁同時有課程、社群、作業、直播、通知、下載、帳號、排行榜。
對熟悉系統的人來說很完整，對新學員來說卻可能一進去就迷路。
這時可以用 Norman 的框架檢查：
下一堂課有沒有清楚 Signifier？
完成單元後有沒有 Feedback？
尚未開放的內容有沒有 Constraint？
學習進度和導覽順序的 Mapping 是否一致？
學員腦中的 Conceptual Model，是「依序學習」，還是「自己到處找內容」？
這些設計會直接影響學習是否順暢。
好的設計不一定讓人驚艷，但會讓人很少需要停下來想
這也是《The Design of Everyday Things》很耐看的地方。
很多設計問題和美不美無關，麻煩的是使用者得花太多腦力理解。
門把要不要拉。
按鈕能不能按。
表單有沒有送出。
目前在哪一步。
出了錯要怎麼回去。
當這些事情都很清楚，使用者不一定會稱讚設計。
他只是順順地把事情做完。
這反而常是好設計最好的證明。
可以用這七題檢查任何網站或數位產品
一、使用者看得出哪些地方可以操作嗎？
二、互動元素有清楚的指示符號嗎？
三、控制方式和結果之間的對應自然嗎？
四、每個重要動作完成後都有清楚回饋嗎？
五、系統有沒有用限制降低常見錯誤？
六、使用者腦中的概念模型，和系統實際運作方式一致嗎？
七、使用者知道怎麼開始，也知道做完之後發生了什麼嗎？
如果這七題大多能答「是」，通常可用性已經有不錯的基礎。
當很多人都看不懂，應該先改設計，不是一直補教學
教學、說明文件與客服都有價值。
但如果每個新使用者都需要同一份教學才能完成最基本操作，這通常代表產品本身還有改善空間。
先看 Signifier 是否夠清楚。
再看 Mapping 是否符合預期。
確認 Feedback 能不能讓人理解目前狀態。
檢查 Constraint 是否能避免錯誤。
最後再回到 Conceptual Model，看介面傳達出的運作方式是否和設計者想像的一樣。
當使用者少一點猜、少一點怕做錯、少一點需要問客服，設計自然就會變得更好用。
常見問題
操作可能性和操作提示有什麼不同？
可供性是「某個動作實際可不可以做」，指示符號則是讓使用者知道「這裡可以做、應該怎麼做」的線索。在數位介面裡，指示符號通常更直接影響使用者能不能找到操作入口。
按鈕一定要做成立體的才算好設計嗎？
不一定。立體感不是必要條件，互動性清楚更重要。顏色、形狀、位置、文字、滑過狀態與一致性，都可以形成有效的操作提示。
回饋是不是每個操作都要跳通知？
不用。回饋要符合操作重要程度。小動作可以用輕微視覺變化，重要操作才需要明確成功、失敗或確認訊息；長時間任務則應提供進度。
使用者一直按錯，是不是代表他不熟產品？
可能，但如果不同使用者反覆在同一位置犯同樣錯誤，就應該把它視為設計訊號。這時要檢查按鈕距離、命名、指示符號、限制與概念模型，而不是只要求使用者記住正確做法。
《The Design of Everyday Things》只適合實體產品嗎？
不是。書中的可供性、指示符號、對應關係、回饋、限制、概念模型與兩個鴻溝，都能直接應用到網站、App、課程平台與其他數位產品。
參考資料
Don Norman. The Design of Everyday Things: Revised and Expanded Edition.
Don Norman. “The Design of Everyday Things, Revised and Expanded Edition.” JND.org.
Don Norman. “Affordances and Design.” JND.org.
Don Norman. “Signifiers, Not Affordances.” JND.org.
Nielsen Norman Group. “The Two UX Gulfs: Evaluation and Execution.”
Nielsen Norman Group. “Preventing User Errors: Avoiding Conscious Mistakes.”