作爲一個體驗設計師，我們會面臨很多問題：複雜的產品需求、糾纏的技術邏輯、難以決策的設計方案、難以計量的設計價值。

而對於面對橫跨 IaaS, PaaS, SaaS 幾百款產品的阿里雲設計師，問題更具挑戰性，但也更具備機會。我們面臨着龐大的產品體系，也就意味着充足的實踐空間；我們面對着複雜的設計問題，也就意味着全面的經驗沉澱。因此，如何在支撐業務的同時創造機會，讓設計在行業中釋放出更大的能量和價值，就成爲了我們的使命。

我們意識到，對於一個複雜的產品系統，體驗設計師不應僅是體驗的微觀設計者，也應是體驗的宏觀管理者。但體驗是一個過於寬泛和宏大的詞，而我們專注於其中和設計師最緊密也最攸關的部分：產品的使用體驗，即用戶在產品使用場景中完成期望目標時所產生的體驗。這是用戶和產品直接接觸的部分，也是最有感知的部分。

而這篇文章，就是爲您分享阿里雲設計中心建立的阿里雲產品使用體驗度量系統 – UES。

UES 是什麼？

UES（User Experience System）是阿里雲設計中心通過多年設計實踐中沉澱下來的雲產品使用體驗度量系統，它不僅是一套方法論，更是一套可運行的體系，由三大部分有機構成：

• 一個包含五大維度的 UES 體驗度量模型。
• 一個體驗問題從發現到閉環的體驗管理機制。
• 一個易用性測試和數字化管理的體驗工具集。

通過 UES，我們度量、我們監測、我們改進。我們希望打造雲計算領域第一個系統化、工具化的產品使用體驗管理體系，並致力於將它開放給更多行業的設計師所用。

但羅馬不是一天建成的，憑空出現的大廈要麼是海市蜃樓，要麼是空中樓閣，而對於任何不斷進化的複雜系統，科學的推理過程，往往比暫時的結果更有價值。因此這回，我們不直接給你結果，而是把故事從頭說起。

1. 無度量，無管理

我們如何管理體驗？現代管理學之父，彼得·德魯克說：「如果你不能很好地度量它，也就無法有效地管理它。」

If you can’t measure it, you can’t manage it。
Druker

現代商業社會本質上是建立在數字交換上的社會，生產、購買、售賣、投資、貿易，新的價值在勞動中產生，又被一次次計量和轉換爲新的形態。如果用戶體驗不能被度量，就註定難以融入到這個數字構成的生產和管理體系中。因此，我們做的第一件事情，便是尋找一個和用戶體驗關聯的商業產品核心度量指標。

我們發掘的第一個指標，是 NPS：Net Promoter Score，淨推薦值。

但這個過程並非一帆風順，硬核的阿里雲產品從來都是技術導向，對用戶體驗的感知度不像 C 端產品那麼強烈，更難引起重視。我們決定先在小範圍的產品進行切入。2016 年 10 月起，我們首先從雲安全的產品入手，一步步去推進 NPS 度量，去建立體驗心智。同時，在 NPS 的問卷中，我們加入更細緻的滿意度問卷，讓用戶更好地反饋，對體驗問題進行深入洞察。

設計中心的持續推動，讓 NPS 開始被產品的管理者所認可和重視。那些不確定的用戶體驗，開始轉化爲確定的淨推薦值和大量的體驗問題反饋，給產品改進帶來實實在在的指引，進而又讓產品更加重視對用戶體驗的管理。體驗和產品的故事，從此走向了一個良好的正循環。而過去一年，NPS 已經從一個設計發掘的體驗數值，變成了大量雲產品的核心指標，而從這些舉足輕重的產品中，我們發現並改進上百個用戶體驗問題。

但對於設計師來說，度量用戶體驗的命題卻遠未得到解決。NPS 更多側重在用戶的綜合評價上，包含產品價格、安全性、穩定性等綜合因素，用戶體驗的要素被掩蓋在這些複雜的「變量」中難以剝離。

而控制和分離變量，是一個科學的度量系統最基本的要求。於是，我們的設計師又開始了新一輪的研究和測試，以尋找一個更合適的用戶體驗度量方法，去回答一個最基本的問題：

2. 我的產品使用體驗，好嗎？

要回答這個問題，首先要回答的是：什麼因素會影響產品使用體驗？

1989年，在技術接受模型( Technology Acceptance Model，TAM )中，Davis 指出了兩個影響技術類產品使用的核心因素：「有用性（usefulness）」和「易用性（ease of use）」。「有用性」更多是產品能力本身層面的屬性，關乎功能和商業，而「易用性」則是設計師能把握和發力的核心，因此，我們決定聚焦「易用性」，作爲撬動中後臺技術產品使用體驗的槓桿。

