探索工具型产品体验度量模型-行为度量理论篇

探索工具型产品体验度量模型-行为度量理论篇-经验/观点-UICN用户体验设计平台

作者：甘饴

酷家乐因其设计工具的产品属性，在过去两年时间里，我们探索出了一套适合工具型产品的体验度量模型理论体系，并在多个工具中实践获得了正向的结果。本文将从度量模型搭建和行为度量手段两个方面，重点阐述设计思路和具体做法，希望对做工具产品的体验设计师有一些帮助。

工具体验度量模型搭建

工具产品特征

使用酷家乐工具有多种类型的设计师用户，因其使用目标不同会导致使用工具的流程不同。如果是一个定制设计师，他首先要从户型开始、然后去定制、再到软装最后去渲染，才能完成一个定制柜的方案设计。

在整个使用流程中有多个设计任务，如果到了一个设计衣柜的阶段，他的设计行为从置入框架开始，再添加隔板、配件、抽屉、门板最后进行全局替换才能完成一个衣柜的设计。然而不同的用户设计习惯不同，设计行为的顺序也不同。

为此工具产品呈现两个特征：一、用户类型多样、用户目标差异大；二、用户使用流程长，设计任务多，设计行为自由且无序。

在工具产品设计开发阶段，经常需要足够了解用户的意图和行为，才能辅助体验设计师做判断和决策。为此我们成立了项目组，开启了工具产品体验度量模型的探索。

• 希望建立一套更加严谨的体系和方法来洞察用户意图和行为，同时还能监测工具产品体验变化及趋势
• 其次更希望从发现问题到优化问题后不断迭代，最后通过产品体验的提升，提高产品的竞争力或达成产品目标、商业目标

再结合公司的现状（以业务目标为导向划分资源）没办法通过管理手段解决产品体验问题，导致设计师在解决体验问题时，会因为优先级不高没办法获取开发资源。

于是对项目的定位是：工具体验度量是协助业务解决体验问题，并非通过自上而下的管理手段解决体验问题

搭建工具度量模型

我们从用户感知层、行为层到反思层拆解多纬度的指标。分别从可用性测试、行为数据和态度数据三种手段，采集用户定量和定性的数据，搭建了一套多种度量手段和多维数据类型的度量模型。同时也为了更好的执行模型定义了度量标准规范，提供了使用的工具和实践案例。

多种度量手段

• 态度度量：主要采集用户的态度数据，核心指标是NPS和NSS，通常会用NSS来评估工具多个模块用户满意度，NPS是整体产品体验的北极星指标
• 可用性测试：通过定义一个用户大目标，拆解多个任务邀请用户测试观摩用户使用过程发现问题，会根据NSS的不同模块满意度低的因子，来继续做定性的调研
• 行为度量：对工具进行行为数据的埋点采集，用大数据分析来了解用户的行为一起判断是否存在体验问题，定义的路径可以与可用性测试的任务一致，来结合做定量的分析

度量手段标准化和工具化

• 度量手段标准规范：让执行模型的人可以更好的理解和实践，同时也能保证指标口径的一致性和横向可对比
• 度量手段工具化：让体验问题指标化、可视化，也能通过看板看到长期的变化，同时也方便大家理解和使用

寻找机会点和切入点

机会点：通过用户调研和用户数据分析手段挖掘产品体验问题，找到影响产品体验和业务指标增长的机会点，再对数据指标进行监测持续不断的优化达成业务目标

切入点：从用户使用路径角度拆解产品功能，用户使用产品的路径作为一个最小度量单元

• 产品由很多个功能组合成的，而用户的使用路径串联了多个功能
• 工具的体验是否友好，可以监测工具的核心路径的体验指标，判断体验的好坏
• 还可以通过多个核心路径的体验指标去关联产品指标，通过不断的产品优化观察产品指标的变化

基于项目是要达成产品目标，切入的方式是对用户使用路径的数据监测，下面重点介绍行为度量的实践方法

行为度量：用户行为数据进行体验度量

指标设计和定义

有了路径作度量单元，又如何衡量一条路径体验好坏呢？于是我们开始从用户完成一个任务的角度思考。这个路径的入口用户可以找到吗？用户可以完成吗？使用的过程是否遇到问题，完成的使用效率怎么样。

定义了两种和体验强相关的指标：可用性和使用效率指标

• 可用性是衡量用户是否能完成任务的基础指标

• 使用效率是在完成任务的基础上从时间和步骤的角度看路径是否高效的高阶指标

可用性指标有三个：触达率、任务完成率、跳出率

• 触达率：表示多少用户进入了定义路径的起点，是衡量入口可见的指标
• 任务完成率：表示用户在预设路径中是否能友好地完成整条路径，是衡量路径可用性是否良好的核心指标
• 跳出率：是分析定义路径中所有触点的指标，可以查看定义路径中任一触点跳出的用户数，用来分析影响路径完成的问题触点

效率指标有两个：任务完成时间、任务完成步骤

• 任务完成时间：用户在任务完成时，所花费的时间，从进入路径到最后完成路径过程中消耗的时间

• 任务完成步骤：用户在任务完成时，所需要的步骤，从进入路径到最后完成路径过程中消耗的步骤（有效点击事件个数）

指标分析纬度和使用场景

全量可交叉分析的维度说明

