本文摘录了书中张小龙关于产品设计的36个观点，分享给大家。建议收藏+看完。

1、产品是进化出来的，而非规划出来

产品是进化出来的，而非规划出来。

微信的每个版本该做什么，都是等上一个版本发布后才确定的。我们不可能知道半年后的产品形态。

有DNA的产品才会进化。DNA到底是什么东西呢？

DNA是产品的价值观和认知，产品在进化的过程中，怎么才能看起来像个生物体那样，有自己的内在？这些都是我们在不断思考的问题。

2、把产品分为高中低端是不道德的

把产品分为高中低端是不道德的，因为人的高中低并没有一个标准。比如我们看到王功权（企业家，因私奔出名）在微博上说自己玩“摇一摇”，只许自己玩十次。

王功权很低端吗？也不是。

我们做“摇一摇”这个功能的出发点是很纯洁的，很多高端用户也很喜欢。

我们从做“邮箱”到“微信”，做的所有事情没有什么高中低之分。

我们在邮箱里面也不会特别为学生做一个中小学生版或幼儿版。这样反而对他们来说是一种“不平等”。

好的产品应该是所有人都喜欢的。

3、先做产品结构，之后才是功能细节

我们做一个产品的时候，结构是最重要的，之后才是细节。

微信里面包含的功能非常多，如果做一个列表把微信的所有功能列出来的话，会发现这是很恐怖的。

但目前大家用到的微信并没有显得很复杂，看起来还挺简单的。

以至于我们做了一个新版本，你都找不到它有什么新功能。

那是因为我们把微信的骨骼梳理清楚了，枝叶的东西藏得很深也没有关系，这样整个产品才不会乱掉。

4、功能模块之间是有机联系的关系

如果我们的产品都是由很多独立的功能堆砌起来的，那会很危险。

我们看到自然界的东西，不是像堆积木那样堆砌起来的，而是有机的联系起来的。

举个例子，当时做个人多头像的呼声很强，因为用户说需要多头像来展示。

如果我们这么做，也是可以的，可能也有很多人喜欢。

但是最终我们想把它做得简化一些，能够没有就没有，最后我们想到的办法是同时做了朋友圈和相册。

因为多头像的目的是展示给别人看，既然有了相册去满足，就不需要再去做多头像了。

5、设计就是分类

我们发现在做很多产品的时候，做得不好往往是分类分得不好，几乎大部分的工作都可以归结到这一点上。

哪怕是一篇简单的文章、一个用户的通知、一个产品特性等。

只有分类分得好，对用户才能显得亲切易懂，对产品才显得结构清晰。

目前微信的界面下，只有4个Tab，我们保证两年之内，还只有4个Tab。为什么要保证这样的规则？

这个源于Tony（腾讯主要创始人之一），他经常向我们提一些需求，要加东西。

我说没有地方放了，他说你们只有4个tab，可以加一个。过几天又提出一个需求，又说可以加个tab。

然后我和Tony说，我们定一个君子协议，两年内微信只有4个Tab，不容许再有第5个了。

因为4个最简单了，5个就变复杂了，5个对整个产品有破坏性的打击。

然后Tony也同意了，最终变成一个协议就确定下来了。

这样就很好呀，我们做朋友圈的时候，也没有把它放成第5个tab。

6、抽象方能化繁为简

我们做任何事情都要去想，是否抽象到“足够抽象”的状态，如果没有抽象到这种状态，就会把事情做得很复杂，甚至会失控。

所谓“抽象”就是，如果我们有100个需求，而我们能把这100个需求汇总成10个需求，从而派生出100个需求，那我们就做了一个很好的“抽象”。

如果能汇总成一个需求就更好了，一个需求就代表了所有的需求了，这需要我们去抓其“共性”的部分来处理。

我们在做外部信息的接入和订阅的时候，可订阅的内容非常广泛，名人、艺人、餐饮、服务、网媒、平媒等各行各业，都有自己不一样的需求。

但我们在微信里只会看到很简单的，高度抽象化的接口，只有一种账号体系，不同的内容都可以放进来。

我们不会为了不同的内容去做不同的系统来支持。

如果这里“抽象”做的不好的话，整个系统就会变得异常复杂，每一块都可以做成一个系统进来。

7、越简单的分类越易于被接受

QQMail是一个很好的例子，它发展到现在，用户看不出来它有什么样的变化，并没有变得复杂。

因为过多的变化会引来用户的不适应。

