标题这句话，正着读或者倒着念，都可以。

用户接触到一个产品，往往是这样的一个路径，

点击图标/输入网址，首先感受到的是产品的色彩，他是白色纯净的还是橘红热闹的。这是视觉设计师的功劳，是用户最先感知的部分；

接着看到的是排列好的界面，这里是促销展示，那里是商品排列，那里是操作入口，那里是一段文案提示。这是界面设计师的功劳，是用户其次感知的部分；

再接着点击了一个商品图片或者操作入口，进入到商品详情页面，或者打开了输入表单，键盘被弹起来。这是交互设计师的功劳，是用户接着感知的部分；

再继续，用户不断的被引导操作，完成一项项任务，这是常见意义上产品经理的功劳。

这一切构成了我们常见意义上的产品。场景设计（用户任务）和功能设计、交互设计、界面设计、视觉设计。

上面是用户对产品的感知路径，而实际上，产品的设计路径是完全相反的。

首先，要做场景的设计。观察与分析用户的需求，拆分出用户任务，进一步设计相应的功能来满足用户的需求/任务。

其次，针对任务的拆分来设计流程引导，第一步做什么，第二步做什么，完成不同的任务。

第三，细分到每一步中，用怎样的界面来表达，要表达哪些元素，这些元素如何展示出来。

第四，对每个界面的每个元素用有品位的视觉做表达。

这是一个非常有趣的值得思考的现象。用户是个感性的动物，他对产品的第一印象，来自于感性的色彩、界面、文字；而产品则是个理性的产物，构成产品的核心是理性的分析与模式的构建。

设计的看上去很好看的产品，往往并不能走很远，因为架构与模式不对；架构与模式很好的产品，又往往设计的并不好看。被流传的产品，是两者相结合的产物。

于是，这必须要求，理性的产品需要具备感性的审美，感性的设计师需要具备理性的思维。

换句话说，不管是产品还是设计师都需要有讲故事的能力，能够清晰明确的在脑海中有场景感。

总结起来看，

1、产品设计的过程就是一个讲故事的过程。

先要讲好一个故事，然后把这个故事用计算机语言表达出来。

比如，我们要向朋友推荐一个司机的时候，我会说，这个司机长的很帅、开车技术很好、车也很好、很多人都坐过他的车。

我们用语言表达的时候，并不难，因为我们就是讲着话长大的。语言的传播是多维度的，用词、语调，都能很好的帮助我们表达想法。

然而，计算机语言中的故事表达就难很多，尤其是在仅用图形和色彩，也就是界面来做表达的时候。用户所见的界面是有限的，表达的内容是要很多的，你首先需要对内容做排序，其次要做排列，然后再思考用什么形式表达，这确实是一件很有挑战的事情。

这是产品设计最难的地方。这个思维，产品需要具备，设计师更需要具备。不具备这个思维的设计师永远都做不出有灵性的界面。

2、交互设计与界面设计是在用逻辑表达来讲一个故事，而视觉设计则是在用视觉语言解决逻辑问题。

不论是交互的设计、界面的设计、视觉的设计，都是要解决问题，不是为了美，美是品位的一种体现，解决问题才是重点。

3、大多数时候，解决问题与品位被割裂了。

在大多数设计师的心里与行动中，解决问题是产品经理的事情，我要做的是有品位。而在大多数产品经理的心里与心动中，品位是设计师的事情，我要做的是解决问题。

这是扭曲的根源，是狭隘的分工导致的恶果。

4、更多的时候，产品与设计师是被自己禁锢了的。

从用户场景出发，先思考如何最优的满足用户需求，然后再思考技术如何实现，而不是倒过来。

这句话，肯定会有很多人会觉得不对。因为，我思考了一个方案，技术不能实现，那不是白扯吗，你还催着我上线呢？

但是，我要说的是，这是一种正确的思维方式。在开始思考的时候，不能禁锢自己，人脑被禁锢的久了，就会越来越狭隘。永远，不要禁锢自己的想象力。

5、同样的道理，市场要有产品的思维，运营要有市场的想法

这是一句废话。

几年前，在我学驾照的过程中，我开始是很痛苦的，因为教练根本不告诉我为什么这么做，只是告诉我，先开出去，看后视镜，当后窗的x点与车库的x点对齐了，右打满往前开，然后，balabalabala的

我为什么痛苦呢，因为他没告诉我为什么这么做（WhyToDo），他只告诉我要这么做（HowToDo）。虽然，从实用性的角度看，直接按照他教的那么机械的做是最高效直接，不会出错的。

学完车之后，关于倒车的那些技法我还是记不住，每次停车都挺难的，所以我上网继续搜索教程，但是，我发现，网上的教程也都是直接告诉你要怎么做，很少说为什么这么做的。就这样，我对着教程慢慢琢磨慢慢练，也算把停车技术弄的还说的过去了。

于是，有个问题就一直在我的脑海里盘旋，为什么他们总是只说怎么做，不说为什么这么做呢？后来开始自己带团队，开始不断的教别人怎么做事情，我觉得我有点理解这个道理了。

从基本意义上看，授之以鱼不如授之以渔，把为什么这样做说清楚是对的。但是，这个理论忽略了一个重要的基础因素，每个个体的接受程度是不一样的，简单讲就是领悟力不同，当你不断给他讲道理的时候，他往往领悟不到，更有甚者则理解偏颇了，出的麻烦更大。同时，这样不断的一遍一遍的讲，效率也是很低下的。

所以，看上去，在实际行动中领悟，不断自我纠偏自我理解则是更为有效的方式，就是中国传统文化中的言传身教。总结成人话就是，先有样学样，然后在失败中总结。会总结的人自然就能举一反三，不会总结的人就自然的被降级为螺丝钉。

你比如做产品这件事，它有没有技法呢？是有的。技法是什么样的呢？在我看来就特别简单，搭架子、定流程、抠细节。这属于理论，属于我自己的方法论，我要给你展开来讲这个方法论，至少可以讲一整体不带歇脚的。我给你讲完了，你会做吗？你肯定不会，而且你往往还会被我带的偏颇了。

问题出在哪里呢？之前有一张比较有意思的图应该可以直观的解释这个问题。

