原文：How to Get Research Recommendations on the Roadmap

做 UX Research 最挫折的事情之一，大概就是花了好幾週做研究、訪談、整理洞察，大家開會時也都點頭說「這個很重要」，結果過一陣子再看 Roadmap，完全沒有它的身影。

在進入正題之前，先簡單講一下 Roadmap 是什麼
Roadmap 可以把它想成產品接下來一段時間的「方向與優先順序地圖」。它不只是把所有想做的功能排成清單，而是幫團隊回答：接下來我們最重要的是什麼？為什麼先做這些？資源要放在哪裡？
例如一個產品可能同時有「改善註冊流程」、「增加搜尋功能」、「修正技術問題」、「開發新的會員功能」等很多事情，但工程和設計資源有限，不可能全部一起做。Roadmap 的功用，就是讓團隊根據產品目標、使用者需求、商業價值、風險與開發成本等條件，決定哪些事情要先做、哪些可以晚一點做。

所以一個研究建議「有沒有進 Roadmap」，其實某種程度也代表：團隊有沒有願意把有限的時間和資源分給這個問題。而且研究要在對的時間進來，而且要能進入產品決策。很多時候不是 PM 不在乎使用者，而是等 UX 拿著完整研究報告出現時，方向早就已經決定一半了。

想影響 Roadmap，第一件事不是做研究，而是先知道 Roadmap 什麼時候被決定

很多 Designer 或 Researcher 甚至不知道公司的 Roadmap 到底什麼時候排。等到某天收到一份 Confluence 文件，才發現下一季要做什麼都已經列好了。
但如果 Roadmap 已經排完，這時候再拿研究結果進去說「使用者其實更需要另外一個功能」，要改動的就不只是一個功能，而是整套已經排好的資源和承諾。
所以真正想影響 Roadmap，不能只參加最後的 Handoff，而是要更早加入那些「大家還不知道答案」的討論。
例如問題還在定義、Solution 還沒決定的 Discovery 階段。
因為一旦大家已經開始討論「按鈕放哪裡」、「這個功能怎麼做」，其實很多更上游的問題早就默默被定案了。

在提出新東西之前，先理解 Roadmap 上原本那些東西為什麼存在

另一個我覺得很容易被忽略的地方是：當我們說「這件事情很重要，應該排進去」時，其實也等於在說：「那 Roadmap 上有一件事情要往後排。」
所以不能只知道自己的研究結果有多重要，也要理解 PM 現在手上有哪些限制。
有些事情本來就很難動，例如主管要求、合約承諾、法規 Deadline。這時候一直要求把自己的項目插進去，反而容易讓人覺得沒有理解整體商業情境。
但也有一些 Roadmap Item 沒有那麼牢固，可能只是半年前覺得「好像應該做」，所以一直留在上面。這些地方反而比較有討論空間。
甚至最好的情況不是「我的需求取代你的需求」，而是找到研究結果和既有 Roadmap 可以一起解決的地方。

不要只跟 PM 說「使用者覺得不好用」

這可能是整篇最直接的一段。假設 UX 做完研究後告訴 PM：「使用者看不懂這個 Navigation。」
這是一個很好的 Finding。但對 PM 來說，接下來還有很多問題：所以呢？影響多少人？有多嚴重？跟這季目標有什麼關係？我要為了這件事把哪一個功能延後？
如果全部都要 PM 自己把研究結果翻譯成 Roadmap 決策，那在一堆優先事項裡，這件事情真的很容易就被放掉。

所以研究結果最好再往前一步。例如：「使用者在 Navigation 找不到下一步，我們懷疑這跟第三步的流失有關，建議先測試一個新的資訊架構。」前者只是告訴 PM「有問題」。後者則同時告訴他：**問題是什麼 → 可能影響什麼 → 接下來可以做什麼。**這時候研究就比較容易變成可以被採取行動的資訊。

UX 也要懂 PM 到底在被什麼指標追著跑

