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

推荐订阅源

小众软件
小众软件
博客园 - Franky
罗磊的独立博客
G
Google Developers Blog
The GitHub Blog
The GitHub Blog
P
Proofpoint News Feed
Recent Announcements
Recent Announcements
V
V2EX
F
Fortinet All Blogs
阮一峰的网络日志
阮一峰的网络日志
Blog — PlanetScale
Blog — PlanetScale
月光博客
月光博客
U
Unit 42
GbyAI
GbyAI
A
About on SuperTechFans
WordPress大学
WordPress大学
Engineering at Meta
Engineering at Meta
雷峰网
雷峰网
Microsoft Azure Blog
Microsoft Azure Blog
Martin Fowler
Martin Fowler
D
DataBreaches.Net
The Cloudflare Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
MongoDB | Blog
MongoDB | 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迎来强劲对手 – 人人都是产品经理,
如何带着批判性思维,参与一场需求评审?
MINGZI · 2023-03-12 · via 人人都是产品经理

评审任务是设计工作中必不可少的环节,能够让各个成员了解需求/设计的完整性和合理性,但全盘接纳不同观点,会导致我们处于被动地位。因此,作者提出,我们需要运用「批判性思维」获取观点,构建自己的答案。那么什么是批判性思维,又该如何运用?看完本文,相信你会获得启发。

01 评审是设计工作中必不可少的环节

我们都知道,评审任务是设计工作中必不可少的环节,设计师的评审任务,集中在项目流程的前半部分,及需求评审和设计评审,这两个环节尤其重要,它们影响着设计思路的方向、设计方案落地的效果。

评审的目的,在于让各个成员了解需求/设计的完整性和合理性,降低需求内容调整的风向,保证信息达成一致性,提高各方协作的效率。

参与评审的人员一般包含产品经理、设计师、技术人员和测试人员等。

全盘接纳不同观点,会导致我们处于被动地位

然而,实际评审情况中往往不太顺利,总有人会对我们传递一些它们坚信不疑却毫无依据的信息,而且观点往往不一致。

如果我们全盘接纳这些不同的观点,难以分辨信息的可信度,就会导致设计师处于被动地位。

  • 在需求评审环节:遇到需求内容不明确,或者功能设计不合理情况,如果没有及时发现和质疑,就会导致设计环节中问题暴露,方案反复调整。
  • 在设计评审环节:设计方案的合理性常常遭各方质疑,如果我们全盘接纳这些质疑点,导致设计方案难以落地。

运用「批判性思维」获取观点,构建自己的答案

因此,我们可以通过运用 「批评性思维」 来获取观点,分辨不同信息的可信度,从而构建出自己的答案,掌握评审环节的主导权。那么,接下来我将分两个部分讲解什么是批评性思维以及我们可以如何运用

批判性思维是一种分辨不同观点信息合理性的思维

具体内容是指:人们在复杂的情境中,结合已有的逻辑分析方法,对问题和解决方案进行选择,做出合理判断的思维方式。

它非常重视在获取知识中 与信息的互动,选择吸收什么和忽视什么,带着特定的态度不断提问,为形成自己的价值观做基础。

02 一套体系化的评审思维模型

我们可以将该思维方式,抽离为一套体系化的思维模型。将每次评审看成一次论证的过程,在这个论证过程中,我们通过以下三个步骤,让我们提高评审的效率:

第一步:明确评审论题

在评审交流中,或者自己宣讲前,要提出一个问题“对方/我想证明什么”“交流的主旨是什么” ,这样可以让我们可以对展开论证的内容有所预期,让我们更好的关注到评审中的问题。

在日常的评审中,我们遇到的大部分评审主题、论题都是描述性论题,它们回答是用来描述世间万物过去、现在或者未来存在的方式。

比如常见的问题“A和B方案那个更减少用户操作路径?“”体验一致性是否在产品生命周期是必要的?”

除此以外,日常中还有一种涉及到伦理或道德范畴的规定性论题,一般评审中不常出现,就不过多讲述。

第二步:寻找理由和结论

明确好评审的主旨, 第二步我们需要下意识地去寻找结论和理由。原因是:评审论证的过程,应该有结论和理由构成的。

结论,指的是一个个观点,它是逐步推断出来的,由理由支撑。

如果某人断言某件事是真的,却没有提供相应陈述来支撑这一言论,那它不能成为结论,只能称之为成为纯观点。我们可以评审/阅读,通过以下关键词来定位或者引导对方表达其结论点,比如说:“因此、表明、由此可知、由此得出、因此可以断定、我要说的重点是、显示出、证明、告诉我们、问题的实质是“等等。

理由,指的是构建出结论可信度的基础,是那些用来支撑或证明结论的信念、证据、隐喻等信息。

我们可以通过这些关键词来定位或者引导对方的理由,关键词包含 “由于、因为这个原因、因为这个事实、鉴于、由以下材料制成、因为证据显示、研究显示、第一,第二,第三”

最后,除了需求评审时多留意,在设计宣讲中,也可以加入这些提示词,来帮助他人快速理解你的理由,找到你的结论,提高我们方案通过率。

四种常见理由中的证据:

当我们找到了结论和理由后,就需要判断不同理由的可信度,来决定我们是否采纳其观点。我们可以依次来看以下四种类型的证据力如何。

1、以个人经历、直觉作为证据

这种证据的可信度低,原因是:

  1. 直觉最大的问题在于他的私密性,别人根本无法判断他是否可靠
  2. 个人经历,常常会受到环境影响,我们所见所闻,其实都是经历过一系列的价值观、偏见和态度所过滤后剩下的东西。

单一的个人经历,根本不足以构成一个有代表性的经历样本,会导致“以偏概全”的问题,比如我们往往就不是产品的目标用户,因此我们的个人经历难以代表用户。