那，如何度量易用性呢？

通過對計算機系統可用性問卷（computer system usability questionnaire，CSUQ）、用戶界面滿意度問卷（Questionnaire for User Interface Satisfaction，QUIS）、網站分析和測量問卷（WAMMI）、系統可用性量表（System usability scale，SUS）等 15 個經過廣泛應用的體驗度量方法進行分析和驗證，並基於測試難度和置信區間進行綜合評估，最終我們得出結論：

並沒有一個合適的易用性量表。

這些量表雖然久經考驗，但它們都不是爲互聯網時代和雲產品體系而生。以 SUS 量表爲例，John Brooke 在 1986 年編制它的時候，喬布斯剛剛離開蘋果創建 NeXT ，距離中國第一封電子郵件發出還有一年。它也並非爲中文而設計，其中的第8題：「我發現這個系統使用起來非常笨拙(cumbersome)。」在實際測試時讓用戶十分困惑，因爲在中文語境中，很少有人會用「笨拙」這個詞去形容一個軟件系統，但你又很難找到一個更合適的詞彙去覆蓋它的本意。

因此，與其墨守成規地去套用一個過時的量表，我們決定去粕取精，去設計一個適合我們自己的量表。在15個易用性問卷中，我們抽取合併出30個典型問題，並走訪客戶和用戶研究專家，讓他們選擇這30個問題中最關心和認爲最重要的問題，以此確定一個12題版的標準問卷，以及6題版的核心問卷。我們把這套度量表，命名爲：

3. 易用性度量量表

Product ease of use metric, PEM

問卷有了，但這個問卷的有效度，值得被信賴嗎？

在進行了一段時間的實驗室測試後，我們對收集到的樣本數據進行了一次信度分析，在最常用也是最準確的科隆巴赫 α 係數分析中，我們的評分甚至優於 SUS 等傳統量表的信度。而更關鍵的是，有了高置信度的量表，我們不再需要成百上千的測試數，而是達到十幾個樣本即可。這對許多需要用戶基數比較少和測試難度高的技術產品無疑至關重要。

整體量表值得信賴還不夠，我們又進一步進行了探索性因素分析，以驗證我們的問卷是否能有效地將 12 個變量綜合爲 3 個核心因子，它們分別是：

• 易操作性：反映產品是否易操作，與用戶的操作效率和任務完成率密切相關。
• 易學性：反映產品是否易於學習，衡量其學習成本與上手難度。

易見性（清晰性）：反映產品的感知清晰性，關乎其信息展示、結構佈局和功能入口等方面。

而通過 KMO 和 Bartlett 的檢驗，發現易用性量表非常適合進行因子分析，結果具有顯著性，且量表 3 個維度項目的因子載荷係數符合易用性預設的專業維度，綜合說明易用性量表具有較高效度水平。

如果以上統計分析過於拗口的話，用人話說就是：

「易用性度量量表，你值得信賴。」

驗證了置信度後，我們立刻想到，那易用性 PEM 評分，和 NPS 是否有關聯呢？而對樣本數據的統計分析後，易用性和 NPS 被認爲是：強正相關。

這意味着，產品易用性和產品淨推薦值中存在着一道隱形的橋樑，在理論上，我們能間接驗證體驗的商業價值。易用性的理論體系建立完成後，很快，我們撰寫了一份易用性度量的規範指南，包含「任務制定-用戶招募-易用性測試評分-統計分析-度量報告-問題解決」的整個測試閉環流程，以幫助易用性測試的標準化執行。

但更重要的是機制。我們成立了易用性小組，組織產品易用性測試專場，以保障測試工作的有序開展。在這個過程中，業務方真切地觀察到用戶的行爲，聽到了用戶的聲音，也瞭解了產品體驗的重要性和體驗度量的專業方法。這時的易用性度量就不再僅是一場專業的研究行爲，也是一次潛移默化間，不同團隊和角色互相理解和信任的關係建構。

4. 由點到面：阿里雲體驗度量系統 UES

有了易用性測試的成功爲基礎，我們便有了更多的信心，去探索更全面的雲產品體驗度量系統。而這，就是回到了我們前面說的，阿里雲產品使用體驗度量系統：UES（User Experience System）。

易用性描述了產品體驗的一個重要維度，但不是唯一。交互和視覺設計是否一致、頁面渲染和API調用是否快捷，這些或主觀或客觀的因素都會綜合影響用戶體驗。

和易用性的思路一樣，我們也不機械套用已有的模型。適合網站的 PLUSE、谷歌的 HEART、螞蟻的 TECHP，它們各有切入點，也各有其適應場景。方法雖無法窮盡，思維卻可以歸納。我們發現，無論模型怎麼變化，表達產品體驗的重要度量指標，總逃不開這三個範圍：用戶態度、用戶行爲、系統表現。

