共计 3478 个字符，预计需要花费 9 分钟才能阅读完成。
引言
原文链接：https://mp.weixin.qq.com/s/9S…
谢邀，人在飞机，刚下海上。
《简洁至上：交互式设计四策略》是最近读的一本领导产品设计的书，它对我的产品设计办法带来了很大的扭转。
书中不仅有设计思维方面的内容，还有执行层面的方法论，让我一个齐全依附直觉和过往教训做功能设计的设计者首次感觉到 设计也是有迹可循。
本文算是一篇读后感 + 笔记的混合文，纲要如下
- 性能和可用性到底哪一个更受用户关注？
- 三类用户：支流、随意型、专家
- 为本人设计还是为用户设计？
- 四策略：删除、组织、暗藏、转移
性能和可用性到底哪一个更受用户关注？
书中展现了一个 2006 年的试验，该试验将用户分为两组去筛选性能数量不同的播放器
- 第一组（未试用组）：只能通过观察产品来做筛选
- 第二组（试用组）：能够试用产品当前再做筛选
播放器的规格如下
- 播放器 A：领有 7 项性能
- 播放器 B：领有 21 项性能
最终试验后果如下
| 抉择播放器 A 的用户比例（7 项性能） | 抉择播放器 B 的用户比例（21 项性能） | |
|---|---|---|
| 未应用组 | 34% | 66% |
| 试用组 | 56% | 44% |
由后果能够看出 对于没有机会试用的消费者而言，性能越多越能吸引用户留神 ； 然而消费者应用了产品之后，他们的偏好就会从器重性能转为器重可用性了。
简单的产品通常很吸引人，这是因为人们喜爱本人被突围在不必要的性能中。
当然这并不是说性能不重要，而是不要以性能的多寡来掂量产品的价值，这里援用一段原文作者的观点：
减少的性能越多，就越难发现真正对用户有价值的新性能。这样自觉增加的新性能早晚会成为垃圾性能。减少复杂性意味着遗留代码越来越惨重，导致产品保护老本越来越高，而且也越来越难以灵便应答市场变动。
简单的性能会导致另一个问题：过多的性能抉择会带给用户累赘。
给用户提供抉择会让人感觉本人在把控场面，但实际上支流用户更心愿少一些抉择，尤其是多种抉择都很类似的状况下，抉择就是一种累赘。
简略的用户体验不会强制用户去做这种抉择，哪种形式最无效应该是设计者思考的事件。
所以作为产品设计者，应该将关注点放在 产品是否满足用户最高优先级的指标上。
这不禁让我想起了前段时间开源的据库文档治理平台 Databasir，该平台有一个模板定制性能，用户能够将表头定义成本人想要的任意名字，如下图所示：
这个性能破费了我大量的工夫做设计、研发，但它的确成为了一个实打实的垃圾性能：用户才懒得来定制呢！
支流用户关怀的始终都是能看懂文档，而不是去学习如何定制文档好满足本人的偏好。
那么针对这个性能，Databasir 的支流用户理论要的是什么性能呢？其实是国际化。
对于一款开源产品来说，用户可能来自各个国家，在他们关上软件的时候，软件如果是以它零碎的默认语言展现那就是最好的。
用户会冀望更多的性能，通常是因为用户晓得本人面临了什么问题，但却不肯定晓得最合适的解决方案，正如乔布斯学生所言
用户并不知道本人须要什么，直到咱们拿出本人的产品，他们就发现，这是我要的货色 ……
三类用户：支流、随意型、专家
个别在做产品之前咱们都会定位产品面向的客户群，比方
- 软件编辑器的指标用户就是软件研发人员
- ERP 软件的指标用户就是企业中的财务人员
- 静止品类垂直电商面向的就是喜爱静止或有健身偏向的用户
- …
在《简洁至上：交互式设计四策略》中，作者又以用户对产品的态度将指标用户再次进行分类，次要有 3 种
- 支流用户
- 随意型用户
- 专家用户
支流用户个别都是最大的用户群体，他们抉择产品的时候不是因为产品所应用到的技术，而是你的产品可能实现某项工作（他们最感兴趣的就是立刻把工作实现），他们会把握产品外围性能的应用办法，但不会产生学习所有性能的想法。
以手机为例，这类用户的需要就是：能疾速地打电话和不便地上网。
专家用户个别是具备摸索欲的用户群体，他们会提出倡议，心愿能看到为他们量身定做的前所未有的技术，这类用户和支流用户的需要有着十分的区别
- 支流用户谋求易操控，专家用户在乎操控的精确度
- 支流用户想要靠谱的后果，专家用户心愿失去完满的后果
- 支流用户胆怯呈现谬误，专家用户则有拆解所有的激动
- 支流用户想看到示例和故事，专家用户想看到的则是原理
最初就是随意型的用户了，他们介于支流用户和专家用户之间，个别是有应用过同类产品的用户，也有趣味应用更高级、简单的产品，但却不违心接触全新的货色。
简略来说就是违心承受新的性能，但新的性能要足够简略，他们才承受。
除了用户分类以外，作者谈到了一个用户的属性：用户所属分类根本是不变的，也就是说不会在一段时间当前支流用户就会降级到专家用户。
即便是用户对一个产品应用了很多年，用户类型的标签也简直很少发生变化，而胜利的产品设计应该是面向支流用户的。
这方面在我做开源时也犯过同样的错，我在思考 Databasir 的性能时就站在了业余用户的角度（可能因为我就是属于业余用户？）。
为了能够灵便扩大数据库，我设计了一个性能：用户只有依照上面的表单填写完数据就能让 Databasir 反对他所应用的的数据库。
刚实现这项性能的时候，我还沾沾自喜了好一阵。
可起初我发现这性能大部分用户都用不了：学习老本太高了，我的用户也有很多非 Java 技术人员，看见 JDBC 这个业余词更是一脸懵逼 ……
最初我抉择了由我来替用户填写表单，用户只须要抉择内置的模板即可
这个模板由社区驱动，能够一直地增加进去，这就相当于将业余用户的常识传递给了支流用户，加重了支流用户的累赘。
为本人设计还是为用户设计？
美国作者马克·吐温有一句名言
如果你身上惟一的工具是一把锤子，那么你会把所有的问题都看成钉子
一个产品的设计背地通常会有多个角色参加，比方研发、设计、产品经理等，不同的角色属性导致了对待问题时的倾向性也有很大的不同。
设计人员习惯于留神用户测试中的失败案例、开发人员习惯于设想各种零碎出错的情景、产品经理则心愿能为用户提供交互式工具去解决各种问题。
主观来说每个角色对待问题的角度都是对的，但这种适度的倾向性理论就是把所有问题当做一类问题来解决（都是钉子），最初失去的后果要么并不是用户想要的，要么就是 100% 的致力失去了 1% 的收益。
无妨想一下：用户真的须要这个解决方案吗？还是你的锤子决定了你要这个解决方案？
四策略：删除、组织、暗藏、转移
最初就是策略篇，作者提出了 4 种做出简化设计的办法
- 删除
- 组织
- 暗藏
- 转移
删除
删除很好了解，就是删除不必要的性能。
但咱们常常会感觉删除不残缺的性能或内容会导致曾经付出的工夫和致力被节约掉了，这种景象被称之为”沉没老本误区“，这部分性能的老本其实是不可能发出来的，它兴许还在发挥作用，但保护它的收入也并没有缩小。
在探讨删除性能时，咱们常常会提出：“如果用户想 ….”。
这少数其实只是在刺激咱们的求全心理，放心本人漏掉了什么需要，这份担心之下就是工夫、精力和金钱的老本。
组织
组织其实就是一种分类，依照肯定的规定将类似的性能聚合在一块。
分块越少，对于用户来说了解的累赘也就越小。在做组织的时候个别须要强调一到两个最重要的主题，分块数量最好在 7 ± 2 的范畴内（因为这是人脑霎时能记住的最大数目）。
人类个别是依照某种惯性在做事，即某种特定的步骤，打乱这个步骤就会造成蛊惑，所以在做组织时，肯定要去了解用户的行为：他们想做什么，先做什么，后做什么。而后再尽力让流程与各个步骤的程序吻合。
暗藏
暗藏代表在用户和性能之间设置了一道阻碍，所以咱们必须审慎的做出暗藏的决策。
通常那些支流用户很少应用，但可能是业余用户须要的性能就非常适合暗藏
- 细节：比方邮件的共性签名
- 偏好设置：比方批改单位、时区等
优雅的暗藏会在用户须要时主动呈现，比方在 Chrome 浏览器中如果咱们选中一段单词，这时候就会弹出一个翻译的图标，我只有点击该图标它就能将单词翻译为中文。
当初我在思考一个性能要如何暗藏时都会想起书中的一句话：保障用户在后退的过程中可能遇到提醒。但，不要挡住他们的来路。
转移
转移很好了解，就是把正确的性能放到正确的平台或者正确的零碎组件中去。
以遥控器为例，老电视的遥控器领有很多的按钮
而最近的智能电视则就简洁不少，以小米为例
这并不是说小米的遥控器就会短少很多性能，它只是将性能都转移到了电视屏幕上的菜单上了，
总结
任何应用程序都会有一些无奈打消的复杂性。要害的问题在于：谁会面对这些复杂性？
泰斯勒有一个很驰名的实践叫复杂度守恒定律（也叫泰斯勒定律）
无论在产品开发环节还是在用户与产品的交互环节，其内在的复杂度都有一个临界值，达到临界值后就不能再简化了，你惟一能做的就是 将固有的复杂性从一个中央挪动到另外一个中央
产品设计者很多时候都得做出将用户面临的复杂性转移到产品外部这样的决策。
