在最早的时候产品设计大多采用瀑布模型方式做迭代，上一个流程完毕之后才进入到下一个流程。这种模式有一个最大的好处就是下一个流程的准备相对充分，但是缺陷也显而易见，那就是迭代成本太大且显得笨重。随着互联网行业的发展，“快”成了这个行业最重要的一个口诀，于是类似“唯快不破”成为大受追捧的产品设计哲学。于此同时，很多项目的设计周期被缩短。

在这个快字的指导下我们省去了对详细MRD的撰写，采用了列出功能点的方式向研发团队讲述整个产品的逻辑与核心需求点；因为要快速，所以我们采用初略原型的方式直接像工程师展示我们需要的产品架构和页面逻辑；因为要快所以产品人员在描述的时候很激昂的描述了我们要做的高优先级系统，并且说这些系统是我们最至关重要的地方，我们高优先级先把这些重点搞通；研发人员在听完整个的需求描述与初略的原型之后迅速做出评估，给出研发排期，于是群情亢奋的就开始干了……

这一切看上去很美好，不是吗？我们比以前快多了，我们也有突出的重点了。但是事情真的是这样吗？

当大体的排期做完了，需求也通过了。下面研发人员开始做后端的架构和程序逻辑的架构了，产品人员开始对之前的需求做梳理，对原型做细化，设计师也开始尝试视觉风格了。这次我们采用了并行的方式，我们要比之前进步多了吧。

很多时候，事情就是这样奇妙，不梳理不知道一梳理吓一跳。原来当时我们在考虑展示部分的时候没有考虑到不同的用户流导向的页面不一样啊；原来一个简单的数据提交过程有如此多的分叉口并导向不同的后端数据处理策略。产品人员认为，这些都是应该重新归纳出来的，于是之前一个展示页面被细分为N个不同的展示样式；之前的一个提交流程被分拆成M个不一样的处理策略。挨个模块的这么梳理下去之后原来简单的一个原型被弄的好生完美，原来一个看似美好的页面结构被修剪的异常丰满。而之前产品人员认为“比较简单，重点突出”的系统被证明是一个很复杂的很重的系统。当然，这个过程是后端工程师和产品设计师共同梳理完成。

这个时候，问题出现了。按照之前的需求描述和原型讲解研发工程师预估的时间在每个系统上都多出来了一倍多。产品人员在不断的“完善”页面逻辑和产品架构，研发工程师在不断的增加研发成本。最终，当研发周期过去大半的时候我们发现，靠！刚做完第一个阶段…..于是，大家都急了，咋办？！砍功能吧，把低优先级的东西先干掉，先做“核心”的事情。一阵的手忙脚乱之后，还是比预期的晚了几周，上线了一个勉强过的去的版本。

那么，在这个案例中整个产品研发过程的问题出在哪？自我反思，我认为是产品人员造成“细节黑洞时间”过长，导致工程师对研发过于乐观，项目开发周期评估失常。不过，问题的症结还是在于快的过头了，因为快所以忘记了一些虽然笨重但仍旧行之有效的方式。

在需求的初期，产品人员并没有能够很好的将业务逻辑转换成产品逻辑。整个业务的核心链条是什么？用户被什么动力所驱动，这些动力在产品上由什么来体现？围绕这个核心链条哪些是我们必须要做的产品模块？

业务逻辑的转换凌乱必然导致产品大的架构凌乱。按照我个人的习惯，在任何一个产品甚至产品模块开始之前都需要先画一张产品架构图，这个架构图会存在在MRD的最前面和原型图的最前面。这样有2个好处，产品自己可以很好的梳理整个产品的结构及每个支点如果有风险会影响的范围；需求被传递的时候下一个流程能够先很清晰的有所认知。

当大的产品架构出来之后接下来要做的事情是按照每条支线模拟一遍流程，使用流程图的方式来做，每个模块都需要。一般的处理方式是直接用相关的页面原型来走流程图，每个页面的下一个页面是什么，有几个支线，分别导向了什么页面。这样走一遍之后就能最大程度的避免“细节时间黑洞”。

是的，就是这样，因为要快，所以我们在赶进度，我们忘记了产品逻辑，凌乱了产品架构，忽视了页面流。这部分时间在排期的时候被忽略了，而这就是个大大的细节时间黑洞，这个黑洞影响着我们每一个产品。如果在研发过程中，我们发现之前的逻辑是错误的，那么问题将更加严重……

当然，这个案例中提到的情况还是相对可控的，因为产品人员有相对独立的控制权。如果再有权力高层掺合进来，不断的增加功能，不断的释放需求，那么，整个产品研发过程将更加糟糕了。最近微博上流行一张图，那才是真正的纠结（点这里围观）