於是我們根據 B 類技術產品特性，在多個維度中評估和挑選，重新思考定製，設計了 UES 模型的五個維度：

易用性 – Ease of use

易⽤性是產品使用質量的核心維度，它反應產品對⽤戶而言是否易於學習和使用，包含易學性、易操作性和清晰性3個維度。易⽤性的提升可以促進操作效率和任務完成率的提升、降低學習成本、提升⽤戶體驗和滿意度。

一致性 – Consistency

一致性指多款產品間通用範式部分的一致程度，分爲整體樣式、通用框架和常用場景及組件等維度。對於⽤戶⽽⾔，體驗⼀致性的提⾼可以降低⽤戶的操作時⻓及錯誤率，降低學習成本，提升⽤戶的滿意度；對於產品設計及開發者⽽⾔，保持體驗⼀致性可以提升開發效能，產品模塊的可集成性、穩定性和可延續性更⾼。

滿意度 – Happiness

滿意度反映着用戶對產品或服務的期望被滿足的程度，這個指標一定程度上會反映用戶再次使用和對產品進行推薦的程度。

任務效率 – Task Success

任務效率包含任務完成率和任務完成時間，雲產品的任務鏈路相對複雜，針對有明確任務或有固定使用流程的產品，通過比對用戶路徑和產品設計的理想路徑之間的差異，能夠幫助我們發現產品流程設計上的問題。

性能 – Performance

監控性能的指標有很多，其中最影響用戶感知的指標是首屏渲染時間（FMP），指用戶從發出請求到看到控制檯主要內容的時間。其次，還包括頁面請求響應時間、API 請求響應時間等指標。

其中，NPS 問卷中的滿意度反映產品的整體主觀體驗；一致性提供以規範爲綱的設計一致性走查和客觀計量方法；性能關注產品的體驗技術指標；任務通過 UBA 工具度量核心任務的成功率；易用性則得出產品體驗最核心的主觀指標，並輸出具體體驗問題清單，指導產品改進。

這五個維度有主觀，有客觀，有定性，有定量，我們用不同的測試方法和工具適應不同的測試指標，以期實現對一個產品各方位體驗的完整度量。這套模型還在不斷修訂和完善中，但最好的模型，不是一個完美的模型，而是一個在業務中應用的模型。

在模型階段性成熟後，我們立即開始了在業務工作流中的試點，從三件事情開始：

第一：促進 UES 成爲了業務線體驗管理的抓手。

基於之前 NPS 和易用性達成的良好效果，加上業務線自身對產品體驗的訴求越來越強烈，UES 推出後很快獲得了理解和認可，設計團隊與業務線聯合發起了以 UES 爲抓手的體驗改進項目，這讓 UES 能夠很快在業務產品中實際跑起來，獲取到真實的體驗數據和改進反饋。

第二：推動 UES 加入到產品商業化發佈流程。

在阿里雲，一款產品的真正發佈需要經過立項、研發、線上運行的層層篩選。而加入其中，意味着 UES 固化成爲了產品發佈的質量標準，背後是對公司從戰略層面對體驗的認可，也是對設計團隊之前所有體驗度量研究工作的認同與信任。

第三：打造核心產品的 UES 體驗改進最佳實踐。

雲服務器 ECS 無疑是阿里雲最核心的產品，爲中國 80% 的創新企業提供彈性可伸縮的計算資源。我們選擇從 ECS 入手，不僅僅因爲它是最核心的產品，更因爲它是極其龐大和複雜的系統，如果能完成 ECS 的 UES 體驗度量，意味着我們就能覆蓋絕大多數的產品系統。

實踐也證明了 UES 的有效性，在第一輪的測試後，我們獲取了 ECS 的體驗基線，優化了控制檯整體樣式一致性，針對易用性收集到的嚴重影響用戶體驗的問題，優化重點鏈路的使用體驗和文案的易理解性。

幾個月後第二次測試，ECS 的各項 UES 指標都有不同程度的提升，且 NPS 評分也維持到了較高區間。更關鍵的是，大量過去不受重視的體驗問題得以曝光和修復，並反映到了實際的體驗分增長中。這三件事情確保了 UES 在阿里雲商業化產品體系中順利和可持續的運轉，但這，還遠遠不夠。

5. 由面到體：體驗數字化管理平臺

各維度的數據指標產生後，很快我們就意識到，我們亟需一個「數字化管理平臺」來對這些數據進行統一的查看和管理，並保證洞察結果能夠改進落地。建平臺本身不是目的，但需要建立好工具和平臺，體驗管理才實現標準化和規模化。

