以下，是我在知乎回复的一些问题的备份，记录于此，无他。不过，需要申明的是，这些都是我自己的理解和某些理想状态下的答案，肯定是有错误的地方的，想挑刺的就别看下去了，想探讨的欢迎留言。

问：产品经理的核心技能是什么？

答：我认为一个真正的产品经理应该是这样的：发现用户的需求并定义客户价值，同时准确传递这个需求与价值给团队成员，并推动团队去很好的满足这个需求最终将价值传递出去。所以，核心能力显而易见了

问：产品和运营的关系是什么？

答：我从一个产品设计师的角度来理解一下这个问题吧。
产品设计与产品运营之间的关系应该是，如果这个产品没有产品运营，依靠自身的产品设计用户一样可以玩的起来，在设计的时候就需要考虑去搭建一个生态循环；产品运营的作用是推动其更良好的发展，发现产品设计的问题及新机遇。
而产品运营的核心在于告诉用户他将要得到什么，而不是，他已经拥有什么。

问：在将Web产品移植到App的时候是如何砍需求的？

答：首先这个问题本身是有问题的，因为一个产品从web端到mobile端其实并不是简单的移植，同时也不一定全是砍需求，更多的时候会是变更或者添加。当然，既然问题是这样问的，那么，就问题本身而言，我的答案如下：
之前看过一本书叫做《简单法则》，虽不是讲移动产品设计的，但是确实给我很大启发，按照书中的原则，我大体提炼了一个方法：缩小——隐藏——附加——组织。
①把Web已有的功能模块全部列出来，排序；
②尽可能的砍，把可以减少的功能尽可能的减少；
③隐藏，把不可减少，但是并非十分必要的功能隐藏起来；
④考虑手机端用户需求与Web端用户需求的差异，然后附加一些手机端特有的需求与功能进去；
⑤有序的组织上述元素

最后，附赠一条发在新浪微博的微博，给走在产品路上的自己

你砍，或者不砍， 需求就在那里，不伦不类；

你排，或者不排， 优先级就在那里，不高不低；

你捋，或者不捋， 流程就在那里，不清不楚；

你分，或者不分， 周期就在那里，不紧不慢；

抓核心快迭代，或者大而全啥都想要；

用户，市场

需求，产品

P.s：我没有知乎的邀请码，请勿在回复中索要。当然，你要是愿意留言索要我也没办法，不过我不得不先告诉你，我已经将“邀请码”设置为Spam词了….

一直以来产品经理与交互设计师之间的话题不断，有人认为交互设计师可以算上是半个产品经理，也有人认为交互设计师的生存空间太过狭小，基本成了一个破画图的，等等说法不一而全。之前，我写过2篇文章大致来表述对于两者之间关系的我的一些观点，在“我理解的产品经理”中我认为产品经理需要同时关注产品设计、工程技术、产品运营3个方面；在“基于axure的PRD写作思考”中我简述了在没有交互设计师辅助的情况下产品经理如何做一个更像样的“破画图”的。今天，结合最近的一些项目经验，总结一下产品经理如何更好的跟交互设计师合作。

首先，我理解的交互包括2个层面的交互，单页面的交互和系统层面的交互。单页面的交互是最常见的对交互设计师的定位，比如把一个注册和登录页面做到极致，把一个搜索框体验做到最好；而系统的交互则是各个页面之间的交互，各个页面之间如何更好的联系在一起，目前显见交互设计师谈到这方面的话题了。

按照传统的瀑布模型，需求分析 – 产品设计 – 产品研发 – 功能测试 – 发布与维护 ，在这套流程中下一个节点必须在上一个节点完全搞定才可以开始。所以在大部分的情况下是产品经理先做需求分析，然后开始撰写足够详细的(注意这个程度)产品需求文档，交互设计师根据PRD文档开始做交互设计，完事后交付给视觉设计师做效果，最后交付给技术人员做开发。而在这个过程中，从最开始的需求到最终开发出来的东西往往很难保证其需求传递的准确性，也让交互设计师的生存空间大打折扣。于是，最常出现的情况就是“我明明想要的是齐天大圣，可是最后你却给了我一个孙猴子”。为了避免这样的情况出现，我们尝试将流程做了如下改进：

1、需求分析阶段

产品经理在产品调研及需求分析阶段产出一份调研报告，这个报告需要说明这个项目的项目背景、项目收益、需要满足用户的核心需求点、为了满足用户的这些核心需求，我们需要使用哪些功能模块。在这个过程中，产品经理只需要考虑如何最大程度最优雅的满足用户的需求，完全不需要去考虑技术实现难度。一定切记不要让某些技术思维使你的思维被僵化或者局限了！

在整个需求分析完成一次之后产品经理需要做的一个重要事情就是跟开发工程师确定需求实现的难度，哪些需求是立刻可以被实现的，哪些是需要长时间开发的，哪些时目前技术无法实现的，….。然后对需求做第二次的筛选与分析，同时试图寻找替代方案，目前无法实现的可以暂时存入需求池，排入工程师研发规划中。

2、需求第一次传递

