原文：Using RAS to Guide UX Research Resource Allocation and Strategy

本文想討論的核心：不要只看研究做了多少，而要開始看研究最後帶來了什麼結果。

RAS 是什麼？簡單來說，就是看研究建議最後走了多遠

RAS 是 Recommendation-Adoption Score，可以把它理解成「研究建議採用程度」。
它想回答的問題很簡單：研究提出的建議裡，有多少價值真的傳到使用者身上？

已經真正實作的建議，代表價值已經送到使用者手上；已經確定會做、有資源、有排程，但還沒上線的建議，則算部分進展；至於只是研究報告講過，卻沒有任何後續行動的建議，就代表價值還停留在報告裡。

RAS 還會考慮建議本身的重要程度。直接影響 Task Success、Retention 或 Satisfaction 的高價值改善，權重比較高；比較像介面小細節、單獨存在時使用者可能根本不會注意到的改善，權重就比較低。這點我覺得很合理，因為「採用了 10 個小改動」不一定比「解決了一個真正影響大量使用者的問題」更有價值。

所以 RAS 真正想看的不是：「Researcher 有沒有把工作做完？」而是：「Researcher 找到的問題，最後有沒有真的影響產品？」

只看 RAS 還不夠，也要看研究是不是持續有產出

不過這篇沒有停在 RAS。
因為假設某個團隊過去的研究建議採用率很高，但最近半年根本沒什麼新的研究，那只看 RAS 也可能誤判。所以文章又加了一個指標：Recommendation Velocity。
Velocity 指的是過去三個月，平均每個月產出多少研究建議。

文章提供了一組參考門檻：平均每月 0～1 個建議可以視為 STOP，2～3 個要 CAUTION，3 個以上則可以 CONTINUE。不過這組數字不是通用標準，而是根據 Cisco 的實務經驗整理出來的起點，每個組織還是要依自己的研究規模調整。
這裡有一個我覺得很重要的提醒：不能只追求建議數量。
一個月提出兩個很重要、真的能解決使用者問題的建議，可能比提出十二個介面小修正更有價值。所以 Velocity 比較像是在確認「這個團隊跟 Research 還有沒有持續合作」，而不是把 UX Research 變成 KPI 生產線。文章也明確提醒，這個 Matrix 應該是討論的起點，而不是看到數字就自動做決策。

同樣都是 RAS 40 分，背後可能是完全不同的狀況

接下來我覺得是這篇最有意思的地方：除了看現在的 RAS，還要看 RAS Trend。也就是過去六個月，採用率到底是在往上、持平，還是一路往下。

因為兩個 Product Team 今天可能都是 RAS 40 分，但一個團隊從 20 慢慢升到 40，另一個則是從 70 一路掉到 40。表面上的分數一樣，背後代表的事情完全不同。
前者代表合作正在變好，研究開始慢慢被採用；後者則代表原本可能還有影響力，但現在研究越來越難進入產品。

所以文章最後把 Velocity + RAS Trend 放在一起，變成三種 Resource Investment Signal：STOP、CAUTION、CONTINUE。簡單來說，如果研究持續有產出，而且建議採用狀況也持續改善，就值得繼續投入；如果研究幾乎沒有產出，或提出的東西一直沒有人採用，就要重新思考是不是還值得繼續把研究資源放在這個團隊。

「研究一直沒被採用」，不一定是 Researcher 不夠好

這篇後面還有一個我覺得滿重要的觀點，就是 RAS 不只可以拿來決定資源放哪裡，也可以幫忙判斷問題到底出在哪。
例如研究本身做得很好，但 RAS 一直很低，那可能根本不是 Researcher 的問題，而是 Stakeholder 不願意採用、產品團隊根本沒有把 Research 放進決策裡。
但如果 RAS 很低，同時 Recommendation 也一直很模糊，例如只講「使用者覺得這個流程不好用」，卻沒有講清楚問題影響什麼、建議下一步怎麼做，那才比較像是需要 Coach Researcher，讓 Recommendation 更具體。
我覺得這個角度很好，因為工作上的很多問題最後很容易被變成一句：「是不是這個人能力不好？」

但 RAS 試著把問題拆開來看：到底是研究品質有問題？Stakeholder 不採用？還是這個團隊本身就沒有讓研究參與產品決策的空間？
數據不是拿來責怪人，而是幫忙找到問題到底在哪一層。