如何解决不同思维模式带来的差异问题呢，最好就是先把大家都调到一个频道上来。怎么把大家调到一个频道上来呢，先做把事情变成「形式化」的，然后所有人「行事化」的执行，之后沉淀成了「习惯化」的。这个时候，决定你是成为一代宗师还是普通武师的时候到了。

如果你能做到自我领悟，你就能成为宗师，有自己的内功心法与招式，甚至开宗立派，比如张三丰；如果你不能自我领悟，你就一辈子只能消耗师傅的招数，甚至因为资质的问题有些招数还演绎不出来。

这里就可以顺带再次回答被无数入门的产品经理们问了无数遍的问题，我想做一个优秀的产品经理，我该怎么入手呢？

1、别管什么狗屁的产品理论，永远不要在刚入行的时候去学习什么狗屁的产品理论，记住，碰都不要碰！

2、去实际使用每一个产品，然后做自我总结，把某一个共性的模块全部归纳出来。比如，把你用过的所有产品的注册、登录流程全部记录下来，整理出来做归纳，得出一般的规律

3、基本的产品模块的设计思路你应该都要做到了然于胸了。当你要设计某一个模块或者流程的时候，把你脑子里存储的那些案例全部调出来，挑拣一遍，选出一个最好的，加点自己的个性进去

4、重复第3点，去尝试新的产品设计。

5、悟到自己的产品理论。

6、你现在可以回去再看看那些产品理论，好像，也不过如此，而且还有些说的非常偏颇

以上这个过程，就是一个从HowToDo到WhyToDo的过程。也是一个相对科学与效率的进入一个新的领域的方式。先不要管任何的理论，直接有样学样照猫画虎，学样的过程中不断感受不断总结，多次的总结与沉淀之后，如果你适合做就会自成一派渐入佳境，如果你不适合做就认命或者换行吧。

这里再次回答被无数入门产品经理问了无数遍的另外一个问题，我想做一个优秀的产品经理，我最重要要具备什么素质？

勤奋，没有之一了。

类似的产品，做了同样的一个功能，但是，我们还是可以很明显的感受到不同，这种不同我们常常把他叫做「用户体验」。

但是这种差异究竟是怎样的，我们似乎很难描述，那好吧，我换个方式来聊聊，我们在使用类似产品的同样功能的时候的感受。

来看看3组类似产品相似功能的设计：

在很早的时候就存在一个需求，听歌识曲。于是早期有很多类似的APP，比如音乐雷达、shazam等。

后来，微信也做一个摇一摇识别歌曲的功能。

最早的音乐雷达只完成一件事，帮你找到这首歌的名字，这属于及格的产品；微信的摇一摇能做到帮你找到这首歌的名字，还能帮你定位到当前播放的位置，并继续自动滚动歌词，这属于优秀的产品。

在很早的时候，支付宝做了手机端的支付流程，我们需要记住很复杂的支付密码。

后来，微信也做了手机端的支付，微信说密码应该延续实体卡片的6位数字，不需要那么复杂；微信说支付这个环节为什么需要确认呢？

支付宝的手机端支付流程，属于一个及格的产品；而微信的手机端支付流程，属于一个优秀的产品。

另外，大家注意对比这2个页面，从设计角度讲，支付宝的这个页面设计实在烂透了！

1、浮层标题栏的提示，微信更简单明了；

支付宝的标题栏，又是icon又是文字，怎一个乱字了得！这个页面是在支付宝APP中调起来的，这个时候还突出你的logo，想要表达什么呢？完全没必要啊

2、主信息展示区域，付多少钱，用什么方式支付，微信在信息的区分展示上处理的更好，而支付宝的这个设计，我经常会分不清楚那个364.00元指的是我的余额还是我要付的钱。

付多少钱与用什么形式付款，是2个不同的层级的信息，但是，支付宝的UI处理上，放在了一个层级上，给用户在信息的识别上增加了更多不必要的负担。

3、为什么要有确认按钮，为什么要有确认按钮，为什么要有确认按钮？

— 重要的事情说3遍！

支付宝迫于微信的鸭梨，把密码修改为支持6位，但是，在设计上，还是没敢放开自己，一个需要确认按钮，一个不需要确认按钮，产品设计功底，高低立现，差的真心不是一丁半点。

ps：我们很多的产品经理，我们很多的设计师，在设计上非常的「传统」。比如，切换城市了不是在后台就自动完成，非要提示一下用户，还要用户确认一下。

产品经理对设计的认知变化，远远赶不上用户越来越懒越来越追求快的心智模型变化！

这是一个导流页面的对比，我们主要看文案的提示。

场景是用户叫出租车叫不到，推荐用户去用专车。快的打车的做法属于及格产品，而滴滴打车的做法属于相对优秀产品。（个人觉得优化空间还较大）

分析一下这个场景，用户叫不到车了，这是现实，用户的需求是用车，但是专车明显比出租车贵。

所以，这个文案提示有2个方面要讲，一方面是没车了，你可以换个别的试试，一方面是别的车大概多少钱，你能省多少，你算算是不是符合你的预期。

这样一分析，高低立现。

所以还是那句话，产品经理们，你们该多读点书的！

及格的产品，能把流程想完整，把该有的元素都放上去；

优秀的产品，流程是极简完整的，元素都是无法再剔除的；

及格的产品，有耐心的用户一步一步坚持，可以完成任务；

优秀的产品，不管是什么用户，很简单就能完成任务；

及格的产品，在思考产品方案的时候，会考虑的是完成任务；

优秀的产品，在思考产品方案的时候，会考虑的是如何愉悦的完成任务；

最后，为了让你们更简单直观的理解及格的产品和优秀的产品，放一张生活中常见的图吧。

关于什么是需求评审，不在这里做解释与定义了，直接进入主题。

关于需求评审的几个原则：

1、需求评审不是谁要说服谁，而是我们要就某一个具体问题寻找到最优的解决方案。

我们有很多PM总是会抱着「我要说服研发」的态度来做需求评审，所以整个需求评审的基本氛围是辩论，是相互的寻找极端情况支撑自己的观点，试图让对方让步，这是非常错误的开局。

2、所有问题的讨论，都必须要先建立基本共识，然后基于这个共识再细化。