需求分析迭代完成并通过评审之后产品经理需要开始将需求可操作化并做第一次传递。一般包括，需求的优先级排序、如何将这些需求衍化到一个可操作的产品中去、以怎样的形态进行展示等。在这个阶段需要输出2个东西，需求概述和产品架构图。需求概述主要对需求分析阶段得到的经过团队成员统一意见后的做总结，其实是继续准确的描述“解决什么人在什么情况下的什么问题”；而产品架构图则是该阶段最为重要的产出物，他是承载整个产品的根基，包括产品包括哪些模块，各个模块之间的关系如何等。

产品经理将需求概述和产品架构图交付给交互设计师，由交互设计师来完成需求的页面化,包括产品架构下的页面逻辑确定、单页面的交互逻辑确定。打个比方的话就像是产品经理提供给交互设计师一颗颗的珠子，并告诉交互设计师这些珠子的串联规则，而交互设计师需要完成的就是将这些珠子串联起来，以最动人的形式展示给用户。这个过程中，产品经理需要给交互设计师足够的信任，但前提是二者对于产品的核心需求点理解一致，由交互设计师主导完成珠子的串联，产品经理做方向把握。最终，产品经理和交互设计师共同接受原型评审，同时完成产品需求文档并做第二次传递。

在产品设计流程中，相对于其他环节的需求传递，产品经理将需求传递给交互设计师的环节最为重要，交互设计师对需求的理解和把握会直接决定后续需求传递的效果如何。

3、需求的第二、三次传递

经过上面的传递后产品需要满足的核心需求得到认同，产品的框架与产品逻辑都得到确认，在接下来的传递过程中，主要涉及到视觉设计师、开发工程师，问题已经不大，面临的一个核心问题就是排期。这里可以直接采用《用户体验的要素》中提到的方式“不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段的工作”

图片来源：用户体验的要素

另外，由于移动设备的特殊性，移动互联网产品设计较传统的Web设计又有其他差异，交互设计师、视觉设计师提供的效果不似Web设计可以在真机上完全模拟。所以，在移动产品设计中，必须要加入交互设计师、视觉设计师的真机效果确认。

絮叨了半天，其实总结起来就是这么几点：

1、满足什么人在什么情况下的什么需求之过东西，必须在每次传递的过程中被准确的传递，同时整个团队形成统一认知；

2、专业的人做专业的事，交互设计师是整个流程中最至关重要的需求传递环节，最好由产品经理提出初略的产品需求纲要，由交互设计师来完善这个纲要，然后向下传递

3、不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作

4、移动设备产品设计的特殊性导致必须要求各个环节最终效果都在真机上做一次回归

5、交互设计师是一个可大可小的职业，这，完全取决于你自己

首先，写这篇文章的一个重要性的冲动诱因在于我这个刚入行的移动互联网产品设计新手在查找资料的时候被太多的前辈恐吓了很久，我最终决定站出来反击一下。

我们看到无数的移动互联网前辈们说，移动互联网产品设计相对于Web设计而言实在太多限制了，太难搞了。你看，屏幕就那么点大小，当Web端主流分辨率停留在1024*768的时候手机上主流的分辨率确还是240*320（注意我是说主流，别说iphone4的640*960）；我们可以在Web上使用鼠标+键盘来顺畅的浏览而在手机上只有键盘（触屏目前还是灰主流吧）;当Web设计已经花哨到泛滥的时候手机上还是个梦想…..好吧，够了，够了，实在是够了

可是事实是这样吗？我不认为！我认为在手机上的设计要比在Web上的设计相对更简单。

更小的屏幕意味着你只需要考虑更少的内容设计；更单一的交互意味着你只需要思考更简单的信息设计和更单线程的流程设计；更限制性的硬件意味着你不再需要考虑哪些花里胡哨的“假动作”，你只需要关注是否能更快速的帮助用户解决需求就足够了…..

一般而言，在手机上的产品设计分为2类，从Web端移植功能到手机端、全部由手机端开始设计。这2类设计实际上都适用以下要说的原则。

一、拥抱约束，习惯在局限下设计

这是一句正确的废话，每个人都知道真正的自由并不在于完全自由，真正的自由在于完全自由与限制性之间的平衡。而这点在手机产品设计上表现的尤为突出。在手机端做设计首先必须要具备的思想就是阉割，当然，这点在Web端的设计上我曾经也认为是最重要的。

《简单法则》里提到一个方法，SHE：缩小（Sherink）——>隐藏（Hide）——>附加（Embody），然后把这些被简单过的元素有组织的放在一起。

以从Web移植产品到手机端为例，①把Web已有的功能模块全部列出来，排序；②尽可能的砍，把可以减少的功能尽可能的减少；③隐藏，把不可减少，但是并非十分必要的功能隐藏起来；④考虑手机端用户需求与Web端用户需求的差异，然后附加一些手机端特有的需求与功能进去；⑤有序的组织上述元素。

这样的做法既做到了简单，同时也避免失去了固有的价值感。这样一顿阉割之后你会发现，其实在手机端这样的环境下去实现这些功能是很简单的了，因为有太多不必要的东西都不需要了。其实，就是用最核心的功能去满足相对局限的条件，在做手机产品设计之前，最需要做的工作就是最小化和剔除不必要的工作。想好不做什么，然后再去做！

