如何评价一个任务型的解法方案体验好坏？
通常商家在门店经营过程中，会根据行业的特性以及自身特点，制定相应的工作流程；设计师根据这些工作流程，进行任务拆解，从而产出对应的设计方案。但是我们如何去评价一个任务型的解法方案体验好坏？很多时候可能设计师自己也是懵的，除了等待商家后续反�。ㄖ鞴郏忻挥衅渌嵌裙┪颐侨チ私�？本文结合零售报损单据查找商品交互优化的例子，做个简单的交流。
度量模型
业内最知名的体验度量模型是Google团队在发布的HEART模型+GSM模型，在C端产品领域应用较多；随着B端产品的大爆发，目前针对这块较为成熟的模型有阿里云-UES系统及蚂蚁的PTECH模型。
阿里云-UES模型，包含以下5个维度：易用性、一致性、满意度、任务效率、性能。前三个主要通过问卷表格及设计交叉走查完成度量，后两个则可通过数据埋点实现。
蚂蚁PETCH模型，包括以下5个维度：性能体验、任务体验、参与度、清晰度、满意度。前三个通过数据埋点实现，后两个通过问卷表格完成度量。
通过比较，可以发现这两个模型都是主观感受+客观数据的结合，都会关注性能、任务效率及满意度。而阿里云的一致性、易用性也更加贴近我们实际做业务时需要考虑的点：商家要觉得易用方便、大多数界面上要遵循ZDS设计语言，因此将UES模型作为此次度量的参考。
如何选取维度及指标
明确设计目标
先回到此次需求，零售行业（蛋糕烘焙、生鲜果蔬、轻餐茶饮）的商品报损是指在日常经营商品中短保商品占比较高的情况下，门店会在每日营业快结束的时候进行商品的清点，将临保、过保或者已损坏的商品记录下来。
那落实到店员身上，其实是需要一系列步骤去完成这项任务。从行业的特性及商家调研中了解到，如蛋糕烘焙分类不是很多，且每个分类下的商品也是有限的，因此设计上相对其他单据最大的变化是选择一级分类直接展现，看是否能帮助商家进行提效（进出存有许多单据，报损是其中一种，之前大部分单据的查找商品结构是一致的）。
选取度量维度及指标
通过上面分析，我们可以发现UES模型里的任务效率，比较契合此次需求。假设此次设计改进是有效的，那么商家完成商品报损整体速度是变快的；将这个感受用客观数据来呈现即是「完成一次报损商品添加时间的均值」和「完成一次报损时间的均值」两个指标，其中整体报损的时间需与行业对齐。
如果我们之前并没有对老的报损交互进行埋点，从而没有初始数据可以对比，那可以从满意度和功能使用率上入手。比如商家满意度，商家查找商品时分类的点击率等，从另一个角度看看商家实际使用的情况。
指标整理
我们再从此次需求引申到进出存整个单据的视角上，结合产品侧的数据诉求，可以发现任务型单据几个共通的维度：用户使用、用户行为及用户效率。
维度 | 子维度 | 数据指标 | 备注 |
用户使用 | 使用情况 | 某单据入口单级次数 | |
完成情况 | 提交/完成点击次数 | 单据需要审核的情况下存在提交 | |
用户行为 | 查找商品 | 一级分组点击次数 | |
搜索点击次数 | |||
扫码点击次数 | |||
修改商品 | 移除点击次数 | ||
编辑按钮点击次数 | |||
用户效率 | 查找商品效率 | 完成一次商品添加所需时间 | 从入口进去到第一个报损商品添加完成的时间 |
单据效率 | 完成一次该单据所需时间 | 从入口进去到最后提交成功的时间 |
用户使用：主要关注功能的使用及完成情况
用户行为：用户是如何来使用你的产品（可以与最初的调研场景进行验证）
用户效率：用户完成任务的时间
小结
通过设立任务型设计度量指标，我们可以观察每次迭代下相关数据的变化情况。在对数据进行分析时，也要关注每次迭代的变量，不能简单地认为时间增加了就是效率下降了，要结合需求，结合商家的反�。鞴酆涂凸垡黄鹱酆峡剂�。
ps：关于主观度量实操，大家有什么好的技巧欢迎在评论区留言交流~
推荐经营方案
打开微信扫一扫即可获取
-
1000+最佳实践
-
500+行业社群
-
50+行业专家问诊
-
全国30+场增长大会
请在手机上确认登录
