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

推荐订阅源

云风的 BLOG
云风的 BLOG
M
MIT News - Artificial intelligence
博客园 - Franky
J
Java Code Geeks
V
Visual Studio Blog
G
Google Developers Blog
罗磊的独立博客
MongoDB | Blog
MongoDB | Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Recent Announcements
Recent Announcements
Last Week in AI
Last Week in AI
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Stack Overflow Blog
Stack Overflow Blog
博客园 - 司徒正美
The GitHub Blog
The GitHub Blog
腾讯CDC
阮一峰的网络日志
阮一峰的网络日志
V
V2EX
博客园 - 【当耐特】
IT之家
IT之家
I
InfoQ
U
Unit 42
C
Check Point Blog
Martin Fowler
Martin Fowler

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
你的“好意”对用户可能是伤害?
产品方法论集散地 · 2024-10-24 · via 人人都是产品经理

这篇文章深入探讨了产品经理在设计产品时可能遇到的三种"执念",以及这些执念如何导致产品功能变得复杂难懂,甚至对用户造成伤害。

小时候,妈妈总会让你穿不喜欢的毛衣和线裤,怕你冷,你无奈地穿上,心理却一直在“嘀咕”,长大后这个场景变成了一个段子-“你妈觉得你冷”。

产品经理某种意义上,就像“妈妈”的角色,可能也会做出不少“我是为你好”的决策或设计,对用户而言,反倒成了一种“伤害”。

案例:一个让人“看不懂”的报表是怎么产生的?

方案1:报表分列表跟详情页。

  • 列表页:按列表形式显示所有余额假期类型,且每个假期类型只显示一个字段(即可用余额);
  • 详情页:按发放记录形式,显示每一条假期来源,且每天记录有单独的状态、发放数量、已使用数量、剩余数量等;

方案2:用列表完整显示一个假期的所有相关余额,所有字段平铺显示。

包含:当前可请总年假、当前可请工龄假、当前可请司龄假、当前可请调整年假(折算发放)、当前可请调整年假(不折算发放)、剩余总年假、剩余工龄年假、剩余司龄年假、剩余调整年假(折算发放)、剩余调整年假(不折算发放)、今年总年假、今年工龄年假、今年司龄年假、调整年假(折算发放)、调整年假(不折算发放)、总年假、总工龄年假、总司龄年假、已用年假、已过期年假、备注。

如果你是用户,哪个方案更容易看懂?

用户视角下,方案1明显优于方案2。产品经理虽能察觉,但有时受限于即时认知,可能未能即时识别出“愚蠢”设计,类似“被猪油蒙了心”的感觉,导致后知后觉。

为什么会这样?通常是受到三种“执念”影响:

产品经理的三种“执念”

第一种执念是”为用户好“。用户视角易于辨识体验优劣,身处其中则易感迷茫,甚至误以为“为用户好”。

比如方案2,你恨不得把所有信息全显示出来,避免用户对余额的明细和过程“有疑问”,殊不知却弄巧成拙。

  • 按可用程度分为总年假、司龄年假、工龄年假、调整年假
  • 按类型分为总年假余额、工龄年假余额等
  • 按时间阶段分为今年总年假、剩余总年假等
  • 按消费程度分为已用年假、已过期年假等

第二种执念是”为团队好“。你会从实现视角决策,确保产品逻辑通顺、可实现,保障项目落地,哪怕牺牲用户体验。

比如方案2设计时,你没办法解决用户修改年假余额的问题,迫于技术实现和工期原因,延伸出两个独立的余额字段:调整年假(折算发放)、调整年假(不折算发放),让用户进一步迷惘。

同时,当初节省工期导致后续客诉问题增加,最终得不偿失,节省的时间以问题的形式成倍返回。

第三种“执念”是认为“影响不大”。决策时,添加额外元素后,可能陷入思维怪圈,认为增加的字段不影响用户体验,用户可以忽略或不常访问该页面。

方法论:任何没用的东西对用户都是一种伤害

产品经理期望在用户价值、商业价值和情绪成本间实现最大化决策。但基于“为用户好”、“为团队好”、“影响不大”的执念,有时可能做出损害用户的设计方案。

所以,我们提出一个方法论:任何没用的东西对用户都是一种伤害。无论出于何种考虑,如果所提供的内容对用户无用,即构成对用户的伤害。

产品价值 = 用户价值 x 商业价值 – 情绪成本 x 2。当你通过无用设计在伤害用户价值时,实际就是在伤害你的产品价值,最终影响企业的商业价值。

比如你设计复杂的年假报表导致用户困惑,增加情绪成本,引发抱怨,寻求帮助,增加客诉,损害运营效率,降低商业价值,对产品价值造成双重伤害。

经验:如何有效运用此方法论?

首先,增加用户价值确认环节。当你设计原型完成后,增加一个用户价值确认环节。它可以分两轮:

  • 第一轮:自我确认。在原型设计完毕后,间隔1天(目的是重置自嗨脑),代入用户视角,重新验证用户场景;
  • 第二轮:外部确认。与用户分享原型,在不过度解释的情况下,观察反馈。如果用户配合度低(或成本高),可找内部业务部门同事确认。

第二,当用户价值与你的“执念”有冲突时,一定是产品方案有问题。你需要换个视角进行重新设计,一般有两个思路:

  • 思路1:仔细研究竞品。可能初次设计方案时没看竞品,或“过眼不过脑”式看了一眼。
  • 思路2:回归用户关键场景。可能初次设计方案时,你期望解决所有用户场景,但应聚焦真实常用场景,重新设计方案。

比如案例中的方案2,就属于不看竞品,也不聚集关键场景,导致产品方案有问题。

最后,请放弃“为用户好”、“为团队好”、“影响不大”的三大“执念”吧,任何无用的东西对用户都是一种伤害。对用户价值的伤害,就是对产品价值的伤害。

专栏作家

邢小作,微信公众号:产品方法论集散地,人人都是产品经理专栏作家。一枚在线教育的产品,关注互联网教育,喜欢研究用户心理。

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

题图来自 Unsplash,基于CC0协议

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