很多 App 的問題不是「不能用」。
功能都有。
按鈕也能按。
資料可以存。
流程最後也走得完。
但使用者就是覺得哪裡不順。
可能是第一次打開不知道要做什麼。
可能是每次操作都要停一下想：「這個按鈕到底會發生什麼？」
可能是畫面很漂亮，卻找不到最重要的功能。
也可能是功能本身沒問題，但點下去要等、狀態不清楚，讓人不敢繼續。
這種「能用卻不好用」的產品，最容易犯的錯，就是直接重做 UI。
第一步：先問使用者到底想完成什麼工作
改善 App 之前，第一個問題不該是「哪個畫面不好看」。
而是：
使用者在什麼情境下打開這個 App？
他想完成什麼？
什麼結果會讓他覺得「這次使用有價值」？
這就是待辦工作理論（Jobs to Be Done）的核心。
例如一個記帳 App，使用者最想完成的可能不是「輸入一筆交易」。
他可能想知道這個月還能不能花。
如果產品把大量力氣放在漂亮的分類圖示，卻讓「快速知道本月剩多少預算」變得很難，功能再完整也會覺得不順。
把使用者工作寫成一句話
可以用這個格式：
「當＿＿發生時，我想要＿＿，這樣我就能＿＿。」
例如：
「當我準備出門前，我想快速知道今天有哪些待辦，這樣我可以安排時間。」
這句話最好不要出現產品名稱。
因為你要描述的是使用者的進展，不是你的功能。
一旦工作定義清楚，後面的介面、文字、速度與功能優先順序才有方向。
先分清楚：是第一次使用就卡住，還是每天用都很累？
這兩種問題看起來都叫「不好用」，改善方式卻不一樣。
如果大量使用者第一次進來就離開，問題通常靠近初次使用：他看不懂產品能幫什麼、第一步太多、權限要求太早，或還沒感受到價值就先被要求註冊與設定。
如果使用者已經留下來，卻每天都覺得麻煩，問題更可能在日常核心流程：步驟太長、常用功能藏太深、狀態不清楚，或每次都要重複輸入同樣資料。
前者要縮短「第一次感受到價值」的距離；後者要降低高頻任務的摩擦。不要把兩種問題混在一起，否則很容易用新手教學去修一個其實是日常流程太累的問題。
第二步：找出讓人停下來想的地方
Jakob Nielsen 的可用性原則很適合拿來做第一輪檢查。
不要只問「喜不喜歡」，要看：
系統狀態清不清楚？
用詞是不是符合使用者熟悉的語言？
使用者有沒有控制權？
介面是否一致？
錯誤能不能預防？
重要資訊是否容易辨認？
有沒有不必要的記憶負擔？
發生錯誤時，訊息有沒有告訴他怎麼修？
這些問題比「按鈕要不要換顏色」更值得先處理。
嚴重度要看「影響多大 × 出現多常」
有些問題看起來很醜，但只出現在很少人使用的設定頁。
有些問題外觀看起來不嚴重，卻每天讓大量使用者卡住。
優先順序應該放在後者。
例如：
註冊流程有一個欄位大家看不懂。
儲存後沒有任何回饋。
主要功能入口藏在第二層選單。
刪除按鈕和編輯按鈕貼太近。
這些都可能比整體配色更值得先修。
改善優先順序要有證據，不要只靠內部覺得
產品團隊每天都在看自己的 App，很容易把熟悉當成「大家都懂」。
所以排改善順序時，最好同時看幾種證據：客服工單、使用者訪談、螢幕錄影、漏斗掉點、錯誤紀錄，以及實際使用頻率。
如果一個問題在客服反覆出現、又剛好發生在核心流程，優先級就應該很高。
相反地，一個只有團隊自己在意、使用者幾乎碰不到的視覺細節，就算改起來很容易，也不該先搶走時間。
改善順序應該先看「哪個最影響使用者完成工作」，不要只挑最好改的項目。
第三步：如果大家一直做錯，先看是不是設計誤導
《The Design of Everyday Things》提醒設計者，很多「使用者錯誤」其實可以往回追到介面。
如果很多人都在同一個地方按錯，就不要只叫大家看教學。
要檢查：
按鈕看起來像不像可以按？
控制項和它影響的內容是否靠近？
危險操作能不能撤銷？
不合法的選項能不能直接限制？
操作之後有沒有清楚回饋？
如果你想深入看這套方法，可以延伸閱讀 The Design of Everyday Things：為什麼不是使用者笨，而是設計讓人看不懂。
錯誤訊息不要只寫「發生錯誤」
好的錯誤訊息至少要回答兩件事：
發生什麼？
接下來怎麼做？
例如：
「付款失敗，請確認信用卡資料或改用其他付款方式。」
就比「Error 403」更有用。
能預防的錯誤，最好在發生前就處理。
例如日期欄位用日期選擇器，而不是讓使用者自由輸入任意格式。
第四步：視覺改善要先處理層級，不是先換風格
App 看起來業餘，常常不是因為缺少特效。
更常見的是視覺層級亂掉。
所有文字差不多大。
每個按鈕都一樣顯眼。
區塊間距忽大忽小。
表單寬度沒有規則。
顏色太多，每個地方都在搶注意力。
比較好的改善順序，是先用大小、粗細、間距、對齊和留白建立層級，再決定顏色。
Apple 在新版 Human Interface Guidelines 也再次強調簡潔、熟悉、一致、清楚層級與可預期互動。
每一個畫面最好只有一個最重要的動作
如果一個畫面有五個同樣顯眼的按鈕，使用者就要自己判斷哪個最重要。
可以先問：
這個畫面最希望使用者完成什麼？
那個動作應該有最清楚的視覺層級。
其他次要動作可以保留，但不要和主要動作搶注意力。
第五步：微互動要讓使用者知道系統有收到
按下儲存，畫面完全沒變。
送出表單，不知道有沒有成功。
切換開關，狀態過了兩秒才更新。
這些都會讓 App 感覺「死掉」。
微互動（Microinteraction）的價值，是在使用者碰產品的瞬間，給出剛好的回饋。
例如：
按鈕按下後立刻改成「儲存中…」。
操作成功後在原本位置顯示完成狀態。
切換設定時，控制項立即反映新狀態。
檔案上傳時顯示進度。
Apple 的介面指南也把清楚、一致的回饋視為讓人保持掌控感的重要原則。
回饋要靠近操作，不要什麼都丟到提示訊息
如果使用者按的是某個按鈕，最直覺的回饋通常就在那個按鈕附近。
例如「儲存」變成「儲存中…」，比畫面角落跳出一個短暫通知更容易理解。
通知、震動、動畫都不是越多越好。
它們要和事件重要程度相稱。
第六步：把應用程式裡的文字改成使用者會說的話
很多產品的功能本身不難，卻被太像內部文件的文字弄得很難懂。
例如：
「建立實體」
「執行同步作業」
「提交資源」
這些詞可能對工程團隊很自然，對使用者卻不一定。
好的介面文字要具體。
按鈕最好說明會發生什麼。
錯誤訊息要說怎麼修。
空白狀態要告訴人下一步。
工具提示要回答當下問題，不要寫成產品說明書。
每個畫面只需要傳達一個主要意思
如果首頁要同時解釋產品定位、教功能、推升級、發公告、邀評價，使用者很容易不知道先看哪裡。
可以先替每個畫面寫一句：
「這個畫面最重要的是讓人＿＿。」
只要那句話答不出來，畫面通常還需要刪東西。
第七步：付費與升級介面要能說服，但不能靠暗招
付費牆、試用到期、升級提示本來就可以做說服。
但證據要是真的。
稀缺要是真的。
價格要看得懂。
取消與返回不能故意藏起來。
可以使用社會證明、權威、承諾一致性或互惠等心理原則，但前提是使用者仍然清楚知道自己在選什麼。
如果一個設計只有在使用者「沒有發現你在做什麼」時才有效，就應該重新檢查。
第八步：速度是 UX，不是工程部門自己的事
App 畫面再漂亮，如果按下去等兩秒才有反應，使用者一樣會覺得不好用。
對 Web App 而言，目前 Core Web Vitals 仍然可以作為基本參考：
LCP 2.5 秒內。
INP 200 毫秒內。
CLS 0.1 以下。
這些數字不是為了考試。
它們對應的是使用者感受到的載入速度、互動反應與畫面穩定。
如果你想拆解網站和瀏覽器效能，可以延伸閱讀 High Performance Browser Networking：網站速度慢，真正瓶頸可能不在主機。
有些延遲消不掉，就先把「等待感」設計好
網路延遲不一定能完全消失。
這時可以用：
骨架畫面。
樂觀式介面。
分段載入。
明確進度。
讓使用者知道系統仍然在工作。
但這些方法不能拿來掩蓋真的很慢的後端問題。
第九步：最後做一次「從零使用」的殘酷檢查
產品團隊每天看自己的 App，很容易對問題失去感覺。
所以最後要假裝自己第一次用。
從下載或登入開始。
不要跳步。
不要使用你腦中知道的捷徑。
記錄：
多久看懂這個產品是做什麼的？
幾步能完成第一個有價值的任務？
哪裡需要停下來想？
哪個功能可以直接拿掉？
哪些細節看起來像「做到能用就停了」？
這種冷啟動檢查，常常比再開一次功能腦力激盪更有用。
改善應用程式的順序，比改善項目本身更重要
如果 App 有很多問題，不要同時亂改。
可以依這個順序：
一、確認使用者最需要完成的工作。
二、先修最嚴重、最常發生的流程摩擦。
三、把容易做錯的地方改成不容易做錯。
四、整理視覺層級與一致性。
五、補齊操作回饋與狀態。
六、把文字改成人看得懂的語言。
七、檢查付費與升級是否透明、可信。
八、處理使用者實際感受到的速度。
九、最後從頭走一次，砍掉不必要的東西。
這個順序能避免團隊先做最顯眼、卻不一定最重要的改版。
怎麼知道改善真的有效？
每一個改動最好都對應一個可觀察結果。
例如：
註冊流程縮短後，看完成率。
錯誤訊息重寫後，看重複失敗率。
主要按鈕層級調整後，看核心任務啟動率。
速度改善後，看 INP、LCP 與實際流失。
新升級頁上線後，看升級率，也看退款與取消。
不要把「大家覺得比較漂亮」當成唯一驗收標準。
應用程式變好用，通常不是靠一個大改版
成熟的產品改善，比較像持續找出阻力。
今天修一個使用者一直找不到的入口。
下週把一個容易誤按的操作改成可撤銷。
再下一輪把最慢的互動縮短。
同時持續看真實使用者到底還卡在哪裡。
如果每一次改善都有證據、有優先順序、有對應指標，產品會慢慢從「功能都在」變成「用起來順」。
常見問題
應用程式不好用，第一步是不是先重做介面？
不建議。先確認使用者要完成的工作，再看流程摩擦、錯誤、狀態與資訊架構。視覺重做如果沒有對應真實問題，很容易只是換皮。
功能很多但使用率低，應該加教學嗎？
不一定。先看功能入口、命名、操作提示和使用情境是不是清楚。如果每個人都需要看教學才能完成基本工作，設計本身通常還有改善空間。
微互動越多，應用程式就越有質感嗎？
不一定。微互動的重點是回饋與狀態，不是動畫數量。過多動效反而會增加干擾，重要的是在需要回饋的時刻給出剛好的反應。
速度問題只需要工程師處理嗎？
不是。速度會直接影響使用者體驗、信任與完成率。產品、設計與工程應該一起決定哪些互動最重要，以及使用者能接受多少等待。
怎麼決定改善優先順序？
先看問題嚴重度、發生頻率與對核心任務的影響。讓大量使用者無法完成主要工作的問題，應該排在純視覺瑕疵之前。
參考資料
Clayton M. Christensen, Taddy Hall, Karen Dillon, and David S. Duncan. Competing Against Luck: The Story of Innovation and Customer Choice.
Jakob Nielsen. “10 Usability Heuristics for User Interface Design.” Nielsen Norman Group.
Don Norman. The Design of Everyday Things: Revised and Expanded Edition.
Adam Wathan and Steve Schoger. Refactoring UI.
Dan Saffer. Microinteractions: Designing with Details.
Chip Heath and Dan Heath. Made to Stick: Why Some Ideas Survive and Others Die.
Robert B. Cialdini. Influence, New and Expanded: The Psychology of Persuasion.
Apple. “Human Interface Guidelines: Design Principles.”
web.dev. “Core Web Vitals.”