之前对过来人的建议都不怎么在意,自己特别骄傲,觉得别人都不比自己聪明。经过了三年,这种心态开始变化。 知乎上有个问题是:『有哪些事情是你入行时不以为然甚至嗤之以鼻,入行后却整个颠覆了之前的认知并奉为至理的?』 我是这么回答的: 1.『产品经理不是经理。』 刚入行的时候觉得自己高高在上,或者至少觉得自己很有分量。相信大多数产品经理都这么感觉的。『我比程序员高贵。』『我是未来要成为 CEO 的男人/女人。』 实际上呢… 请自行百度『产品经理是条狗』。歌词很感人。 真把自己当成经理,工作上绝逼会步步维艰,什么都推动不了。 2. 『不管设计得再怎么样完美,需求总会改的。』 以前还特别奇怪,你设计产品的时候考虑周全点儿不就行了,干嘛非得改需求。但是经过了很多次惨痛的教训,终于发现,需求总是会改的。 改需求不代表产品经理不认真、太随意,也不是老板或者高层总喜欢拍脑门想点子,而是有很多现实原因。 可以列举一些: 市场情况变化。比如因为某些事件,用户的需求变动;或者竞争对手的动作,导致必须有应对措施。 运营策略变化。比如公司的运营手段不同了,导致产品上的支撑方法也要不同。 研发阶段暴露出了问题。比如有一些底层逻辑之前很难发现会出问题,但研发中暴露了,导致产品方案要改为更适配的。 时效性变化。比如由于开发周期过长,导致时效性下降,所以也没必要用原来的复杂方案。 临时需求插入。比如各种因素导致的,有更重要的需求紧急加入,这时必然要修整原来的方案或者延后开发。 虽然产品经理确实会在设计上出现纰漏,但更多情况下,产品经理只是背锅侠而已…这是我从事这个职业前没有意识到的。 3. 『用户很傻,而且会越来越傻。』 这里说的傻不是 low,也不是笨,而是用户不会愿意在使用产品的时候还思考。 我在入行前也觉得说用户傻的人才傻,现在是什么年代,大家的知识量、对新事物的接受程度都大不一样,什么不会用去网上搜一搜、跟朋友问一问不就好了? 几年前很出名的书《Don’t Make Me Think》说的理念我就不太明白,想一想怎么了。 后来发现在设计的时候真的很蛋疼。 一些特别小的问题、在用户体验上一点极小的漏洞,都会产生巨大的灾难性的后果。真的除非把用户当成小白,不然设计出的产品总会被骂。 比如之前朋友做的产品的一个功能,是邀请有奖。用户 A 发二维码给用户 B,用户 B 扫码下载,注册成功再去输入邀请码,两边都有奖。就是中间有个环节,用户 B 扫码下载后,90% 都意识不到要去设置里输入邀请码。 虽然邀请机制在各种 APP 里都有我们认为大家都很熟悉了,虽然在用户 A 发给用户 B 的使用说明里都明确写好,但是用户就偏偏不去找,也不知道去找。 最后怎么办呢。把用户当成小白,设计中用户 B 扫码后先填自己的手机号,才能下载。这样记录下用户 B 的手机号,也就知道他是用户 A 邀请的了。后面就不需要用户 B 再输入邀请码了。 就是从产品设计上来说很小的改动,让这个功能的使用率上升了好几倍。 空白页的设计也是很好的防呆设计。比如相册、任务表等空白页里,可以提示用户点击什么/去哪里找到新建照片、新建任务的功能。是的,现在看起来都很傻,但真的很重要……估计众多产品同僚们有过血泪史。 像这个空白页,是分享过的内容,下面看起来像是废话:『你分享过的东西将会出现在这里。』不过没有的话,真的会有很多用户搞不明白。 再比如一个很经典的反面例子: 尼玛谁知道 USB Mass Storage Device 是啥啊。好,就算知道这个,『通用卷』又是什么鬼? 我百度过了,知道什么 Storage Device 和『通用卷』的意思了,那现在呢?我该干嘛啊? 国产的某应用的做法就形成了鲜明的对比。 防呆、把用户当成傻子,是产品设计的基本思路。并不是说用户真傻,而是他们越来越懒,并且希望找到最不需要动脑的产品。 这也是为什么 T2 发布会上老罗主打的远程协助功能引起大家共鸣。这个技术难吗?不难。这个功能之前没有吗?有啊。但是发布会里演示的效果就是操作简便,老人用起来不费力,这也是产品的竞争力。 说到用户越来越傻,其实大家都是有体会的。各种设计都在让大家少动脑、少动手,过去的电脑要经过专业培训才能用,现在的智能手机 3 岁小孩都可以快速上手。 4. 『要把用户体验做好,很不简单』 每次用什么产品,总觉得卧槽不就是几个按钮点来点去,几个页面切来切去吗?有什么难的。 用户体验的话,大家都差球不多,都没啥区别,比着搞一搞就行了。 后来才慢慢知道,原来看起来越简单、越自然的操作,就越需要更纠结、更慎重的考虑。 比如很多人用过聊天时会标注消息已被对方读到的功能后,就觉得自己想得比微信远了。大家都倾向于认为自己想到的别人没想到的,就是自己有理;而自己觉得应该没有,别人有了,也是自己有理。其实微信做这个是有自己的考虑的,他们的产品经理也不傻: 如果我们针对需求一个人去满足,你可能获取了这部分用户,但是得罪了另外一部分用户。有人就挺不喜欢把我的已读状态暴露给别人,你想这样的话,如果你的上级找你,你看了然后你又不回,就很麻烦。 我们要给人撒谎的机会,我们说人性是什么?给他撒谎的机会,说我没有看到。你看短信不太准确,我们经常会说,你那个短信丢了,我们没有看到。如果我们把人都像机器一样约束起来不一定是好事。 我们为什么不做已送达的状态?因为我们觉得未来的系统是绝对可靠的,我们有这个信心,肯定会送达,除非他关机了,我们不会再专门做一个是不是已送达,只有不自信的系统才会做这样一个状态。而且你每发一个消息还有个已送达或者发送中,那很丑陋的,多了一个东西在那里。所以这也是一种态度。对于这种用户要什么就给什么,其实这是考验产品经理水准的东西,因为我满足需求很容易,但是你怎么找到理由拒绝他,或者说找到什么方式实现它这个非常难。 也是从此之后,我对很多产品有了敬畏之心,不是想当然地跟大家扯皮:『这个 APP 做得好垃圾,你看这里XXX,你看那里XXX』。 真是做产品经理时间越久,就越发现自己的无知。比如很简单的可用性三个字,就有所谓的尼尔森十大原则: 一、状态可见原则 用户在网页上的任何操作,不论是单击、滚动还是按下键盘,页面应即时给出反馈。"即时"是指,页面响应时间小于用户能忍受的等待时间。 二、环境贴切原则 网页的一切表现和表述,应该尽可能贴近用户所在的环境(年龄、学历、文化、时代背景),而不要使用第二世界的语言。《iPhone人机交互指南》里提到的隐喻与拟物化是很好的实践。此外,还应该使用易懂和约定俗成的表达。 三、撤销重做原则 为了避免用户的误用和误击,网页应提供撤销和重做功能。 四、一致性原则 同一用语、功能、操作保持一致。 五、防错原则 通过网页的设计、重组或特别安排,防止用户出错。 六、易取原则 好记性不如烂笔头。尽可能减少用户回忆负担,把需要记忆的内容摆上台面。 七、灵活高效原则 中级用户的数量远高于初级和高级用户数。为大多数用户设计,不要低估,也不可轻视,保持灵活高效。 八、易扫原则 互联网用户浏览网页的动作不是读,不是看,而是扫。易扫,意味着突出重点,弱化和剔除无关信息。 九、容错原则 帮助用户从错误中恢复,将损失降到最低。如果无法自动挽回,则提供详尽的说明文字和指导方向,而非代码,比如404。 十、人性化帮助原则 帮助性提示最好的方式是:1、无需提示;2、一次性提示;3、常驻提示;4;帮助文档。 现在真的不敢随便说『用户体验不就是那么回事』这样的话了。 5. 『产品设计,尤其是交互和 UI,(大部分情况下)在一个产品中起到的作用只占 10%。』 这也是过去我嗤之以鼻的。牛逼的产品的交互和 UI,没有做得烂的,怎么可能起不到主要作用。 后来真的发现,如果功能不好用,再顺畅的交互、再华丽的 UI,都没意义。 比如聊微信,你发现数据丢了、记录没了,你是不会再用的;比如逛淘宝,你搞了半天都找不到想买的东西,你也不会再用。 再比如 12306,交互一塌糊涂(当然改版后略有好转),验证码烂到爆,更没什么视觉效果可言,但大家不得不用啊,因为能买票,买到票就行了。 还有像这个网站: 要是在意用户体验的同学,肯定已经要反胃了。但这可能是少有的广大男同胞都会使用的产品,因为只有这里能满足需求。 所以你看,12306 核心竞争力是垄断了票务,[敏感词]网站也是提供了其他地方没有的资源。交互和 UI 比起这些来微不足道。 这是一个方面,你会发现真的几乎没有人单纯为了交互和 UI 去使用什么产品。从另一方面说,互联网公司的成功之路上,产品设计相对于运营、推广、内容、资源,都是微不足道的。 你会因为滴滴打车那几个弹窗舒服、按钮合适就用吗?当然不是。用是因为补贴多,或者能打到车(有雄厚的推广资金和强大的线下运营团队)。 你会因为微信比别的社交 APP 简单、色调明朗就用吗?当然不是。用是因为大家都用啊,没得选(有海量的用户基础)。 你会因为支付宝的交互优秀、视觉突出就用吗?当然不是。用是因为安全啊,因为方便啊(有极佳的技术支撑和广泛的线下合作)。 有人会问,那为什么好产品的设计和交互都很不错呢?只是因为他们花得起钱雇高阶的设计师了而已… 6. 『产品经理要多看书、多学习。』 在入行前别人告诉我多看书多学习时,我不认可,我觉得产品经理应该多体验、多实践。 我当时想到证明我的论点的理由是: 互联网是千变万化的,产品经理又是很新的职业,过去的书和知识不能提供帮助 产品经理需要的都是软实力,比如逻辑判断、沟通能力、审美和创新能力 产品经理并不需要太多技能和成体系的方法,尤其是工具、流程和制度,没有通用的 只要够聪明,在摸爬滚打中同样能快速成长 于是摸爬滚打一段时间后,再开始看书、虚心跟牛人学习,才意识到自己犯了很大的错误。 按刚才的顺序,倒着来说。 关于成长 够聪明的确能快速成长,但是产品经理的工作周期很长,也不像工程师或者设计师,做的成果很快就能得到检验。产品设计和项目跟进做得好不好,很有可能是要通过长达数月甚至半年的检验。 自己摸爬滚打的成本很高,还是建立在学习能力足够强的基础上。 而产品设计或者项目跟进的工作,可不像写代码一样,调试时就会报错,甚至还会告诉你怎么改。产品经理的工作你可能做了一年,成果有好有坏,但你很可能不能发现原因,也不知道好的怎么保持、不好的怎么改正。 所以明明通过别的途径能少走弯路,却偏偏要靠自己撞墙来学习,这是不合理的。 关于技能和方法 确实没有通用的技能、工具和制度,比如有的团队喜欢 Axure,有的就喜欢 Keynote。有的喜欢把文档按照交互逻辑整理,有的喜欢按照功能逻辑整理。大公司讲究格式和流程,小团队追求效率。 这只是说浅层次的,在深层次的概念和方法论,却不仅可以算是通用的,简直要说是必备的。 比如刚刚说的用户体验中可用性的原则,再比如用户体验的五大要素(层次分类方法不一样,但道理都相通)。还有大致有几种图片排列方式啊、有哪些注册登录方法啊……这些海量的知识,如果不去有针对性地学习,很可能需要自己折腾几个月搞明白一个地方的做法后,才发现在知乎上别人已经答过了,看一眼就全明白。 前人的经验在这个方面显得特别重要。 关于软实力 逻辑能力、沟通能力等等,都确实是产品经理要具备的。但这些能力反而更需要系统去学习。 从逻辑方面来说,有的是能应用于日常生活中的逻辑科普书籍,讲社交和沟通的更多。其他的能力比如管理能力、组织协调能力,也都是成熟的大企业已经总结过成熟的方法论的。 这些仅靠个人领悟,不知道多久才能悟到书里能达到的水平。 关于变化 我在读很多书时看到例子觉得老,就有点嫌弃了。估计大家都有这种感受。书的出版周期很长,所以时效性难免差一些,不过主要是指例子。 在读了很多关于互联网、创业和产品的书之后,我深刻感觉到,除了例子很老,绝大多数的方法论、道理和逻辑,都是不会过时的。 这简直打开了新世界的大门。我翻了很多出版三五年,甚至七八年的书,发现现在遇到的问题居然都能得到解答。Web 时代的很多分析,用在移动互联网只是在实现层面有差别,在底层逻辑上完全一致。这也是为什么《用户体验要素》是差不多上个世纪的作品,过了 15 年仍然是产品经理们的必读书籍。 就拿《启示录》举例子吧。这是 2008 年的一本书,但关于产品设计的内容,到 8 年后的现在都是适用的。 比如很多朋友会问我的问题:『外包团队靠谱吗?有什么问题?』 书里提到(作者把外包成为定制): 长久以来,开发定制软件困难重重……虽然需求存在,但客户通常不知道自己想要什么……等到交付软件时,客户往往发现到手的软件和想象中的相差十万八千里,于是又要求开发人员修改,如此恶性循环,客户屡屡失望而归。 定制软件的客户认为自己了解自己的需求,所以不需要什么产品经理,他们也不需要用户体验设计师……客户不理解什么是用户体验,以及对成本过于敏感(让开发人员设计产品可以节约成本)。 是不是特别眼熟? 换句话说,这就是现在到处问『开发个 APP 到底多少钱呀?』『我让外包做的产品怎么不满意呢?』的土老板们遇到的问题。 他们既不理解为什么需要产品经理和设计师(不就是放几个按钮、画几个图标吗?),也不理解为什么外包团队总是做不满意(告诉他们大概的样子,实现不就行了吗?)。 我见过的所有的,真的是所有的,外包团队的作品,都会遇到这样的问题。 我再摘录几段话,看看是不是感觉特别有道理、特别眼熟。是的,这些在我之前的答案中都出现过。 许多产品团队没有意识到,或者很晚才意识到要转变工作重心。更糟糕的是,产品经理还时不时冒出新点子;公司高管认为产品文档还可以继续修改,导致开发要求大幅变更,严重影响开发团队工作。结果不是发布日期一推再推,就是某些功能被迫取消,或者产品质量下滑。 这段话说的就是我提过的『产品经理不仅要想点子,还要保证产品的实现』。 在我看来,每当团队内出现严重的意见分歧时,并非是大家对事实的认定有争议,而是对目标和目标的优先级有不同的理解。 这是我提过的『有争执时讲道理都可以解决问题,除非大家价值判断不同』。 我无法想象不深入理解用户需求,特别是在禁止与用户面对面交流的情况下,产品经理怎样打造出让用户满意的产品。 这是我提过的『任何事情都看用户的需求,做判断,而不是主观上做太多自以为是的设计』。 目前流行的研发模式通常是这样的:创业者想到一个好点子,得到启动资金后,马上招聘程序员开发产品。由于创始人最清楚要做什么,因此,他通常会扮演产品经理和产品设计师的角色。开发团队则按照他的想法实现产品。这些创业公司一般在『秘密状态』下运行,很少与用户互动。另外,由于产品需求和创意往往边做边变化,开发进度相对较慢。 这里面同时提到了创业中『创始人会兼任产品经理』、『创业过程中太过频繁改动需求』和『创业者过于关注自己的点子的保密性』的问题。难以想象,08 年美国就流行的事情,在如今的中关村和望京 SOHO 重新上演。 我看书的时候边看边拍大腿,一是因为说的太有道理了跟我想的一样一样的,二是妈蛋为什么没有早多些读书。 7. 『程序员总是会讨厌产品经理。』 不管怎么讨好程序员,他们总会讨厌你的,不用太担心是不是自己做得太差。协作中尽量公正就好啦。 具体原因?还用说吗。参见第一条。