在過去兩年時間里，我們探索了一套適合工具型產品的體驗度量模型理論體系，并在多個工具產品中實踐，獲得了正向的結果。

本文將從工具產品度量模型搭建和行為度量手段兩個方面，重點闡述設計思路和具體做法，希望對做工具產品的體驗設計師有一些幫助。

一、工具體驗度量模型搭建

1. 工具產品特征

使用酷家樂工具有多種類型的設計師用戶，因其使用目標不同會導致使用工具的流程不同。如果是一個定制設計師，他首先要從戶型開始、然后去定制、再到軟裝最后去渲染，才能完成一個定制柜的方案設計。

在整個使用流程中有多個設計任務，如果到了一個設計衣柜的階段，他的設計行為從置入框架開始，再添加隔板、配件、抽屜、門板最后進行全局替換才能完成一個衣柜的設計。然而不同的用戶設計習慣不同，設計行為的順序也不同。

為此工具產品呈現兩個特征：一、用戶類型多樣、用戶目標差異大；二、用戶使用流程長，設計任務多，設計行為自由且無序。

在工具產品設計開發階段，經常需要足夠了解用戶的意圖和行為，才能輔助體驗設計師做判斷和決策。為此我們成立了項目組，開啟了工具產品體驗度量模型的探索。

2. 項目定位

項目初衷

• 希望建立一套更加嚴謹的體系和方法來洞察用戶意圖和行為，同時還能監測工具產品體驗變化及趨勢
• 其次更希望從發現問題到優化問題后不斷迭代，最后通過產品體驗的提升，提高產品的競爭力或達成產品目標、商業目標

再結合公司的現狀（以業務目標為導向劃分資源）沒辦法通過管理手段解決產品體驗問題，導致設計師在解決體驗問題時，會因為優先級不高沒辦法獲取開發資源。

于是對項目的定位是：工具體驗度量是協助業務解決體驗問題（影響業務指標的核心問題）的工具，并非通過自上而下的管理手段解決體驗問題，這個定位需要更精準的找到價值更高的優化點。

3. 搭建工具度量模型

我們從用戶感知層、行為層到反思層拆解多維度的指標。分別從可用性測試、行為數據和態度數據三種手段，采集用戶定量和定性的數據，搭建了一套多種度量手段和多維數據類型的度量模型。同時也為了更好的執行模型定義了度量標準規范，提供了使用的工具和實踐案例。

多種度量手段

• 態度度量：主要采集用戶的態度數據，核心指標是NPS和NSS，通常會用NSS來評估工具多個模塊用戶滿意度，NPS是整體產品體驗的北極星指標
• 可用性測試：通過定義一個用戶大目標，拆解多個任務邀請用戶測試觀摩用戶使用過程發現問題，會根據NSS的不同模塊滿意度低的因子，來繼續做定性的調研
• 行為度量：對工具進行行為數據的埋點采集，用大數據分析來了解用戶的行為一起判斷是否存在體驗問題，定義的路徑可以與可用性測試的任務一致，來結合做定量的分析

度量手段標準化和工具化

• 度量手段標準規范：讓執行模型的人可以更好的理解和實踐，同時也能保證指標口徑的一致性和橫向可對比
• 度量手段工具化：讓體驗問題指標化、可視化，也能通過看板看到長期的變化，同時也方便大家理解和使用

4. 尋找機會點和切入點

機會點：通過用戶調研和用戶數據分析手段挖掘產品體驗問題，找到影響產品體驗和業務指標增長的機會點，再對數據指標進行監控持續不斷的優化達成業務目標

切入點：從用戶使用路徑角度拆解產品功能，用戶使用產品的路徑作為一個最小度量單元

• 產品由很多個功能組合成的，而用戶的使用路徑串聯了多個功能
• 工具的體驗是否友好，可以監測工具的核心路徑的體驗指標，判斷體驗的好壞
• 還可以通過多個核心路徑的體驗指標去關聯產品指標，通過不斷的產品優化觀察產品指標的變化

基于項目是要達成產品目標，切入的方式是對用戶使用路徑的數據監測，下面重點介紹行為度量的實踐方法

二、行為度量：用戶行為數據進行體驗度量

1. 指標設計和定義

有了路徑作度量單元，又如何衡量一條路徑體驗好壞呢？于是我們開始從用戶完成一個任務的角度思考。這個路徑的入口用戶可以找到嗎？用戶可以完成嗎？使用的過程是否遇到問題，完成的使用效率怎么樣。

定義了兩種和體驗強相關的指標：可用性和使用效率指標

• 可用性是衡量用戶是否能完成任務的基礎指標
• 使用效率是在完成任務的基礎上從時間和步驟的角度看路徑是否高效的高階指標

可用性指標有三個：觸達率、任務完成率、跳出率

• 觸達率：表示多少用戶進入了定義路徑的起點，是衡量入口可見的指標
• 任務完成率：表示用戶在預設路徑中是否能友好地完成整條路徑，是衡量路徑可用性是否良好的核心指標
• 跳出率：是分析定義路徑中所有觸點的指標，可以查看定義路徑中任一觸點跳出的用戶數，用來分析影響路徑完成的問題觸點

效率指標有兩個：任務完成時間、任務完成步驟

• 任務完成時間：用戶在任務完成時，所花費的時間，從進入路徑到最后完成路徑過程中消耗的時間
• 任務完成步驟：用戶在任務完成時，所需要的步驟，從進入路徑到最后完成路徑過程中消耗的步驟（有效點擊事件個數）

2. 指標分析緯度和使用場景

全量可交叉分析的維度說明

