正如我的一条微博所说：最好的合作方式是，在大局上想法主意互补，细节上各逞其能。最差的合作方式是，大局思路一致，结果盲点重合，然后在细节上吵得不可开交，各自都气呼呼地坚持“细节决定成败”。

    据我所知，符合以上四点的产品项目环境，在业内不足10%。信任感这种东西不是天上掉下来的，而是在适当的泥土中生长出来的。“泥土”本身多半取决于“体系体例”，个人的气力很难去改变。所以，更务实的方法仍是精简团队，加强个人责任感并减少不合。多多咨询听取意见没错，但在详细介入、决议计划的产品面上只铺排少而精的人。产品设计的“群策群力”演变成“人多嘴杂”，屡见不鲜，又是何必喃？

1、交互设计师的才能可托赖

2、交互设计师与产品经理有一定的磨合经历，配合上比较默契
3、交互设计师长期介入此项目，能及时响应需求
4、交互设计师长期研究此产品，对用户群特征有较深了解
    还有同行说，“产品经理应该更关注逻辑，没有必要在页面、交互上面钻牛角尖。”相称于将细节决定权完全赋予了交互设计师。这么做倒也不错，但要吻合几个先决前提：
    要知道，产品设计中加入一些并非绝对必要的细节追求，这几乎是不可避免的；即便细节“绝对必要”，标准把控也因人而异。谁没有一点点个性呢？为了避免个性不一致导致的效率损失与细节过载，通常只能靠精简团队来实现，规避争执，用快速的步履力抵消潜伏的失误率。互相信赖的创业小队，在这一点上往往比权力分配盘根错节的至公司大团队更有上风。

    于是沉默沉静，面无表情，内心有点后悔当初把摊子搞这么大。尤其在大家都没做过APP的时候，项目并不会由于人多而变得更安全，只会由于人多而意见混乱，进而执行力下降得厉害。在每一个产品面上（如APP设计），不仅只有一位决议计划者，最好也只有一两位介入者。保证产品执行力的条件不是人多打老虎，而是默契的团队构成。因为“默契”本身是一件非常难的事情，“精简人数”就成了保持默契最有效的方法。

    公道归公道，由于细节上的个性活跃，又常遭否决，85后年青人的热情依然大受打击。其中一位跟我说，这就是份工作，哈，一份工作而已。

    我又叹了口吻说，我级别比你们高，经验也比你们丰硕，既然这个项目由我在一线带队，当然是我话事。大是大非的题目我们放开了争论无妨，细节不合暂且全听我的，否则谁想做什么效果都往里边加，或者吵不出共鸣就拖着不转动，这进度会像铅块一样沉。直到年底站稳脚跟，进入相对安全的发展阶段，再由你们各自独当一面，我退居二线。这岂不是很公道？

    有一次，我对两个版本的PM说，实在我很少同时反对你们两位的想法主意。我反对M君的时候，W君多半支持我；我反对W君的时候，M君多半支持我。其中的对与错无关成败，大部门是体验细节上的个性判定罢了。但由于拍板的人是我，所以靶子也是我，给你们留下的共同印象就是，我是个压制你们施展的(傻逼)(忘八)(大反派)上司。枪口一致对外。   

    二季度以来，我一直在带队做相册APP。这是部分第一款移动应用，又涉及复杂的跨部分合作。谨严起见，介入产品设计的除了我之外，还包括iOS与Android版本的PM各一，临时增援的交互与视觉设计师各一，再加上工程师也会提供意见。整个项目过程中布满了吵吵闹闹，各种产品观混战一团，固然最后由我来拍板，但观点被否定的人往往不悦。

    换个角度来看，假如项目需要充分调动设计者的热情，让其全身心地投入，当然就得尊重他的个性。好比说乔老爷子一定要在mac电路板上刻个精美的logo，又看Google APP的Logo色阶颇不顺眼；又好比卡梅隆拍《泰坦尼克号》的时候，坚持购买昂贵的欧洲瓷器作为道具（摔碎），说这样才气场和谐。显而易见，这些想法主意都很有点偏执在里边，但你假如限制了天才的偏执，也就无法施展出他们伟大的创造力。对于常人，亦是如斯。

    这则经验之谈的本意是，实在没有太多办法去解决细节中的“个性之争”，只好在保证主干准确的基础上，把细节决定权赋予意见同一的个人或派别。转化到产品项目治理中，介入制定细节的人越少，则进度越快；人越多，则意见越杂。两种截然不同的处理方法可能都是准确的，即便有对有错，效果差别往往也不大。但多种个性的冲突会导致决断效率低下，多种个性叠加又会导致产品需求过载——其中大部门对终极成败的影响为零。它们的存在意义仅在于，让设计者觉得这是融入了我的个性，我的风格，我的产品观的个人作品。仅此而已。

    在此再一次回顾国外某科技至公司高管的经验之谈。他说“产品项目的效率很低的话，我就从小组中抽走一个人。还低？那就再抽走一个人。眼看着效率biubiu就提上来了。”是啊，都没人跟你吵架，掰腕子，对抠细节了，效率当然大有晋升。

    如我发微博所说：“产品抠细节这种事情，假如是自己做呢，会得意于无微不至与用户关怀；假如是别人要求自己做呢，又会咒骂他无聊透顶，吹毛求疵。”

    很可惜，所有糖水大道理并不能匡助我们解决实际的题目。在发生争执的时候，每个人都会以为，自己的观点最能够代表用户需求。即便对于何谓“核心功能、主干流程”达成共鸣，这部门哪些细节该抠，哪些不该抠，也会吵个热火朝天。什么才是“用户真的需要”？什么才是“值得反复推敲的细节”？两边恨不得拿起火箭炮豪快地轰杀对方。究竟细节判定中的主观个性多于客观共鸣，假如每份争议都去做用户调研、数据挖掘、网站建设，AB测试来解决，就会把产品设计变成一场漫长的，气呼呼的拉锯战。

    “细节决定成败，是在已经把基础做好的情况下。大面上都过不去，谈何细节。更何况，不是所有的细节都值得去反复推敲。”

    “产品体验往往会变成几个人埋头追求完美，用户都感觉不到。在大方向上掌握用户真的需要的才比较枢纽。”

    “做产品调研时要发散再发散，想到各种可能的方向；做产品设计时要收缩再收缩，重点做最能吸引用户的功能。 ”

    “产品首先应该是有用、能用的，然后才是易用、想用，现在良多人直接跳到最后2步甚至1步上了。尼玛都不想想这东西有没有用能不能用，搞个P的用户体验。”