微信会升级，但是结构和界面依然会保持简单。

8、找到需求背后的本质需求

朋友圈该不该分组？是我们讨论的时间最长的案例。

很多用户反馈，我不希望我的朋友圈被所有人看到，因此需要分组的功能。

但是，即使我们提供了分组功能，很多这些反馈需要分组功能的用户也不会去用。

为什么？因为懒，因为人不愿意去做太多的管理性工作。

后面我们发现用户真正需要的只是屏蔽有限的几个人，比如父母、上级。

所以所谓的分组的需求，其实只需要屏蔽掉特别的几个人就可以了。

如果我们为了用户的想法“做了分组才在朋友圈发照片”而去分组，那肯定就不对了。

9、面向场景来设计，而非功能列表

功能脱离场景是没有意义的。

微信有一个版本中，会话里新来的语音是可以自动播放的。接下版本中，把这个功能我们下掉了。

因为语音自动播放是脱离场景的。

语音自动播放的场景只有两类：

1）只有一个人在场，没有其他人干扰的情况下

2）在开车的时候，旁边也没有人

除了这两个场景，其他很多场合自动播放语音很不方便。比如开会、比如在公共场所，自动播放语音就显得很尴尬。

但我们又希望支持某些场景下的自动播放，这就需要把场景再做细分，比如驾驶的时候。

10、面向场景，才能取舍

面向场景的时候，我们才能想到，为什么我们不要在线状态，以为手机是永远在线的。

我们在微信里做得比较成功的一点是，改变了用户在PC上聊天的一些习惯。比如不再用“再见”来结束微信里的聊天。

因为没有这种会话的状态。

11、让功能存在无形之中

让功能存在无形之中，是以前做邮箱的时候Pony（马化腾）说过的一句话，我们在做新功能的时候会特别参考。

因为我们做新功能时，总喜欢把新功能摆出来，总是怕用户不知道我们做了什么。这是新手的做法。

之前跟同事聊起，很多用户反馈在微信里找不到商家。我想说的是，把它隐藏起来，完全看不到，使用的时候才看到，这是最好的。

扫码成为会员也是，只有在扫码成为会员时，功能才会出现。

这样才不让系统变得更复杂。

12、区分手机和pc

前面「用户篇」中总结过，设计中环境是很重要的。

我们坐在计算机前和拿手机最大的区别在哪里？

计算机是一个环境，里面的内容对你来说就是外界。而手机，你可以认为，它跟你的肢体是连在一起的。

我们要深刻理解里面的差异，而不是把PC的产品移植到手机上就可以了。

因为我们不能把外界的东西移植到内在的东西里面。

13、不过渡设计

我们很喜欢表现自己的聪明才智，认为做功能越多会越好，做了东西没有被用户看到的话感觉很遗憾、吃亏

所以这里特别强调一点，很多的“枝叶”是可以去掉的，不要做得太过分。

一个例子，微信“附近的人”可能在所有同类相似的产品中是做得最简单的。一开始的版本甚至连按性别筛选都没有。

我们在讨论产品设计的时候，常常会想，怎么才能不打扰用户，特别是我们想把一些新功能体现给用户的时候。

现在很常见的是tips去提示新功能，看似体贴，实则让人烦躁。

14、宁愿损失功能，也不损失体验

以前的版本中，有用户反馈找不到删除会话的功能，为何不在微信界面左上角放一个编辑按钮，方便删除会话。

最后我们也没有这样做，因为用户多次返回上一级操作时，很容易触发编辑状态。

在这种场景下，我们觉得保证体验更重要一些，而非提供这个功能更重要一些。

15、产品，还是运营？

对于一个产品，我们更应该偏向产品本身还是运营？这没有绝对的衡量标准，这要看各家的特长和偏好了。而且对于不同类型的产品，也会有不同的侧重点。

我的观点是，做一劳永逸的事情是最好的。

很多开发的同事都知道，我们要做“类型”还是做一个一个“实例”？如果我们不是把各种订阅内容抽象为一个订阅平台的话，可能就会做了很多很多的“实例”出来，产品变得非常复杂。

邮箱漂流瓶和微信漂流瓶有什么区别？邮箱里的漂流瓶有不同类型，有同城瓶、交友瓶，是一个个“实例”，偏运营多一些。微信漂流瓶只有一种。

可以想象，邮箱漂流瓶因为用户需求类型增加就增加“实例”，这样做下来，会把大家累死。