妥善的组织能使复杂的系统显得比较简单。比如iPod的按钮设计就经历了一个这样的过程，在最开始的时候iPod的按钮设计成了滚轮式的，在第三代的时候iPod将转盘外围的4个按钮抽出来放在了转盘的上面，变成了一排小按钮，这显然让iPod的交互变得复杂而混乱了，于是在第四代的时候我们发现所有的按钮重回转轮之上，并且完全一体了。这是一个典型的从一开始简单到变得复杂又简单到不能再简单的案例。

（图片来源：腾讯科技）

二、智者知止

过度设计这事这几年在Web产品上时有发生，仿佛产品设计师们觉得如果某个页面他们不“加工”一下就显得不专业，但是往往是越加工越不专业。 每一个设计都有它的核心诉求点（中心思想）和所有传达的信息，凡是引起用户感到迷惑和无关主题的信息都是需要避免的。哦对，这个东西有个专业术语，叫做“噪点”。

在手机端的设计上需要时刻跟“万一……，索性还是加上去吧”的思想做斗争。不为20%的用户需求买单，不因为20%的用户而丢失80%甚至更多的用户。最好的产品体验，我个人认为是用最简洁的方式，最优雅的满足用户的需求。

三、单线程浅层次的信息设计

因为更多的限制，所以手机上的信息设计无法像Web设计那样的无限制的以网状延伸，而必须是相对很浅的。不要在同一个页面里展开多个流程，使用清晰的布局，准确的提示等等。关于这点推荐围观@默契的这篇PPT 。

好吧，你可能意识到了，我并没有提到超过12000种终端的适配问题。是的，这是真正的问题，我跟你一样，都很无奈….但是，每个产品的用户群是一定的，也许，缩小范围后问题会相对简单一点。当然，也许你会认为未来类iphone的机器会成为主流，但是，别忘了，那是未来。而，事实就是这样！

前段时间千鸟写UCD概念在中国系列的时候，我跟他说你可以写个“产品经理在中国”，千鸟说这个事情太复杂没有经历去搞，等有时间的。于是，我一直期待到现在我想表达一下我自己理解的产品经理了……

首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是Product Manager，中文翻译为产品经理，简称PM。我试着从这2个缩写字母来理解一下目前的产品经理流派。

1、产品的经理。P：Professional，专注于做（Design）；M：Management，专注于管理。
2、产品和市场。P：Product，产品设计层面；M：Market，市场运营层面。

第一种流派是目前几个大公司的产品经理流派，每个产品经理最终的发展方向不一样，有专注于设计的有以管理为方向的，然后P1、…、P12，M1、…第二种是我自己杜撰的，基于我自己的理解，个人为人第二种缩写的解释会更适合我理解的产品经理。

产品经理是永远从需求出发的立足于产品的有良好运营思维并擅于团队作战的狼首领。

记得早前在微博上有一条关于产品经理的微博流传甚广，被转发很多次，我是这样回复的：“我们只是：开发里面最懂UI的；运营里更注重用户的；战略中比老板更知道从细微着眼的；销售中比运营更了解产品的；比谁的权利都低但比谁都会运用权利的；产品做好了最容易被遗忘的那个小人物”。这是我对我理解的产品经理的第一次概括。下面详细说下

1、产品经理首先必须要对所从事行业充分了解，先是行业专家。深度了解这个行业的用户行为、行业规则、行业特点，或者至少是资深用户，才能培养自己的同理心，才能把握住整个产品的发展方向，最终去做产品。

2、产品经理是个立足与产品有运营思维的人。之前我说，产品设计师都是自负的，他们思考问题的方式在于这个事情应该是什么样子而不是他现在是什么样子；工程师同学永远都会先考虑功能实现然后考虑是什么样子；而市场运营同学考虑问题在于老板给我的预算额度是一定，我怎么分配这些市场费用能够达到收益最大化。所以，产品经理同学就必须兼备以上的思维，在做某个决定的时候同时“人格分裂”的从这三个方面考虑一遍。

在产品团队中，产品经理必须时刻记得问自己这样几个问题：我的核心用户是谁？他们在什么情况下有这个需求？这个产品的目标与期望值是多少？并且，要让整个团队的人都有问这几个问题的意识。需求，永远都是最根本的，如果产品经理搞不清楚这个事情，那么交互设计、视觉设计、工程师都会跟着错！产品经理草率的告诉交互设计师说我们需要上一个某某功能，交互设计师有责任有义务询问产品经理，为什么要做这个，给谁做？然后才是开始去做设计！否则就只是个工具。

3、产品经理要在团队中扮演寻找满意解的角色，而不是最优解的角色。如上图所示，产品设计、市场运营、工程技术3个部门关注的产品的点是存在重叠的，而产品经理就是去发现这个重叠的部分并很好的利用这个重叠的人。

满意解的意思在于，产品经理是基于“权益”的标准来进行团队沟通的，而不是基于权利或者权力，这个解需要平衡团队所有成员的权益。所以，我一直认为，“马化腾、史玉柱等是中国最好的产品经理”的说法是有问题的，他们应该被叫做“拜用户教”教徒以及“UCD型Boss”，他们算不上产品经理。

