”简单并不意味着欠缺或者低劣，也不意味着不注重装饰或者完全赤裸，而是说装饰应该贴近设计本身，任何无关的要素都应该被剔除“——Paul Jacques Grillo
前言
『简约远胜于复杂』，这是这本书想要表达的核心。我花两个周末读完了这本名为《简约至上》的书，书很精致，每一页都会配一个插图，这些插图恰恰是内容的巧妙佐证，每次都能够击中我，让我惊叹一句：『确实是这样』。
这本书对产品设计过程中的各个细节的评述十分到位，给了我不少的灵感和想法。
为什么简单很重要？
很多用过苹果产品的人和关注过苹果广告的人都会有一个感受，那就是简单且易用。
Apple Store 让你无需关心 APP 的来源、是否有恶意，也无需关心 APP 会被安装在何处，你只要搜索你想要的 APP，然后下载它就好了。而当你想要删除一个 APP 的时候，只要长按它，然后点击删除。
这种体验是我们在传统 PC 上几乎体验不到的，就是这样简单的设计，让用户能够轻松上手，掌握他们的设备。我将此视作为苹果成功的一个重要因素。
在本书中，Giles Colborne（本书作者）以 2007 年风靡一时的 Flip 相机为例解释了简单的力量。Flip 在当时是一款在功能上远不如其他竞品的相机，但是它简单易用，去掉了数据线，任何人拿到它就可以拍摄一段视频并上传到视频网站。就是这样的一款相机取得了重大的成功。
当然，这并非在否定那些可调节各类参数的功能强大的相机。Giles 将一个产品的用户分为三类，分别是随意型、专家型和主流用户，而在整个用户群中，主流用户占据了绝对大多数。Flip 相机让所有人都不需要经过学习就可以拍出一段让他们满意的片段，功能强大的竞品更符合专家型用户的需要，但却让多数主流用户无法快速地上手使用。
只有用户觉得产品是易于掌握的，他们才会乐于去使用，而易于掌握的产品，往往是简单的。回想一下：你是如何刷抖音的？你是如何在淘宝购物的？
再想象一下，如果在你进入抖音之前，抖音先让你选择一大堆的所谓你感兴趣的标签，然后让你选择是要立体声播放还是3D环绕声播放，你还会继续用下去吗？
如果你回答，『会』，那就说明你是一个专家型用户或者随意型用户（比如像我一样会到处看看的产品经理）。主流用户的回答大概率是不会。
实际情况是这样，你根本就不需要注册就可以刷抖音，也不需要选择什么兴趣标签或者做什么设置。在你刷抖音的过程中，它在慢慢了解你的喜好，然后给你推荐更多你喜欢的东西，而你要做的就是上下滑动手指。这就是一种简单（这也和 Giles 提出的“转移”策略相符，我会在后文说到）。
BTW：幸存者偏差
指的是只能看到经过某种筛选而产生的结果，而没有意识到筛选的过程，因此忽略了被筛选掉的关键信息。
为什么我们经常会在网上看到某些产品被骂的很惨但是销量或者用户量却在蹭蹭上涨的现象？
这里有好几个例子，被骂的体无完肤却卖的异常火爆的 Iphone XR，被指责功能简陋的微信却占据了社交的大半边天。
这就是一种幸存者偏差，只有那些觉得不舒服的用户才会来吐槽，而用得舒服的主流用户却很少会来发声，从而让我们产生了一种逻辑谬误——用户都在吐槽这个产品很烂。
普通用户只想要一个简单方便的聊天工具而已，而不是想要一个聊天之前需要先倒走十步，然后后空翻，笑着穿过9又3/4站台的工具——虽然这样可能会让人觉得很酷炫。
到底怎样才是简单？
简单不是把问题说明白，而是让问题本身就不需要说明。
回到上文说的例子，如果你是那个需要笑着穿过9又3/4站台才能使用的聊天工具的产品经理，你会如何去改善这个问题？
很多人可能会在 APP 中增加一个操作向导或者增加一串说明来引导用户使用。现实的例子就是类似于抖音一样的产品增加了一个非常好看漂亮的引导界面引导用户来添加标签和进行设置。
但其实正确的做法是思考用户最根本想要做的那件事情是什么 ，然后推倒重来。
Giles 举了一个非常形象的关于设置密码的例子。
这看似是一个非常好的解决方案，把问题说明白了，但是用户根本就不会去读，问题也没有变简单。
当然，这只是方法论。在实际的生产中，我估计很少有PM能有资源、能力或者魄力去推倒这样一个产品然后重做。（又不是不能Work）
我们要让问题不需要解释，而不是尝试去把一个问题解释清楚。
删除、组织、隐藏、转移
这是 Giles 提出的交互四大策略，他用一个电视机遥控器的例子很好的阐述了这几个策略。总结一下就是：
- 删除——去掉所有不必要的按钮。
- 组织——按照有意义的标准进行划分
- 隐藏——把不是最重要的按钮隐藏在滑盖下面
- 转移——遥控器保留最简单的功能，其他功能使用电视机屏幕上的菜单、手势等来实现。
删除——不做求全的产品
删除就是去掉不必要的，留下最核心的，多余的按钮/功能/信息都会给用户带来干扰，造成不良好的体验。这其实是一个非常难做到的策略。
往往我们在提需求的时候，需求并不是毫无根据的，于是我们总会说『假如用户XXX，他一定会需要这个功能』。
这就直接的导致了我们会认为每一个功能其实都是必要的，自然我们也就无法删除掉任何一个功能。
这样的现象往往是由于我们对用户的了解不够深入而产生的，因此最好的方法就是真正去看看、调查主流用户到底要不要，而不是产品团队、开发团队自己关着门想象“用户需要这个”。
任何一种设计都很难满足所有的用户，那么不如抛弃那些少数，而照顾那些主流用户。
我认为微软公司就是一个非常典型的例子，他们总有一些酷炫的功能和黑科技，然后把产品的体验做烂。众所周知， Windows 是一个兼容性非常强且功能强大的操作系统（你现在还可以运行非常古早的软件），导致有很多的包袱都无法放下，但是用户总会抱怨其有各种各样的问题。但其拥有超强的技术实力和垄断地位，这并不妨碍微软成为一家伟大的公司。
相反苹果就大有不同，能抛弃一些陈旧的包袱，将体验做好。我经历过 IOS 的某几个版本的升级，导致之前的 APP 完全无法使用的问题。你可能也听说过苹果将那些不适配新系统/新手机的软件强行从 Apple Store 下架，这会引起一些开发者和用户的不满，但是却保证了新产品的良好体验。
组织——将功能分门别类
Giles 提出，当要提供的信息或内容很多的时候，将它们有逻辑的组织起来会是一种不错的选择。换句话说，就是要对功能进行分类。
分类的原则就是用户的行为组织，即『想做什么，先做什么，后做什么』。
例如，遥控器上开机/关机的按钮应该组织为一块，接着应该是调整频道的按钮放在一块。如果将调整频道的按钮和开机/关机的按钮放在一块，就会让用户觉得不舒服。
想象一下，如果键盘上的字母键和数字键杂糅在一起是什么样的体验，例如把「4」和「V」换个位置，你还会觉得这个键盘好用吗？
其实不一定。如果有一个游戏，名字叫做『3V5』，谁最先按出『3V5』谁就是赢家。那么显然对于这个游戏的用户来说，把「4」和「V」换个位置是非常有逻辑且有效的，因为这符合用户行为组织『想要赢得游戏，先按「3」，然后按「V」，再按「5」』。但是对于大多数人来说，是没有逻辑的且不友好的，『3V5』一看就是个很无聊的游戏。
当然，实际上的产品并不会像遥控器/键盘一样简单，思考一下就能想明白。这就是考验产品经理的逻辑能力和归纳能力的时候了。
比如，你可以思考一下，Windows 系统的设置怎么组织分类才更好（假装你还没看过）？
隐藏——把不常用的藏起来
隐藏策略的核心是要把必要但是不常用的功能或者信息隐藏起来。
最常见的，就是将设置菜单隐藏起来，因为它是一个必须但是不常用也不是每个用户都会使用的功能。
Windows 将其系统设置藏在了开始菜单中一个不起眼的地方。微信把设置放在了『我』这个页面中的最下方。
你可以想象一下，Windows 键变成了设置入口，而微信在底部菜单栏中添加了一个设置TAB是什么情景。主流用户几乎不会或者很少去点击它们，白白浪费了一个非常好的入口。
Giles 还指出，功能不仅要能够隐藏，还要能适时的出现。
正如前面所说，隐藏的功能是不常用但必要的功能，那么用户如果想要的时候，就必须要让他们能够轻易的找到。
很好的例子就是搜索引擎的提示下拉框，当你在搜索框输入内容的时候，会有下拉框显示你可能想要搜索的内容。
再一个例子就是某些英文阅读网站，会在你把鼠标放在一个单词上的时候自动显示单词的相关意思。
在实践中，所有要做的功能都是必要的，如何把握不常用就是产品经理各显神通的时候了。
转移——与人或设备协作
这里主要涉及到跨设备的功能转移，以及设备与人的转移。
Giles 还是以遥控器为例，对比几年前的彩电电视机遥控器和现在的智能电视遥控器，你会发现后者变得简单多了。下面是一个 Apple TV 的遥控器。
但是你用这个遥控器能够实现的功能不仅没有变少，反而更多样了。因为很多的菜单都被移到了电视机上，你只需使用上下左右控制电视机上的光标就可以了。
这就是设备之间的转移。
那什么是设备和人的转移？
回到我们在第一部分末尾说的抖音的例子，你不需要在进入抖音之前选择你感兴趣的标签，而是抖音在学习你喜欢什么。
这两者的目的都是要给你推荐你感兴趣的视频，但是后者相对于前者就是把操作从用户转移到了手机。事实证明后者是用户喜欢的，也是简单的。
团队协作的若干提示
不要尝试说服团队中和你意见不符的人
这让我想起了我的概率论老师说的，『不要去和另外一个人争论，因为在他看来他所持的理论即为真理，在你看来你所持的想法是真理，谁也说服不了谁。』
在产品开发中，我们也会遇到某个团队成员可能对某个点坚定的持某一个不同意见，往往我们第一反应就是尝试去说服对方。
Giles 提出，我们不应该说服这个人，而是让他自己承认“错误“。
即你可以不停询问他，『接下来呢？』，『遇到这个问题要怎么解决？』
如果事情明显变得不合逻辑了，给对方一个台阶，他就不会再坚持这样的想法。如果对方对答如流，井井有条，就请思考是不是自己错了。
这就是很多公司在招聘的时候设置无领导小组讨论想要测试的能力之一吧。
开会讨论的目的是得出结论而不是评论
当评论家容易，提出解决方案很难。
我参加过好几次产品的评审会议，我会发现，与会者经常把自己当成评论家而不是工程师（包括我自己）。即大家会去批评这个产品哪里不好，但是又说不出一个更好的替代方案。
作为用户来说，提出批评无可厚非，但作为产品团队的一员，最好还是能够贡献出自己的解决思路。
到底是产品经理还是做产品的人？
这其实是苏杰在他的公众号提出的一个问题。即如果目标是为了让产品更好，增加用户体验，那么这个人就是做产品的人，不论是工程师、设计师、运营还是产品经理，而产品经理是把这些工作抽象出来集中处理的人。
理想中的团队的组成应该全是做产品的人，而不是工程师、设计师、运营和产品经理。
Giles 也指出，如果团队要能够更好的协作，就要统一蓝图和目标，即把产品做好，让用户体验变好。如果可以实现的话，团队的积极性会增加，也会省掉很多不必要的争吵。
最后
如果你认真思考一下，我们周围很多的产品设计，确实都用到了删除、组织、隐藏和转移这四种策略。
《简约至上》这本书给了我很多新的思考方式和灵感，让我换了一种模式来思考周遭的设计。
我十分推荐对产品和设计感兴趣的人来阅读它。
需要注意，读这本书并不会让你变成一个非常厉害的产品经理。书上能提供的仅仅只是思路和方法论，而不一定符合你要从事的工作和行业。成为一个厉害的产品经理需要很多很多的实践和经验（我正在努力中）。
如果你想快速的了解本书中的精华，欢迎你访问我的完全阅读笔记，我把所有的重点都记录在了这里。你可以访问我的网站 www.iamzjt.top 来查看。
我是一个0岁的产品经理，希望和你一起学习进步。
欢迎你搜索产品部的小张，关注我的公众号。
