作者：木木是个小尾巴，蚂蚁集团设计师
互联网下半场，所有的比拼都在产品体验；然而“体验”是一个非常抽象的词，我们怎么把一个抽象的概念拆解成可落地执行的策略，作用到企业中后台产品上，怎么衡量策略的有效性，这一直是我们团队面临的重大课题。
目前关于“体验度量”比较成熟的理论模型当属 Google 的 HEART 模型、ISO 9126 软件质量模型和Davis 的 TAM 技术接受模型。后人在此基础上进行了很多实践，譬如 SAP 的用户体验问卷（UEQ）、Oracle 的客户体验价值公式（CX）等。公司内部各个 BU 也在不断的尝试和探索，譬如新零售技术团队的 TES 模型，技术团队研发效能的 DEVA 模型，国际 UED 语音设计的 HII 模型，阿里云的 QoUE 模型。纵观这些模型和实践，大多是主观数据和客观数据的结合。
我们团队也曾提出过 TECH 、PTECH 模型，但由于模型的操作门槛较高、对埋点数据有不少要求，难以推广到各条业务线。痛定思痛后，我们决定重新回归业务，回归“体验度量”的初心，去繁从简，提高通用性。
企业级中后台产品最大的特点是任务性质非常明确；用户使用这类产品通常是为了解决某个确定的问题点，期待用新的解决方式降本增效。
桌面研究也表明：可用性问题是软件行业的普遍问题：在英国，一般商用计算机用户只有30%-40%的有效生产率；软件缺陷中，48%是可用性问题。
正是基于上述原因，我们尝试提出了“两章一分”的标准，分别从设计验收、可用性测试、易用度分数等三个维度对产品体验进行体检和把关。
“设计验收章”主要有 3 个维度：产品还原度、任务流程跑通率、单页面加载时间。
汇总人工智能线、技术风险线等 5 个产品近 1 年的可用性测试结果。除功能、性能问题外，高频体验问题主要集中在“帮助引导”、“操作反馈”、“任务流程”、“概念术语”、“功能入口”这 5 个方面。同时，结合之前项目沉淀的设计经验和设计工具，我们最终将“产品还原度”的子维度定为“信息导航”、“帮助引导”、“操作反馈”、“文案名词”；每个子维度用 2-3 句描述来进行评分。
“可用性测试章”也在验收阶段执行，同样有三个参评维度：最终完成率、人均求助次数和高阻碍页面。
我们没有考虑将可用性测试的常用指标——操作时长作为参评维度，主要原因是企业中后台产品类型多、使用场景复杂程度各自不同：用语雀创建企业空间只需要 5 分钟；用云凤蝶搭建一个后台页面可能需要 60 分钟，用 sofa stack 创建并发布一个应用可能需要 2-3 个小时......难以确定可以作为标准的具体操作时长。
“易用度分数”标准为 5.5 分。（关于“易用度分数”的更多详情，请查阅《企业级中后台产品体验度量探索（上）》）。
截至 2020 年 9 月，已有 58 个 产品实践过“两章一分”系列方法，基本覆盖平台设计团队支撑的重点项目及 UV 超过 100 的产品。详细数据如下图：
完整体验“两章一分”的 18 个产品，仅可用性测试就帮助发现 364 个问题，平均每个产品发现 20 个问题；其中，“九州2.0 发布部署”发现问题数多达 53 个。
企业中后台产品生产阶段中，由于一般没有专门的测试同学，因此设计验收都是由设计师或 PD 单独执行，没有作为必选环节，有时候甚至会因为开发周期紧张而直接略过；既没有方法论，又缺乏仪式感。
“两章一分”的实践中，我们首次践行“共创式验收”，以项目组会议的方式，邀请各个角色共同参与到验收环节中：如果产品没有什么技术门槛，那么各个角色分别独立操作核心流程；如果产品有一定的技术门槛，则由技术同学操作核心流程，同时共享屏幕，其他同学从旁观察。操作完毕后，项目组内共同讨论发现的体验问题，并将问题落地到 Aone 中进行排期管理落地。
企业中后台产品通常有一定的技术门槛，以 SOFAstack的测试任务为例：
使用 sofaboot 技术栈，创建 “hello world” 应用，通过“经典版”发布部署模式发布成功。
测试过程中经常会出现一些涉及到底层技术系统的问题，非设计同学能解决，因此我们建议做企业中后台产品的可用性测试时，需要配备至少一名技术支持同学，以备不时之需。
Jakob Nielsen 在 2000年提出测试 5 人就能发现 85%的可用性问题；结合我们的实际业务场景：有些产品真实客户非常难找；前期“共创式验收”已跑通核心主干流程；因此我们将最低测试人数限制为 3 人。
我们开始实操案例时，恰逢疫情期间，于是就引入了线上远程测试的方式；后续实践下来，发现远程测试能在观察、分析阶段显著降低执行成本。
通过钉钉或阿里郎发起视频会议，邀请参加测试和观察的同学入会，请测试用户共享操作屏幕，主持人录屏捕捉用户操作轨迹，PD、技术等项目组成员从旁观察。测试结束后，使用语音转文本工具，快速将音频转成文字。这种模式最大的好处有两点：
最开始提出“两章一分”的时候，我们原本希望这套标准能被作为判断产品体验是否好用，能否上线的标准之一；但实际并未推动成功。这里面有很多原因，其中一个非常实际的问题是很多产品需要调用线上数据库才能跑通核心流程，在测试阶段没法跑通；这就导致在测试阶段做可用性测试无法真实还原用户场景。
此外，设计师或 PD 新接手某款产品时，也希望能通过可用性测试的方式来快速了解产品问题。回归到“两章一分”的初心——帮助产品发现体验问题，因此，我们拓展了方法的执行阶段，不再局限于测试或验证阶段，只要场景适合，都可以用。
LinkE 研发运维中心是云通未来 Serverless 战场的重要产品；业务方希望用该产品来整合研发同学日常高频使用的研发、运维、中间件平台，大幅减少平台割裂和跳转，提供沉浸式的产品体验。
目前该产品还处于 0-1 建设的阶段。
结果用户在任务 2 遇到高阻碍页面，导致可用性测试结果为“不通过”，任务 2 的易用度分为仅 4.4 分，显著低于 5.5 分的参考标准；最终发现 30+ 问题点，并推动 PD 思考产品逻辑设置是否合理。
在实践过程中，我们发现企业中后台产品的典型场景大致可以分为 4 个场景；不同场景面临的设计项目有所偏重；不同设计项目在体验度量方面的切入点也有所不同。譬如：云凤蝶是一个典型的沉浸式画布页面，所有操作几乎都是通过编辑器属性面板来调整，那么如何来评估编辑器的效率呢？通过一系列实践和思考，我们提出可以通过“高频属性查找、配置的步骤数和时间”、“设置相同组件属性的耗时变化”等指标进行衡量。以下是我们根据不同典型场景、设计项目提出的体验度量切入点。
经过 S1 长达几个月的探索：我们制定了“两章一分”的标准；对 30+ 产品进行了易用度分数的测试，捕捉分数基线；提炼实操方法技巧，并赋能给各位设计师；联合设计师和业务方跑通近 20 个案例。不管是问题发现数量，还是设计师、业务方的主观反馈，都让我们坚定“两章一分”在企业中后台产品体验优化中是一个相对有效的模式。为此，S2 我们打算继续深化。
我们团队当前支持的企业中后台产品以 0-1 阶段产品为主，PD 通常缺少用户意识和体验优化手段，这就导致了设计稿还原度较差、产品上手门槛较高。针对这一现状，我们尝试性地提出了“两章一分”这个评价标准，从设计验收、可用性测试、易用度分数 3 个维度来评价产品当前的体验现状。
通过 S1 50+ 产品的实操，我们一边不断完善评价标准和实操经验，一边总结体验度量经验；共帮助 18 个产品发现 364 个产品，并在 link 、sofa 等重点产品线中落地到业务生产环节中，在业务方层面收到良好反馈。
在这过程中，我们总结了适合不同场景、不同设计项目的体验度量切入点，验证了这种方式在当前企业中后台产品中确实有效。后续我们将尝试细化标准，闭环案例，对内对外发声等方式，更好地推动体验思维在企业中后台产品生根发芽；同时，也期待能跟对这块感兴趣的同行朋友们多多交流。
Powered by Froala Editor
企业级产品设计体系，创造高效愉悦的工作体验
59
作品
568
粉丝
1
关注
大牛，别默默的看了，快登录帮我点评一下吧！:)
登录 立即注册