“产品是做给用户使用的，当然要以用户的需求为尺度。以自认为是的尺度做一款产品，无异于闭门造车。做产品，最最少要读懂人道。”

    表面看上去，这算是细节与大条的两党之争，实在不然。我们经常赞美“细节决定成败”，同时也经常咒骂别人抠细节太无聊，然而这两个极端经常从统一人的嘴巴里讲出来，仅时区不同，让你觉得他简直就是个神经病！换句话说，是否注重细节并不取决于个人偏好，枢纽是情景判定。不少业内人士在我的微博上对此评论道：

    主干流程，频发应用情景需要抠细节，分支流程与偶发情景无此必要

    核心功能需要抠细节，非核心功能无此必要

 ★大条派
-在激烈竞争中，核心体验轻易同质化，这时细节就成为决定用户倾向度的天平
-即便是微小的细节愉悦，也能给用户带来惊喜，并晋升对产品的信赖感
★细节派
对此有如下几种常见诠释：
   第二件琐事关于Piictu，这款立异APP自5月发布以来，关注度不断晋升，我试用几天后却出故障了，不管怎么发图都不能刷新。当时还讥笑Piictu对网络环境要求太高，突然回过神来，岂非是我测试“捣乱行为”时被系统拖黑了？注册新号一看，擦！新号果然正常。像这样对拖黑用户无任何提示，相信是大多数交互、用研、PM无法容忍之事，然而Piictu就这么义正辞严地干了。去咬它啊，Who care？

    那一年，新浪微博崛起，逐渐改变了整个中国互联网的生态。在微博动静中央回复评论，或在微博列表页转发内容，都只是弹窗提示成功。是否不够友好呢？是的，我自己常常多点击一次确认回复或转发结果。然而这丁点体验损失对新浪微博雄霸天下造成的影响是……零。既然如斯，为什么博客当年要花费额外的研发时间去纠结这点细节呢？

    这个想法主意被工程师从技术层面否决了，细节略过。最后达成的妥协方案是，回复内容可以挂在动静中央，但样式和评论区块（多级回复）不一致，只吊挂一级，相称于重新天生一条静态化的提示，利便你确认“回复已成功”。当然，这会耗用额外的研发时间。

    2009年，我被邀请旁听博客新动静系统的策划讨论。有人提到，在动静中央内回复评论的时候，假如仅仅弹窗告知“回复成功”，很不友好，用户可能还要去日志下面确认是否回复成功。最好能和开心一样，回复内容直接挂在动静中央里边，和评论区块的样式一致。当时我也支持此观点。