什么是基本共识呢？就是我们首先要把双方调整到一个频道上来。不要在不同的频道上相互努力，那没意义。比如，我们先要定义清楚什么是激活用户、什么是注册用户；比如我用到的这个名词指代的是什么这样的基础的小问题。

3、先不要在僵持不下的观点上浪费时间，先求同，后攻异。

在已经形成基本共识的基础上，如果一个小问题有分歧，且一时半会讨论不清楚，那就先放下，继续讨论其他的，等其他的解决了，再回来解决这个差异点上的问题。

关于需求评审的推进步骤：

1、先说我们这次需求的目标与目的。

简单说就是先讲明白我们要做什么，我们为什么要做这个。

就像是演讲的时候，先讲一个能够引起观众兴趣的故事或者观点，然后再提出一个在这个美好的故事中需要解决的难题。

这个问题是经常会产品经理忽略的，但也恰恰是需求评审中最最重要的，它的重要性甚至超过了后面所有的步骤！

我看过太多的产品经理在需求评审的时候，上来就打开画好的原型图，开始讲功能，讲流程。这是完全错误的。一定要花时间先讲为什么要做这个，要达到什么目标，并且一定要在这个目标上达成一致意见。

就像我之前说的，「设计师，别急着打开设计软件」，产品经理在需求评审之前，请别着急讲功能点与流程，这非常重要。

2、在目标与目的达成一致的基础上，再说你准备怎么做

在谈怎么做的时候，我们是默认为什么做大家达成了一致的。这个时候，不要再返回去讨论第一个问题了，聚焦在怎么做上。

在我们讨论问题的时候，在我们评审一个需求的时候，很多人会很着急，当你说要做这个的时候，他的思路会跑的很快，立刻就先跑到了想要是这么干，我们目前的架构会有什么问题，会存在什么潜在风险，已经跑到细节上了。

这样很不科学，也很不高效，很容易把问题混到一起去了，然后就会陷入到细节的争吵与辩论，然后就走偏了。这样的讨论也是低效的。

谈第一个层次问题的时候，就不要想第二个层次的事情，谈第二个层次的事情的时候，就不要再回去质疑第一个层次的结论了。

讲述你准备怎么做的过程，实际上就是要描述你的解答对解决问题而言的好处。

关于「准备怎么做」的讨论，会有2个结果：

2.1、你认同或者大部分认同我的方案

那么，就按照这个方案来执行，其中有一些不太认同的，我们坐下来讨论，看是否有更好的方案来做。

2.2、你不认同我的方案

那么，我们先回到第一个问题「关于我们要做这个事情的目标与目的」是否认同。如果认同目标了，那就是实现方案的问题了，我们可以坐下来研究。如果不认同这个目标，那这评审也就没得玩了，这个状态一般极少出现。

好，现在问题出在不认同方案上了，又有2个结果：

2.2.1、这个方案可以做基本的修正吗？

可以，那我们探讨如何修正

2.2.2、你是否有更好的解决方案呢，这个方案是否可以勉强执行？

可以，那好，先按照这个方案干。如果你有更好的方案，我们按照你的方案干。

2.2.3、我没有更好的方案，我也不认同你的方案

靠，你这完全不是一个团队合作的状态，赶紧换人。

3、方案达成一致了，开始做排期与风险及收益预估

为什么做这个事情，都清楚了，也认同了；

是不是可以这么干，也基本达成一致了；

剩下的就是排期，安排人员，具体去执行了，这是一个新的话题，不展开了。

总结一下，其实就是一个不断拆解的过程，

1. 先说我们的目标与目的，在为什么要做这个事情上达成一致；
2. 再说我是这么想的，你觉得方案是否可行，我们一起看看有没有更好的方案，在怎么做上达成一致；
3. 按照我们讨论的这个做法，看看我们现有的人手，具体怎么一步一步执行。

讨论问题与需求评审一样，是一个解决问题的过程，解决问题的最合理方式就是不断拆解问题，拆解到不能再拆解了，然后分别的寻找解决方式。

另外，相比情商，智商反而有时候显得不是最重要的。

1.

如果我们把「做产品」或者叫「做功能」吧，比喻成是打造一把剑。我们也可以同样的把运营/销售/推广这个产品，比喻成要去上阵杀人。

很显然，这里存在相互依存的关系。那么，同样的，问题也来了。

你必须要拥有一把锋利的剑，一把像样的剑，一把剑才能上阵迎敌吗？

在很多人的意识里，这个问题的答案是肯定的。产品必须要做好了，我们才能去运营与销售。在产品没有做好之前，我只能等待。我都没有剑啊，你总不能让我赤膊上阵吧！

这个意识是有待商榷的。把金子卖出金子的价钱，是一般的运营与销售；把银子卖出金子的价钱，是相对出色的运营与销售；把一坨屎卖出金子的价钱，是天才的运营与销售。

有条件要上，没有条件创造条件也要上。

2.

面试一个做策略的产品经理。我问了一个问题，你觉得微信拼手气红包，分钱的策略是什么，是纯随机的吗？如果你来设计这个策略，你会怎么做？

对方回答，我觉得不应该是随机的。我应该考虑如何让这个「功能」可以玩的起来，我需要同时照顾发红包的人和抢红包的人的利益。比如，发的越多的人，可以抢的越多。

我问，在发红包这个场景里面，发红包的人一般会是什么样的人，抢红包的一般又会是什么样的人？他们分别是什么心理呢？你的老板应该是发红包很多的人，相对的，你可能是发红包很少的人，你的老板会抢很多红包吗？

对方回答，可能不会吧。

我问，那你有怎么去实现这个平衡呢？

对方就着这个问题继续分散了很多，想了更多的策略去弥补我所设想的分支场景。然后，策略叠加策略，很多策略交织在一起了。

然后我说，好，我们现在停一下，回到问题的原点，你重新来设计这个策略，你会设计成纯随机的吗？

对方怯怯的回答说，会。

你看，这就是我们作为一个「设计者」最爱犯的毛病，我们什么都想去「设计」一下，仿佛不设计就不能显示我们的本领来。我们始终不愿意去走那条看似最平常的路，我们就这样被自己设计的设计所设计着，平常总是蕴含着无穷的力量，而我们常常忽略她。

