起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識工作經驗｜產品的設計體驗度量模型，該怎么用？
有很多同學，在產品的設計體驗度量模型常常摸不著頭腦，不知道該如何運用度量模型，或者運用哪一個度量模型。作者以度量模型的定義及其本質出發，探析如何使用度量模型，希望對你有所啟發。
很多同學一提到“度量模型”這幾個字就頭大。我也收到過不少同學關于設計體驗度量概念的問題，大多都是讓我幫忙分析幾個度量模型之間的優劣，想看看應該將哪一個模型用在自己的產品上。比如：
“可以對比分析下 SUS 和阿里云的 UES 度量模型嗎？我所在的公司主要做的是 B 端系統，請問哪個更實用？”
“螞蟻的 PTECH 模型和“兩章一分”模型，后者是否更輕量級、更適合度量技術類的工具設計？”
對于這類問題，解釋這些模型的具體用法，是治標不治本的。學知識要究其本質，我們就先看看以下這幾個度量模型的本質性問題，如果你都讀懂了，自然就會有上面這些問題的答案了。
一、體驗度量模型是什么
體驗度量模型也可以被叫做「產品體驗評估模型」或「設計質量檢測模型」等等。這類模型的使用對象通常是設計師或用戶研究團隊，其本質是一種產品設計及體驗的質量的評估工具。一套體驗度量模型的組成通常包括以下幾個部分：
1. 度量維度
即對于要度量的內容的性質定義和分類，為的是讓度量過程更具備邏輯、更全面。通常這些度量維度的英文首字母結合在一起，就是這個度量模型的名稱。
比如螞蟻集團平臺設計部 2019年提出的用于評估企業級產品體驗的度量模型 PTECH，其實是從產品的性能體驗（Performance）、任務體驗（Task success）、參與度（Engagement）、清晰度（Clarity）、滿意度（Happiness）這五個維度來對產品的設計和體驗質量做評估。這幾個單詞的首字母就組合成了「PTECH」這個模型名稱：
2. 度量方法
包括需要度量和檢測的具體內容、注意事項、操作策略和具體操作步驟、完成的指標等一系列內容。目的在于告訴設計師需要在不同的度量維度下收集哪些內容和信息，以及用什么策略和方法來做度量。
度量方法會從度量維度出發，針對每一個維度給出不同的策略和方法，并匹配對應的指標。比如我們上面說過的 PTECH 模型，除了劃分度量維度，也對每個維度下關鍵的度量內容和度量手段做了規范和定義：
3. 評分機制
評分機制并不是必備項，可以被明確而簡單的指標替代。但由于每項具體的度量內容對于產品體驗的權重和影響不同，當設計師想要對于產品整體質量有一個精準的量化認知，就需要通過數字化公式進行計算。所以一些完整性較高的度量體系都是具備評分和轉化機制的。
還是以 PTECH 模型為例，這個模型就引用了一套復雜的分數轉換和核算方法，將五個維度測量出來的內容結果轉化為數值，幫助設計師精確計算出產品的體驗分值：
這種數字計算公式和方法并不是隨隨便便拍拍腦袋就可以想出來的，其中的邏輯和推演過程比較復雜，沒有些許數學功底或是對度量模型不了解還真是不太行的。
不過也不得不說，這種高級的換算方式，不僅在確定公式的過程中增加了模型的復雜度，在使用公式計算出最終得分的過程也同樣給設計師增加了不少工作負擔。所以現在很多度量模型也會選擇避重就輕，使用更加簡單明了的指標來呈現度量結果。
比如谷歌公司的設計團隊提出的 GSM 模型，就是將結果的評估重點放在對指標的定義上，用指標來判斷設計質量的水平和標準：
看到這里你可能會有疑問：本就都是對于產品設計和體驗的質量評估，為什么要有這么多不同的模型？大家就不能使用一套統一的標準模型么？
這是因為一款產品的評估方式本來就是多維度、多方面、多標準的，對不同業務領域的產品制定和使用統一的檢驗標準，是幾乎不可能實現的理想情況。由于度量模型本身具備與產品強綁定的工具屬性，所以「拋開產品自身特點和需求談體驗度量，就是耍流氓」。
螞蟻的設計團隊就應用過 PTECH 模型和「兩章一分模型」等不同的度量方案。對于這種情況相信集團內部也曾經想努力地統一度量模型，盡量避免重復造車。但實際情況卻是，這么多條業務線和產品類型，都各自有自己的想法和訴求。所以大家最終還是各自沉淀、百花齊放，也就有了不同的評估標準和模型工具。
值得一提的是，這種各自沉淀的過程并不是完全地重復造車，而是搭建思路和經驗上的相互借鑒，取長補短，讓每個團隊都可以找到最適合自己業務的度量模型。
二、如何使用度量模型
判斷一款度量模型好不好用，其實只有一個核心的判斷原則：只有適合的，才是好用的。
同樣的道理，當你想要對產品應用度量模型來做體驗評估，也只有一個核心的使用原則：把度量模型當作工具去使用，而不是當作規則去迎合。
在實際工作中，工具和方法大多數情況下都是用來解決實際問題的，而它們的誕生也源于使用者對于這些問題的梳理和總結。你能看到的這些經典的度量模型，都是設計師們對于幾十上百個項目千錘百煉后的經驗沉淀，或多或少都會帶有一些各自的業務特性和場景屬性，因此沒有絕對的高低優劣之分。
而能夠完全適合你的產品特征、匹配你的度量需求的現成的度量模型是極少數的。這也是為什么你在借用這些模型的過程中，有時會有「不太好用」或「生拉硬套」的感覺。
因此，你可以根據你的產品特點和想要度量的內容，有目的性地、有選擇性地、部分性地對這些業內已經成熟的度量模型進行借鑒和應用。當然在你的時間和精力允許的條件下，我也鼓勵你參考這些經典案例，打磨出針對你自己產品的定制化度量模型。
所以你要做的，不是一板一眼地套用某個模型，而是發揮主觀能動性，去判斷、去篩選出真正對你的產品有用的部分，以及去學習這些模型搭建時的思考方式和工作經驗。
度量模型就再高大上、評分標準再數理化，究其根本它也只是一款評估工具。對于這款工具的應用，不要為了彰顯設計師的「工作量」或「學術專業性」而應用，也不要被這個工具限制住思考的能力。我們的核心目標是用它來發現產品的問題并找到有效的解決方案。
說了這么多，再來看看開篇的問題：SUS 和 UES 度量模型哪個更實用？你應該知道答案了吧？
專欄作家
元堯，微信公眾號：長弓小子，人人都是產品經理專欄作家。一線互聯網大廠B端體驗設計師，清華大學美術學院本碩連讀。曾負責國內最大開源組件庫Ant Design組件的設計和運營工作，目前負責國際業務線B端產品體驗設計和組件庫的搭建工作。
本文原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
判斷一款度量模型好不好用，其實只有一個核心的判斷原則：只有適合的，才是好用的。