4、产品经理的核心技能在于沟通与控制。团队以及合作的观念必须时刻具备，当团队里每个人都受到鼓励、赋予了权利并且被尊重与信任的时候，团队就会有最理想的表现。从另一个层面上看，以团队意识为核心的结果往往会是没有核心，平衡了各方的利益之后，往往把本来最有利的部分完全抹杀了，敢于拍板和为自己的决定负责对产品经理来讲很重要，也就是要讲究控制，或者按照百度的话说叫做“和多数人商量，听少数人意见，自己做决定”。记得之前有位前辈给我推荐过一本书《只有偏执狂才能生存》，受益颇多。

你可以有某个领域不会，但是，你要有能力指使会的人去做。当然，也有必须什么都去做的产品经理。我把国内目前的产品经理分为两个类别：有UED支撑的产品经理（雌雄异体）、全能型产品经理（雌雄同体）。在有UED支撑的情况下，产品经理不太需要去关注产品具体的设计细节，产品经理更加偏重于如何去沟通，去解决问题；而没有UED支撑的产品经理更多的在于学会如何最大限度的利用资源，由于从设想到实现几乎都是一个人来做，所以，偏颇在所难免，寂寞是产品经理最要命的敌人。

5、产品经理一定是最爱自己产品的那个人，并且，我觉得只有自己一个人爱是不够的，同时还需要让整个团队的成员都植入这个观念。这种爱不是溺爱，我觉得有2个方面：擅于且敢于主动的自我阉割，开放的心态接受一切批评意见；不断的向大家介绍你的产品，并推荐之。为了爱产品需要有狼性，如我在微博上所说，产品经理应该明白，资源是靠“打砸抢”得到的，别指望别人施舍；社区的运营与产品设计者也应该明白，要做好社区就必须要有铁血政策，特别是在一个充满刁民的社区，当然，对部分意见领袖的怀柔也是必须的！

6、产品经理需要关注细节，但是不能纠结与细节。这点其实不用上纲上线，写出来只是警醒一下我自己。

没开始写之前我觉得我想的挺明白的，可是写着写着发现这些话好像是直接对我微博上说的过的话进行总结与摘抄，然后再读一遍发现好像都是废话…..不过，好吧，也许最难做到的就是那些正确的废话了，我还是记录下来了，我会不时回头看看我走过的路我思考过的痕迹的

故事1，我要的是葫芦

小D：小Q，我需要一个没有籽的葫芦，能搞定吗？
小Q：葫芦是可以搞定的，但是，没有籽的目前无法搞定，不过，搞定是可以的，但是需要很长的时间。
小D：都是男人，直接点，我在一周内需要，能不能搞定吧！
小Q：这个很复杂，而且目前的工艺还不具备，所以，我实现不了。
小D：好吧，我早就听腻了，我要的是葫芦而已，你跟说其他的有什么用？

故事2，放心大胆的去挑礼物吧
小Q：小D，去挑礼物吧，拣你最喜欢的拿，我付钱
小D：好啊，我喜欢那个2K的兔子
小Q：不行，我只能花20块，重新去挑吧
小D不依不饶又哭又闹，事情变得无法收场了….

故事3，我们种苦瓜吧
小M：小D，小D，隔壁种了苦瓜耶，不少人去围观了，收效不错哦，我们也搞颗来玩玩吧
小D：呃，苦瓜不适合出现在我们的园子里，而且，来我们园子的家伙们不太适应苦瓜的味道哦
小M：为神马，为神马？为神马隔壁搞苦瓜就能火呢？再说了，等我们种了他们自然就能慢慢接受了，说不定能把隔壁的人拉过来呢
小D：……

故事讲完，聪明的你一定也能看出来了，这里小D是个典型的设计师、小Q是典型的工程师、小M是典型的市场运营。是的，就是他们，上面三个故事讲的就是他们三个之间的世世代代都无法理清楚的剪不断的纠葛。

在 传统模式的团队里，市场运营人员从市场的角度来分析产品概念：谁需要某种产品，谁会购买这个产品，产品讲如何被供应和销售，其成本是多少；设计师根据产品 的卖相（视觉）和人机工程学等方面的知识进行测量，设计师更注重的是某个事物应该是什么样子而不是它现在是什么样子；工程师则只会专心的考虑产品技术创新 方面的概念问题，以及开发的技术成本。在这样的产品研发模式下，各自独立的专业分工，不可避免的就是出现三个中心。这也是上面三个故事出现的根源。

首 先，我们必须承认上述分歧是天然存在的；其次，这种分歧实际上对产品团队是有利的，当然，这种分歧是必须要控制在工作范围内的，工作范围外的分歧必然会危 害整个产品团队的发展；第三，控制这个分歧的理念应该是“以用户为中心的设计（UCD）”，而具体执行的家伙应该是产品经理。

一般而言，解决团队的分歧会动用三种手段，分别是：权力、权利、权益。

以权力为基准的协商过程，简单说就是动用等级制度强迫别人做他们不愿意做的事情。其结果必然是产品相互间的矛盾，在协商中输掉权益的一方在今后的工作中往往会需求反击的机会，最终损害整个团队的运转。

