設計師不是沒有話語權，是讓渡了它

有一個場景我在 1on1 裡遇過很多次。

我問設計師：「這個專案的流程有什麼可以改的？」對方想了一下說：「不太知道，我能改變什麼⋯」然後話題就這樣過去了。

那一刻不是話語權被拿走的時刻。是設計師自己放棄的時刻。組織行為學者 Amy Edmondson 提出的心理安全感（psychological safety）概念，可以解釋這個放棄為什麼會發生：在一個人不確定自己說出想法會不會被否定、被記在心裡的環境裡，最省成本的反應不是冒險發言，而是先自我噤聲。「不太知道」往往不是真的不知道，是還沒判斷清楚說出來安不安全。

但同一個問題，我也遇過另一種回應。同一家公司、同樣的組織結構、同樣沒有設計師在決策核心的環境。另一個設計師回答我：「我覺得規格交付的節點可以往前移，目前工程師拿到設計稿的時候已經沒有時間給意見了。我上個迭代試了一次，提前兩天交付，那次的來回次數少了一半。」

這兩個設計師坐在同一個組織裡。一個在等話語權，一個已經在用了。心理安全感低不低，是組織給的環境變數；但在同一個環境變數下，還是有人選擇先讓自己的影響被看見，這說明環境不是唯一的解釋。

核心洞察 話語權不是別人主動賦予的，而是設計師自己「讓渡」出去的。真正的話語權建立在影響力的可見性與主動溝通之上。

你在等一個從來不會主動到來的東西

設計師抱怨話語權的故事我聽了很多——公司不重視、產品說了算、工程優先。這些描述不是假的，但我不認同它背後的邏輯：話語權是別人給的。

話語權的運作順序是反的。不是先被重視，再開始有影響力。而是先讓影響可見，話語權才跟著來。社會學家 Erving Goffman 在討論日常生活裡的自我呈現時提出一個說法：人在他人面前，隨時都在進行一種「印象管理」（impression management），透過選擇性地展示哪些行為、哪些成果，來塑造別人對自己能力與可信度的判斷。這不是虛偽，是所有專業互動的基本結構：決策者無法直接讀取你的能力，只能從你展示出來的東西去推論。你不展示，決策者手上就沒有可以判斷的材料，信任自然無從產生。

在我管理的設計師裡，那些最終有發言份量的人，沒有一個是等到「被賦予權力」才開口的。他們找到一件能影響的事，讓它可見，然後慢慢建立話語的基礎。

這不是「正能量」或「努力就有回報」的邏輯。這是一個可以觀察的因果關係：決策者對設計師的信任，來自於他們能判斷這個設計師是否「知道自己在做什麼」。而那個判斷，來自設計師怎麼說話，不是來自他做了什麼。

話語權的因果順序 誤區：先被重視 → 再獲得影響力 真相：讓影響可見 → 話語權自然產生 決策者的信任取決於設計師展現出的專業判斷力與溝通方式，而非等待授權。

成果沒有消失，是語言讓它消失的

大多數設計師並不是沒有在做有影響力的事。他們讓流程更順、讓規格更清晰、讓使用者少踩一個坑。問題是，這些成果在語言裡消失了。

設計師說：「這個介面更直覺了。」決策者聽到：「嗯，不錯。」對話結束。

同一個設計師改一個說法：「這個介面調整後，客服詢問量下降了 18%，因為使用者自己找得到答案了。」決策者聽到：「這個設計師知道她在做什麼。」

話語權就在這兩句話的差距裡。這個差距不是決策者比較勢利，是人類判斷本身的運作方式。Daniel Kahneman 描述的雙系統模型（直覺、自動的系統一，與需要費力思考的系統二）可以解釋這件事：「更直覺了」是一個沒有具體錨點的形容詞，系統一抓不到任何可以快速比對的訊號，只能給出一個禮貌但空洞的回應；「下降 18%」是一個具體的數字錨點，系統一可以立刻辨認出「這是一個結果」，並自動觸發對能力的正面判斷，完全不需要系統二介入去慢慢分析。決策者不是不重視設計，是設計師給的語言，從一開始就沒有進入他能快速處理的格式。

但這只是其中一種翻譯。設計的影響力有很多層，每一層都有對應的決策者語言。

開發效率的翻譯。 設計師通常說：「這次規格寫得比較完整。」決策者聽到的是：好，那就繼續這樣。設計師如果改說：「這次因為提早確認了互動邏輯，工程團隊少問了我大概 12 個問題，估算省了兩天的來回。」決策者聽到的是：這個人在管理成本，不只是在做設計。

