多數人以為網站越改版越亂，是因為聽進太多意見；原因其實不在意見本身，而在於意見蒐集完之後，沒有人真正負責把它們收斂成一個決定。軟體與設計圈把這種現象稱為 design by committee（委員會式設計），指的是一項產出得先經過太多方各自把關，每一方都握有否決權或加註意見的空間，最後拼出一個誰都點頭、卻誰都不特別滿意的版本。
網站改版最容易掉進這個坑，因為牽涉的角色天生就多，而且每個角色各自的訴求單獨看幾乎都站得住腳。真正麻煩的，是把這些訴求疊在同一個首頁之後，沒有人負責做取捨，版面只會越改越擠，讀者也越來越看不出這個網站要他先做什麼。
同一個網站背著 6 個部門互相衝突的期待
把一家中小型電商的官網改版攤開來看，提出意見的人手一份清單。行銷部門要放上這一季的活動橫幅，顏色要夠搶眼，才拉得動點擊；業務或客服想要的是報價與聯絡方式擺在最顯眼的位置，少讓客人多點兩下才找得到；創辦人或經營者在意的是品牌故事、得獎紀錄跟理念宣言有沒有露出，這關係到外界怎麼認識這家公司；負責產品或技術的人希望每一項功能與規格都講到，擔心少講一項就等於少賣一項；財務或背後的投資人在意首頁夠不夠專業、夠不夠像個有規模的公司；法務或人資可能還要求加一段免責聲明，或是把徵才連結放進去。
單獨挑出任何一項來看，幾乎都很難反駁。行銷要搶眼是為了業績，業務要清楚是為了不流失客人，創辦人要露出品牌故事是為了建立信任，這些訴求本身沒有一個是無理取鬧。真正的問題出在，這些聲音疊加在同一張首頁上時，沒有人被賦予「這次改版要優先服務誰」的決定權，結果是每一項訴求都被塞進去一點，首頁的版面越改越擠，讀者一打開，反而分不清這個網站要他先看廣告、先詢價，還是先讀品牌故事。
這不是哪個部門不對，是疊加之後少了一個環節。沒有人把這些合理的訴求排出優先順序，也沒有人有權說「這次先服務詢價的人，品牌故事這次先退到第二層」。缺了這個取捨的動作，每次改版都只是把清單上的項目再塞進去一次，首頁只會越來越擠，不會越來越清楚。
決策鏈每多一層，網站的風格與訊息就多一種版本
把上一節的現象往「為什麼」再推一層，可以先看電腦科學家 Melvin Conway 的一個觀察。他在 1968 年於《Datamation》期刊發表的論文〈How Do Committees Invent?〉裡指出，任何設計系統的組織，做出來的系統結構會複製這個組織原本的溝通結構。這個說法後來被電腦科學家 Fred Brooks 正式命名為 Conway’s Law（康威定律），成為軟體與系統設計領域的經典理論。
網站也是一種系統，它的用色、字體、文案語氣，同樣會不自覺反映決策鏈的形狀。想像同一個改版案，先經過行銷部門審過一輪，再送到業務部門加意見，接著給創辦人拍板，最後還要法務點頭，決策鏈每多一層，網站上就多一種可能的版本，因為每個把關的人只對自己負責的那一塊盡責，沒有人被賦予「整體看起來是不是同一個網站」這個職責。行銷加的橫幅是一種語氣，業務堅持的報價區塊是另一種語氣，兩者擺在同一頁，讀者一眼就能感覺出這個網站好像不是同一群人做的。
為什麼有些網站看起來很亂，卻又說不出具體哪裡做錯，這個現象也給出了答案。答案通常不是設計師的技術不夠，而是背後的決策結構本身就分裂，網站只是把這個分裂如實映照出來。要讓網站的風格與訊息回到同一套邏輯，得先處理決策鏈本身的長度與分工，不能只在視覺層面反覆調整用色與排版。
全體點頭的方案未必有人真心想要
開會時全員點頭，不代表這是所有人都想要的方向。這個現象在管理學裡有個名字，叫做 Abilene Paradox（艾比林悖論），由喬治華盛頓大學管理學教授 Jerry B. Harvey 於 1974 年發表在期刊《Organizational Dynamics》的論文裡提出，核心主張是，團體成員常常因為害怕被當成唱反調的人，又誤判其他人應該都支持某個方案，於是共同附和了一件其實沒有人真心想做的事。Harvey 認為，這不是管理階層沒管好衝突，而是沒有管理好「一致性」本身。
套回網站改版的情境很好想像。會議上提出一個折衷版首頁，行銷覺得不夠搶眼卻沒說出口，業務覺得報價區塊被擠壓卻也沒反對，創辦人看了皺一下眉頭仍然點頭，因為每個人都以為只有自己不滿意，不想第一個公開反對。最後這個方案順利過關，上線之後卻沒有一個部門真心滿意，回頭檢討時才發現，原來當時每個人心裡都有疑慮。
這說明一件反直覺的事，團隊看起來越和諧，反而越可能在氣氛裡做出誰都不滿意的決定。真正重要的不是會議上有沒有人反對，而是有沒有一個管道讓每個人把真實想法說出來，而不是靠觀察別人的表情去猜測共識在哪裡。
位階越高的意見，未必最懂使用者的真正需求
當團隊對某個設計選擇沒有明確數據可以佐證對錯，很容易出現另一種傾向，習慣性服從職位最高或最資深者的判斷，而不是回頭看使用者實際怎麼用這個網站。這種現象有個通稱的縮寫，叫做 HiPPO，是「Highest Paid Person’s Opinion（最高薪者意見）」的縮寫。這個詞最早由 Intuit 內部團隊在 2006 年發展出來，後來由分析領域的作者 Avinash Kaushik 大力推廣，他認為很多網站體驗差，是因為由 HiPPO 打造出來的，當沒有數據可以佐證方向對錯時，團隊會傾向服從最資深者的判斷，而不是驗證使用者實際的需求。
要澄清的是，這不是在說位階高的人判斷一定是錯的，問題出在「位階最高」跟「最了解這次要解決的使用者問題」被劃上等號這件事本身。一個資深主管對品牌調性或商業考量，確實可能有比較準的直覺，但使用者實際上怎麼點、怎麼找、在哪個環節遇到困難，不是靠職位判斷得出來的，得回頭看使用者的行為。當這兩者被混為一談，網站就變成照著組織的權力結構長，而不是照著使用者的需求長。
退一步的妥協換來平庸的中間值
折衷常被誤會成把幾個方案的優點平均起來，實際上運作的方式恰好相反。折衷通常是把每個方案裡最有主張、最可能得罪人的部分磨掉，換來一個誰都不反對，但也沒有人真心喜歡的中間值。這也是為什麼很多「大家都同意」的網站看起來四平八穩，卻沒有一處讓人記得住，不是設計師的能力不夠，是決策過程本身系統性地把突出的選擇篩掉了。
這也是 design by committee 這個說法容易被誤解的地方。多篇國際 UX 與產品設計媒體反覆整理過同一個觀察：一旦設計變成集體決策，就會系統性地往「沒有人討厭、但也沒有人特別喜歡」的方向收斂，因此有人認為 design by compromise（妥協式設計）其實比 design by committee 更精準描述這個機制，問題不在有多少人參與討論，而在討論之後怎麼收尾。
前面幾節鋪陳的都是問題本身，意見疊加、決策鏈拉長、集體附和、位階凌駕數據，最後全都收斂成同一個結果，就是版面越改越平庸。真正做得好的網站，決策過程往往完全不一樣。
好的網站，幾乎都出自一個人或一組高度共識的團隊
電腦科學家 Fred Brooks 在 1975 年出版的經典著作《The Mythical Man-Month》裡提出一個關鍵概念，叫做「概念完整性（conceptual integrity）」。他的主張是，真正好的系統設計，幾乎都出自一個人，或者最多兩三個高度契合的頭腦，而不是很多人妥協出來的結果。他認為概念完整性是系統設計裡最重要的考量，一旦要顧及規模，做法就不是把決策權分給更多人，而是採用他所稱的「外科手術團隊」模式，由一位總設計師對整體一致性負責，其他成員負責支援與執行，而不是讓每個參與者都握有平等的否決權。
這裡要先釐清一個容易誤解的地方。「一個人拍板」不等於「一個人埋頭做完所有事」，重點是決策權集中在一個人或一個很小的決策圈手上，執行的工作仍然可以分給團隊裡的每一個人，兩者是分開的兩件事。
可以參考一個公開的國際案例。記者 Adam Lashinsky 在 2012 年出版的著作《Inside Apple》裡記錄了蘋果公司長期採行的做法，公司裡幾乎每一件事都會指定一位 DRI（directly responsible individual，直接負責人），出了狀況就是找這個人負責，而不是靠一整個委員會共同承擔。這種做法沒有涉及台灣任何廠商，單純是說明一種組織設計，規模化不代表決策一定要分散，反而越是規模大的組織，越需要清楚指定誰對整體一致性負責。
把這兩個觀察合起來看，能得到一個立場。網站要維持一致的風格與訊息，靠的不是找更多人來把關，而是有一個人或一個很小的決策圈，持續對「這個網站整體看起來、讀起來像不像同一件事」負責。
收斂決策權不是拒絕聽意見
看到這裡，容易產生一個誤會，以為「一個人拍板」等於關起門來自己做決定，不聽任何人的意見。如果你也擔心「收斂決策權」等於不聽別人講話，答案就是不會。真正的做法，是把「蒐集意見」跟「做出決定」這兩件事分開處理。每個部門的意見仍然重要，行銷了解活動節奏、業務清楚客人真正在意什麼、法務知道哪些地方有風險，這些資訊都該被聽進去。差別在於，聽完之後，要有一個人，或一個很小的決策圈，對最終方向負最終責任，其他人的角色是提供資訊與觀點，不是共同投票決定版面長什麼樣子。
這個轉折呼應前面兩節的論點。Harvey 提醒的是，集體投票容易掉進表面和諧、實則沒有人滿意的陷阱；Brooks 提醒的是，真正一致的設計需要一個穩定的決策核心。把兩者放在一起看，答案並不是要組織變得更集權、更少溝通，而是把溝通的角色重新分工，讓意見有地方說，也讓決定有人真正拍板。
意見蒐集與決策拍板，該是兩個分開的步驟
第一個具體做法，可以參考 Nielsen Norman Group（國際知名的使用者研究與可用性顧問機構）一篇談團體迷思（groupthink）的文章提出的建議。文章的核心主張是，團隊凝聚力越高，越容易為了達成表面共識而壓抑不同意見，導致方案沒有經過充分檢驗就定案。建議的做法是讓每個成員先各自獨立提出想法，把重點想法整理出來之後，才進入團體討論，而不是一開始就把所有人拉進同一場會議現場公開討論。
套用到你的網站改版上，與其把行銷、業務、創辦人、技術、法務全部拉進同一場會議當場討論版面，不如先請每個部門各自獨立提出書面意見與理由，列清楚自己的訴求跟原因，等所有意見都收齊了，再交給拍板的人或決策圈統一比對、取捨。這樣做能避開會議現場的從眾壓力，不用擔心自己是第一個唱反調的人，也能讓決策者看清楚每個意見背後真正要解決的問題是什麼，而不是被誰的表達方式或誰的音量牽著走。
使用者的實際行為，該取代「我覺得」的喜好之爭
第二個具體做法，呼應前面 HiPPO 那一節的機制。當你的團隊對某個設計選擇僵持不下，與其比誰的職位高、誰的聲音大，不如回頭看使用者實際怎麼用這個網站：哪個頁面停留得久、哪一條路徑被點得最多、詢問或訂單實際從哪裡進來。有數據可以佐證的判斷，才拿出來說服團隊；沒有數據佐證、純粹是喜好之爭的部分，可以先擱置，不必急著在這一次改版裡分出勝負。
延續同一個道理，前面 Kaushik 的主張也適用在這裡。有數據可以驗證時，就用數據決定；沒有數據的時候，才輪到經驗與判斷出場，而不是反過來，先讓經驗與判斷主導，有了數據才拿來背書。
你的網站如果越改越亂，通常就不是因為聽進太多意見，而是意見蒐集完之後，沒有人真正把它們收斂成一個決定。把「蒐集意見」跟「做出決定」拆成兩個分開的步驟，讓一個人或一個很小的決策圈對整體一致性負最終責任，是目前看得到最能對症下藥的做法。改版的次數，或者「這次又調整了一次」這件事本身，並不能證明網站有變好；真正讓網站變好的，是決策權收斂之後維持住的一致性，加上拿時間去驗證每次調整實際帶來的效果，而不是靠下一輪意見再重新洗一次牌。