所以我倾向直接做到最本质的东西，至于他能满足用户什么需求，那是用户自己的行为。

我们做一个“类型”，用户自己产生“实例”就可以了。也就是做高度抽象，而不是具体化。

16、让用户推动用户

怎让用用户去推动用户，而不是系统去推动用户？

我们常常认为，发现用户的行为不太好，可以通过系统努力去“教育”或者“引导”用户，让用户符合我们的期望。但这不是好的办法。

比如如何让微信新用户设置头像？可以注册时必须上传头像，比如当做任务奖励。但我们这样做。

没有头像的用户，发送给好友的消息，是没有头像的。当用户发现自己没有头像时，很快就去设置了。这比引导用户去设置头像自然得多，这是用户自发的，不是被系统引导的。

17、极简方能不被超越

“摇一摇”是非常好的一种体验过程，这个体验过程包括了肢体动作、来福枪的声音、动画以及操作的结果，非常连贯。

我们把这个功能已经做到了极简化，这种极简化的体验是很难被超越的。

如果有一个东西已经做得非常非常少了，要更少是很困难的。

18、面向未来场景来做设计

要不要做“已送达”这个特性，我们当初争论了很久。

当时支持的一个重要的理由是：我们将来的服务器会很稳定，网络状态也会越来越好，消息是必然会送达的。

虽然说现在（指2011年）的网络状况不是很好，也会出现丢消息的情况，但是我们首先要考虑的是未来的情况，要根据未来的场景来设计。

19、操作的响应速度永远是第一体验

我们在做邮箱时思考，对于一个产品来说什么是好的体验？可能需要满足几个要求。比如“切入要准”、“功能设计得要好”。

但是我们把速度单独列出来，“速度一定要快”，这个速度是指系统响应的速度。

回顾邮箱能做起来，有两点是最重要的。第一是简单，第二是速度快。

简单和速度快，合起来就是简单快捷。

“简单”和“快捷”是用户体验里重要的两个关键词。

微信4.0的时候，点击进入一个会话群的响应速度是挺慢的，我们做了很多改进来保证进入速度得到提高。

在微信的朋友圈里，我们的开发做了很多次重构，才保证了时间线的流畅体验，保证我们速度能超越所有有时间线的产品。

虽然为了提升这里的速度，开发的代价很大，但是这样的代价是值得的。

20、如果一个特性不能让人兴奋，不如不做

一个特性的决定是来自上级任务？还是来自版本计划？

对于产品经理来说，这个特性本身不足够令人兴奋，让人产生热情的话，可能做了也做不好，也没办法理解这个特性还可以有哪些亮点或者别的什么更好的想法。

好奇心是产品经理的驱动力，你不可能真正理解自己不感兴趣的需求。

21、保留变化

保留变化是围棋里的一句话，这在产品里面也是挺重要的。

在产品里面我们常常会把后面版本该做的事情放到前面去了，这会导致我们把1.0版本规划得非常完美，把2.0的东西给做了。

比如web微信上线的时候，很多同事提意见说功能不全，为什么做了这么简单的功能就发布了？

我们没办法一下子就做一个功能全面的东西出来，如果我们再做一个版本就做全面功能的话，一定是错误的。

因为我们不可能一开始就想得那么细，只能一边做，一边看发布后用户有什么反馈，根据反馈再决定2.0应该做什么。

也有用户提到，觉得微信的朋友圈很粗糙，连评论和回复都没有就发布了。当时并不是没有想到，只是觉得这些东西是可以放到以后再做的。

22、如果没有自然增长，就不必推广

不管是做邮箱还是做微信，我们都追求用户的“自然增长”。

微信在2011年5月才开始在邮箱里做推广在此之前，微信没有打任何广告，因为我们还没有看到自然增长的曲线，或者说增长得很慢，没有一个爆发点。

当一个产品还没有到爆发点的时候去推广做广告，他的投入和收益是不太成比例的。

好的产品应该是自然增长的，而不应该为KPI而改变产品。KPI这是一个好产品的副产品，好的产品自然会产生好的增长曲线。

23、保持粗放，保持笨拙

做产品可以保持一些粗放的状态。如果还没有好的解决方案，一定不要先去做。

因为我们的需求非常多，当没有想好方案或者没有想到方案会带来副作用，硬要去解决的话，可能会得不偿失，产生的副作用可能会远远大于正面作用。