使用者行為的翻譯。 設計師說：「這個流程改得更清晰了。」決策者聽不出清晰是什麼意思，因為清晰是設計師的語言。改成：「原本 40% 的使用者在第三步就離開了，我們把那一步的資訊量減半，之後完成率升到 67%。」決策者聽到的是：這個設計決策有效，值得信任她的下一個決策。

商業指標的翻譯。 這條路最長，但不是做不到。「改了付款頁面的按鈕排列」和「付款成功率提高了 9%」，這中間的連結需要設計師自己建立——去找數字、去追蹤、去問 PM 有沒有數據。很多設計師覺得這是 PM 的工作，不是設計的工作。但話語權的建立，從來不是等人拿數據來敲你的門。

工作的品質沒有變，是翻譯能力的差距——把設計影響翻譯成決策者的語言。這不是一個軟技能，是一個可以練習的動作。

影響力翻譯的三個維度

• 開發效率：從「規格完整」轉為「節省來回時間與成本」。
• 使用者行為：從「流程清晰」轉為「轉換率/離開率的具體數據變化」。
• 商業指標：從「視覺/交互調整」轉為「營收/成功率等關鍵數字」。 翻譯不是妥協，而是建立利益相關者與設計價值之間的邏輯橋樑。

「不知道能改變什麼」是最危險的一句話

當設計師說「不知道能改變什麼」，他可能是還沒找到切入點、嘗試過被忽略、或是不確定怎麼讓改變可見。這三種情況都有解。

真正沒有解的，是停止問這個問題的狀態。

話語權讓渡的起點，不是某個組織決定「設計不重要」，而是某個設計師停止尋找他能影響的地方。那個組織裡的設計聲音，就少了一個。

作為管理者，我能做的其實有限，但也不是零。心理安全感這個概念的重點不在於「讓每個人都舒服」，是降低發言的感知風險，讓「說錯了會怎樣」這個念頭不再是第一個跳出來的反應。我可以幫設計師找到切入點、幫他把成果翻譯成決策語言、在他第一次開口時公開接住而不是當場挑錯，這些都是在降低那個感知風險。但我沒辦法替他決定要不要開始。這是那個「我能改變什麼⋯」的問題的真正含義：不是沒有答案，是設計師自己還沒有決定要找答案。

找出一件事，讓它可見

話語權不需要全面突破，只需要一個具體的開始。

找出一件你正在做、但從來沒有「翻譯」給決策者聽的事。可以很小：一個讓開發少走冤枉路的規格決定、一個讓使用者停止離開頁面的細節調整、一個讓下次提案更快過的流程改變。

然後，用影響說話，不用品質說話。

不是「設計更精緻了」，是「這個版本減少了設計來回，上線時間提前了一週」。不是「體驗改善了」，是「這個流程改了之後，完成率從 62% 到 78%」。

練習一個句型：「因為這個設計決策，所以⋯」

這個句型看起來簡單，但很多設計師說到「因為這個設計決策」之後就說不下去了——因為他們不知道「所以」是什麼。這不是因為沒有影響，而是因為沒有追蹤影響的習慣。

幾個具體的練習方向：

• 追蹤一個指標三個迭代：不需要全部的數字，只需要一個你能持續觀察的數字——完成率、離開率、客服詢問數、工程師問設計問題的頻率。三個 Sprint 之後，你就有一條數據，而不只是一個感覺。
• 和工程團隊確認規格的成效：每個 sprint 結束問一次：「這次規格有沒有讓你少問幾個問題？」這個對話很短，但它讓你知道你的規格能力有沒有在進步，也讓工程師感受到你在意跨職能的影響。
• 用「所以」測試提案：每次做完設計決策，問自己：如果有人問我「為什麼這樣設計」，我能不能說出「因為這樣，所以用戶會⋯」或「因為這樣，所以工程師不需要⋯」？說不出來，就是還沒解清楚問題。說得出來，就是話語權的材料。

實戰練習建議

1. 數據追蹤：鎖定單一指標連續觀察三個迭代，將「感覺」轉化為「事實」。
2. 跨職能對話：主動向工程師確認規格交付對開發流程的實際影響。
3. 決策驗證：強制自己使用「因為設計決策 A，所以產生結果 B」的結構進行提案與複盤。

翻譯能力怎麼練

翻譯能力不是天生的，但也不是靠努力就能練起來的。它需要一個前提：你得先聽懂決策者在說什麼。