以权利为基准的协商手段是运用各种已有的标准、和观点等来解决纷争。这里往往会有输掉冲突的一方，或者必须选择一种折衷的方案。虽然协商各方的权利在设计过程中都有他的地位和作用，但是这种方法得到的结果往往都是常规的，缺乏新意的。

以权益为基准的协商反映了与项目相关的每一个人所关心、期待和需求的事情。我们了解每个人的喜好和工作重点，找到消除障碍的权益措施，从而使所有人所有专业的权益得到兼顾。而更重要的一点在于，用户的利益也被考虑到其中了！

如果我们使用一种以权益做基准的协商手段为主、适当的时候结合权利基准、不得己时小心动用权力的团队协作方式应该可以得到团队效率的最大值。

所以，在一个团队里，我们应该鼓励任何人拿下面的问题去问任何人（注意，是任何人都可以这样问，特别是产品经理最需要被这样拷问！）：我们这个产品的核心用户是谁？我们是在什么情况下，满足他们的什么需求？这个产品模块的市场目标是多少？我们面临多大的技术难度？

最后，四个问题的答案必须的是理性的（有数据支撑的），而不是以“XX这样说”、“我认为”、“以XX的经验来看”。正确答案的格式是：“根据我们拿到的数据进行分析…..”、“我们做的用户访谈说明….”、“根据市场预测并且基于我们产品的成长….”

记得很早的时候我在微博上说过这么一条：“每个产品设计者都必须是一个善于自我阉割的完美主义者！既要想到产品每个犄角旮旯中会出现的问题及预防措施，也要根据市场、技术等限制因素的限制对可能出 现的问题进行舍弃以保全大局。”

有的时候想想，很多事情之所以珍贵或者说弥足珍贵就在于那敢于自我阉割的惊艳。

比如，爱情为何让人觉得如此圣洁，堪比金坚的爱情为何万世传颂，其根源就在于，当你选定了一个你爱的人之后，你的心里就再无法放心任何人，TA就是你心里的唯一，从那一刻起你想的就只是为TA了。换句粗俗的话就是，你为TA放弃了整个世界，阉割掉了所有的关于“爱情”的情感，你会去主动拒绝任何异性对你的诱惑。这是一种难能可贵的品质与需要极度责任感的事情，如果怀着这样的思想去经营爱情，那必是让人艳羡的。

说回到产品上来，之前记得我写过的一系列读书笔记中讲到“产品的机会缺口来源于不断对社会趋势（S）、经济动力（E）、先进技术（T）三个方面因素（SET因素）进行综合分析研究”，由这3个因素相互作用会出现很多的缺口。那么，当我们发现这个缺口的时候该如何处理？

个人感觉，想明白做什么不算什么，想明白不做什么才是真正考察一个产品设计者能力的地方。

按照我目前的操作手法一个产品从预感到机会的出现到最终上线会经过这样的步骤：间谍——（阉割）——演说家——（阉割或反阉割）——雕刻家——（阉割）——救火队员——（阉割）——打磨师。

简单说就是这样的：

»当预感到这个市场存在的时候，先伪装成用户潜入到这个潜在市场的目标人群中，观察他们，明确他们的需求。在这个时候数据的作用只用在告诉我这个市场预计有多大，但并不能告诉我用户的真正需求在什么地方，不尽信数据。

»获取到用户的需求，根据这个需求想到能够做出A、B、C3个产品来完全的满足他们，并获得市场占有率。对这些需求进行排序，与现有资源与企业战略目标做匹配。阉割掉那些对目前战略目标没有促进意义的，目前不做死不了人的，目前团队没有精力做的功能，实现第一步阉割。

»拿着被第一次阉割的需求做需求研讨，先做团队内部讨论再到Boss那讨论。这个过程中其实就是个演说家的角色，力求团队的人首先要达成一致目标，然后去PK老板，当然，这个过程中会有第一次被阉割掉的需求再次被提上来，抗住！（如果实在扛不住，那好吧，你可以试着弱化它…）

»根据团队明确的需求，进入产品设计与研发阶段。在这个过程中会有小部分的需求被阉割掉，源自技术的压力以及市场的变化。当在与技术部门周旋的时候，如果一个产品设计者在最开始的时候只做了一套方案，那就会永远被他们牵着走。善于与技术妥协是门艺术！善于妥协意味着原型必须是炮灰，而最终目标（核心需求）一定不能变化！这个阶段实际上就是个雕刻家的角色，小步慢跑，同时要调动资源，平衡利益。

»在产品进入测试阶段开始，需要准备与运营部门联姻了。告知产品的运作机制，产品的亮点与卖点以及怎么卖卖相比较好。同时，进入救火队员的角色，因为根据经验，每个新产品都会有个死角在测试的时候是不会被发现，每个产品都会有让用户痴迷而我们没注意到的地方，所以，如果产品上线不被用户骂，那只能说明产品足够差或者产品压根不被重视。这个时候，要顶住，如果他们骂，就努力让他们多骂一些出来，然后悄悄改掉。根据经验，往往骂声最高的用户也是最愿意为你做口碑宣传的用户。

