这一批笔记的主角是「PM 和 UX 怎么不打架地一起把产品做好」。产品经理(PM, Product Manager) 管业务价值、优先级、做不做;用户体验(UX)团队 管研究、设计、用户能不能用得爽。理想里两边是黄金搭档,现实里却经常为「这活到底归谁干」互相踩脚——NNGroup 一项 372 人调查实测:UX 平均每过一阵就觉得自己的活被别人插手(频率 2.6/4,接近「有时」),PM 也一样(2.4)。
对一个 PM 来说,这批资料的价值是把「我和设计师为什么总别扭」从模糊感受变成可量化的分歧地图 + 可执行的分工工具。全文八块: ①分歧实证(谁觉得哪活归谁,双方差几十个点)→ ②重叠工作的频率/根因/危害(为什么会抢活)→ ③协作 vs 重叠的本质区别(同样两人干一件事,什么是好什么是坏)→ ④PM 角色模型(设计师视角:PM 是个什么样的人,怎么配合 ta)→ ⑤RACI 分工矩阵(把「归谁」一次性钉死的工具)→ ⑥合作五建议(关系层面怎么经营)→ ⑦UXer 要像产品领导者思考(UX 这边怎么主动破局)→ ⑧PLG 与 UX(增长模式下 UX 的新角色)→ ⑨术语表(PM×UX 共同语言)。
一、实证分歧:同一件活,PM 和 UX 觉得归谁?(372 人调查)
NNGroup 调查了 372 人(279 名 UX + 93 名 PM,60% 工龄 3–10 年,54% 美国 / 27% 欧洲)。核心发现:双方对「这活归谁」的认知能差出几十个百分点——这不是态度问题,是结构性的角色模糊。下面把关键数据全列出(数字是「持此观点的人占该群体的比例」)。
研究类任务(发现 / 访谈 / 测试)——分歧最大在「发现」:
| 任务 | PM 认为是 UX 职责 | PM 认为是 PM 职责 | UX 认为是 UX 职责 | UX 认为是 PM 职责 |
|---|---|---|---|---|
| 发现 Discovery(摸清问题与机会) | 19% | 44% | 73% | 7% |
| 用户访谈 User Interviews | 45% | 23% | 88% | 2% |
| 用户测试 User Testing | 46% | 17% | 88% | 1% |
读法:UX 群体 88% 认为「用户测试是我们的活」,但只有 46% 的 PM 同意——意味着近半数 PM 觉得用户测试可以不归 UX。「发现」最危险:73% 的 UX 当成自己的核心活,却只有 19% 的 PM 这么看,44% 的 PM 觉得发现归 PM。
PM 的反例警告:你以为「发现阶段我自己摸用户就行」,但 UX 几乎全员认为这是他们的专业地盘。你跳过他们直接做发现,等于一边抢了活、一边丢掉了专业质量。
设计类任务——双方对「设计创意归谁」差得离谱:
| 任务 | PM 认为是 UX 职责 | UX 认为是 UX 职责 |
|---|---|---|
| 提出设计创意 Ideation | 33% | 76% |
| 定义任务流程 Task Flows | 34% | 70% |
| 绘制线框图 Wireframing | 42% | 74% |
| 优先考虑用户需求 Prioritizing User Needs | 38% | 78% |
连「画线框图(界面草图)」这种看起来最像 UX 专属的活,都有近 6 成 PM 不认为它必然归 UX。心法:线框图和创意一旦被 PM 顺手包办,UX 就退化成「按图施工的画图员」(见第七节 UXer 的核心痛点)。
信息架构 IA(Information Architecture,内容怎么组织、菜单怎么分类):50% 的 PM 认为这该归开发团队,而 75% 的 UX 认为这是 UX 核心职责。——这是个典型「三不管/三都管」地带。
管理设计工作(谁定研究方向 / 谁定要设计哪些功能):
| 任务 | PM 认为是 PM 职责 | UX 认为是 UX 职责 | UX 认为是 PO 职责 |
|---|---|---|---|
| 决定 UX 团队研究的领域 | 47% | 59% | 15% |
| 确定 UX 团队设计的功能 | 56% | 39% | 34% |
| 将用户研究纳入路线图 | 55% | 38% | 22% |
PO = Product Owner 产品负责人(敏捷 Scrum 里管 backlog 待办清单的人,常与 PM 重叠或就是同一人)。注意 UX 在「该设计哪些功能」上把责任分散给了 PO(34%),反映 UX 内部对「谁拍板做什么」也没共识。
项目管理类任务——这块 PM 主张更强,但「用户之声」严重错位:
- 产品愿景与优先级:超 63% 的 PM 认为愿景和优先级归 PM;UX 的观点分散在 PM 和 PO 之间。
- 进度跟踪:60% 的 UX 认为这是 PM 的活,反而高于 PM 自己的认定(45%)——即 UX 比 PM 更愿意把进度管理推给 PM。
- 维护产品待办 backlog:56% 的 PM 认为归 PM;确保项目满足业务需求:73% 的 PM 认为归 PM。
- 产品宣传 Evangelizing:72% 的 PM 认为归 PM;UX 更倾向给 PO(41%)。
- 竞品研究:PM 倾向归 PM;UX 分散在 PM/PO/市场之间。
「用户之声 Voice of the Customer」传递给产品团队——最该警惕的错位:
| 谁该负责传递用户之声 | PM 的看法 | UX 的看法 |
|---|---|---|
| PM 自己 | 25% | — |
| 客户体验团队 CX | 29% | — |
| 产品负责人 PO | 16% | — |
| UX 团队 | 9% | 54% |
反例(NNGroup 重点警告):54% 的 UX 认为「把用户的真实声音带给产品团队/领导层」是自己的天职,但只有 9% 的 PM 同意。结果就是经常由非设计人员替设计向高层汇报——设计逻辑被转述走样,UX 还白白丢掉了在组织里展示价值、积累信任的机会。给 PM 的提醒:让设计师亲自向 stakeholder 讲设计,既是尊重专业,也是帮你拿到没失真的一手信息。
内容决策 Content:61% 的 PM + 79% 的 UX 都认为内容该归 UX 或专门的内容团队。NNGroup 评:很多人觉得「谁都能写文案」,但只有专业内容团队能保证数字媒介的内容质量。
解释设计 / 争取认可(Buy-in):45%–53% 的 PM 认为「解释设计、争取 stakeholder 认可」是 PM 的活;只有 23%–29% 的 UX 认为归 UX。——又一个 UX 被代言的领域。
角色权力排名:双方对各角色权力排序大体一致,唯一统计显著的差异是——UX 给产品负责人 PO 的权力评分高于 PM 给的评分(UX 认为 PO 比 PM 想象的更有话语权)。
角色模糊的三大恶果 + 解药:
| 恶果 | 说明 |
|---|---|
| 缺乏熟练度 | 频繁换活 → 谁都练不出深功夫 |
| 缺乏专业性 | 非专业的人硬做 UX → 质量塌方 |
| 效率低下 | 活落到不擅长的人手里 → 慢且差 |
解药(给 PM 直接抄):①项目早期就同步——开工前 PM 和 UX 先把研究/设计/任务流的职责当面定清;②持续沟通——每阶段再确认一次谁干什么;③角色边界清晰化——避免「人人都是负责人」的混乱。
二、重叠工作:多频繁、谁和谁、为什么、有多伤
第一节讲「认知分歧」,这节讲分歧落地后的实际后果——重复劳动(work overlap)。同一批 372 人,问「别人插手/重复你的活有多频繁」(1=从不,2=很少,3=有时,4=经常):
| 群体 | 平均频率(1–4) | 含义 |
|---|---|---|
| UX | 2.6 | 接近「有时」,且统计显著高于 PM(p<0.05) |
| PM | 2.4 | 介于「很少」与「有时」之间 |
结论:UX 被插手得更频繁、更广——因为 UX 的角色最模糊(谁都觉得自己能做点设计/研究),所以最容易被人「顺手代劳」。
谁和谁重叠(各群体感知的重叠强度 1–4):
| UX 觉得跟谁重叠 | 强度 | PM 觉得跟谁重叠 | 强度 |
|---|---|---|---|
| 产品负责人 PO | 2.75 | 其他 PM | 2.71 |
| 开发 Development | 2.53 | 产品负责人 PO | 2.44 |
| 客户体验 CX | 2.5 | UX | 2.37 |
| 内容 Content | 2.3 | 营销 Marketing | 2.25 |
重叠的负面影响(评分越低越糟,2=中性):
| 影响维度 | UX 评分 | PM 评分 | 解读 |
|---|---|---|---|
| 产品/服务质量 | 1.60 | 1.97 | UX 感受到的质量伤害显著更重(p<0.05) |
| 工作满意度 | ≈1.5 | ≈1.5 | 两边都低于中性——重叠让人不爽 |
| 外界对团队的看法 | ≈1.76 | ≈1.76 | 重叠让别人看低你的团队(p<0.05) |
典型吐槽:PM——「重复工作降低士气,让我怀疑自己的价值」;UX——「角色不清导致设计治理(design governance,谁来统一把关设计一致性)困难,体验前后不一致」;UX——「最沮丧的是别人觉得『不需要专业背景也能干这活』」。
重复工作的根因(各原因的被选比例):
| 原因 | UX 选 | PM 选 | 显著性 |
|---|---|---|---|
| 缺乏领导力 Lack of leadership | 54% | 42% | 接近显著(p=0.07) |
| 试图做好事 Trying to do the right thing | 46% | 66% | 显著(p<0.05) |
| 认为自己有能力 They believe they are skilled | 46% | 34% | 不显著 |
| 你的职责不清 | 28% | 26% | 不显著 |
| 对方职责不清 | 19% | 26% | 不显著 |
| 性格 / 团队没空帮 / 喜欢这活 | ≤21% | ≤17% | 不显著 |
| 不信任别人做对 | 0% | 0% | — |
最反直觉的发现:重叠不是因为互相不信任(这项 0% 选择),恰恰相反——大多是出于好意(PM 66% 认为「大家都想把事做好」)。也就是说,抢活的人往往是热心、负责、自认有能力的人,问题出在领导层没把责任划清(UX 54% 把锅扣给「缺乏领导力」)。给 PM 的启示:别把 UX 抱怨「你插手」理解成「嫌你能力差/不信任你」,根子是没人在上面把边界定好——这是个管理问题,不是人品问题。
改善三招:①明确每个项目每个角色的责任范围(→ 用第五节 RACI);②靠跨职能小组互相了解彼此的活(增强角色意识);③领导层主动识别重叠、组织公开讨论把责任定清。
三、协作 vs 重叠:一字之差,天壤之别
这是整批资料的概念地基,PM 务必内化:同样是「两个人参与同一件事」,可能是好事也可能是坏事,区别就在两点。
| 维度 | 协作 Collaboration(好) | 重叠 Overlap(坏) |
|---|---|---|
| 责任 | 清晰——谁主谁辅事先定好 | 模糊——没人说得清归谁 |
| 沟通 | 顺畅——开工前对齐、过程中同步 | 缺失——未经沟通就插手 |
| 结果 | 提升整体质量 | 困惑 + 低效 + 重复劳动 |
UX 受访者的原话:「每一份工作都应该提升整体质量,而不是制造重复劳动。协作必须建立在清晰的责任分工之上。」 ——这句话基本是本批所有解药的总纲:不是要 PM 和 UX 离得远一点(那是孤岛),而是要在一起干之前先把边界说清楚。
四、PM 角色模型 Archetype:设计师眼里的产品经理是个什么人
这篇是 NNGroup 给设计师写的「如何理解并配合你的 PM」——但反过来对 PM 自己也是面镜子。前提认知:PM(敏捷里也叫产品负责人)负责推动产品战略、为业务和用户创造价值;理想上 PM 应该懂用户研究的价值,但现实常常不是。设计师需要主动证明自己的价值、建立信任、用专业去影响产品决策。
下面五维度,每一维列「PM 的典型特征」+「设计师该怎么配合」:
| 维度 | PM 的典型特征 | 设计师配合招法 |
|---|---|---|
| 目标 · 快速实验 | 用快速实验验证假设、评估机会 | 推动「基于高质量研究」的实验,避免瞎试浪费资源;给发现阶段的痛点做原型测试并请 PM 来旁观 |
| 目标 · 价值优先排序 | 让产品决策的业务价值最大化 | 引入优先级框架,把业务指标(如收入)和用户指标(如任务成功率)结合起来排序 |
| 目标 · 团队对齐 | 确保大家的活都对准共享目标 | 把日常设计活动跟高层目标挂钩,定期和 PM 核对优先级,别跑偏 |
| 目标 · 风险管理 | 识别业务/可用性/技术风险 | 用研究方法评估可用性和功能风险,按严重度同步给 PM |
| 优势 · 战略思维 | 整合工程/设计/市场多方信息定方向 | 请 PM 解释「设计需求和目标之间的逻辑链」,避免不透明引发冲突 |
| 优势 · 沟通能力 | 高频沟通保一致、保持续交付价值 | 主动找 PM 拿信息,别等,免得做错方向白费力气 |
| 优势 · 果断决策 | 从海量信息里抓重点、快速优先 | 用「耐心 + 好奇」的语气问 PM 决策依据,再用研究证据帮 ta 达成共识 |
| 挑战 · 时间管理 | 数据太多,没空啃复杂研究报告 | 把研究成果简化成关键洞察摘要,让 PM 几分钟看懂 |
| 挑战 · 平衡细节 | 要在用户需求和技术优先级间权衡 | 邀请 PM 亲自参与用户研究,帮 ta 记住用户细节 |
| 挑战 · 数据探索效率 | 容易被「有趣但没上下文」的数据带跑偏 | 帮 PM 追问用户行为背后的原因,给业务有意义的洞察 |
| 挑战 · 想插手设计 | 可能直接下场主导设计 | 深入了解业务和用户目标,主动给出设计决策的合理性解释(堵住 ta 插手的理由) |
| 活动 · 管 backlog | 定期审查更新待办清单 | 确保用户故事里写清用户需求和预期结果 |
| 活动 · 研究商业数据 | 分析数据找问题/机会 | 摸清 PM 关注哪些关键指标,用研究为这些指标补背景 |
| 活动 · 研究竞争 | 跟踪对手策略与技术 | 从「功能可用性」角度补充竞品分析 |
| 活动 · 记录进展 | 跟踪团队成果、为团队争取支持 | 帮忙更新进展文档,确保设计工作不被埋没 |
| 技能 · 技术知识 | 懂点技术概念,但要靠工程师 | 拉上工程师 + PM 一起聊技术约束,增强设计可行性 |
| 技能 · 业务知识 | 推动财务可持续与增长 | 学 PM 用的业务指标,找「UX 成功指标 ↔ 业务指标」的联系 |
| 技能 · 设计知识 | 设计知识有限,可能有点经验 | 用清晰的产出 + 研究支撑,赢得 PM 对设计专业性的信任 |
给 PM 的自我审视:看到设计师对你的「想插手设计」这条防备没?那不是冒犯——是行业共识。你最该做的是把「为什么要做这个功能」(业务/用户目标)讲透,然后把怎么设计交给 UX,这样你既省心又能拿到更专业的结果。
五、RACI 责任分配矩阵:把「这活归谁」一次钉死的工具
前面几节诊断出病根是「责任不清」,RACI 就是最直接的处方。RACI(责任分配矩阵) = 一张表,横向列任务、纵向列角色,每个交叉格填一个字母,说清每个人在每件事上是什么身份:
| 字母 | 含义 | 数量规则 | 例子 |
|---|---|---|---|
| R = Responsible 负责 | 实际动手干这活的人 | 可多人 | 用户研究员负责跑可用性测试 |
| A = Accountable 最终责任人 | 对完成时间和质量背锅的人 | 每个任务只能有一个 A | UX 负责人既统筹研究又下场参与 |
| C = Consulted 顾问 | 要提供专业意见的人(双向沟通) | 可多人 | 各领域专家 |
| I = Informed 知情者 | 要知道进展但不直接干的人(单向通知) | 可多人 | stakeholder、法务、营销 |
RACI 的灵活性——角色和任务都可按团队定制:
- 角色:UX 侧(UX 设计师、用户研究员、信息架构师)+ 关键伙伴(PM、PO、工程师、Scrum Master)
- 任务按阶段排:战略阶段(定愿景/目标/策略/路线图)→ 发现阶段(用户访谈/竞品分析)→ 设计阶段(原型/可用性测试)→ 交付阶段(发布计划/QA/产品演示)。图中「X」表示该角色完全不参与。
为什么 + 何时用:不画 RACI 容易出这些事——必要角色被漏掉、有人太晚才被拉进来、忘了通知受影响的人、对「谁负责」产生误解。最佳启用时机:①回顾会(retrospective)后,当团队提到「谁谁被漏了 / 任务延迟」;②新项目启动时,在 Scrum sprint 或产品增量阶段做初始分工讨论。建议由 UX 团队牵头提议、当成一个实验工具推行,通过线上/线下工作坊全员共同制定(不是某人单独填好甩给大家)。
分配任务时除了职位描述,还要看:
- 技能组合:懂访谈技巧的 PM 可以负责(R)用户访谈,UX 负责人负责出题(C/A)——别死按头衔分。
- 与团队的关系:即使 UX 这次无法直接做某访谈,至少也要当知情者 I,确保成果及时回流给 UX 团队。
- 时间与兴趣:按每个人的档期和意愿合理派活。
协作纪律:对同一任务标了 R 或 A 的角色必须紧密合作、明确「谁具体做什么」;别搞成单向交付,而要建立持续协作的设计文化(定期互相 check 进展)。
六、提升 PM×UX 合作的五大建议(关系经营层面)
前面是「分工工具」,这节是「关系经营」——NNGroup 给的五条相处之道:
| # | 建议 | 关键动作 | 反例(别这么干) |
|---|---|---|---|
| 1 | 分享过去经验与当前意图 | 公开聊各自的技能、兴趣、过往经验、待改进项,建立信任、消除信息不对称 | 为个人利益藏着掖着信息、囤积情报 → 团队内部不健康博弈 |
| 2 | 协作做发现性研究 | PM 定业务目标和 OKR(说明研究的意义),UX 主导高质量用户研究,PM + 工程一起参与讨论分析 | PM 或 UX 单独做发现、甚至跳过发现 → 全队对用户问题和机会的理解被削弱 |
| 3 | 互相尊重设计能力与决策权 | UX 主导把方案具体化(线框/原型),PM 通过白板共创给建设性意见;UX 理解 PM 要基于可行性做优先级决策 | PM 下场主导设计;UX 不理解 PM 的优先级职责 → 角色冲突 |
| 4 | 接受反馈,别防御 | 乐于接受 stakeholder/同事/用户的反馈;PM 和 UX 对方案有分歧时搁置主观意见,用用户测试来裁决 | 对反馈摆防御姿态 → 在错方向上浪费时间 |
| 5 | 共同理解并关注指标 | 全员都知道在收集/跟踪哪些指标(PM 牵头促成共识);UX 把定性洞察和定量数据结合;PM 向高层报喜时让全队都拿到认可 | 指标只有 PM 知道;PM 报功劳时把团队晾一边 |
贯穿主线:第 4 条「用用户测试裁决分歧」是 PM×UX 最强的止争工具——当你和设计师为「该不该这么设计」争执不下时,别比谁嗓门大,搁置双方假设,让真实用户来投票。这既快又能服众。
七、UXer 要像产品领导者一样思考(UX 侧的破局之道)
前几节多从 PM 视角看,这篇是 UX 自我突围指南(作者 Fuego UX 公司)——但 PM 读了能更懂设计师在焦虑什么、以及一个「想往上走的设计师」会怎么靠近你。
当下 UX 面临的三重困境:
| 困境 | 具体表现 |
|---|---|
| 决策权旁落 | 产品和工程掌握主要决策权,UX 团队人少;尽管越来越多 UX 改向产品汇报,工程师仍主导多数科技公司;设计师常常只能按要求画图,影响不了产品方向 |
| 优先级错位 + 语言不通 | 产品要快速上新功能,设计师看不懂长期目标 → 热情受挫;PM 讲用户增长、留存率这些业务数据,设计师如果不会用同样的语言表达价值,想法就被忽视 |
| 资源紧缩 + 角色模糊 | 裁员后 UX 人手减少、活被别的团队分担 → 合作变多但专业水平下降 |
破局四步(UX 主动出击):
- 吃透业务(不止表面)——先搞清产品领导者在干啥(开发新功能/维护客户关系/盯竞品),观察他们怎么协作、怎么调优先级、用什么形式沟通(演示/表格/计划)。看全局,不只看自己那摊;了解公司所有产品和服务。
- 画一张「关系图」摸清权力与资源流向——NNGroup 给了一个落地模板(下表节选),列出你打交道的每个人:姓名/职位/协作内容/主要支持点/部门。用两个符号标清依赖关系:
- ⊝(减号)= 你依赖对方:你需要从 ta 那拿到的信息/资源/协作
- ⊕(加号)= 对方能给你支持:ta 能提供但你不一定主动要的帮助
| 姓名 | 职位 | 协作内容 | 主要支持点 | 部门 |
|---|---|---|---|---|
| Aditi L. | Product Manager | 产品 Backlog | ⊝ 有用的功能设计、用户行为 · ⊕ 优先处理产品 UX 负债 | Product |
| Naomi I. | Director, Product Design | UX 总负责 | ⊕ 汇报对象,制定策略方向 | UX |
| George Q. | UX Researcher | 用户研究支持 | ⊝ 及时提供研究支持 · ⊕ 用户招募、研究模板、画像 | UX |
| Jess G. | Architect | 后端架构与可行性 | ⊝ 可行性建议 · ⊕ 性能问题建议 | Development |
这张图的用处:让设计师看清「自己手里攥着哪些筹码、又卡在谁手里」,从被动画图员转向主动经营关系的人。对 PM 的启示:一个会画这种关系图的设计师,是把你当「关键合作方」在经营,不是来抢你活的——值得拉近。
- 战略性协作与沟通——用业务理解去帮 PM/工程验证想法、解决技术问题;好的产品领导者都很会处理人际关系。三个关键动作:建立良好工作关系 / 展示工作成果 / 知道什么时候该让步。向高管汇报要简明,少堆技术细节,看人下菜。
- 按公司类型调整打法(让 UX 成为「产品必需品」而非可有可无的装饰):
| 公司类型 | UX 该强调什么 |
|---|---|
| 数据驱动型 | 设计如何提升关键指标(留存率、转化率) |
| 工程师主导型 | 设计如何提高效率、带来收益;用数据说话,同时懂技术约束 |
| 产品主导型 | UX 如何帮产品在市场竞争;设计配合产品战略,研究支撑产品方向 |
额外能力:培养「职场政治智商 + 跨职能技能」——懂公司氛围、分清哪些是重要 UX 问题哪些是小事、别把自己框死在职位描述里(各团队的活越来越像了,谁都能参与研究和规划)、多做实用的快研究(快速拿用户反馈 > 做太深的研究)。
八、产品驱动增长 PLG 与 UX 的角色
PLG(Product-Led Growth,产品驱动增长) = 让用户先免费试用、自己感受到价值,再付费的获客/转化/留存策略。对的是传统的 SLG(Sales-Led Growth,销售驱动增长)——后者要求用户先看演示、签合同、付费才能用。
PLG 的三种变现模型:
| 模型 | 玩法 |
|---|---|
| 免费增值 Freemium | 部分功能永久免费,付费解锁高级功能 |
| 免费试用 Free Trial | 限定时间内全功能免费,到期付费续用 |
| 混合 Hybrid | 前两者结合 |
为什么选 PLG / 代价是什么:
| 优势 | 缺点 |
|---|---|
| 快速给用户传递价值(缩短「接触→感知价值」时间) | 前期成本高:要为没付费的用户也建好、养好产品 |
| 省成本:客户旅程里不用塞销售代表 | 需要更多付费用户:得用付费用户养活大量没转化的试用者 |
| 分散风险:不依赖少数大客户合同收入 |
PLG 六大关键指标(PM 必盯):
| 指标 | 定义 | 方向 |
|---|---|---|
| 价值实现时间 Time to Value | 从首次接触到感知价值要多久 | 越小越好 |
| 转化率 Conversion Rate | 免费 → 付费的比例 | 越大越好 |
| 客户留存率 Retention Rate | 一段时间内回来的用户比例 | 越大越好(留存成本低收益高) |
| 客户流失率 Churn Rate | 一段时间内不回来的比例 | 越小越好 |
| 使用流失率 Usage-Churn | 因使用减少而可能流失的比例 | 越小越好 |
| 客户获取成本 CAC | 拉一个新客户的成本 | 越小越好 |
UX 在 PLG 里为什么是命门:PLG 下用户的首次体验直接决定成败——初体验差,用户秒切到竞品(没有销售在中间兜底挽留)。所以 UX 的活是「优化初体验 + 扫清使用障碍」来给 PLG 降险。
UX 助力 PLG 的 7 招:
- 盯紧 PLG 指标——把每个设计/内容改动都跟具体 PLG 指标挂钩,讲清价值贡献。
- 降低获客阶段阻力——初体验易用且高价值;减少多余步骤,避免登录墙(除非真有验证必要)。
- 最小化 Time to Value——研究用户心智模型,让产品价值被快速感知。
- 聚焦已转化用户——按帕累托(Pareto,二八)原则优先服务贡献最大收益的 20% 用户,深挖高价值客户的行为与反馈。
- 提升留存——对比「转化 vs 未转化」用户的行为差异,找出阻碍点;定量 + 定性一起用。
- 预防流失——靠使用行为预测流失风险并主动干预;给低活跃用户推新功能拉参与。
- 跨业务沟通——和产品/营销/销售对齐,UX 目标服务整体业务策略;定义宏观和微观转化指标,追踪用户旅程里的关键里程碑。
给 PM 的串联:这 7 招几乎条条要 UX 和你深度协作(指标共识、登录墙取舍、转化漏斗优化)——又回到第六节「共同关注指标」。PLG 模式下 UX 不再是「画得好看」,而是直接对转化/留存数字负责,这是你能给设计师赋权、也能向他们要结果的最佳切口。
九、产品与 UX 术语表(PM×UX 共同语言)
NNGroup 整理的核心术语,按主题分组——这是 PM 和 UX「说同一种话」的字典。
收益模型:
- 广告收入模型 Advertisement-Based:卖产品里的广告位获利,按展示量/点击量计费。
- 免费增值 Freemium:部分功能免费,付费解锁高级。
- 订阅收入 Subscription:按月/年付费换使用权。
商业与战略:
- 蓝海战略 Blue-Ocean:靠显著差异化创造全新市场,避开正面竞争。
- 红海 Red Ocean:竞争激烈、产品同质的市场,靠低成本或差异化抢客。
- 商业模型画布 Business-Model Canvas:描述商业模式九大组件(价值主张/客户群体/渠道/收入来源等)的工具。
产品开发与管理:
- 最小可行产品 MVP:用最少资源展示核心价值的初始版,快速拿反馈。
- 产品愿景 Product Vision:对产品未来影响力和用户价值的理想化声明。
- 产品生命周期 Product Lifecycle:引入 Introduction → 增长 Growth → 成熟 Maturity → 衰退 Decline 四阶段。
- 产品路线图 Product Roadmap:展示未来工作优先级和目标的高层计划,含 UX/开发/营销跨职能内容。
用户与市场:
- 客户反馈循环 Customer Feedback Loop:持续收集分析用户反馈(调查/反馈表/社媒)以迭代产品。
- 客户终身价值 CLV:一个客户全生命周期为企业创造的总收入预测。
- 目标市场 Target Market:按人口统计/行为/需求定义的预期客户群。
- 总可服务市场 TAM:市场潜在总收入 = 潜在客户数 × 单客户平均收入。
运营与技术:
- 瓶颈 Bottleneck:请求/工作量超过系统处理能力导致性能下降。
- 功能膨胀 Feature Creep:功能越加越多,反而拉低可用性和效用。
- 功能标志 Feature Flag:无需重新部署代码就能开关功能的技术,便于实验/快修。
- UX 债务 UX Debt:为图短期方案牺牲长期体验的代价,会拖垮满意度和品牌忠诚度(类比技术债)。
测量与决策:
- OKR(目标与关键结果):设可量化目标的框架,目标定性、关键结果定量。
- 时间到价值 Time to Value:用户获得核心价值所需时间(PLG 核心指标)。
- 客户获取成本 CAC:获得一个新客户的平均成本(营销 + 销售等)。
- 价值主张 Value Proposition:产品提供的独特核心价值,是吸引并留住用户的关键。
源自 NNGroup Topics / Product and UX Study Guide - 产品与设计师(8 篇)。这是 NNGroup 系列里专门讲「PM × UX 协作」的一批,与基础概念 NNGroup UX 基础知识(UX/可用性/UI 定义辨析 · 以人为中心设计 HCD · 设计思维 5+1 阶段 · 产品三元组 DVF · 没有研究就不是 UX · 研究方法三维框架/20 法/定量 9 法/用户访谈 · 方案取舍 6 步 · 10 大启发式索引 · UX 职业 5 阶段/转型/作品集/简历)、UX 团队管理 NNGroup UX 团队组织与运营(DesignOps 5 结构 · 集中/嵌入/矩阵汇报 · MUXI · RACI · 角色职责 · 入职 30/60/90 · UX 研究计划 PET(S) · 设计思维强团队 · 团队决策质量:确认偏误/群体思维/书写思考 · UX 6 阶成熟度与最大挑战 · Refine/Remodel/Rebuild) 互为补充;研究方法层面可串联用户画像 NNGroup 用户画像 Personas(本质/三类型/范围层级/创建/对比 JTBD-原型-分群/应用/维护/5 大失败) 与可用性测试 NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估)。图片/原档保留在 sources。
来源与关联资料
- NNGroup UX 基础知识(UX/可用性/UI 定义辨析 · 以人为中心设计 HCD · 设计思维 5+1 阶段 · 产品三元组 DVF · 没有研究就不是 UX · 研究方法三维框架/20 法/定量 9 法/用户访谈 · 方案取舍 6 步 · 10 大启发式索引 · UX 职业 5 阶段/转型/作品集/简历)
- NNGroup UX 团队组织与运营(DesignOps 5 结构 · 集中/嵌入/矩阵汇报 · MUXI · RACI · 角色职责 · 入职 30/60/90 · UX 研究计划 PET(S) · 设计思维强团队 · 团队决策质量:确认偏误/群体思维/书写思考 · UX 6 阶成熟度与最大挑战 · Refine/Remodel/Rebuild)