最后，提到“唯快不破”，忍不住多唠叨一句。不要被“互联网产品唯快不破”带到沟里了，这句话原本没错，但是要注意2个前提：第一枪一定要打响，不然以后你就算再勃起的高也没人看了；在快的同时需要考虑自己是否有能力应对“快问题”并及时完美解决掉，是否有足够精力应付快之后被拉长的战线，不然就是快刀子也容易剌到手！

特别说明：细节黑洞时间这个词来源于一条微博，作者画了一张很大很纠结的一个产品研发流程。看完颇多感受，结合自己的感受写出了以上文字。

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

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

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

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

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

问：在将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的经验来看”。正确答案的格式是：“根据我们拿到的数据进行分析…..”、“我们做的用户访谈说明….”、“根据市场预测并且基于我们产品的成长….”

关于看图说话这个固定的栏目从我的博客搬家到新浪微博了我的ID：@kentzhu ，平时抓到的图也都会先放到新浪微博上，然后以合辑的形式放到我自己的博客上来做存档，由于图片较多，加载缓慢，如果各位看官已经看过了请自动忽略，多谢

1、从@YesKafei同学的微博看到的一张图。饭店的盘子等也经常有特别的设计，真是聪明绝顶的设计师。

2、Android耳机的一个小细节，在外侧只有右耳有个小标志，在对比的同时降低了用户的使用成本；同时，很多耳机只在内侧有R,L的标识，也就意味着戴耳 机前要先翻一下，用户使用成本太高…

3、每次看到这种柜台，坐下之后就会有莫名的压 抑感…..取材与交通银行

4、来自必胜客的点餐单，汤与饮品的记录方式采用了格线形式

UpData:有同学问我这个点菜单有什么奥妙，我解释一下：这个单子是负责记录客人点菜和负责上菜的服务员之间传递信息用的。因为披萨等是公用食品，所以不用细分到人，但是饮品与汤是每个人不一样的，那么在上汤的时候就需要注意了。于是这个格线正好可以按照座位的不同进行标注，解决了这个问题。我个人觉得这个方法是不错的，至少不需要再问下“这个汤是哪位先生的？”也不至于打断客人进餐了。

5、这是动车组上提供的杂志，这个贴纸其实并没有卷边。这种人工修饰的卷边效果至少有2个优点：吸引用户的注意，来源与真实的模拟的亲切感。在web交互设计 上这种做法其实也很常见

6、10点11分提交订单，10:43商品出库，14:48配送员出发，京东商城的这个速度确实牛掰。另外，这一排订单处理操作人的设计也确实够唬人，很震撼

7、这个，某组织的EDM邮件，这个退订链接的设置，绝对是故意的！

8、很多公共场所有摄像头的地方都提示：“图像采集区”，而光合作用书店的提示是“摄影中，请微笑”，赞！

9、北京四惠东某外贸成衣店，店门口的位置有个展 板，里面都是挂着这样的真人照片，下面标识出这件衣服的存货情况。该老板在淘宝有店。这种商品展示与营销的方式不错

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

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

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

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

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

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

简单说就是这样的：

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

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

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

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

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

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

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

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

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

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

在零售领域中有句定律：想要多赚钱最简单的办法就是卖更多的东西给现有的顾客群。因此有人建议，只要有顾客拿着超过3件或3件以上的东西的时候店员就应该递给他一个购物篮。

而购物篮（车）的出现解决了销售中一个很核心的问题：帮助并刺激消费者继续他们的“即兴购物”行为。因为消费者并不会按照我们设想的那样是列着单子到商店取货的，他们总是在选购了第一本书的时候往往会对第二本书感兴趣，或者碰到其他值得他们购物的商品，这种行为被称作即兴购物。

所以，在零售领域里很重要的一个问题就是解决购物蓝（车）的摆放位置、提供形式、提供时间。比如，购物篮应该散在购物者可能需要它的任何地方而不是只放在商店的进门处（进门处其实并不是个好地方）；是浅口带把手的硬塑料篮子还是像宜家那样的提供手提袋子；冬天时衣服的存放如何与购物篮结合起来？

当电子商务在互联网上兴起的时候，购物篮这个概念被映射到了Web上，我们把它统一称为“购物车”。如下图，简单模拟的电子商务网站购物漏斗（Via），在巨大的推广成本的推动下顾客最终浏览了网站，但是却在购物车环节上有很大的流失。

paypal 在2009年第八次年度商户调研中发现，有大概45%的购物车遗弃率。其中占据前几位的分别是：

• 运费太贵，46%；
• 想做购物对比，37%；
• 钱不够，36%；
• 想找优惠券27%；
• 找不到偏好的付款方式24%；
• 结帐时发现商品缺货或其他原因无法购买23%；
• 找不到客服支持22%；
• 安全的顾虑21%。

Via：emarketer

当然，关于购物车的流失率挽回问题是很多B2C产品经理非常重视的问题，基于常规的非注册用户是否可以直接购买；对付款流程的修改；客服的支持；提高网站可信度等这样的问题不在这里讨论。