（微信红包的策略具体是不是随机的，我不知道，这个问题我只是从我的思维出发，做的答案，大家没必要较真）

3.

我们经常受惠与机器，所以我们变的特别依赖与机器，依赖与技术。相应的，我们希望并且试图把所有东西都技术功能化来完成。于是，我们会提出很多的需求，要做很多的功能。

如果没有用技术去实现一个功能，我们好像都不能再去推进什么事情了。所以，我经常开玩笑的说，整个互联网已经快变成了劳动密集型产业了，稍微上规模的互联网公司，都有超级多的工程师。这些工程师还经常需要加班。

核算成本是一个看似跟产品设计、跟体验设计、跟技术开发没什么关系的事情。所以，很多工程师写了很多代码，这些代码很少发挥价值，这是个很悲哀的现象。

4.

我们偏爱铸剑，但是很少磨剑。同样的，我们偏爱开发功能，设计功能，但是，很少持续运营功能。

一个产品在推进的过程中，很少去合算成本。反正做功能是一个很简单的事情，有想法了，有方案了，就可以去开发了，再激进一点，需要很快这个功能就可以出来，所见即所得最好。

一个功能做出来了，发现之前想的不太对，不愿意去运营，也不想迭代。那就继续再去做功能，反正做功能是一个简单的事情，有想法了，有方案了，就可以去开发了。

产品重要，但是，持续运营要比产品更重要一百倍。不要随意的满足一个用户提出的要求，因为，每一个用户的要求，都可能会是一个包袱。

5.

要转载我的文章，请带上作者名称，原文地址的超链接，不允许修改我的标题，不允许删减修改我的内容，包括错别字的修改！如果你无法全部满足上面3个要求，请不要转载，欢迎大家举报。

2011年11月左右，FB发布了新的ios和android客户端，其中一个重要的变化就是导航模式的变化，推出了新的抽屉式的导航，同时强化了对Timeline的展示。

FB推出这种新的导航模式不久，Gmail的ios版本同样采用了这种导航模式，再之后path 2.0版本也采用了这种抽屉式导航并将其演变到极致。至此，这种抽屉式的导航模式迅速窜红与ios产品设计中。

我在2012年7月曾经对抽屉式导航做了总结，在「说说抽屉式导航」中我认为，大部分APP会使用抽屉式导航，核心原因是为了突出核心功能，将其他的功能隐藏掉。

现在来看，这个说法并不完全对。2011年到2012年，是中小屏幕移动设备占绝对主导的时代，中小屏幕，单手完全可以操作，不存在太多的操作盲区。同时，中心屏幕使得可以展示的内容有限，所以，抽屉式导航是最合适的做法。将导航收缩到一个入口，放在左上角最显眼的位置，用户操作也没有困难，其他核心的内容直接显示出来。

2012年之后，大屏幕成为移动设备的一个新趋势。一方面手机从一个单一的工具，逐渐演变成人们生活的一部分，不可或缺的一部分，用户在手机上处理的事务越多，使用的时间越长；另一方面，屏幕尺寸和内容消费效率及阅读舒适度极为相关。所以慢慢的，手持舒适度和携带便利在整个产品设计众多决策里面的重要排序便没有那么高。

所以，我们看到4寸屏、5寸屏越来越成为主流，尤其是iPhone6和iPhone6 plus的推出，大屏幕手机时代就这么不可阻挡的来了。有一篇老外的分析，点击这里查看。

手机屏幕越来越大，带来了哪些问题呢？

最简单直接的就是，内容显示变多了，但是，单手操作变难了。曾经有报告显示，49%的用户是单手操作手机的，现在，是改变单手操作的设计的时候了。

这张图，非常直观明了的告诉了我们，为什么抽屉式导航衰退了。因为，一个需要被经常操作的入口，现在，处在了操作盲区。

那么，伴随着抽屉式导航的衰退，在大屏幕时代，该如何去设计呢？这是每个产品设计师面临的一个新的思考。我有几点感受，可以分享出来

1、手势操作将会变的更加重要。

Android上有单独的back键，而iOS的返回一直依靠左上角的导航。大屏幕下，iOS的左上角点击返回将非常低效，在屏幕边缘右滑返回是最高效的模式。另外，针对信息流类产品，点击顶部迅速返回到最开始的信息的模式，也是一种高效的交互。阅读类产品可以考虑使用双击关闭这类的手势交互。

相应的，一个产品统一使用上滑、下滑来进行导航的产品将会更多。

2、底部Tab模式导航重新受追捧

实际上，底部Tab模式导航在iOS和Android上一直是「最安全」的一种导航模式，他不怎么出彩，但是绝对不会犯错。在大屏幕时代，底部Tab模式的导航更能适应，也更好设计。

3、浮动导航入口有可能出彩

在path的3.0版本，那个浮动在左下角的「+」号曾经一度流行。在大屏幕时代，这种浮动的入口很有可能出现优秀的设计。

4、将提交类操作按钮，放在弹出的键盘的顶部

这个模式，在Android中较为常见，但是同样存在不同屏幕的适配问题，需要仔细考虑。

5、语音交互，谨慎看好

语音交互，始终感觉没有一个好的使用场景。

「专注、极致、口碑、快」，这是小米神话中传播最广的一则口诀。

人人都喜欢极致，因为极致代表着完美，代表着用心，没有人不喜欢完美，所以人人都喜欢极致。

不过，在夜深人静的时候，我也会反思一下，我们是不是中了「极致」的毒。世事无绝对，产品设计尤其如此，对极致的狂热追求，在很多时候，会掩盖一些更本质重要的东西。

今天这篇文章是一位工程师写的，很难得的看到从工程师的视角，有人能反思一下目前互联网圈子对极致的过渡崇拜。

在乔布斯的时代，其实，乔布斯说的对多的观点应该是，「It just works」。我认为，这才是我们应该推崇的产品理念，是一个更环保的产品理念！

从一个产品架构开始，到一个产品功能，到实现功能所需要的代码，都应该考虑是否环保。环保的产品是恰如其分的可以工作，环保的代码是在当前的那个情境能达到运行状态。

