B端产品可用性度量评估体系

释放双眼,带上耳机,听听看~!

针对某个议题,我们经常会听到这种解决方案式的总结:“通过提升用户体验来提升满意度”,但行动时发现貌似事事都能跟用户体验扯上点关系,但改了很多好像又没什么效果,工作价值很难自证。这种情况主要因为体验是很感性主观的、外延大又自成系统,决定和影响因素多,且有些还不能全然掌控。

B端产品可用性度量评估体系

这种情景下开展产品优化或改版工作,作用在了哪、功效几何能被客观的度量出来,就显得很是迫切了。目标既是提升,就需要初始数据和结果数据的比对验证。体验(或满意度)是感性的,该度量什么?要怎么度量呢?

在这之前,“体验”这件事,又如何在团队内达成统一意识呢?这有助于度量形成标准化。

作为TOB的京东商家后台产品体系设计团队,我们在探索解决这个问题过程中,形成了初步的思路和结论如下文介绍,以供交流探讨。

总体思路:如何提升用户体验(满意度)?

使用类似服务蓝图、用户旅程地图类的工具,整体系统性的分析部门作为主体可有所作为的范围,以及利益相关方。

以POP商家在京东经营为例,经营体验和满意度是个整体感知。商家全生命周期内,影响体验的交互触点分散在各个部门。提升体验,有些需要打破部门墙,协同利益相关方联合解决,有些是部门职责内可控的,需要先明确考核度量范围。

在可作用范围内,拆解影响体验/满意度的因素,并进行分类管理,比如哪些是完全可掌控的、哪些是什么角色通过什么手段可解决的、影响体验的主次矛盾是怎么样的等。

建立标准化的评估体系来主控工作方向和量化工作价值,提供比较客观的视角对满意度调研结果进行补充。

如下图。经分析权衡,我们确定了提升产品可用性为至关重要的,也是最基础有效、切实可推动落地的满意度提升抓手和方向。

B端产品可用性度量评估体系

图1 商家后台产品矩阵满意度拆解之二

最后思考制定了度量评估体系,健全了评估流程、统一团队内部共识和可用性度量标准,整体服务于产品进行更加深入具体的问题发掘,指导产品、设计人员聚焦并制定具体的体验提升方案,持续监控和改进。

体系内很多度量指标理论依据源于可用性理论,该评估体系可供比较广泛的B端产品参考。

FLOE可用性度量评估体系

指标体系模型与度量量表

可用性度量指标体系从4个核心维度切入,系统的思考并制定了可用性的核心目标:“功能性(functionality)”、“易学性(easy to learn)”、“易操作性(operability)” 和“效率(efficiency)”,以及19项关键指标。它们之间并非相互独立,而是一定程度上成正相关关系互为影响共同塑造着用户体验。

B端产品可用性度量评估体系

表1 FLOE可用性度量指标体系构成

“功能性”对产品是否“有用”承担一定程度的检测能力,衡量用户对产品价值的实际感知,其他三个维度专注于对产品可用性表现的度量。“易学性”是评估产品结构设计、页面布局、信息组织方式有无问题,能否被快速理解并习得。“可操作性”用于评估产品的基础质量,用户是否能正确操作,顺利使用产品完成任务。产品具备了基础的可操作性能,用户能完成任务。“高效性”评估的是用户任务完成效率和负荷程度,需要产品更主动利用技术帮助用户提高完成任务的效率,避免承受非必要、繁琐、小心谨慎的操作过程。

度量量表,最多由19项关键指标内容组成,用于可用性测试结束后由测评用户根据使用感受进行评分,使产品问题分布比较直观可见。所有量表评分按照评分机制计算可得可用性总得分。

B端产品可用性度量评估体系

图2 度量量表示例

特点

相较于其他度量体系,FLOE度量评估体系有如下几个特点:

比SUS、WAMMI、USE类行业前驱向前迈进一步,根据产品总体特性,从 4个维度对可用性进行了专业方向上19项指标细化,诊断结果不仅是评估分数,更具象的指出了体验提升的方向;

对产品的评估,不囿于某个产品内域的可用性设计,而是着眼产品对用户完成完整任务支持能力的评估,增加了“任务衔接度”指标度量;

使用上更注重结合用户任务和用户观察,这还有个好处是节约后续用研资源的投入。

可用性度量实施流程

B端产品可用性度量评估体系

图3 可用性测试流程图

制定评价计划。选择评估方式,是启发式评估(仅专家参加)还是可用性测试(需要真实用户参与)。该阶段主要制作任务卡和准备测试数据、硬件等材料。

招募测试人员。根据公司条件可以选择性进行测试人员配比。招募的真实用户必须是目标用户,要符合测试目的所要求的条件。专家一般3~5人;用户一般20人以内即可,不可太少。

实施测评。测试用户使用产品完成任务,过程中思考发声,观察人员记录用户使用产品过程中遇到的问题。如果没有条件招募到真实用户现场参与,可以试试协商用户按照任务卡录屏操作结合度量打分的方式远程参与。

计算评价结果。计算可用性得分;并结合量表评分、专家反馈问题、用户录屏或反馈问题,在“观察到的事实”基础上整合问题清单,为下一步开会准备好议题。

开会落实解决方案。业务、产品、研发、设计等各相关方到场,讨论问题,排定产品优化清单。会后,最终整理生成《可用性度量报告》。

度量报告内容包括背景、测试情况概述、可用性评分结果、核心问题总结、问题详述(含现象观察、问题分析)、产品问题清单、优化方案。报告形式、载体不限。制作ppt会比较方便分享和汇报。

执行。研发根据《可用性度量报告》中的产品优化清单的综合得分(优先级)来推进工作,产品验收也更明晰便捷。问题的综合得分(优先级)评判标准:影响严重程度、出现频率、修复难度、迭代规划。该过程可能需要完善数据埋点,以便监控跟踪后续产品迭代效果。

验收。每次测试完结,务必要做好资料的归档管理,作为下次迭代的参照系。

项目实践示例

该工具主要适用于发现问题产品,诊断问题、产品迭代跟踪。做为共识性可用性指标,也可在进行原型测试时使用,帮助产品和观测人员对与用户交流和观察到的问题以结构化,为产品优化提供决策支持。

目前,我们的实践形式有两种:1.与测试部合作定期发起体验组,对选定产品展开走查,驱动产品完成优化。2.与迭代意向产品合作,进行诊断度量,产出可用性评估报告以供制定优化计划。

B端产品可用性度量评估体系

图4 某产品可用性度量报告节选示例

为TA充电
共{{data.count}}人
人已赞赏
产品设计

从新事物看产品设计,读懂云游戏的来龙去脉

2021-6-9 16:46:02

产品设计

后台系统:基于RBAC模型的权限设计

2021-6-10 10:57:59

0 条回复 A文章作者
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索