那么，基于已经被遗弃的购物车该如何利用？我觉得可以有以下几个方面：

1、在一个只有注册用户才能购物的平台上，如果新注册用户发生了购物车遗弃。可以考虑在一定时间内如15天向该用户投递EDM。内容包括：他们放入购物车中的产品的降价优惠等信息；和被他遗弃的购物车中商品相类似的商品的推荐营销；礼貌的询问是什么原因遗弃了购物车，要求填写调查问卷并发放奖励。对于新用户而言这种做法既能提现客户关怀同时伴随着降价信息的提醒常常会让用户觉得你确实把他当作上帝来对待了，当然，你也可以把这个叫做用户体验….

2、可以利用用户上次被遗弃的购物车中的商品来做关联推荐。一旦用户将一个商品加入购物车，在99%的情况下他是有潜在的购买欲望的，最后迫于各种原因没有结账，而这些原因并不在于商品本身，而在于平台。当该用户第二次再来的时候，如果能把他上次选中但未付款的商品以另外的形式推送给他，这个效果相信是很好的。

3、替代品推荐。这个需要跟第2条关联使用，并借助整个平台会员的UGC力量，最终形成一个独到的“推荐系统”或者说是“需求挖掘”系统。在用户遗弃的购物车中的商品是否有同类可替代商品？这些商品的价格与运费是否可以被其他用户接受，这些商品是否可以推荐给该用户？

4、被遗弃的购物车中的商品如何处理？当坏人在微博上提出这个问题的时候我们在群里曾有过一个争论。坏人认为，在购物车中的商品是用户购物欲望的体现，被用户遗弃后应该转入到收藏夹；而大熊认为，既然用户遗弃了购物车就说明用户此次购物终止，购物车应该被清空。

我的看法是，被遗弃的购物车中商品的转化需要根据不同的平台来进行判断。很多用户其实是想利用购物车来做比较购物的，保留他们所选的商品在购物车中，方便他们在不同的B2C上比较完成之后来下单应该更合适。

5、其实这些被遗弃的购物车数据也可以被比较购物网站所利用。采用OpenID的形式将是比较购物网站的一个发展方向。就比较购物而言，单纯的机器进行数据挖掘是欠准确的，最精准的最好还是基于用户UGC行为的推荐系统数据挖掘。

当然，这里会引发另外几个问题：比较购物网站是否需要购物车，比较购物网站的购物车该如何设计？下回再扯

写在前面：“观察”将是一个我会长期更新的话题。在这个话题里，主要分享我所遇见的和听到的用户使用产品的习惯，以及如何使用等现象。强调，我只客观的讲述现象，不会做任何评论，当然，我也没有资格做什么评论。

故事1：要不要再来杯豆浆？早餐需要多点营养哦

从永安里地铁站出来到CBD国家大厦，会经过一条不算长的小街道，道路的右侧是民房，这里的居民一大半是靠贩卖早餐和小吃生活的。

为了赚取多点利润，这里的早餐基本都是搭配销售，比如煎饼再搭配个火腿肠、要了煎饼再来杯豆浆或者有包好的韭菜盒子…..我经常在一个40岁左右的夫妻的摊子那买东西，他的隔壁是一对年轻夫妻。两个小摊贩卖的东西是一样的，但是生意却很有差距。

我举一个简单的例子：
这对40岁的夫妻在你到了摊子前面的时候她会一边做手头的煎饼一边就主动给你打招呼然后问你，要几个煎饼？要不要加肠呢？等煎饼做好，给你打包后你给钱的时候，他会再问你，要不再来杯豆浆吧！早餐要有营养哦，年轻人。这个时候我多半会付钱买杯豆浆….
而隔壁小夫妻经常是这样的：来点什么？一个煎饼。要不要加肠？呃，不要。打包完事他会问一句，再来点什么吧…这个时候我会犹豫（其实是在寻找并决定），然后说，不用了。

问题出在哪？来个煎饼吧（核心功能优先展示）；需不需要加肠（附加功能礼貌推荐）；再来杯豆浆吧（越少的选择越多的被采纳可能）。
就像下面这种图片展示形式，焦点图高亮显示，非焦点图暗下来，用户的注意力在第一时间被聚焦。

故事2：接受第一份传单之后

还是永安里地铁站到CBD大厦的那条小街。每天早上从地铁出口一直到华彬国际路口，这里会挤满了散发传单的人。从海景房到游泳健身到外卖单到保险….

不知道大家是否有这样的感觉，当你在开始的时候接受了一份传单之后，你将很难再拒绝其他的传单；当散发传单的人看到你手上拿有传单的时候，他会把你当作主要的进攻对象。如果你在最开始的时候就不接受传单，那么，慢慢的其他的散发传单的人会慢慢的放弃你。

这个，是不是是心理学上说的那个，破窗理论？