在移动互联网时代，摩尔定律已经失效，这意味着更快的发展，更快的变化，更多的不确定性在等待我们，所以，不要制定遥远漫长的工作计划，如果做不到高瞻远瞩，那就尽可能把最重要的功能实现，保证系统可运行。

说白了，这个世界上，存在某种“极致”的产品吗？我认为不存在极致的产品，甚至不存在有着极致倾向的产品。

“代码是为产品服务，产品是为用户服务的。”这是一个非常简单直接的道理，但是这个道理在纷繁复杂的当今社会，竟然被各种花花绿绿五光十色的词汇所裹挟与扭曲，忽视用户，忽视产品生命周期，追求虚无缥缈的所谓“极致”与“完美”，出现这样的苗头其实是非常令人诧异和心痛的。

其实，“极致”从来都不是产品需要具备的品质，甚至从来都不是成为产品的开发倾向。产品的天性，只是迎合消费者的需要，体现技术的价值而已，无他。

— 点击这里可以查看原文，略长。

每年都要有一次总结，这事儿坚持了好几年。每年都是到最后一刻才想起来，今年没忘记，正好写完一篇跟团队小伙伴的分享，索性直接贴出来，当做总结吧。

—

hi，亲爱的小伙伴们

本来想着赶在12点之前写完这封邮件的，但是到家就12点了，所以，硬生生的把标题又改了。

作为产品部的一员，我特别的希望能跟大家每一个人做最充分的沟通，特别的希望这个部门里的每一个人都能快速的成长，有所收获，快乐的工作。

但是，时间太有限了，所以我没能实现跟每个人都1on1一次，至今，我还没有跟UED的同学们1on1过，在接下来的日子里，我努力跟大家一对一的交流。

我觉得我们都应该感到很幸运。我们所处的这个行业，站在了风口上，我们的订单和用户每天都在快速增长。在一个激烈的战场中，顶着前方的炮火前进，这是最快速的成长方式，这也是最刺激的职业生涯，这是我选择加入易到的最核心的原因。

同时，我们也应该有足够的危机感。刺刀见红，这个行业的玩家们都在肉搏，这是最坏的年代，也是最好的年代。在战场上，只有顽强的人才能活着，只有学习能力足够强的人才能最终胜利。

思考了很久，最终决定写下这封邮件，有些话，想跟大家说说：

我很早的时候就意识到，我下一份工作的薪水与待遇，是由我上一份工作决定的。所以，我把每一分工作都当成是自己的一次修炼，我在思考的事情是，我能在这份工作里让自己成长多少，让自己的段位提升多少。我希望所有的小伙伴们都能有这个意识，你是在为自己的下一份工作拼命的增加筹码。互联网是一个相对公平的行业，产品与设计更是一个用成绩说话的职业，这一点我们必须意识到。

这就要求我们必须有策略的成长，我有几点建议：

1、我们必须足够努力才能让自己看起来毫不费力

设计师也好，产品经理也好，基本上不用拼天份，拼努力就已经足够可以笑傲江湖了。我以前觉得自己挺努力的，后来发现一位我敬重的前辈居然可以做到每天工作17个小时，我只有默默的继续努力了。世界真特么的可怕啊！

2、我们必须有很强的学习能力

每一次功能设计，每一次界面设计，都是一次锻炼，在每个锻炼之后，我们都应该有所总结，这次哪里做的好，哪里做的不好，为什么做的不好，我该如何让下次做的更好。只有不断的自我总结，自我反思，才能形成属于自己的方法论。
只拼努力是不科学的，有效的努力才是王道。

3、独立思考，做正确的事情

在百度PM文化中，有一句非常经典的话，叫做「跟多数人商量，听少数人意见，自己做决定」。
我们必须要先判断哪些事情是对的，必须对一个需求，一个设计先有自己的判断，有自己深刻的理解。然后才去做设计，做产品，而不是拿到了一个需求就开始做，做了一半被人PK回来了。
「不唯上」应该是我们产品部门最核心的价值观，另一个核心的价值观是，我们只做对用户有价值的事情。
我们应该用我们对用户需求最精准的把握，对用户需求最深刻的理解去跟需求方探讨，去跟老板PK。我们之所以背动，核心就在于我们没有深刻的去理解，去思考。

4、优化流程，正确的做事

我们应该针对每个case去做总结，通过流程的优化，规避多次犯同样的错误。我们也应该根据自身的特点，建立适合自己的工作流，不断提升效率。
傅红雪是个瘸子，但是他依旧是个绝世高手，因为丫通过苦练找到适合自己的刀法。

5、我们必须学会合作

这是一个需要合作的互联网，这不是一个逞个人之勇的年代，合作才能创造更多的价值，合作、学习才能让自己成长的更快。
我们一再的墙掉，我们内部一定要做到足够的信息互通，一定要建立充分分享的意识，只有这样，我们才能更加强大

6、不要等，要快

我最反感的就是你们跟我说，「等明天再看看」，为什么要等到明天？明天世界会有很大的变化吗？为什么不是现在呢！
一旦我们决定了，我们就应该迅速的展开。做产品，怎么做都是错的，唯一不同的是，谁做的更快，谁能更快的从错误的坑里爬出来。不要等，等待是loser才会用的词儿！

7、一定，一定要好好锻炼身体

身体，始终是我们最值钱最珍贵的。多锻炼身体，让自己强壮起来，这样，你才能更好的享受你的成功。

就写到这里吧，记住，我亲爱的小伙伴们，「对贡献充满激情，对回报充满信心」。

– kentzhu，2014.12.30 0：50

从事产品设计行业有些年头了，发现还是会不断遇到新的问题，不断强迫自己去思考，去总结，这是这个行业最吸引我的地方。并且，我也时常翻看自己之前的总结，发现，总是能从过去的总结中重新寻找很多灵感。也许正是这样的感觉不断的推动着自己在往前走吧。

产品设计3件事，搭架子、定流程、抠细节。

搭架子

产品设计工作，首先是一个创造的过程。依据设计者对市场的理解，对用户的理解，对战略布局的理解，去搭建一个生态系统，或者换个角度看，就是一个虚拟的王国。产品架构是最底层的设计，这会直接影响到后续产品的不断发展路径。

我比较喜欢用一个词叫做「产品的边界」，任何事情都有边界，产品也一样。产品边界的一个直观外在体现就是产品的架构。