而一個我們需要的阿里雲體驗數字化管理平臺，至少應該滿足3個要求：

第一：聚合體驗數據。

它需要能夠對所有的體驗數據做一站式的便捷化管理，經過UES標準的數據模型和加權，將5個維度的度量分形成「體驗分」呈現給產品PD。

第二：閉環體驗問題。

針對在各維度測試環節中提出的體驗問題，包括體驗設計、功能開發、前端、文案4個類型，需要能方便進行實時的跟蹤與修復，幫助體驗問題從「洞察」到「閉環」。

第三：實時體驗管理。

最後，它能夠支持完成單個產品內多次度量的自我比較，明確體驗改進的效果，爲產品規劃提供輔助決策。

基於以上三個目標，我們設計並在雲知（阿里雲數字化產品管理系統）集成了 UES 的體驗度量看板，讓 PD 可以隨時查看目前產品使用體驗的水位，瞭解產品體驗的薄弱項，跟進體驗問題改進。

△  圖片中所有數據僅示意，非真實數據

除了「看」的整合，更關鍵的是「做」的提效。

對於 UES 中最核心也最複雜的易用性測試，雖然我們有了完整的行動指南，但依然需要大量的學習、培訓成本，難以適應集中爆發的大量產品測試需求。

於是易用性測試工具 – Etest 應運而生。

Etest 是一個在線化、智能化的易用性測試工具。收到邀請參加易用性測試的用戶，能通過Etest完成在線遠程測試的，完成測試任務並提交對產品的體驗反饋、爲設計師提供多維數據分析。同時，Etest 能幫助每個產品的易用性測試節約大量的人力時間成本和差旅產生的費用。

△ 圖片中所有數據僅示意，非真實數據

年初的疫情，讓客戶現場拜訪和調研的活動都無法正常開展，而 Etest 恰好解決了這個問題。我們通過 Etest 完成了超過 100 名用戶的遠程測試，保證了產品體驗改進工作的持續開展。

5. 思考未來：從開始到開始

從 2016 年初探 NPS，到 2018 年開始深耕易用性，到 2020 年，基於 UES 的雲產品數字化管理系統初步建成和工具化，我們從一個開始到另一個開始，此時在做的工作很多，彼時要做的工作更多。但我們依然在思考，下一個「更大的問題」是什麼？

最初，我們希望度量「雲產品」的用戶體驗，未來我們能否度量「產品」的用戶體驗？最初，我們希望解決「阿里雲設計師」的問題，未來我們能否解決「設計師」的問題？或者更遠一點。

既然雲計算把計算資源雲化，讓千百萬沒有能力建設數據中心的企業獲得彈性的海量資源；若設計也可以雲化、體驗可以度量，那我們是否能讓千百萬沒有設計能力和團隊的企業，能更低成本地獲得好的用戶體驗，進而提升整個社會的平均產品設計水平？

這是一個看上去還虛無縹緲的願景，但我們有兩件事情，正在開始：

第一：完善阿里雲體驗度量系統 UES，開放 Etest 易用性測試工具。

我們正在推進 UES 模型的進一步迭代完善，並將在 2020 年內全面開放 Etest 工具，目前產品核心功能剛剛孵化成型，還在持續生長和進化，以讓我們有能力服務於阿里雲體系外更廣泛的應用場景。

第二：建設「體驗度量」的國家團體標準。

雲計算行業有 33 項國家標準，卻沒有一個設計標準；而過去一年，阿里雲設計中心起草併發布了 2 項雲產品體驗度量的國家團體標準：《雲計算軟件產品易用性度量方法》團體標準和《雲計算軟件產品使用體驗度量模型及方法》團體標準。

形成標準的目的，是把我們一整套的體驗度量和實踐經驗，「開源」給整個行業，這樣才能激發出更多的團體標準、企業標準、國家標準，進而促進設計產業的工程化發展。

而這兩件小事，也是我們對未來的希冀：

• 面向產品，提供體驗度量模型、優化策略、管理和能力工具，幫助產品帶來市場競爭力的提升；
• 面向客戶/用戶，爲用戶提供最佳產品體驗，促進客戶滿意度提升，幫助營收增長；
• 面向生態夥伴，通過輸出行業標準，爲阿里雲產品和解決方案提升專業度和信任，爲生態夥伴提效賦能。

以上這些，似乎是遠方遙不可及的終點，但也是作爲設計師，支撐我們在體驗度量這條路上，求索和探尋至今，最初的起點和初心。體驗的量化與管理，是我們爲了構建雲上美好生態的方法與工具，我們起步於此、執着於此，也不會止步於此。

最後，關於「體驗度量」的話題，期待和你一起交流，一同進步。

歡迎關注「AlibabaDesign」的微信公衆號：