資源配置不只是「哪個團隊多派一個人」

這篇還把 RAS 延伸到 UX Researcher 的職涯與人力安排，我覺得這部分滿有意思。
如果一個 Product Team 幾乎完全不採用 Research，把一個剛入行的 Researcher 丟過去，不一定叫做「給他挑戰」。因為新人除了要學研究方法，還得同時跟一個根本不相信 Research 的環境對抗，很容易最後變成挫折甚至 Burnout。
反過來，如果一個團隊本來就很願意採用 Research，可能比較適合 Junior 或 Mid-level Researcher 累積經驗；有些採用程度普通、但開始有改善跡象的團隊，反而適合放一個很會 Stakeholder Management、Influence 和 Persuasion 的 Researcher 去推動。

所以「資源配置」不只是算誰現在有空，而是要看：這個人的能力，跟這個團隊現在的成熟程度搭不搭。

我的延伸思考

1. 如果研究建議沒有被採用，就代表這份 Research 沒有價值嗎？

我覺得不能直接這樣判斷。
有些建議沒有被採用，可能是因為技術成本太高、法規限制、商業優先順序不同，甚至只是現在不是適合執行的時機。RAS 比較適合拿來觀察一個長期 Pattern，而不是看到單一 Recommendation 沒被做，就說研究失敗。
真正值得注意的情況應該是：同一個團隊長時間累積很多研究，卻幾乎沒有任何建議被採用。
這時候才要開始問，問題到底是 Recommendation 不夠具體、研究跟產品目標沒有連起來，還是團隊根本沒有讓 Research 參與決策。
所以我覺得 RAS 的價值不是拿來評分「哪一份研究好不好」，而是幫助團隊看到：「我們是不是一直在做研究，卻沒有真的讓它產生作用？」

2. 如果團隊沒有專職 UX Researcher，PM 可以用這種概念嗎？

我覺得可以，而且不一定真的要把完整 RAS 公式搬過來。
有些團隊可能就是 PM 自己做訪談、看 GA4、整理客服回饋，再從裡面提出一些改善建議。這時候也可以定期回頭盤點：我之前透過數據或使用者研究找到的問題，最後有多少真的有往下走？
例如三個月前發現註冊流程有明顯流失，當時提出要改善價值溝通，現在是已經做了、已經排進 Roadmap，還是最後完全沒有後續？
如果每隔幾個月回頭看，發現自己一直在「找到問題」，但沒有任何東西真的進到產品，我覺得就值得思考：是不是研究做完之後，少了把 Insight 轉成 Recommendation、評估優先順序和追蹤後續的那一步。
對 PM 來說，這也是一個提醒：Research 不是找到原因就結束，而是要想辦法讓有價值的洞察真正進入產品決策。

3. 會不會為了提高 RAS，最後只敢提「容易被採用」的建議？

這是我看完後第一個會擔心的副作用。如果 RAS 變成一個很重要的績效數字，Researcher 會不會開始想：「那我不要提太難的問題，我多提一些工程很好做的小改善，採用率就會比較漂亮。」這反而會讓指標失去原本的意義。所以我覺得文章裡「Recommendation 要依價值加權」和「Matrix 只是討論起點」這兩個前提很重要。最後還是不能只看一個數字。除了「有沒有被採用」，還要一起問：「這個 Recommendation 到底解決了多重要的問題？」不然很容易從「不要只追研究產出數量」，變成另一種「只追 Recommendation Adoption 數字」。

最後

看完這篇之後，我最大的感受是：UX Research 的完成點，不應該只是 Report 交出去的那一刻。

研究做完、Insight 整理完、簡報報告完，這些都只是 Output。真正值得看的還是：它最後有沒有改變產品決策？有沒有進入 Roadmap？有沒有真的被做出來？最後使用者有沒有因此得到比較好的體驗？RAS 想做的，就是把這段原本很難量化的距離稍微變得看得見。

當然，我不覺得每個團隊都需要立刻開始算一套很完整的 RAS，但我覺得背後這個問題很值得留下來：**「我們做了這麼多研究，最後到底有多少真的走到了使用者身上？」**如果答案一直是「不知道」，那可能就是下一個值得追蹤的地方。