比如，在12年的时候，我在做快捷酒店管家的产品。快捷酒店管家的起源是一张便签纸，连长在上面画了一个原型，地图上面插几个小牌子，牌子展示的是酒店的名称，这就是快捷酒店管家最早的产品框架。

我对这个产品框架做了完善，增加了个人中心的入口，增加了展示列表的入口。但是，架子没有做改动，就是以地图为核心，展示附近的酒店。

现在回头再看这个框架，是有明显的边界，其根本的限制就在于地图的使用。地图占据了用户界面的绝大部分内容，这些内容看上去很直观，但是实际上展示信息有限。所以，如果快捷酒店管家要做更广阔的探索，必须要改变这个架构。

同样的，uber作为一个用车应用，也使用了地图作为其基本的产品框架，而国内的打车软件滴滴和快的也都使用了这个架构。这个框架对uber而言，有更多的限制性，可以预见的，在不久的将来，这个架构将成为限制其产品扩展的一个巨大问题。

uber用地图做为主要界面展示，揣测一下，是试图达到这样几个目的，将车辆的位置实时在地图上展示，可以突出很多车，且车就在附近的感觉，建立用户的信任感。当只有一个业务的时候，这个框架非常适合，但是，扩展性就差了很多，我们可以看到，uber目前主要在页面的下方，与地图并列的部分展示不同的车型，不同的服务的，在某些地区，服务特别多的时候，uber都开始采用双行选择的展示方式了，很臃肿。可以预见的，国内学习uber的滴滴和快的，肯定会多品类的扩充，肯定会遇到一样的尴尬。

另外一点，车辆在APP的地图里表现为一个图标的时候，因为颜色的限制以及形状的限制，如果密集展示的话，会导致地图非常的难看，密集恐惧症啊。

相对而言，易到用车目前的产品框架在扩展性上则强了很多。易到用车抛弃了地图模式的产品框架，在一开始的时候就使用了服务细分，并且下面的模块也可以延伸更多的细分服务类型。在非地图的产品架构下，甚至扩展类目压力都不是很大。

所以，搭架子是一个很基础的产品工作。一个好的产品框架需要同时具备易用性、稳定性、扩展性。

搭架子是一个如此重要的产品工作，以至于很多产品直接放弃了这个工作，搞起了拿来主义。所以，我们看到在中国，所有的电商产品、在线旅游产品基本上都是同一个产品框架。如果不是用色和logo的区分，你几乎分不出来哪个产品是哪个…..

搭架子的外在表现是产品的界面结构，这是一个比较容易被看出来的架子，而另外一个更重要的架子则是业务架构，业务如何通过技术作用产品。

比如说，你不能让业务之间有太多的耦合与相互嵌套，共用一套流程看似很快，坏处也显而易见，未来你想改动任何一个流程，都会影响到所有的业务；你也不能把同一个业务体系里的功能，分散到各个业务流程里去，应该建立一个统一的系统，通过调用的方式去支撑不同的流程，比如风控、个人信用体系等。

业务层面的架构与产品层面、技术层面的架构需要相互作用，最终确定产品的边界。

定流程

框架一旦确认下来，接下来一个很重要的工作就是确定流程。这里的流程表现在产品上就是产品流程，而背后驱动的则是业务流程。

在做快捷酒店管家的时候，我们没有依照现有的流程，完全从移动出发，从需求出发思考了一个新的流程。包括，不需要用户登录，直接用手机号作为帐号，密码就是每次的短信验证，最大限度的提高流程效率。默认就是用户自己给自己预订，预订就是一间房，尽量弱化分枝流程等等。这背后都是一个核心的业务逻辑在支撑，马上订，立即住。

uber的业务模式下，追求了极致的快，所以，uber使用系统发单的模式，用户点击使用，系统按照规则给用户派发一辆车来。而易到用车的模式则相反，用户点击使用，系统会给出一些司机，用户自己来选择司机。

一个系统决策，用户没有决定权，一个系统推荐，用户有完全的决策权。这2个流程下，2个产品的不同价值观与调性就出现了。用车这件事，并不是一个特别标准化的事情，因为用车背后的意义其实是服务，服务无法标准化，或者说，标准化的服务的边界很显而易见。再一点，用车这件事，核心并不是快，而是有车，其次是这个车符合我的要求。因为专车不像是出租车那么标准化与深入人心的信任感，所以，在使用这个服务之前，需要给用户建立信任感，建立信任感的方式就是让用户自己去选择。

这个选择，虽然是用户去点击了一次，但是并没有拖延用户太多的使用时间，在效率上损耗不大。

同样的，为什么uber那么强调信用卡付款，甚至在注册的时候必须要求绑定信用卡，而国内大多数的专车应用则把这个步骤放在了后面？2个完全不一样的业务思路，高门槛控制新用户，进入之后第二次使用流程超级顺畅，下单，来车，下车直接走人。

产品的流程必须追随着业务的流程走，然后通过交互方式的优化来提高用户的使用效率，这是产品的第二步。

抠细节

我们看到太多平庸的产品，根源就在于细节不到位。我最痛恨的就是PM对我说，我觉得这个也可以吧。一个也可以吧，心中的那口气就完全散了，再也做不出惊艳的产品。

不注重细节的产品可以生出来，但是肯定活不下来，不注重细节的产品经理也永远都只会是个功能经理。

先看看日常生活里的例子：

小卖部挂着一个牌子说：本店有新鲜羊肉出售，10块钱3斤。其实，只需要说，「新鲜羊肉，10块钱3斤」就足够了。

饭店门口经常出现的招聘信息：本店诚聘业务人员，男女不限，吃苦耐劳优先，有意者请联系，电话：13800138000。这里的’有意者请联系’是不需要的。

卖水果的叫卖到，「新鲜苹果，又大又甜 ，不甜不要钱」，通俗易懂、卖点明确。

我的朋友keith说，「一个写不好文案的产品经理，就像一个瘸了腿的武士」。

现实中看，能写好文案的产品经理确实是少之又少。文案的几个层次，把事情说清楚、不啰嗦、传递情感。大多数产品经理倒在把事情说清楚这里了。

把事情说清楚，第一看用户所处的场景，其次看语境。