之前的文章也提到「UX 不要只報告 UX Metrics，要連到 Business Outcome」，這篇其實又再次呼應同一件事情。
如果 PM 這一季被追的是 Activation，而研究結果可以指出：「使用者其實在 Onboarding 第三步就開始大量流失」，這件事就不再只是 UX 說「體驗不好」，而是直接跟 PM 的目標連在一起。
可能是 Retention、Conversion、Support Volume，也可能是其他產品指標。
UX 不一定要把所有東西硬換算成營收，但至少要知道：「我發現的這個問題，跟團隊現在正在努力改善的事情有什麼關係？」
當兩件事情連起來，Research 就比較容易從「UX 想改善的問題」，變成「產品團隊需要一起解決的問題」。

研究做得再完整，出現得太晚還是沒有用

這篇有一句我滿喜歡的概念：一份 5 人的 Usability Study，如果在 Planning 前兩週給出關鍵洞察，可能比一份 20 人研究、但在 Planning 結束兩週後才出現更有價值。不是因為 5 人研究比較好。而是**研究的價值除了品質，還包含時機。**假設九月要做下一季規劃，那真正有用的 Research 應該八月就準備好，而不是十月才端出一份很完整的報告。這也讓我重新想到研究和產品開發的關係。
以前可能會把 Research 想成：「把研究做好 → 做成報告 → 分享給大家。」但如果研究真的要影響產品，更像是：「接下來要做什麼決策 → 在決策之前需要知道什麼 → 研究能不能在那之前提供答案？」這個順序其實差很多。

如果研究一直被忽略，也不一定是研究做得不夠好

研究沒有被採用時，很容易第一個反應是：「那我再補更多資料。」但這篇提醒了一件滿重要的事：先搞清楚問題到底出在哪裡。
可能只是 Timing 不對，也可能研究沒有連到團隊現在真正的問題。還有一種比較麻煩的情況，是研究結果和某個人早就做好的決定衝突。如果是最後一種，那再做一次 Research 可能也沒有用。因為這已經不是 Data 的問題，而是決策方式的問題。誰有決定權？團隊允不允許挑戰已經做出的決定？大家真的願意讓研究改變方向嗎？這些問題雖然比較難談，但至少比一直做更多研究，然後期待下一次大家突然會聽更有意義。

好的 Recommendation 還要知道「做不做得到」

另一個是 Engineering Feasibility。假設研究真的找到一個很重要的問題，也提出一個很棒的改善方向，但進 Planning Meeting 後工程師第一次聽到，直接說：「這個至少要半年。」那它很可能馬上被放掉。

所以如果真的希望建議進 Roadmap，在正式提案之前，可以先跟工程確認大概需要多少成本，也先了解 Legal、Data、Marketing 等其他可能被影響的地方。不一定需要非常精準的 Estimate，但至少要知道：這是一個兩週的小實驗，還是一個半年專案？因為當一個 Proposal 同時有使用者證據、商業影響，又大概知道實作成本，它才真的開始變成可以被排序的東西。

最後，其實不是怎麼把 UX 塞進 Roadmap

文章最後的觀點，我覺得反而是整篇最重要的。如果 UX 一直把自己的角色想成：「我負責研究，然後把研究結果交出去。」那很多時候工作做到 Report 就結束了。但如果把自己的角色想成：**「我要幫助團隊做出更好的產品決策。」**思考方式就會完全不一樣。

會開始注意 Roadmap 什麼時候排、PM 在意哪些指標、Engineering 有什麼限制、這份 Research 要在什麼時間點出現，以及最後應該提出什麼 Recommendation。研究本身還是很重要。只是「研究做完」跟「研究真的產生影響」，其實是兩件不同的事情。

我的延伸思考

1. UX Research 應該回答「使用者怎麼了」，還是「我們接下來該做什麼」？

