当前位置 博文首页 > colorant的专栏：简约至上－读书笔记
作者：刘旭晖 Raymond 转载请注明出处
Email：colorant at 163.com
BLOG：http://blog.csdn.net/colorant/
复杂的产品不可持续
TODO：我们有哪些产品在功能设计方面，已经超过了它应有的复杂度？需要重点关注改进，或者抽象简化的？
为主流用户设计，而非专家用户
主流用户和专家用户的划分，需要根据业务具体分析，比如自定义查询的主流用户和开发平台的主流用户，可能就不是一个人群，何谓主流功能和专家功能，定义就可能不一样
再比如即使只服务BI／数仓／开发同学的平台，哪些同学的需求，是其中偏少数派的需求，属于专家用户而非主流用户的，在听取客户建议时，也需要反复提醒自己，甄别需求。对业务和系统最熟悉的同学的意见，并不一定是主流意见。要避免为了满足专家用户的需求，把系统搞得过于复杂，但也不能完全忽略，这就需要根据以下的四个策略原则来具体解决了。
实际操作中，如何识别那些是专家用户需求，哪些是主流用户需求，可能，更多的还要依靠数据的反馈，及时的调整，毕竟大范围的调查成本很高，不是所有的功能开发流程都能这样实施，特别是大众用户对自己的需求很可能也不明确的时候
简单意味着控制，要让用户感觉自己掌控了一切
个人理解，功能，界面不要让用户迷茫是一回事。就掌控一切的角度来说，在交互反馈上，还需要注意：任何操作，都需要有明确的结果反馈，比如：我们提交完一个任务以后，不要无声无息就没有任何反馈了，可以做的比如，提示用户下一步该做什么，自动导航去该去的地方，反馈执行进度，明确到哪里去看结果之类等等。再比如，如果任何操作过程产生错误，明确的告诉用户该怎么办，而不是抛出一个看不懂的Exception砸用户脸上
设计时，通过讲story，描述用户体验来思考产品和功能设计：什么环境，什么角色，希望做什么。
说起来很简单，但我们在设计产品方案时，可能常常并不是从这个角度出发的，而是习惯的跳过这个环节，直接按照自己的理解从具体的功能点或细节的需求点出发，而忽视了大环境Story的思考过程。导致流程或产品设计偏离用户的核心痛点，或者只是满足用户表面凌乱的要求，而非本质的需求。
需要注意的是，避免误删，不要因为功能难实现而删，而要根据价值和核心目标，避免导致系统最终目标偏离设计初衷
简单说，就是核心目标再难也要实现，不能以简化系统，保障进度，先上一期，后面再改等做为借口。否则，进度赶上了，结果和下场一定不好。
大胆砍掉不好用或残缺的功能，问题绝非“为什么要去掉它了，而是，为什么要留下它？”
沉没成本已然无法挽回，重要的是将来的成本（维护）和收益，还有用户对系统的整体体验的破坏。
TODO：需要找时间梳理一下各个系统的类似问题，先做一轮减法，再做加法
设计过程中重要的是问题的解决方案，不是流程的实现，当问题和流程变得复杂时，跳出来想想，还有别的解决方式吗？
重要的是要解决问题，不是怎么解决问题。简单易用的原则不能妥协，其它都可以变通。我们很多时候，没有这么做，还是因为对用户的核心需求，应用场景的把握不到位，拘泥于形式而非目标。
提供必要的尽可能少的选择，提供合理的默认值
让用户来做不必要的选择，只能说明设计者自己没有想明白哪些才是核心的内容，把思考的工作推给用户。 我们常常会以给用户提供更自由的选择为理由，不是没有这种场景，但更多的时候，想想是不是因为自己太懒。
减少让人分心的页面元素
审美问题，美不是炫出来的，一切元素要为功能服务。
消除用户可能犯的错误，再小的错误也会让用户烦恼，破坏体验，应该通过合理改造交互，让用户没有犯错的机会
很多时候，我们完善了各钟错误反馈，各种限制管控，就觉得自己做的很到位了，也期望用户能知错就改。比如，这个操作结果不对？对不起，因为你没权限，那个数据不通过？对不起我进行了合法性校验，你没有按规范来，别说我没提醒，我不是给你弹个Error框么？甚至还告诉你，有任何问题请咨询xxx。我们还有正确使用姿势的FAQ，系统robust的不得了。
但这样的系统，用户也可能是崩溃的。如果是用户经常犯的错误，那错的就不是用户，而是系统，没有想办法让用户规避这个错。
就是要合理整理，突出重点，好像很直白，没有太多想特别记下来的。
不要强迫主流用户使用自定义功能
也就是说，自定义功能不应该成为主流用户的使用路径上必需做的事。常用，不常用，应该设计者总结归纳，或者像下面一条一样，在用户的使用过程中，自然的引入。
隐藏精确控制选项，但专家用户必须能够让这些选项始终可见（比如记忆用户行为，像文件存储的拓展框一样，保持上次的偏好）
在降低主流用户使用成本的前提下，降低专家用户的使用成本。
如果可能，要做到彻底隐藏，然后，适时出现
像微信小程序的理念，不要在不必要的时候干扰用户。
把正确的功能放到正确的平台或者正确的系统模块中去实现。
不同地方实现的成本可能不一样，收益可能不一样。这点，在我们考虑开发平台各个系统融合打通的过程中，可能尤其重要。
把复杂性向用户转移！
这个点很有意思，如果用户期望的行为，你的确无法预测，或者就是千差万别。那么在：约束用户的行为，或者通过强大的界面支持各种行为之外，或许，用简单的交互界面，以简单，但不带强制含义的功能让用户自己定义自己喜欢的行为，这可能反而是更好的方式（不过这个真的很难做好）
这里的关键，我理解不是真的把复杂性抛给用户，而是说，一些功能，从系统来支持的角度来说，要满足群体用户可能是复杂的，但挪到具体的某个用户身上时，个体而言，场景并不复杂，那么一些设计就要考虑让用户自己去完成，和上一条转移到正确的地方去做，有点类似。
创造开放式体验，让一个功能拥有多种用途，哪种用途，让用户自己去选择。学习一种功能，总比学习多种功能，或者在多种功能中挑选自己要的功能容易
这一条，是实现上一条的一种途径。
最高境界是让同一个工具，大众用户和专家都觉得非常好用，简单的工具，自由的空间，比如菜刀，钢琴
反例来说，笛子之类起步就需要足够技巧的乐器，就不满足新手上手能用的标准。功能足够简单，用不好，不会太差，用的好，有足够的空间，大概也是上一条要实现的境界。
开放性界面，秘诀在于尽量减少仅适合中级用户实用的“便捷”特性
我理解是一些让交互和流程变得复杂，主流用户不常用，但是又不能完成专家所需要的所有定制化需求的这些特性功能。能不做就不做，能够帮助一些用户，但是会给更多的用户带来不必要的学习使用成本
总体而言，上面的很多内容，可能平时我们自己或多或少也有些体会，但是否足够重视，是否真的认可它的重要性，是否把它们作为出发点和基本原则，贯彻到所做的每一件事情中去。而非景上添花，可有可无的后续改进目标，可能才是看完书以后需要时刻提醒自己的。
顺道，推销一下个人公众号 “望月的蚂蚁”, 和技术完全无关。。。。 一切有趣的兴趣爱好等为主题。工作生活要平衡不是；）