互联网产品里随处可见的「确定」按钮是产品经理最偷懒的表现之一，这些按钮的名字完全可以根据不同的场景进行扩展的。我写完一篇文章，那个提交的按钮如果是「发布」或者「预览」会不会更清楚些？我修改了我的个人资料，那个确定按钮如果是「更新资料」会不会更清晰一点？

另一个表现就是随意造词或者搬词到产品里来做表述，在我的wordpress后台，「仪表盘」这个汉化的翻译我一直很困惑，这到底是个啥？

当然，近年来，有另外一个趋势是用图标代替文案提示了，比如用手机的图标告诉用户这里是写手机号的。这算是一种进步了，图标可以传达出这个要素的内容，也让页面更美观。但是，并不是所有的页面元素都可以同图标代替的。图标的表现方式只适用于大家都能理解的元素，并且图标并不利于扩展。

所有的文案都应该有特定的语境，结合特定的语境，有些文字是可以省略的。

比如上面的例子，你的门口挂的牌子，绝大多数的时候都应该是你的店里卖的东西，「本店有售」是一个不必要的累赘；而如果对方无意联系的话也不会没事儿拨打你的电话跟你扯淡。

啰嗦的文案很招人烦，同时也会让文案没有重点，浪费用户的时间。

如果一个人正在开车，你发了一段很长的文案出来，他哪里有时间看？在《汉武大帝》里，霍去病建议汉武帝给军士的诏书要越短越好，越通俗越好，士兵将士都是大老粗，哪里看得懂那些文绉绉的词汇。士兵们最在乎的是什么？皇帝奖赏我还是惩罚我，奖赏了我什么，惩罚了我什么，其他的修饰词汇他才懒的在乎。

同样的，在大多数产品，尤其是工具性产品里，用户在乎的就是你告诉他结果和该如何操作，其他的事情，不是他关注的对象啊。简单粗暴，直接明确才是最为重要的部分。

在移动产品上，如果要发布相对较长的文案内容，尽量用短句，一定要注意分行，先说结论，然后再做解释。

在短信通知上，尽量把突出的信息放在前面。比如一个短信验证码的内容，要保证验证码在系统消息栏直接展示出来，用户的操作场景是点击了「获取验证码」按钮之后，在那个界面等待输入呢，抬眼看到系统消息栏有内容了，记下来验证码，直接就在输入框输入了，这样的效率才是最高的。

用更少的元素直接告知用户结果，不需要用户自己去计算

不啰嗦的另一个表现就是，如果一个元素就可以让用户锚定一个信息的话，就不要用两个，两个信息，看似可以让用户更多的对比与了解，但实际上是增加了用户的认知成本，用户需要的是你直接告知他结果。

上周的时候，我跟同事探讨了一个设计。在产品上，我们需要通过一个元素来告知用户，给他服务的人什么时候可以到达。在产品上，使用了「距离」和「到达时间」2个元素。

我认为，2个元素太多了，不直接；我们应该用一个元素，给用户明确的预期就好了。所以，我选择只展示时间就好了。

同事反驳说，我们的时间计算的不准，所以我们用2个元素来同时让用户锚定。但是，再深入看，时间是根据距离计算出来的，距离并不是直线距离，是系统计算出来的路径距离。

那么，从结果上看，这2个元素是关联的，如果系统不准确，2个都不准确，放2个不准确的元素，更没有意义；同时，从用户的认知上看，时间是最直观的，其次是距离。如果时间的计算没有路径距离准确，我只能退而求其次的只显示距离了。（这个问题的根源在于技术的限制，产品做了妥协）

传递情感是一个更高层次的文案功底，一般出现在类似宣传页上，核心目的是引起用户的共鸣，下载或者使用或者传播你的产品。我曾经在内部做了个比喻，产品的页面分为几类、引诱用户下载的、引诱用户下单的、引诱用户传播的，不同的类型下，文案的方式不一样，但是背后的核心都是要找到引发用户共鸣的那个最直接突出的要素。

文案的练习是一个长期的过程，我的经验有这样几个：

• 坚持写作，写日记、写博客、写邮件；
• 公开演讲，向其他角色介绍你的产品方案、团队内部分享；
• 读书，读世界文明的法律文件、读调查报告

开会，最司空见惯而又让人无法摆脱的事情。

在我还短暂的职业生涯中，经历了很多次会议，大大小小林林总总。

我也经常被临时拉去参加一个开了一半的会，搞的我很不知所措，完全不知道讨论的什么，到什么程度了；我也经常参加一些超过2小时的会议，大家讨论来讨论去，始终无法形成结论，然后继续会议；我还经常被拉去参加一些我们完全无法独立形成结论的会议，或者结论就是说要看另外的人的决定，妈的，这是我最无语的，如果我们都不是能做决定的人，我们开始的时候就应该明确一下，找到那个能决定的人，直接找他不就完了，一群人浪费时间啊！！！

我曾经一度极其厌恶开会，但是，实际上我并不是厌恶开会这种形式，而是厌恶没有目的的会议，漫长的会议，没有章法的会议。

后来，我发现，很多人并不懂如何开会。更令我无语的是，我认为是最应该知道如何开会的产品经理这个角色中，也有很多人不知道如何开会。

开会这件事，就跟做一个项目差不多，而做一个项目，就跟你泡一个姑娘差不多。无非都是，事前研究，中间琢磨，事后复盘。

你必须先确定这样几件事情：

1、会议的背景与目的是什么？

– 作为一个召集会议的人，你需要先跟大家说清楚，我们要一起干什么，为什么干这个事情，我们准备达到什么目的。所以，相应的，你要准备好材料，并在你的会议邀请里描述清楚。

2、会议需要参与的人都有谁，哪些必须参与，哪些可以参与，哪些不需要参与？

– 不是每个人的时间都是那么的随你支配，也并不一定是什么事情都群体决策。不需要参加的人，发给会议纪要就可以了。

3、会议的形式是什么，头脑风暴、方案拍板？

– 也还有可能是抽生死签呢，不提前说，我还真不一定敢去。是否在邮件里讨论一下就可以，是否当面沟通一下就完成，是否需要召集一起正经八百的讨论……

4、会议的地点是哪里？会议的时间如何？