我觀察到一個常見的誤區。設計師去聽主管或 PM 說話，聽的是「他同不同意我的設計」，而不是「他在用什麼語言衡量這件事」。這兩個聽法，得到的資訊完全不同。

組織學者 Chris Argyris 提出的推論階梯（ladder of inference）可以說明這個誤區的機制：同一段對話，每個人會先從龐大的原始資訊裡「選擇性地」挑出自己在意的那一小段，再基於這一小段做出結論。設計師選的是「他有沒有點頭」，決策者選的是「這件事符不符合他的衡量標準」。兩個人站在同一段對話裡，卻爬上了不同的推論階梯，得出的結論自然對不起來。翻譯能力的第一步，不是學會說「商業語言」，是先意識到對方在爬哪一段階梯：他從一堆資訊裡挑出來當作證據的，到底是哪一種。

前者讓你知道今天的提案過沒過。後者讓你知道這個人的決策邏輯是什麼。

每個決策者都有他們在意的幾個維度。有的人在意速度——「這能不能這個 sprint 做完」就是他的語言。有的人在意競爭——「競品有沒有這個功能」是他用來評估優先級的尺。有的人在意數字——沒有數據支撐的設計決策對他而言不算論據。

然後，把你的設計影響映射進去。

這聽起來像妥協——像是在把設計的價值「轉換」成對方能接受的版本。我不這樣看。翻譯不是妥協，是溝通。外科醫生跟病人解釋手術方案，不會用解剖學術語——不是因為術語不精確，而是因為讓對方理解才能推進決策。設計師把設計影響翻譯成決策語言，本質上是同一件事。

練習翻譯有一個最快的路徑：在日常工作的 email 或 slack 裡，每次描述設計決策的時候，加一句「這樣做的影響是⋯」。不需要很正式，不需要很完整。但這個習慣會強迫你去想「影響是什麼」，而不是只說「設計是這樣」。

三個月後，你會發現你說話的方式變了。不是因為你學了什麼框架，而是因為你養成了追蹤影響的習慣，而那個習慣讓你有材料可以翻譯。

溝通的本質 翻譯不是妥協，而是溝通。就像外科醫生不會對病人使用解剖學術語，設計師將設計影響轉譯為決策語言，是為了讓對方理解並推進決策。核心在於理解對方的「衡量標準」與「決策邏輯」，而非僅關注「提案結果」。

翻譯會失靈的兩種情況

這套翻譯邏輯不是萬用鑰匙，有兩種情況會讓它失靈，值得誠實面對。

第一種：數字本身被扭曲。印象管理一旦脫離真實的影響，就從「讓別人看見你做了什麼」滑向「讓別人以為你做了什麼」。挑一個對自己有利的指標窗口、只講漲不講跌、把相關性包裝成因果，短期內或許還是能讓決策者的系統一買單，但一旦被追問細節或被交叉核對，翻譯能力會反過來變成不誠實的證據，代價比什麼都不說更高。這套方法建立在「真的有影響，只是沒被看見」的前提上，不是拿來替沒有效果的工作上妝。

第二種：決策者的判準根本不是理性論證。如果一個人否決設計的真正理由是政治性的，例如保護自己的預算、迴避跟誰對立，再精準的數字翻譯也翻不動，因為問題從來不在「你有沒有說清楚」。這種情況下，翻譯能力用盡之後，該面對的是組織政治問題，不是溝通問題。硬要用翻譯去解，只會讓你誤判自己的努力方向。

地方也很重要，但不是你現在想的那種重要

我不想假裝環境完全不重要。有些組織的結構，就是不讓設計參與決策。在那種地方，個人能做的有限。

但我觀察到的大多數情況，不是結構問題，是起跑點的問題。設計師在還沒讓自己的影響可見之前，就先認定了「這個地方不重視設計」。

怎麼判斷是不是真的地方的問題？我有幾個觀察指標。

環境診斷與去留判斷 在決定離開前，請先確認以下三個指標：

1. 可見性：你是否有用對的語言呈現過設計成果？（否則結論只是假設）
2. 路徑：影響是否僅停留在直屬主管層級，未觸達高層決策者？
3. 系統性排除：組織內是否有其他設計師擁有話語權？若完全沒有且結構明確排除設計，才是真正的結構問題。 若指標全符合，離開是理性選擇；若未嘗試，「不知道能改變什麼」僅是開放式問題，非結論。

下次 1on1，試著問自己：上個月有一件什麼事，如果我換個說法，決策者的反應可能會不同？

那一件事，就是話語權的起點。