从指标定义角度，拆解了指标可交叉分析的纬度，提供使用指标的分析思路。全量可以从相似路径（相同使用目的路径）、用户类型、时间角度（优化前后）进行交叉对比分析。

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

场景一：多条路径单个指标怎么分析

对比相似路径（目标相同的路径）单个指标。例如查找模型的路径有两种方式：a用搜索找模型；b用类目层级找模型，对比两条路径任务完成率，看哪条路径是使用量大

• 对比并列路径（前后依赖的路径）单个指标。例如完成一个模型的摆放有三个前后依赖的路径：a素材面板找模型；b画布放置模型；c在参数面板调整尺寸，可以对比任务完成率，看是哪条路径影响了后续路径的使用。

场景二：单条路径多个指标对比分析

• 分析单条路径多个指标，例如可以观察多少用户触达了该路径起点，多少用户完成了该路径，多少用户从某个触点跳出了
• 还可以继续对完成路径的使用效率（时间和步骤）进一步分析，判断路径的使用步骤影响大还是时间消耗大

场景三：多条路径多个指标的分析

多个路径和多个指标主要用于对路径更加深入的分析，一般常用的使用案例有以下几种：

• 触达率和任务完成率结合，对多条路径不同入口和任务完成情况的对比
• 任务完成率和跳出率结合，在多条路径中找到影响任务完成的问题触点分析
• 使用效率对比，多条路径的任务完成率和任务完成步骤或时间进行分析

有了指标的定义和分析思路，如果需要大家用起来，还需要降低指标的使用难度，于是我们开始了路径分析的工具建设。

行为度量工具建设

困难和挑选

以路径作为切入点，按照之前的设想，只要对工具进行全埋点的数据采集后，再进行数据分析找到工具TOPN的路径，最后通过监测TOPN路径的体验指标来观察产品体验的变化。但是在埋点上我们遇到了全埋点实现不了和历史埋点结构不一致的问题

工具产品全埋点的困难体现在以下几个方面：

• 埋点成本大：用户在场景画布的操作频繁，触发事件数据量大，存储和分析资源消费庞大
• 画布中埋点不精准：画布中是一个三维的海拔，采集埋点时需要识别不同海拔对应的对象，尤其3D场景下，模型发生旋转后海拔会发生变化会导致埋点不精准
• 使用效率比较低：对于很多埋点数据，需要人工定义事件名称和事件是否有效。例如在画布拖动一个模型，需要详细的定义起点和结束的行为、时间、位置

埋点结构不一致：

• 不同业务历史埋点都是按照自己需求定义的埋点结构，如果需要跨业务分析需要统一埋点和历史数据结构，重新定义埋点采集标准和规范。

从全埋点到核心路径埋点

相对中后台产品工具产品呈现一条路径多个分叉，使用方式反反复复且无序的情况。

因为全埋点的限制，只能人工拆解工具的核心路径，为了不漏掉用户更多的使用行为，同时需要梳理核心路径的多个子路径。

指标模型化、工具化降低使用难度

基于拆解的埋点让路径支持自定义拼接和指标模型化，降低使用难度

• 路径自定义：一条路径由多个触点组成，在使用的时候可以按需拼接即可
• 指标模型化：只要定义路径就可以快速拉取对应的路径指标数据
• 同时还兼容了用户分群、路径保存和数据下载等用于二次分析的功能

业务实践

我们相信任何理论方法，都需要在业务实践中达成产品目标和商业目标才能更有说服力

目前行为度量的路径分析工具在酷家乐多个工具业务实践，实践案例有以下几种：

• 在日常开发过程中监测用户体验：拆解工具核心行为，监测体验指标的数据波动，来判断产品迭代对用户体验是否造成损害
• 路径分析辅助体验设计师做决策：拆解核心操作路径，建立数据指标监测看板，通过不断迭代优化观察指标的变化后调整优化思路，最终达成设计目标
• 通过路径分析提高新用户留存：找到新用户任务完成率低的多条路径，再用路径的任务完成率关联新用户次周留存，建立数据看板，通过迭代优化，观测新用户使用哪条或哪几条路径后对工具有更强的探索意愿并在次周进入工具

最后

作为体验设计师的我们深有感触，在设计评审阶段，评估设计方案的合理性和设计优化是否有价值上我们会遇到较大的挑战。尤其是涉及到管理者、研发、商业和运营等非设计岗位的同事，很容易带入自己的感受去评估设计的好坏。因为大家没有统一知识背景，我们需要用数据做一层转译。同时也需要用数据传递出设计方案迭代的思路、方向以及当前阶段的结果。

工具产品因其复杂的特性：一方面希望打造一套更严谨的设计方法体系，从用户调研和用户行为数据分析的方法定位问题，到设计方案评估阶段表达设计思考的合理，最终拿到正向数据结果；另一方面希望基于业务目标的角度，通过体验度量的手段，不断的发现问题和解决体验问题从而达成业务目标，来证明产品体验对业务结果的直接价值。

同时我们也坚信工具产品体验对用户增长和公司商业目标有着更大价值，后续我们会在体验指标关联业务指标上持续尝试工具产品增长模型的探索。

非常感谢项目组其他成员：灵雨（用户研究员）、阿淼（数据分析师）、燎原、柠乐（开发工程师）