»OK，现在上线了，但并不意味着结束，恰恰只是个开始，因为新的一个循环开始。这个循环我把他叫做养孩子，就像恋爱谈完了，婚也结了，孩子出来了….一个有生命力的产品是每天都会有变化的产品，当然，肯定不会是在前台，更多的是在后台的优化….

所以，我最近常常感觉，做产品设计，其实就是个自我阉割的过程，越是优秀的产品设计越是善于阉割。

在我憋着一口真气一鼓作气的敲完上面的字之后，兔子跟我说，你这不是教人犯错吗？我想，肯定会有人没看完就直接说，你的意思就是让人一直砍一直砍，砍到最后就只剩下个小裤衩了呗….

其实不然，这篇文章的核心不过一句话耳：审时度势，在正确的时间做正确的事情，顶得住诱惑。阉割掉的需求不等于全部抛弃，有的是需要扔进“需求池”去浸泡的，在适当的时候再返回来考虑。在产品设计阶段，其实还是之前说过的那篇：做最多的，展示最好的。如是而已…..

P.S：最近思维比较混乱，所以说的很不明白。其实，我只是认为一个好的产品经理至少需要具备这样几点：有产品信仰，不惟钱；有理性思维，不惟心；知道变通，不惟己；有坚持，不惟他。

这篇是读《好玩心理学》与《决策与判断》两本书的读书笔记。

首先，我们需要在一个问题上达成一致：我们并不是孤立地去感知和记忆某个事件，而是根据过去的经验和事件发生时的情境去理解和解释新信息。换句话说就是，在不同的情况下，同一个人对同一刺激的认知可能完全不同。这个就是心理学上常说的“情景依赖性”，他主要有四种表现方式：对比效应、初始效应、近因效应、晕轮效应。

对比效应也叫做感觉对比。这是我们最常见和最容易被感知到的一个情景依赖性行为。由对比效应引发出来另一个心理学效应叫做错觉，常见的是错视。
值得注意的是对比效应也是产品设计中最常用的一个设计原则；而销售中也常常运用这个效应，比如商家在劝说用户买下其想要出售的房屋之前，常常会让买家看一所破旧不堪或者标价过高的房子，以利用二者之间的对比效应。

首因效应也叫做初始效应、首次效应、优先效应或“第一印象”效应、开头效应等。
与一个人初次会面，45秒钟内就能产生第一印象。这一最先的印象对他人的社会知觉产生较强的影响，并且在对方的头脑中形成并占据着主导地位，这就是我们常说的，第一印象非常重要的道理。
这个效应没有必要做过多的解释了吧。不过，提醒注意的是，首因效应往往是不靠谱的，所谓，路遥知马力日久见人心….

近因效应也叫做新颖效应。事实上，初始效应是有关进入位置及其对判断的影响的一个总体描述，在多种刺激一次出现的时候，印象的形成往往主要取决于后来出现的刺激。即交往过程中，我们对他人最近、最新的认识占了主体地位，掩盖了以往形成的对他人的评价。
如果人们连续的列出有利原因和不利原因，就会产生很强的初始效应；但如果人们在列出有利原因和不利原因之间有3分钟的间隔，就会出现近因效应。这个技巧也在销售中被广泛应用，销售者常常会鼓励顾客列出购买原因（有利因素）和不购买原因（不利因素），如果在列出各自原因之间没有间隔，顾客就可能在无意间受到初始效应的影响。
近因效应的一个主要表现就是顺序效应，当某一答案出现在所有备选答案最后的时候其被选中的概率最高。当然，这个效应跟被问者对该问题的了解程度成反比，当被问者完全清楚这个问题的时候，这个效应几乎不存在。

晕轮效应也叫光环效应。人们对他人的认知判断首先是根据个人的好恶得出的，然后再从这个判断推论出认知对象的其他品质的现象。如果认知对象被标明是好的，他就会被好的光 圈笼罩着，并被赋予一切好的品质；如果认知对象被标明是坏的，他就会被坏的光圈笼罩着，他所有的品质都会被认为是坏的。这种强烈知觉的品质或特点，就象月亮形式的光环一样，向周围弥漫、扩散，从而掩盖了其它品质或 特点。我们用一句成语来概括的话就是：爱屋及乌。
苹果公司之前推出的imac、macbook、ipod、itouch等不论在品质、设计还是易用性上都得到了较高的赞扬。前几种产品的良好形象为苹果公司制造了一个光环，在这个光环的照耀下，消费者对其推出的其他产品也抱有很高的期望，这就是一种典型的光环效应。
当然，我们目前见人就说美女、美女经济学等现象其实也是一种光环效应….

情景效应处处可见，以至于我们常常会忽略他的存在。知觉本身就是具有选择性，因此在做任何重大决策与判断之前，很值得停下来想一想这些问题：
我看待实物的动机是否收到了某种动机的驱使？我在看待和处理问题时是否夹杂了自身的预期？我是否与那些与我有不同预期和动机的人交换过意见？

读《明朝那些事儿》，朱棣起兵造反欲取建文帝而代之，在离胜利只差一步的时候，朱棣陷入思维陷阱。朱棣得知京师空虚，如果此时出击京师必可得胜，但是此时朱棣在北平建文帝京师在南京，而在通往南京的路上，最大的障碍就是山东，此地民风彪悍，士兵作战勇猛，而且还有名将镇守，无论如何也是很难打过去的。在朱棣看来这是一个很难克服的障碍！