因此,在设计评审中不做推荐这类信息作为证据。

2、以权威或专家理论作为证据

这种证据的可信度较高,原因是:

这类证据通常是某个领域的专家针对所研究的内容发表的学术言论/论文,有一定的代表性

在这类证据中,我们需要留意两点

  1. 该专家是否有从事与主题相关的丰富经历
  2. 了解对方获取该证据的渠道,是否为正确的资料或者一手资料,是否存在专家言论进行歪曲事实的可能

这类理由在设计评审中较为推荐,设计论证中,可以引用业内专家所提出过的 设计原则以及心理学理论来支撑设计方案合理性。比如设计原则中的米勒定律、希克定律、菲兹定律等,心理学中的 稀缺性心理、厌恶损失心理、沉没成本等。

3、以研究报告论作为证据:

这种证据的可信度较高,原因是:它是有多个样本以及有具体分析方法得出的,具有一定的验证性和精确性,它的不足点在于研究常常随时间流逝而发生改变,甚至互相矛盾,且研究治疗和人工因素有直接影响关系。

在这类证据中,我们需要留意:

  1. 研究报告被引用时间与实施研究时间距离多久,是否有理由怀疑研究结果已不适合目前阶段采用
  2. 研究是否被重复研究过,是否有其他不一样结论
  3. 研究样本量多少,比如问卷背后的用户量级、数据统计背后的数据量级
  4. 研究和分析的方法是否片面,是否能直接推导出相关结论,比如问卷具体的问题内容,数据统计背后的公式和分析方法。

在设计论证中,我们也可以调用一些用研究报告、数据分析报告或者竞品报告等研究报告结论作为 理由支撑,效果往往很好。

4、以类比陈述作为证据:

这种证据的可信度一般,它指的是:用两件事物之间的相似点作为基础,推导出另一件事物在同个位置特征的结论,它非常普遍,而且极有说服力却难以反驳。

在这类证据中,我们需要留意:

  1. 几乎任何事物都能找到相同点,因此不能仅仅因为共同点多而具有说服力。
  2. 多留意两个事物之间的不同点,以及这些不同点对于证据的影响成都。

有人主张 “产品不需要新手引导功能,用户如果遇到问题时,一定回去找使用帮助。就好比我们在机场迷路时,必然会去找机场人员帮忙。”

这个是典型的错误类比证据,我们来看这两个事物的不同点,类比的A事物中,互联网用户使用长杭静是挤碎片化的时间,偏好更低成本的使用方式,因此遇到任何问题都可能随时离开产品,并不一定去寻找帮忙。

而在类比的B事物中机场用户有必须完成的飞行任务,离开成本较高。因此这样的理由并不能推断出我们不需要新手引导功能的结论。

这类理由在设计评审中不作为推荐~

第三步:警惕误导信息

前面完成了两个步骤后,当我们对整个评审的内容有了一定的基础判断。

最后一步中,我们在这个过程中需要要警惕评审中的误导信息,即为论证中的“小花招”,它指的是利用逻辑上的谬误或其他具有欺骗性的形式来糊弄对方,警惕这类信息,可以帮助避免我们被对方错误的逻辑推理误导。

我将简单讲一下常见的三类误谬。

1、滑坡型谬误

它指的是:对方通过设想 他一旦采取某个提议后,会引发一连串不可控的不利事件,他的核心问题是:将各类事物之间的“可能性”理解为“必然性”。

当我们想对某个复杂页面进行分步骤形式设计时,有人质疑:“若这里采用分步骤设计形势,会直接导致其他页面也采用了这类设计形势,最终导致产品整体用户路径变长,导致体验变差,因以我不同意。”

面对这种情况,我们就需要注意到事件A和事件B的影响程度,比如 在该页面使用分步设计形势,是否会导致其他页面也需要用该形式设计?

其实并不会,我们通常可以通过制定规则,来决定不同场景、页面中是否采用分步骤设计形式。因此不会导致后面对方所提到的后面一些不利事件。

2、追求完美型谬误

它指的是:对方错误地认为因为尝试某种解决方案后还有遗留问题未解决,那么这种解决方案根本就不该采用。它的核心问题是:因为某个解决方案遗留部分问题,而不采用,导致我们固守原地,动弹不得,目前现有情况下是最好的选择。

我们建议在用户购买环节要离开时,提供带有优惠信息的信息来留住用户。该方案遭到对方的质疑,其原因是:“提供挽留用户的优惠信息是不会奏效的,因为如果用户一旦有离开的想法,他肯定头也不回就想退出。”

面对这种场景,我们可以通过明确目标的形式来解决,运用“不是……而是……”的方法来回答对方。

比如,我们的目标不是杜绝所有用户流失,而是减少部分用户流失,因此我认为提供优惠信息,是目前留住用户最好的解决方法。

3、虚假两难型谬误

它指的是:当现实存在两种以上的选择,对方却假想只有两种选择方案,引导我们在两个方案中选择其中一个,这种情况下,如果我们不加思考,就会陷入到在AB方案的选择困境中。

面对这种场景,我们可以尝试考虑下是否有方法可以将两种方案相结合,或者是第三种方案。

要警惕“不是……就是,唯一的选择是……”这些词语。

03 最后的话

今天的分享内容,介绍了什么是批评性思维,以及如何使用批判性思维模型。

感谢大家的观看,希望对大家之后的评审有所帮助,以下有一些本文参考的文献内容,大家感兴趣的话可以了解一下~

  • 《学会提问》— [美]尼尔·布朗 斯图尔特·基利
  • 《社会心理学》— 戴维·迈尔斯
  • 《麦肯锡高效沟通课》— [日]高衫尚孝

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

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

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