我覺得兩個都需要，但責任不一定全部落在 Researcher 身上。Research 最重要的價值還是把使用者真實的問題找出來，不能為了讓研究「好賣」，就直接跳到自己喜歡的 Solution。但如果永遠只停在「我們發現使用者很困惑」，確實又很容易離產品決策太遠。所以我覺得比較合理的方式是：Finding 和 Recommendation 分開。先講清楚我們知道了什麼，再說「根據目前證據，我建議下一步驗證什麼」。這樣既不會把研究結果和解法混在一起，也不會把所有判斷工作全部丟給 PM。

2. 如果團隊根本沒有 UX，PM 自己就要兼 UX 呢？

看這篇的時候，我也想到另一種很常見的情況：有些團隊根本沒有專職的 UX Researcher 或 UX Designer，使用者研究、需求訪談、問題定義，甚至簡單的流程規劃，最後都落在 PM 身上。
這時候文章裡講的「讓 UX 更早加入 Discovery」就不能照字面理解了，因為根本沒有另一個 UX 可以加入。反而變成 PM 要提醒自己：不要因為「我是排 Roadmap 的人」，就直接跳過研究，從需求一路做到 Solution。

例如收到一句：「我們希望提高會員登入率。」
如果同時兼 UX 的 PM 很忙，很容易直接想到：「那我們是不是做一個更明顯的登入 Popup？」接著寫規格、找工程估時，最後把它排進 Roadmap。但這樣其實已經直接跳到解法了。
如果往前多走一步，可以先問：使用者為什麼不登入？是根本沒有登入需求？不知道登入後有什麼好處？流程太麻煩？還是內容本身還沒有讓他覺得值得登入？
這時候即使沒有完整的 UX Research 資源，也可以做一些比較輕量的 Discovery。看看 GA4 Funnel、客服回饋、使用者留言，甚至找 3～5 位使用者聊聊，都可能比直接開始畫 Solution 多得到很多資訊。

我覺得 PM 兼 UX 最容易遇到的問題，是自己同時是提出假設的人，也是決定要不要做的人。今天我認為某個功能很好，很容易在研究時也一直尋找支持自己的證據。所以這種團隊反而更需要刻意把幾個東西拆開：先寫下「我們目前知道什麼」，再寫「我們猜測什麼」，最後才是「所以我們想測什麼」。
例如：「目前知道：很多未登入使用者到了影片頁卻沒有播放。」「我們猜測：使用者還沒感受到影片價值，所以不願意登入。」「想驗證：如果先提供 30 秒 Preview，登入／註冊率會不會提高？」
這樣即使 PM 同時兼 UX，也比較不容易從「我想到一個功能」直接跳成「所以這個功能應該進 Roadmap」。所以我覺得，沒有 UX Team 並不代表不能做 User-centered Product。只是 PM 要多戴一頂帽子，而且要一直提醒自己：Roadmap 裡放的應該是經過判斷後值得解決的問題，而不是自己最先想到的 Solution。

3. 如果 Roadmap 已經很滿，UX 改善是不是永遠排不到？

這也是我覺得很現實的問題。Accessibility、Usability 這種項目很容易輸給新功能，因為沒有 Sales 在後面追，也不一定能直接帶來新的營收。但換一個角度，它其實可能是在處理 Risk 或 Usability Debt。一個難用的流程如果每年都繼續疊新功能上去，最後可能變成每次改東西都需要更多設計、開發和客服成本。所以 UX 改善不一定只能用「這樣比較好用」去爭取。也可以問： 「如果我們今年不處理，這個問題半年後會變得更便宜，還是更貴？」 如果答案是越來越貴，那它其實就已經是一個 Roadmap 的風險問題，而不只是設計品質問題。

最後

看完這篇之後，我最大的感受是：好的 UX Research 不只是找到更多洞察，而是**在團隊還能做決定的時候，提供剛好能幫助決策的資訊。**做得早一點、了解 Roadmap 背後的限制、知道 PM 在意什麼、把 Findings 變成可以討論的 Recommendation，再提前了解實作成本。這些事情聽起來好像已經超出「做 UX」的範圍，但也正是研究真正能影響產品的地方。也許真正成熟的 UX，不只是問：「使用者需要什麼？」還會再多問一句：「我要怎麼讓這個需求真的進入產品決策？」