于是朱棣很郁闷，欲取建文帝需先取京师，欲取京师则必取山东，但是，山东无法撼动。朱棣倒推了一下，发现，自己没有希望了…..
就在朱棣钻入思维牛角尖的时候，谋士告诉他，我们的目标只是京师而已，去京师又不是只有一条单行道，条条大路都可通京师，我们为什么不绕道山东过去呢？朱棣恍然大悟，遂引兵南京，夺了江山…..

当年明月认为，这里山东就是朱棣的思维盲点，朱棣对江山、京师、山东三者关系的推定就是思维死循环。读到此处恰逢近期也遇到类似的事情，颇有感受。
4月的时候我的房子会到期，过年来了之后我和室友连想到没想直接准备换房子搬家，于是我们找了约半个月的房子无果。我们的问题是，我们可以接受房租比去年稍贵的地方，但必须离地铁近。于是我们拿着这2个标准去对照，发现，根本没有办法做到，地铁边的都超级贵，便宜的都质量很差，同时不满足交通。
就在我纠结与房子的时候，有天我突然问我自己，我为什么要搬家？我搬家的目的是什么？是为了上班方便，同时房租不贵。OK，那，我现在住的地方算不方便吗？不算！那，我现在住的地方房租算贵吗？虽有涨幅但与寻找新房相比相当能接受…..

靠！问题回来了，那，为什么要搬家？又折腾又难找…于是，我说服自己继续住这里。

在做产品设计的时候，我也会经常钻牛角尖，当由于技术的或者其他的阻力的时候我发现我无法按照之前的构想来继续设计，于是，我不断的对之前的那个想法进行改良，不断的堆加新的东西进来进行补充与完善以求可以实现，最后搞的自己累的要死。
突然有一天睡觉之前，我问自己，为什么花这么大的力气来做这个模块或者这个交互？目的是什么？最后发现，靠！完全可以舍弃他，对核心功能没有影响啊，遂释然….

2010年3月的UCD书友会话题是“设计的沟通与协作”，在说到如何向团队成员表达你的设计意图的是时候，Angela提到应该先再次的向团队成员统一我们为什么要做这个？然后再开始布道….其实，也是这个意思，永远不要忘记问题的核心点，不要被横着的马其诺防线挡住，可以试着把他竖着来看！
如果在做产品设计的时候把现在做的东西与我们的目的进行比对，或许会避免出现很多不必要的思维盲点。以此共勉。

是的，我是个抄袭型的互联网产品设计师。

这点我毫不否认，如果某个产品模块我不会设计，我会毫不犹豫的拿我竞争对手的或者类似的产品来进行抄袭。然后把做出来的东西交给我的用户来做检验，最后修改与完善。

我的抄袭过程大概是这样的：

1）求同
拿到某个需求之后进行分析，并与我脑袋中储存的我用过的我见过的产品进行比对，如果没有就去搜索。发现我现在做的产品和我之前用过的产品的相通点。

2）存异
认认真真的使用一次存在与我现在做的产品相通的产品，去看大家对他们产品的反应，以及我用我自己的观点和掌握的知识做出判断。看哪些是他们做的优秀的，哪些是他们做的不好的，哪些是对他们而言可行但是却不能放在我的产品上的。
比如，Gmail的邮件功能做的很强大，防spam模块也很赞，但是，类比这个去做电子商务网站的邮件系统，那就绝对是得不偿失了。

3）组合
研究完所有类似功能的产品之后，我会发现A家的未登录提示做的很赞、B家对于文案的优化很合人心、C家的信息架构很牛掰。然后我需要做的就是把A、B、C三家的优点做综合，然后分开抄袭。
是的，完全抄袭一家的产品是低级的抄袭，也是不认真的抄袭。

4）优化
也许D家的类似产品的创意很棒，但是做出来的东西实在太烂了，用着超级不爽。我就会选择把他的创意抄袭来，然后进行优化。
比如，之前做电子商务平台商铺系统的时候，有个小站搞了个“邻家铺子”的小功能。但是，点击“邻家铺子”按钮的时候他只是对所有的店铺进行一个按顺序的在新 页面打开而已。我觉得这个创意太牛掰了，但是这个设计太糟糕了。于是，我也做了个邻家铺子的模块，我把规则修改成从与当前用户浏览的该店铺的同类店铺中随 机打开一家进行展示，既达到了邻家的目的也做到了契合用户兴趣。

5）修正
当把这些抄袭来的东西进行拼装之后，属于我的抄袭作品就出来了。它看着像是披着A产品的皮，拿着B产品的刀，走着C产品的步子，还比D产品多戴了顶帽子。但是战斗力如何则是由我的用户说的算。
快速上线之后，通过后台流量的监测、用户的回馈、相关领导的意见等等就能知道这个组装出来的家伙是变形金刚还是坨泥巴了。这个时候你也知道问题点出在什么地方了，迅速做出判定，然后修改之。