举一个案例，发错群消息。这个问题还挺普遍的，也挺难解决的。

我们以前尝试过一个版本，把群聊的气泡变成蓝色（其他的是绿色），希望用户可以通过气泡的颜色来辨别群聊。

但发现这种方案很难接受，用户接受了绿色气泡，就不是很能接受蓝色气泡。我们也不能在用户输入的时候提升用户：你正在群聊中，发消息请小心。

所以我们先把问题放着了，放到后面想明白了，再去解决。

24、如果解决方案非常复杂，一定是问题错了

有一次，一个能力很全面很厉害的开发同事在朋友圈抱怨：觉得微信的代码越来越复杂了，开始搞不定了。

我在后面给他写了一句评论：如果一个问题的解决方案太复杂，一定是问题本身错了，事实上就是这样的。

一个好问题，不应该导致解决方案太复杂。

比如为了解决视频通话里面多种状态切换的问题，里面的状态有点太多了。这时我们跳出技术方案反推回来，会发现可能我们的需求一开始就定义的不对。

25、在每个细节中体现认知

我们会发现有些应用很奇怪，在细节上出现一些难以理解的东西。

比如微博的博文后面，会出现“来自iPhone客户端”、“来自iPad客户端”...之类的。

这里我们一直没有想清楚，为什么“来自iPhone客户端”是值得显示的信息。

虽然前面提到过要满足用户的“贪嗔痴”，这也是“贪嗔痴”的一部分。但是这些信息是没有含义的。

所以我们不会搞一个“微信iPhone在线”这样的东西。

而从需求上来说，地点就显得更有意义一些。

另外，这也跟我们产品的态度有关。

26、给用户选择权

为了保持微信的简单，在微信里面，除了核心功能，大部分的功能都做成插件的形式，这个方向很早就定了下来。

这让我们就算加了很多东西，也没有把微信变得复杂。

所以微信里面可以看到很多插件，而这些插件都是可以卸载掉的。甚至一些大的功能，比如朋友圈、语音视频聊天等都是可以卸载的。

所谓的平台，就是最基础最简单的核心架构，可以支撑更多的插件插入，这才是一个平台。

27、尊重用户

在尊重用户这一点上，我觉得我们一直做得还不错。

比如最基础的用户隐私保护，通讯录上传需要经过用户同意，LBS暴露位置需要告知，不去诱导用户做一些事情。

在任何时候，只要在编辑状态下有可能因为crash或别的原因导致数据丢失，都应该把中途的数据保护下来，方便用户下次使用的时候找回数据。

举一个尊重用户的案例。

我很早就在想，为何我们给QQ邮箱用户的通知都是“系统管理员”作为发言方，为什么不是我们自己的美女产品经理？

之后，我们的“系统管理员”的邮件，被替换成一个真实的产品经理。

这一点值得很多产品借鉴，只需要做一点很小的改动，就可以让用户感觉是跟一个背后有人的产品在沟通，而不是在跟机器沟通。

28、把用户体验做到极致就是创新

我们知道微信有一个特性，把手机放到耳边，语音的声音会切换到从听筒出来。

可能很多用户认为，这是通过听筒旁边的遮光传感器做到的。

但是测试一下就会知道，并不是。微信会识别用户的耳朵。

为什么会识别呢？其实我们是通过动作的识别做到的。

这个方案创意来源于Siri。虽然不是我们发明的这个特性，但是能把它用到极致也是非常好的。

29、你的价值观（态度）决定产品的特性

回到之前的问题：要不要做类似显示“iPhone在线”这样的特性。这取决于你的态度和价值观。

举个例子，朋友圈发照片，要不要提供滤镜功能？这个问题是没有办法通过理性的分析找到答案的。

有一次，我在朋友圈分享过一个观点：真正的生活状态不应该有滤镜。

如果不反思这个问题，我们的做法或许是越多专业的滤镜越好。这个结果可能也不会有错，可能很多人也会很满意，但这结果未必是好的。

所以，朋友圈一开始有提供滤镜，后面我们把滤镜下掉了。

我们对功能的设计，是很主观的，跟我们做产品的价值观和态度密切相关。

30、改变用户习惯

我们做用户体验的都知道，用户习惯是很难被改变的。

但是有些时候，我们确实需要去改变一下用户习惯。

我个人非常不喜欢电话这种没有经过预约的骚扰，是一种强行中断的行为。这种中断的行为对于每个人来说都不那么舒服。但是因为一直以来都是这样，大家就默认了电话来了就要接。

