惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Blog — PlanetScale
Blog — PlanetScale
Y
Y Combinator Blog
G
Google Developers Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
L
LangChain Blog
S
SegmentFault 最新的问题
J
Java Code Geeks
V
Visual Studio Blog
H
Help Net Security
Stack Overflow Blog
Stack Overflow Blog
aimingoo的专栏
aimingoo的专栏
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
T
Tailwind CSS Blog
Microsoft Azure Blog
Microsoft Azure Blog
博客园_首页
H
Hackread – Cybersecurity News, Data Breaches, AI and More
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - Franky
B
Blog RSS Feed
The Cloudflare Blog
MyScale Blog
MyScale Blog
月光博客
月光博客
Microsoft Security Blog
Microsoft Security Blog
美团技术团队

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
工作经验|产品的设计体验度量模型,该怎么用?
元尧 · 2022-08-22 · via 人人都是产品经理

有很多同学,在产品的设计体验度量模型常常摸不着头脑,不知道该如何运用度量模型,或者运用哪一个度量模型。作者以度量模型的定义及其本质出发,探析如何使用度量模型,希望对你有所启发。

很多同学一提到“度量模型”这几个字就头大。我也收到过不少同学关于设计体验度量概念的问题,大多都是让我帮忙分析几个度量模型之间的优劣,想看看应该将哪一个模型用在自己的产品上。比如:

“可以对比分析下 SUS 和阿里云的 UES 度量模型吗?我所在的公司主要做的是 B 端系统,请问哪个更实用?”

“蚂蚁的 PTECH 模型和“两章一分”模型,后者是否更轻量级、更适合度量技术类的工具设计?”

对于这类问题,解释这些模型的具体用法,是治标不治本的。学知识要究其本质,我们就先看看以下这几个度量模型的本质性问题,如果你都读懂了,自然就会有上面这些问题的答案了。

一、体验度量模型是什么

体验度量模型也可以被叫做「产品体验评估模型」或「设计质量检测模型」等等。这类模型的使用对象通常是设计师或用户研究团队,其本质是一种产品设计及体验的质量的评估工具。一套体验度量模型的组成通常包括以下几个部分:

1. 度量维度

即对于要度量的内容的性质定义和分类,为的是让度量过程更具备逻辑、更全面。通常这些度量维度的英文首字母结合在一起,就是这个度量模型的名称。

比如蚂蚁集团平台设计部 2019年提出的用于评估企业级产品体验的度量模型 PTECH,其实是从产品的性能体验(Performance)、任务体验(Task success)、参与度(Engagement)、清晰度(Clarity)、满意度(Happiness)这五个维度来对产品的设计和体验质量做评估。这几个单词的首字母就组合成了「PTECH」这个模型名称:

2. 度量方法

包括需要度量和检测的具体内容、注意事项、操作策略和具体操作步骤、完成的指标等一系列内容。目的在于告诉设计师需要在不同的度量维度下收集哪些内容和信息,以及用什么策略和方法来做度量。

度量方法会从度量维度出发,针对每一个维度给出不同的策略和方法,并匹配对应的指标。比如我们上面说过的 PTECH 模型,除了划分度量维度,也对每个维度下关键的度量内容和度量手段做了规范和定义:

3. 评分机制

评分机制并不是必备项,可以被明确而简单的指标替代。但由于每项具体的度量内容对于产品体验的权重和影响不同,当设计师想要对于产品整体质量有一个精准的量化认知,就需要通过数字化公式进行计算。所以一些完整性较高的度量体系都是具备评分和转化机制的。

还是以 PTECH 模型为例,这个模型就引用了一套复杂的分数转换和核算方法,将五个维度测量出来的内容结果转化为数值,帮助设计师精确计算出产品的体验分值:

这种数字计算公式和方法并不是随随便便拍拍脑袋就可以想出来的,其中的逻辑和推演过程比较复杂,没有些许数学功底或是对度量模型不了解还真是不太行的。

不过也不得不说,这种高级的换算方式,不仅在确定公式的过程中增加了模型的复杂度,在使用公式计算出最终得分的过程也同样给设计师增加了不少工作负担。所以现在很多度量模型也会选择避重就轻,使用更加简单明了的指标来呈现度量结果。

比如谷歌公司的设计团队提出的 GSM 模型,就是将结果的评估重点放在对指标的定义上,用指标来判断设计质量的水平和标准:

看到这里你可能会有疑问:本就都是对于产品设计和体验的质量评估,为什么要有这么多不同的模型?大家就不能使用一套统一的标准模型么?

这是因为一款产品的评估方式本来就是多维度、多方面、多标准的,对不同业务领域的产品制定和使用统一的检验标准,是几乎不可能实现的理想情况。由于度量模型本身具备与产品强绑定的工具属性,所以「抛开产品自身特点和需求谈体验度量,就是耍流氓」。

蚂蚁的设计团队就应用过 PTECH 模型和「两章一分模型」等不同的度量方案。对于这种情况相信集团内部也曾经想努力地统一度量模型,尽量避免重复造车。但实际情况却是,这么多条业务线和产品类型,都各自有自己的想法和诉求。所以大家最终还是各自沉淀、百花齐放,也就有了不同的评估标准和模型工具。

值得一提的是,这种各自沉淀的过程并不是完全地重复造车,而是搭建思路和经验上的相互借鉴,取长补短,让每个团队都可以找到最适合自己业务的度量模型。

二、如何使用度量模型

判断一款度量模型好不好用,其实只有一个核心的判断原则:只有适合的,才是好用的。

同样的道理,当你想要对产品应用度量模型来做体验评估,也只有一个核心的使用原则:把度量模型当作工具去使用,而不是当作规则去迎合。

在实际工作中,工具和方法大多数情况下都是用来解决实际问题的,而它们的诞生也源于使用者对于这些问题的梳理和总结。你能看到的这些经典的度量模型,都是设计师们对于几十上百个项目千锤百炼后的经验沉淀,或多或少都会带有一些各自的业务特性和场景属性,因此没有绝对的高低优劣之分。

而能够完全适合你的产品特征、匹配你的度量需求的现成的度量模型是极少数的。这也是为什么你在借用这些模型的过程中,有时会有「不太好用」或「生拉硬套」的感觉。

因此,你可以根据你的产品特点和想要度量的内容,有目的性地、有选择性地、部分性地对这些业内已经成熟的度量模型进行借鉴和应用。当然在你的时间和精力允许的条件下,我也鼓励你参考这些经典案例,打磨出针对你自己产品的定制化度量模型。

所以你要做的,不是一板一眼地套用某个模型,而是发挥主观能动性,去判断、去筛选出真正对你的产品有用的部分,以及去学习这些模型搭建时的思考方式和工作经验。

度量模型就再高大上、评分标准再数理化,究其根本它也只是一款评估工具。对于这款工具的应用,不要为了彰显设计师的「工作量」或「学术专业性」而应用,也不要被这个工具限制住思考的能力。我们的核心目标是用它来发现产品的问题并找到有效的解决方案。

说了这么多,再来看看开篇的问题:SUS 和 UES 度量模型哪个更实用?你应该知道答案了吧?

专栏作家

元尧,微信公众号:长弓小子,人人都是产品经理专栏作家。一线互联网大厂B端体验设计师,清华大学美术学院本硕连读。曾负责国内最大开源组件库Ant Design组件的设计和运营工作,目前负责国际业务线B端产品体验设计和组件库的搭建工作。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。