從指標定義角度，拆解了指標可交叉分析的緯度，提供使用指標的分析思路。全量可以從相似路徑（相同使用目的路徑）、用戶類型、時間角度（優化前后）進行交叉對比分析。

基于全量可交叉分析的角度，下面枚舉了日常工作中比較常用到的分析場景

場景一：多條路徑單個指標怎么分析

• 對比相似路徑（目標相同的路徑）單個指標。例如查找模型的路徑有兩種方式：a用搜索找模型；b用類目層級找模型，對比兩條路徑任務完成率，看哪條路徑是使用量大
• 對比并列路徑（前后依賴的路徑）單個指標。例如完成一個模型的擺放有三個前后依賴的路徑：a素材面板找模型；b畫布放置模型；c在參數面板調整尺寸，可以對比任務完成率，看是哪條路徑影響了后續路徑的使用。

場景二：單條路徑多個指標對比分析

• 分析單條路徑多個指標，例如可以觀察多少用戶觸達了該路徑起點，多少用戶完成了該路徑，多少用戶從某個觸點跳出了
• 還可以繼續對完成路徑的使用效率（時間和步驟）進一步分析，判斷路徑的使用步驟影響大還是時間消耗大

場景三：多個路徑多個指標的分析

多個路徑和多個指標主要用于對路徑更加深入的分析，一般常用的使用案例有以下幾種：

• 觸達率和任務完成率結合，對多條路徑不同入口和任務完成情況的對比
• 任務完成率和跳出率結合，在多條路徑中找到影響任務完成的問題觸點分析
• 使用效率對比，多條路徑的任務完成率和任務完成步驟或時間進行分析

有了指標的定義和分析思路，如果需要大家用起來，還需要降低指標的使用難度，于是我們開始了路徑分析的工具建設。

3. 行為度量工具建設

1）困難和挑選

以路徑作為切入點，按照之前的設想，只要對工具進行全埋點的數據采集后，再進行數據分析找到工具TOPN的路徑，最后通過監測TOPN路徑的體驗指標來觀察產品體驗的變化。但是在埋點上我們遇到了全埋點實現不了和歷史埋點結構不一致的問題

工具產品全埋點的困難體現在以下幾個方面：

• 埋點成本大：用戶在場景畫布的操作頻繁，觸發事件數據量大，存儲和分析資源消費龐大
• 畫布中埋點不精準：畫布中是一個三維的海拔，采集埋點時需要識別不同海拔對應的對象，尤其3D場景下，模型發生旋轉后海拔會發生變化會導致埋點不精準
• 使用效率比較低：對于很多埋點數據，需要人工定義事件名稱和事件是否有效。例如在畫布拖動一個模型，需要詳細的定義起點和結束的行為、時間、位置

埋點結構不一致：

• 不同業務歷史埋點都是按照自己需求定義的埋點結構，如果需要跨業務分析需要統一埋點和歷史數據結構，重新定義埋點采集標準和規范。

從全埋點到核心路徑埋點

相對中后臺產品工具產品呈現一條路徑多個分叉，使用方式反反復復且無序的情況。

因為全埋點的限制，只能人工拆解工具的核心路徑，為了不漏掉用戶更多的使用行為，同時需要梳理核心路徑的多個子路徑。

指標模型化、工具化降低使用難度

基于拆解的埋點讓路徑支持自定義拼接和指標模型化，降低使用難度

• 路徑自定義：一條路徑由多個觸點組成，在使用的時候可以按需拼接即可
• 指標模型化：只要定義路徑就可以快速拉取對應的路徑指標數據

同時還兼容了用戶分群、路徑保存和數據下載等用于二次分析的功能

三、業務實踐

我們相信任何理論方法，都需要在業務實踐中達成產品目標和商業目標才能更有說服力

目前行為度量的路徑分析工具在酷家樂多個工具業務實踐，實踐案例有以下幾種：

• 在日常開發過程中監測用戶體驗：拆解工具核心行為，監測體驗指標的數據波動，來判斷產品迭代對用戶體驗是否造成損害
• 路徑分析輔助體驗設計師做決策：拆解核心操作路徑，建立數據指標監控看板，通過不斷迭代優化觀察指標的變化后調整優化思路，最終達成設計目標
• 通過路徑分析提高新用戶留存：找到新用戶任務完成率低的多條路徑，再用路徑的任務完成率關聯新用戶次周留存，建立數據看板，通過迭代優化，觀測新用戶使用哪條或哪幾條路徑后對工具有更強的探索意愿并在次周進入工具

四、最后

作為體驗設計師的我們深有感觸，在設計評審階段，評估設計方案的合理性和設計優化是否有價值上我們會遇到較大的挑戰。尤其是涉及到管理者、研發、商業和運營等非設計崗位的同事，很容易帶入自己的感受去評估設計的好壞。因為大家沒有統一知識背景，我們需要用數據做一層轉譯。同時也需要用數據傳遞出設計方案迭代的思路、方向以及當前階段的結果。

工具產品因其復雜的特性：一方面希望打造一套更嚴謹的設計方法體系，從用戶調研和用戶行為數據分析的方法定位問題，到設計方案評估階段表達設計思考的合理，最終拿到正向數據結果；另一方面希望基于業務目標的角度，通過體驗度量的手段，不斷的發現問題和解決體驗問題從而達成業務目標，來證明產品體驗對業務結果的直接價值。

同時我們也堅信工具產品體驗對用戶增長和公司商業目標有著更大價值，后續我們會在體驗指標關聯業務指標上持續嘗試工具產品增長模型的探索。

非常感謝項目組其他成員：靈雨（用戶研究員）、阿淼（數據分析師）、燎原、檸樂（開發工程師）

注：文中數據僅作為演示用途，非業務真實數據