原文：Stop Reporting UX Activity and Report Business Outcomes

做 UX 或產品相關工作時，我們很容易在報告裡寫：「這季做了 24 場訪談」、「完成 3 次 Usability Testing」、「SUS 從 62 分提升到 74 分」。

這些數字都沒有錯，也確實代表團隊做了很多事情，但問題是，如果今天坐在對面的是主管、財務或其他部門，他們真正想知道的可能不是「你做了多少研究」，而是：

所以，這件事情最後替公司帶來了什麼？

這也是這篇文章最主要想談的事情。

做了很多，不等於讓別人看見你的價值

UX 團隊常見的第一個問題，是很習慣報告「做了什麼」，而不是「改變了什麼」。

例如：「我們訪談了 24 位使用者、做了 3 次易用性測試。」這些資訊可以證明團隊很忙，但站在管理層的角度，他看到的可能只是公司投入了人力和時間，卻不知道這些投入最後產生了什麼結果。

第二個問題則是，UX 很習慣使用自己的語言。

像是 Task Success Rate、Error Rate、SUS，這些對 UX 團隊來說都很熟悉，但對 CFO 或其他主管來說，不一定知道 SUS 74 分到底算好還是不好，更不知道它和公司這一季的目標有什麼關係。

所以問題不是這些 UX 指標不重要，而是不同場合需要講不同的語言。

Task Success Rate 和 SUS 很適合放在研究報告裡，但如果今天是在爭取預算或向主管說明 UX 的價值，就需要再多往後追一步：這些改善最後對營收、成本或留存造成了什麼影響？

主管真正關心的，其實是這五件事

如果把 UX 的成果轉換成商業語言，大致可以從五個方向來思考：營收、成本、風險、上市速度，以及留存與滿意度。

例如一個結帳流程很難操作，UX 看到的可能是 Task Success Rate 太低，但公司真正承受的結果，可能是使用者結帳到一半就離開，最後直接影響轉換率和營收。

如果介面設計不清楚，使用者一直打電話或寄信問客服，UX 改善流程之後，客服詢問量下降，其實就是替公司省下成本。還有一些問題，如果能在設計階段就先透過研究或測試發現，只需要在 Figma 裡修改；等做到開發甚至上線後才發現，就可能得重新開發、測試，甚至延期。

這時候 UX 帶來的價值，就不只是「這個畫面比較好用」，而是減少後續重工、降低風險，也讓產品可以更順利上線。

同樣地，如果新手引導做得不好，使用者第一次進來連核心功能都沒體驗到就離開，UX 可能關心的是 First-use Completion，但從公司的角度來看，更值得關注的是這些使用者 7 天、30 天後還有沒有留下來。

這也是我覺得這篇文章最值得記住的地方：不是把 UX 指標丟掉，而是繼續把它往下追。

從 UX Metric 再往後追一步

文章把指標分成 Upstream Metrics 和 Downstream Metrics。

Upstream Metrics 可以理解成比較靠近設計本身的指標，例如任務成功率、錯誤率、SUS。它們告訴我們：「這次設計做得好不好？」

Downstream Metrics 則比較接近公司最後看到的結果，例如轉換率、客服量、Churn。它們回答的是：「設計改善之後，實際帶來了什麼改變？」

例如我們發現使用者在某個流程錯誤率很高，重新設計之後錯誤率下降，這當然是一件好事。但如果還能繼續看到退款或客服詢問因此減少，那整條價值就會變得更完整：

UX 改善 → 使用者比較不容易犯錯 → 客服／退款減少 → 公司成本下降。

這時候 UX 的價值就不再停在「使用者覺得比較好用」，而是可以和公司原本就在追蹤的數字連在一起。

不過這也代表 UX 不能只待在自己的資料裡。想知道後面的 Business Outcome，就需要跟 Product Analytics、客服、財務或 Marketing 合作，才有辦法取得改版前後的資料。

而且也不用為了證明 UX 很重要，硬把所有成果都算成營收。文章其實特別提醒，重點不是誇大 UX 的貢獻，而是把原本就存在的關係找出來。

我的延伸思考

1. 如果一個功能真的變好用了，但 Business Metric 沒有改善，代表 UX 沒價值嗎？

我覺得不能直接這樣判斷。

例如我們改善一個註冊流程，Task Success Rate 明顯提高，但最後註冊率沒有增加，可能不代表 UX 改善失敗，而是還有其他因素影響最後的結果，例如使用者本來就沒有足夠的註冊動機、流量來源不同，甚至產品本身的價值還沒有被說清楚。

所以我覺得 UX Metric 和 Business Metric 其實不是二選一。

Upstream Metric 可以告訴我們：「我們是不是解決了原本的使用問題？」Downstream Metric則進一步告訴我們：「解決這個問題之後，有沒有真的影響商業結果？」

兩個都看，才比較容易知道問題到底卡在哪裡。

2. PM 在這中間應該扮演什麼角色？

這讓我想到之前在上專案經理的課程，談到「量化專案的價值」。

公司主要以盈利為目的，如果大家關注的價值都以「盈利」來衡量，就可以依此來判斷優先順序

盈利是提升收入，降低成本。但是大家所定義的價值都不同，就無法達成一樣的共識。所以了解公司哪些 KPI 對於 營收提升、成本下降 有關係。

我覺得 PM 很重要的一件事，就是在功能開始之前，先把「UX 改善」和「Business Outcome」接起來，而不是上線之後才想辦法找一個數字證明它有效。

例如我們今天想改善會員限定文章的登入流程，不能只定義成「登入介面要更好用」，而是可以先把假設寫清楚：

使用者目前看不懂文章價值 → 不願意點登入／註冊 → 如果讓價值更清楚，登入／註冊轉換率可能提升。

這樣 UX 就知道需要觀察使用者在哪裡卡住，PM 也知道上線後要追哪些數字。

換句話說，我覺得 PM 要做的不是把 UX 的成果「翻譯」成商業話術，而是在一開始就讓 UX 問題和產品目標有連結。