– 基本素养问题，没什么好讨论的。

5、会议的结论以什么形式发出，是否有记录供回溯？

– 没有记录，就没有发生；没有记录，就代表随意。

6、会议之后如何追踪？

– 我们形成的结论谁去执行，我们存疑的地方，谁去继续研究…..

相应的，

1、不参加没有预期的会议

2、不加入没有背景与目的介绍的会议，即使加入，也要提前问清楚，然后再开始讨论

3、能站着开会就别坐着，能当面沟通就别召集单独会议

4、手机静音、电脑关掉，记会议纪要的除外

5、形成了结论，就别再讨论了，先干再说

6、没法形成结论的会议，尽早结束

7、一定，一定，一定，一定要有会议纪要。纪要，只发结论性内容即可，稍微复杂的，发推导过程

题外话，

经常有刚入行的产品经理问我，我该如何培养自己作为产品经理呢？

我只有一个方法，别想着那是在做一个特别的产品，你就想着，你是在生活。你的生活中，最重要的是什么？是有计划，是有条理，是有目标，是有验证方式。

与一个同行闲扯，不知怎么地聊到了最近一个莫名其妙的问题叫做PM四件套。

在经过一顿调侃之后，我抽了颗烟，憋出来一句话，「产品经理应该少用甚至尽量不用PPT，善用多用Excel，常用纸跟笔，不断训练用口。」

1、少用甚至不用PPT

总感觉使用PPT的人都无法避免的陷入形式大于内容的怪圈。当然，工具本身没有错误，只是使用工具的人无法克制自己。

同时，我深信我是一个不太能控制好自己的人，所以，我选择少用甚至不用PPT。

（用keynote来做交互是另外一个高逼格高效率的玩法，另说）

2、善用多用Excel

说起这句，肯定会有人第一时间就联想到了数据的重要性什么什么的。并不是这样的，这不是我要表达的重点。

我之前大概的表达过一个观点，是在怎么写好需求文档的时候，我说，我们应该使用一个更好的方式，来同时兼顾阅读+操作。怎么个意思呢，就是说，研发的人可以一边对照你的需求文档，一边直接开发，而不是先翻到这里看半天，再翻到另一个地方，然后再来开发，这样效率会低下。

同样的，在需要从多个维度来描述一个事情的时候，Excel是最好的方式。

比如，甘特图是最好的表述计划的方式。同样的，需求列表等也可以用Excel来极好的表达。

当你需要从多个维度来描述一个事情，或者将一些事情划分成多个维度来进行展示的时候，试试Excel吧。

3、常用纸和笔

在产品经理这个行业里，永远都在讨论的一个话题就是，用什么来画原型。

年少不懂事的时候，尝试了无数个工具，最后，还是回归到了纸和笔。

将脑海中的想法输入到电脑的效率还是不够高，相比起来，直接通过纸跟笔的方式输出更为高效，而且局限性也更小。

一直梦想着会有一款只能硬件，在纸上直接书写，然后同步到电脑里，可以实现无缝的衔接，那就足够酷了。

4、不断训练用口

说服力，表达技巧是产品经理这个角色极为重要的外在表现。我观察发现，很多时候我们的沟通是非常低效的，根本原因就是表达的问题。

不知道怎么把一个事情按照一个好的方式表达出来，然后大家就讨论啊，讨论啊，讨论到很艰难的时候才发现也许大家讲了半天讲的不是一个事情。

表达就是讲故事，只可惜我们很多时候讲的故事太乏味了。

这里，再次推荐《金字塔原理》这本书。

之前跟团队开会，最烦的就是遇到这样的对话：

这个任务什么时候可以完成，按照我们的计划，是今天可以搞定的？

我在等A的接口。

那A的接口什么时候可以完成，他现在进展到什么阶段了？

不知道。

那你有去跟他沟通过吗？

额……

这是一个典型的等待「拉动」的人。你不拉他，他就不动，别人不拉他，他也不动。不拉我，我就等，等到了我就做，反正没做完问题不在我这里了，是另一个人没准备好。

或者也有这样的对话：

你的这个方案，基本不可执行，我们要花多少钱，覆盖多少用户，获得多少收益，我们的目标是什么？

这个不是我能定的啊，你没告诉我。我需要你来定一个目标。

那为什么当时要你做这个方案的时候，你没问？

额……

你发给我一个任务，我领了一个任务，我领了这个任务，我就要快速完成这个任务，至于任务的目的是什么，我不在乎，反正我按时交了方案。

这2类人，如果在一个大公司里，每天都可以很悠哉悠哉的。但是，这2类人，如果在你的创业团队里，尽快把他们干掉！

在大公司，老板要什么，我要努力给他达到，我只要达到他要的那个东西就可以了，其他的，我也懒的管，反正大多数时候老板都好糊弄，老板都是傻逼；在创业团队，我对这个事情是什么看法，我想要怎么做，老板你应该如何支持我，我要为整个事情负责任。

在大公司，基本都靠拉动，老板踢一脚，出来一个任务，我把这个任务完成了，事情解决了；在创业公司，靠推动，相互推动，在一个目标的基础上，我需要推动哪些角色，来提供哪些资源，我要完整的来负责这个事情。

靠拉动的人，最终都会沦为工具，或者晋升为一个更优秀的工具；懂的推动的人，最终都会利用工具。

在团队里，我一直倡导2个文化，我们要在工作上相互推动，相互透明。

所以，我所在的团队，必须都要有基于项目的站立会。花5到10分钟，每个角色都来说说自己目前的进度，即将开展的工作，还有需要的资源支持。

在早期，这是一种通过制度来帮助团队成员进入到推动状态的方式。后来，逐渐会建立一种观念，这个观念就是不再等待，而是主动去要，主动去沟通，主导去找。

另外，每个任务，需要有一个明确的时间点。那个时间点之前没完成，一定要提前申明，说明为什么。

一来大家知道你的进度，知道你问题出在哪里，我该怎么配合你；二来，你耽误了，那么跟你相关的人的计划就要重做。而不是要一直等到你给的时间点到了，才手忙脚乱的去更改自己跟你相关的计划。

或许，我们都应该问一问自己，你是一个善于推动的人吗？你喜欢主动还是被动，这很重要！