2026年9月1日 下午 12:50
UI/UX 設計UX 法則 · 2026
QUICK ANSWER
帕金森定律（Parkinson's Law）說：工作會自己膨脹，直到填滿所有可用的時間。它在設計裡有兩種用法——對使用者，任務耗時會膨脹到填滿他心裡預期的長度，所以結帳、註冊、填表要壓到比他預期更短；對設計師自己，設計時程與檔案也會膨脹到填滿死線，所以要主動設限。這是 1955 年一篇諷刺文裡的觀察，在 AI 把執行時間壓掉一大截的今天反而更準。
CHAPTER 01 · WHAT IS IT
1955 年 11 月 19 日，《經濟學人》登了一篇匿名投稿。第一句話是：工作會膨脹，直到把可用的時間填滿。作者寫這句的時候還加了但書，說這只是「一個老生常談的觀察」——真正想講的在後面。
寫的人叫 Cyril Northcote Parkinson，英國海軍史學家，當時在新加坡教書。他真正想證明的是第二件事：公家機關的人數會自己長大，而且跟實際工作量沒有關係。他手上有海軍部的統計可以打臉。
1914 到 1928 年之間，英國皇家海軍的主力艦少了三分之二、水兵少了三分之一。同一段時間，海軍部的行政官員從 2,000 人變成 3,569 人。艦隊縮水，管艦隊的人反而多了將近八成。
2,000
官員 · 1914
3,569
官員 · 1928
+78%
十四年增幅
−2/3
同期艦艇數
兩年後這篇文章擴寫成書《Parkinson's Law: The Pursuit of Progress》，成了暢銷書。有趣的是後世記得的不是他花最多篇幅論證的組織膨脹，而是那句他自己都說是老生常談的開場白。這句話被一路借用到專案管理、時間管理，最後進了 UX 的參考書單——Jon Yablonski 把它收進 Laws of UX，成為設計師最常被引用的心理學法則之一。
CHAPTER 02 · THE EVIDENCE
一句諷刺文的開場白憑什麼被當成法則？因為心理學家真的去測了。
1966 年，Aronson 與 Gerard 設計了一個實驗：一個五分鐘能做完的任務，讓受試者「不小心」拿到五分鐘或十五分鐘。拿到多餘時間的那一組，實際動手的時間顯著更長。這還算符合直覺。難聽的在第二輪——研究者接著給同一批人第二個任務，這次沒有任何時間限制，先前被給了多餘時間的人，還是花得比較久。他們把這個現象叫做「多餘時間效應」（excess time effect）。一次寬鬆的死線，會留下一個慢下來的習慣。
隔年 Bryan 與 Locke 做了更細的版本，想知道中間到底發生了什麼事。答案是目標。時間寬裕的人不是被時間拖慢的，是他們自己把目標訂低了——手上有兩倍的時間，心裡就自動把「做完」的標準往下調。
KEY INSIGHT
壓縮死線但沒給明確產出，只會得到壓力。「這個提早三天交」是沒用的指令，「提早三天交，交的是這三張主視覺」才是。
“
時間不會拖慢你，是你在看到時間之後，偷偷把標準放低了。
CHAPTER 03 · FOR USERS
Laws of UX 給的操作建議只有一句：把完成任務所需的時間，限制在使用者預期的範圍內。關鍵字是「預期」，不是絕對秒數。同樣三十秒，用來訂一張機票是快的，用來按一個讚是荒謬的。
結帳流程是這條法則被驗證得最徹底的地方。Baymard Institute 的結帳基準資料庫顯示，美國網站的結帳流程平均預設顯示 23.48 個表單元素（只算輸入欄位是 14.88 個）；而他們大規模可用性測試得出的理想值，是 12 到 14 個元素、7 到 8 個欄位。也就是說多數網站的結帳頁，大約是理想值的兩倍長。
美國網站平均
23.48 個
預設顯示的表單元素
測出來的理想值
12–14 個
多數站台可砍掉兩到六成
代價很具體。Baymard 彙整五十份研究算出的平均棄單率是 70.22%，而在扣掉「只是逛逛」這群人之後的棄單原因裡，有 17% 的美國網購者說自己曾因為「結帳流程太長或太複雜」而放棄訂單。這不是體驗好不好的問題，是錢直接從表單的縫裡漏掉。
能砍的東西通常比想像中多：自動填入、地址自動補完、免註冊結帳、把非必要欄位收進「選填」的摺疊區、把兩頁併成一頁。我在拆解 Framer 表單的填完率設計 與 Landing Page 的六個設計步驟 時，最後一步永遠是同一件事：把使用者要做的動作再刪一次。
同一本書裡還有一條跟它並肩的法則叫 Doherty 門檻：當系統與人的往返低於 400 毫秒，生產力會跳升。帕金森定律管的是整個任務的長度，Doherty 門檻管的是每一次互動的間隙，兩條一起看才完整。
想一次看完整套法則的脈絡，Yablonski 自己講過一場約一小時的講座，把這些原則怎麼來、怎麼用講得比網站上完整：
▲ Jon Yablonski 談 Laws of UX 的完整講座（Proximity Lab）。
CHAPTER 04 · THE EXCEPTION
這是多數人引用帕金森定律時漏掉的一半。
2011 年，哈佛商學院的 Buell 與 Norton 做了一個現在被叫做「勞動錯覺」（labor illusion）的研究。他們找來 266 位受試者，用一個模擬的旅遊比價網站訂行程，等待時間從 0 到 60 秒不等。一半的人看到的是一條進度條，另一半看到的是不斷跳動的清單，一行一行寫著現在正在搜尋哪一家航空公司。結果完全一樣，只有「看不看得到它在幹活」不同。
看得到過程那組，對服務的評價高了約 8%，而且在每一個等待長度上都贏。受試者甚至估計那個網站搜尋了更多家業者——實際上兩邊搜的一樣多。研究者的解釋是互惠：你看見對方為你花了力氣，你就願意給它更高的評價。
該壓縮的
使用者要出力的部分：輸入欄位、重複驗證、無意義的確認頁、沒人看的條款勾選。
不必壓到零的
系統在替他出力的部分：比價、演算、生成、核對。這段時間如果看得見，它是價值不是等待。
所以帕金森定律用在介面上要修正一句：要砍的是任務的長度，不是過程的能見度。AI 產品尤其明顯——現在幾乎所有推理型的工具都會把思考步驟攤開來給你看，那不只是為了透明，也是為了讓那幾秒鐘的等待值得。
CHAPTER 05 · FOR DESIGNERS
案子給兩週，就會做兩週。給一個月，第一週會拿去「先探索方向」。Figma 檔案也一樣，給多大的畫布就長多少個 frame，最後沒有人敢刪。
Parkinson 在 1957 年那本書裡還寫了另一條，叫做瑣碎定律（Law of Triviality）。他虛構了一個財務委員會，議程上有三個案子。第一個是造價一千萬英鎊的核子反應爐，兩分半鐘通過。第二個是三百五十英鎊的員工腳踏車棚，吵了四十五分鐘。第三個是二十一英鎊的茶點預算，討論了一小時十五分。
討論時間跟金額成反比。原因不難猜：反應爐沒有人真的懂，也沒有人想在同事面前承認自己不懂，於是大家點頭。腳踏車棚每個人都有意見，而且發表意見完全沒有風險。九〇年代末，FreeBSD 社群的 Poul-Henning Kamp 把這個現象搬進軟體開發，還替它加上了最傳神的一筆——大家吵的其實是腳踏車棚要漆什麼顏色。
設計評審會議是這條定律的原產地。資訊架構五分鐘就過了，按鈕圓角四還是六可以吵四十分鐘。防守方法不是在會議上據理力爭，是提前把腳踏車棚的顏色定死——圓角、間距、字級這類人人有意見的東西寫進設計系統，變成不能在會議上重開的參數。我寫過的 8pt 間距系統 本質上就是幹這件事：把可以吵的事情，變成查表就有答案的事情。
CHAPTER 06 · IN THE AI ERA
這是我這一年最有感的版本。
生成一張視覺從三小時掉到三分鐘，切一頁版從一天掉到二十分鐘。照理說專案週期應該跟著垮下來，但沒有。省下來的時間去了哪裡？去了第七版、第十二版、第二十版。以前提三個方向是因為只做得出三個，現在能做三十個，於是就真的做了三十個，然後花整個下午在裡面挑。工作照樣膨脹到填滿死線，只是膨脹的形狀從「做得慢」變成「做得多」。
2026 年那份大規模科技從業者調查其實已經把答案寫在數字裡了：設計師在焦慮、疲憊、不推薦入行三項都是所有職位最高，但只有 22% 擔心被 AI 取代，51% 擔心的是做更多、拿一樣的錢。那不是 AI 的問題，那是帕金森定律遇上一個突然變便宜的產能。
Sagmeister 在訪談裡說，只要求可讀的排版，他一個下午能做幾千個。合格的部分已經免費了，剩下值錢的是收斂——決定哪一個是對的，然後停手。帕金森定律在 AI 時代真正的用法，是替省下來的時間先安排好去處，否則它會自己找到去處，而且通常是第二十版。
CHAPTER 07 · HOW TO USE IT
前三個對使用者，後三個對自己。
先量預期，再量實際
在使用者測試裡多問一題：「你覺得這件事會花你多久？」他的答案就是你要打敗的基準線，而不是你自己覺得快不快。
砍輸入，不砍回饋
自動填入、地址補完、免註冊結帳，能省的輸入全部省掉；但系統在替他工作的那幾秒，留著並且讓他看見。
把剩下的長度講出來
還剩幾步、大約幾分鐘，寫在畫面上。預估值抓得保守一點，讓實際落在預期之內——這是最便宜的體驗升級。
死線要配產出，不能只配時間
Bryan 與 Locke 的結論：真正在起作用的是目標。壓縮時程的同時把交付物寫死，否則你只是換到一個更焦慮的版本。
用天當單位，不要用週
「這週做完」會準時在週五晚上做完。拆成「週二給版型、週四給完稿」，膨脹的空間就只剩兩天大。
提前把腳踏車棚漆好
圓角、間距、字級、色票寫進設計系統，開會前就定案。留給會議的時間才會落在真正難的那個題目上。
CHAPTER 08 · TAKEAWAYS
TAKEAWAYS
→
帕金森定律出自 1955 年《經濟學人》的一篇諷刺文，本意是罵官僚組織膨脹，後來被 UX 借用成「任務會膨脹到填滿預期時間」。
→
它經過實驗驗證，而且中介變項是目標不是時間：寬鬆的死線會讓人自動調低標準，效果還會延續到下一個任務。
→
對使用者：美國網站結帳平均 23.48 個表單元素，理想只要 12 到 14 個，17% 的人因為結帳太長棄單。能砍就砍。
→
但過程不要一起砍。勞動錯覺研究顯示，看得見系統在幹活的版本，感知價值高出約 8%。
→
對自己：時程與檔案都會膨脹，設計評審則會被腳踏車棚吃掉。用天當單位、把可吵的參數寫進設計系統。
Parkinson 寫那篇文章的時候是在酸英國公務體系，他大概沒想過七十年後最會膨脹的東西不是海軍部，是一個 Figma 檔案。工具愈快，這條定律愈準，因為省下來的時間從來不會自己變成休息——它只是在等下一批工作把它填滿。決定要拿它裝什麼的人，只能是你自己。
RELATED READS · 延伸閱讀
一頁式網站為什麼好看卻沒人填表單？從 Hero 到 CTA 的六段說服順序
把六個區塊照說服順序排，讓使用者不必自己拼湊你在賣什麼。→
Framer 表單怎麼做？從原生 Form 元件到通知、防垃圾與成效追蹤
欄位命名、三種提交目的地，以及影響填完率的那些細節。→
網頁排版的間距系統：8pt 網格與四層間距，讓版面看起來有人在管
把間距變成查表就有答案的事，會議上就少一個可以吵的題目。→
AI 時代的設計師為什麼最焦慮？2026 調查數據與兩位 AI 設計主管的診斷
51% 的人擔心的不是被取代，是做更多、拿一樣的錢。→
Claude Code 怎麼做出沒有 AI 感的網站？三步驟把 AI 調教成懂品味的設計師
產能變便宜之後，收斂的方法比生成的方法重要。→
去 AI 味怎麼做才有效？別抄 Prompt，建一套會自我更新的寫作 Skill
把判斷寫成規則，就不必每次重新決定一遍。→
Figma Projects 改名 Folders 了？巢狀資料夾、10 層結構與權限大改完整解析
檔案會膨脹到填滿你給它的資料夾層數，先想好規則再開層。→
接案設計師的素材天堂：六個來源、真實花費，與三條會賠錢的授權紅線
省下的不只是錢，是不必從零開始的那幾個小時。→
EXTRA · LINKS
Laws of UX — Parkinson's Law 本文的起點，附官方海報下載。
Laws of UX — Doherty Threshold 400 毫秒那條線的出處。
《Laws of UX》第二版 Jon Yablonski 著，O'Reilly 出版。
1955 年《經濟學人》原文 PDF 含海軍部統計表原始數據。
Baymard Institute — 棄單率統計 結帳欄位數與棄單原因的原始資料。
The Labor Illusion（Buell & Norton, 2011） 勞動錯覺的完整論文 PDF。
Law of Triviality 腳踏車棚效應與 bikeshedding 的來龍去脈。
A：英國海軍史學家 Cyril Northcote Parkinson。他在 1955 年 11 月 19 日以匿名投稿的方式，在《經濟學人》發表一篇諷刺公務體系的文章，第一句就是「工作會膨脹，直到填滿可用的時間」。1957 年擴寫成書《Parkinson's Law: The Pursuit of Progress》。
A：有實驗支持。1966 年 Aronson 與 Gerard 發現，拿到多餘時間的受試者做同一個任務會花更久，而且這個「多餘時間效應」會延續到下一個沒有時間限制的任務。1967 年 Bryan 與 Locke 進一步指出，真正的中介變項是目標設定：時間寬裕的人會自動把目標訂低。
A：把完成任務的實際時間，壓到比使用者預期的更短。具體做法是自動填入、地址自動補完、免註冊結帳、砍掉非必要欄位，並在畫面上明示還剩幾步。基準線是使用者心裡的預期長度，不是絕對秒數。
A：Baymard Institute 的可用性測試給的理想值是 12 到 14 個表單元素，只算輸入欄位是 7 到 8 個。對照他們的基準資料庫，美國網站平均預設顯示 23.48 個元素，多數站台有 20% 到 60% 的刪減空間。
A：不一定。哈佛商學院 Buell 與 Norton 在 2011 年提出的「勞動錯覺」顯示，讓使用者看見系統正在為他工作的版本，即使等得比較久，感知價值仍高出約 8%。該壓縮的是使用者要出力的部分，系統出力的過程反而值得被看見。
A：同一個作者的另一條觀察，1957 年提出，正式名稱是瑣碎定律。他虛構的委員會花 2.5 分鐘通過一千萬英鎊的核子反應爐，卻花 45 分鐘討論三百五十英鎊的腳踏車棚。設計評審裡的版本，就是資訊架構五分鐘過、按鈕圓角吵四十分鐘。
A：因為工作膨脹去填滿了省下來的時間。以前提三個方向是因為只做得出三個，現在能做三十個就真的做了三十個。要讓產能變便宜真的轉換成時間，必須主動替省下的時段安排用途，並在壓縮死線的同時把交付物寫死。