概括来说，这就是我的产品设计迭代理论。个人觉得互联网的产品设计首先是个快速迭代的过程，其次是个不断的被抄袭、抄袭、再被抄袭这么一个大的迭代过程，整体来看是一个螺旋式上升的过程。
而决定你是否能够成为一个优秀的设计师的条件是，你是否能“抄越”。因为抄习，所以抄越！

当然，不排除你是天才的产品设计师的可能，那么，如果你是个完全就只按照自己脑子里的设计想法去设计而不会参照任何其他人的产品的设计师，请，尽情的鄙视我吧，我完全真诚的接受你的鄙视！

附注：“抄越”一词我从我们团队的一个美女那听来的，后经bian和白鸦同学的演化就成了，“因为抄习，所以抄越！”

最后，用毕加索的一句话结尾：Good artists copy, great artists steal——Picasso

事件缘起，哥们让我去观摩一个网站，然后跟我说，这个网站很牛掰的，值得我们学习。
我去溜达了一圈就出来了。因为我发现无论从信息架构上和体验上还是交互设计上都算不上出色，而且视觉上还略显简陋。
若干时间后，哥们问我，看出什么门道了吗？知道他们的牛掰之处了吗？我茫然，说这个站点很一般啊，没什么值得我们学习的吧…….
哥们听完大笑，然后跟我说了其中的门道。听完我真是拜服的五体投地，彻底的被洗脑了一回。

这个感觉就像是看魔术表演，魔术师表演看着很玄幻，搞的他跟个神仙，一旦那个原理被揭开，我们就惊呼原来事情那么奇妙。比如，我们看Gmail，从表面上看他足够简洁，但是功能足够强大，强大到你想到什么他都能提你实现了。我们从表面上能看到的只是Gmail简洁的界面，优秀的用户体验，然而，其背后的东西呢？我们都看不到，那么Gmail的核心竞争力何在？是仅仅简单的界面与架构吗？显然不是！

核心竞争力是个不断被诠释和放大的东西，到底什么是核心竞争力？是Google的简洁？是淘宝的免费？是支付宝的可信赖？是目前电子商务B2C的便宜？
不，这些都不是，核心竞争力恰恰是那些无法被局外人看到的东西，是无法通过模仿得到的东西。
外界总是在说腾讯在模仿，但是他从来没有模仿到别人的核心竞争力他也无法模仿到。当然，他能成功，这是他自己核心竞争力的体现，之所以，我们之前没有发现腾讯的这个核心竞争力，恰恰也是因为，看到的都不是核心竞争力！我们总是看到腾讯在模仿，却没有关注腾讯在模仿的背后的巨大的力量。当我们的目光总是落在外在的时候，我们是无法读懂他的。

看到的都不是核心竞争力，更何况，往往，我们连看都没有仔细的看，所以，我们永远无法超越。

所以，不要去相信什么观察家，观察无法出真知。观察到的东西是最肤浅的现象，是人家故意走光给你看的。
我是个会不断有不同的ideas的家伙，几个月前，Tony和千鸟对我做了个会诊，结论是：我是个缺乏实践的可以培养的学生。那个时候，我总会通过自己的一点观察就下结论，现在等我深入了，我越来越觉得，那个时候自己多肤浅啊。
当你观察的时候，你时常会从一个很单一的维度去做判定，当你深入去做的时候，你发现，原来这个设计是多个维度权衡的结果，而你之前作出判定的那个维度跟其他的点合在一起的时候，那个点是可以忽略掉的，因为，平衡之后的设计是最优化的设计。

假如，我说假如。
有一天，我们产品设计师们都没有底薪了，也跟销售一样按照提成拿工资。我们的提成算法是我们设计的一个产品模块给公司带来了多少收益，设计师们根据这个收益进行分成。
我们对注册表单的改进为网站增加了多少注册用户；我们对购物流程的优化提高了网站多少转化率；我们对首页的信息架构重构提高了多少PV；我们对一个按钮文 案的更新增加了多少销售额；我们对一个小细节做体验的改进减少了多少跳出率；…，所有这些产品的改进、设计给公司带来了多少效益，然后根据带来的效益 来确定设计师们的提成工资，我们的设计状态会是怎么样的呢？
这个想法来自于今天下午一个会议之后，我突然想到的。

设计师们总是在说UED，在说以用户为中心，但是，实际上设计师恰恰是对用户效益最不敏感的一个职业，一直以来。
设计师的产品做好了，市场容易开拓了，运营也好做了，销售更是可以把黄金卖成钻石价钱。但是，设计师们呢？设计师们看到每个月市场与销售们春光满面，看着 运营越玩越有意思，他自己实际上是没有太过直接的感受。说的再露骨一点，没有金钱的刺激，他们感受不到他们好的设计和他们不好的设计的差距。目前好的设计 与坏的设计对于他们最直观的感受就是，看是否有用户站出来骂，是否有用户偷偷的叫好，看老板心情爽不爽。
我再继续把我的观点低俗化一点。想让设计师关注用户，从用户出发有2个可能，设计师本身有深刻且正确的UCD信仰，设计师受到直接的利益的刺激(工资)。

不知道是否已经有公司这么玩着呢？你们玩的怎么样？不过从现在开始的时间里，我要这么玩下去了……