我们在做微信视频的时候，就一直在考虑能不能做得不一样。

比如视频通话需要经过对方某种程度的认可，比如规定10分钟之内，对方给你发过消息（表示他有空），并且你们正在联系，你才可以拨号过去等。

31、抛弃不人性的创新

我们很少专门说创新，不说的时候就会做很多创新的事情。每天都说我要创新的人，往往是没有创新的。

之前看到一句话我专门记下来，觉得写得挺好的：你要不计一切代价地展示聪明，还是选择善良？——贝索斯

聪明对于我们大部分人来说，都不缺少，但我们往往把聪明表达得过分了，在产品里，会在很地方，千方百计的表达出来。

32、避免战略行为替代真实需求

比如一些“多合一”的产品，多实践几次后，就知道“多合一”的都是不好的。

“多合一”的情况出现，一般是多个产品都遇到了麻烦，还不如不做。因为多个50分的产品合起来，一定是低于50分的。

如果是好的产品，是不需要打包销售的。

之所以说这些方法在通常情况下都不好，是因为它不是来自用户的需求层面，而是为了数据层面，或者是想象中的结果。

比如朋友圈里最重要的信息，是每个用户产生的有价值的照片，而不是把Qzone里面一个相册的几百张照片都导入进来，或者把微博里面的内容导入进来。

这些东西的导入反而会破坏朋友圈的价值，会让大家都不想玩了。

战略行为不一定来自需求层面，更多来自战略任务。

战略任务可能放在任何一个时代都成立，但是在真实场景下不一定成立。

33、从人出发，改变商业模式

商业模式的改变，是让用户能够动起来，然后才会产生新的商业模式，而不是我们先计划好一个商业模式，用户就跟着计划动了。这只是一厢情愿而已。

所以我们做产品的时候，常常会思考，到底这只是我们自己一厢情愿地认为可以，还是用户的意愿。这里的区别会非常大。

34、没有设计，只有解决问题

前面讲了很多设计上的问题，到这里我想跟大家说，其实没有设计，只有解决问题。

很多人把设计工作想得非常高端，觉得这是一个很高尚的职业。

其实我们每天都是在解决问题，而不是从事设计工作，只有把问题解决好了，才是做了一个好的设计。

但不是为了去做设计而去解决问题。这是本末倒置的。

35、创新，还是抄袭

这可能也是一个敏感的话题，是很值得讨论的。

当朋友圈发布以后，我发表了一个想法。

在我们发布朋友圈的时候，评论界立马发出评论说我们是抄袭的。

但是我们自己知道自己所做的事情是在抄袭，还是在创新。

我们很理解为什么那么多人喜欢说别人抄袭，一个人自己很平庸，所以希望别人也很平庸，评论别人抄袭能获得心理上的安慰。

我们需要允许别人获得安慰的权利。

我们做的所有事情，都来自知识的积累，而不是凭空的想象。

贝尔发明电话一百多年后，还是很多人做电话相关的产品。那是不是大家都在抄袭贝尔呢？就算是贝尔，可能也是延续很多先去的研究而发明了电话。

所以我们说的创新不是凭空生什么东西，这是不可能的。

比如“摇一摇”，基于传感器来做的，我们不能说因为传感器已经有了，就不能做“摇一摇”，就不能用传感器。

我们不用太在意你用的知识是否有前人用过，但是你可以以新的方式去使用它。

最终我们面对一些指责的时候，可以用产品说话。用产品说话，比去辩解什么更有威力一些。

36、朋友圈的演化故事

朋友圈是我们做的特别辛苦的特性，也是团队内PK次数最多的，讨论各种场景，讨论各种可能性。

我们要把朋友圈做得真正符合用户的需要，而不是跟其他某个产品一样，这样的难度确实非常大。

当很多人提到朋友圈的时候，觉得这是一个path或Instagram，而不知道我们经过了多少努力才演化成这样的一个产品。

有些人以为，我们可以一下子就知道一个产品该怎么做。其实并不是这样的，特别对于一些比较复杂的大型一点的功能来说，真的是挺难做的。

需要大家不断在脑海里面，在PK里面模拟各式各样的场景、各式各样的可能性和用户想法，特别是我们不再考虑单个用户，而是考虑一群用户，考虑他们会产生什么样的行为，这些行为是正面的激励还是负面的。（编辑：也很美）