谁都想要简单。无论是在考虑手机、机械工具和汽车仪表面板的时候，还是站在商店里选购产品的时候，我们的期望都是一样的。“为什么我们的科技产品不能跟我家车库开门器一样好用？”有人在一篇相关文章里问道，“就一个按钮，要么开门要么关门。多么简单优雅！”

这期望来自生活中的普通人、报纸评论员和专业人士。既然期望如此明了，需求这么迫切，为什么产品却能做到这一点呢？

因为所有人都没抓住重点——简单性并不是最终目标。我们并不想放弃技术带来的强大功能和灵活性。车库开门器也许是很简单，但它也真的做不了太多事情。如果我的手机只有一个按钮，手机当然是简单了，但是……呃……那我除了开关手机之外，什么也做不了——连电话也打不了。钢琴有88个键和3个踏板，我们能因此就说钢琴很复杂，应该进行简化吗？音乐作品当然不太可能同时用到所有琴键。之所以呼唤简单，是因为没抓住重点。

市场营销专家会说，看看大家在商店里实际买了些什么就知道了，人们真想要的是功能。的确如此。我在之前的一篇文章中已经讨论过这个问题（《简单性被吹捧过头了》Interactions, March/April 2007)。

这就出现了一个明显的冲突。随着功能的增加，对产品的渴求度也会增加，而同时简单性却降低了。如此一来，大家购买了功能繁多的产品，便开始渴求简单了。这样看来，功能复杂度与简单性似乎形成了尖锐的对立。真是这样吗？照常规来衡量的话，确实如此。

我们的确想要功能多的产品，但同时也希望产品不那么令人迷惑，用起来不那么让人气馁。你瞧瞧，根本不是简单不简单的问题，而是产品是否容易理解掌握的问题。整个围绕产品展开的争论被放到了错误的框架里（简单性）展开。功能（feature）多寡与实际能力（capability）强不强不是一码事。简单不简单跟可用性高不高也不是一码事。简单不是所有问题的答案。

有这么一种潜在的假设存在：

功能（features） => 能力（capability）

简单性（simplicity） => 易用性（ease of use）

这两个式子体现出简单的思路：所有人都希望产品的能力尽量强大，于是就想要更多功能；所有人都希望产品易用性强，于是就希望产品简单。

可惜得很，这种思路是错误的，因为关系链被颠倒了。假如我说：

大晴天 ==> 不会下雨

那么，我们能不能因此就说，因为不会下雨所以天气就是大晴天呢？当然不能。箭头指明的是从左向右的推导关系，没有描述从右向左的关系——我们不能从右边的情况推导出左边的情况。因此更强大的能力（capability）并不一定要求功能（feature）更多，易用性高并不一定要求简单性高。

由此我可得出结论：关于功能（features）和简单性的争论带有误导性。我们完全可以渴求更强大的能力和更高的易用性，但不用将其与更多功能和更简单等同起来。人们想要的其实是好用的东西，意即容易理解的东西。

世界是复杂的，因此我们做的事情也是复杂的。但那并不意味着，我们就得生活在不间断的气馁当中。绝不是那样。以人为中心的设计（human-centered design），其实质在于驯服复杂性，把本来可能很复杂的工具转化为顺手的工具、容易理解的工具、受用的工具、用起来令人愉快的工具。

用设计来拯救

面对“把复杂性转化为易懂易用”的巨大挑战，我们不必担心，因为好的设计能帮我们做到这一点。大家想要的是更多功能赋予产品的更多能力，但又对由此造成的复杂性深恶痛绝。这真的是一种矛盾吗？并不一定。复杂性是可以被掌控的。

真正的问题是如何设计得让人容易理解，一旦认识到这一点，我们就成功了一半。好的设计能拯救我们。那么，如何来把握复杂性的问题呢？那就须要遵循一些简单的设计原则。设想一下，要把一堆杂乱无序、不易理解的功能转化为井然有序、容易理解的体验需要什么？需要的是模块化、良好的映射关系和恰当的概念模型（conceptual model）。还有许多其他的重要设计原则，但这三个已经能说明问题了。

模块化意味着，要把一个活动切分为更小但更易掌控的模块。设计优秀的打印机、扫描仪、复印机和传真机正是这方面的典范——把功能经由分组和图示被划分开来，每个功能都相对简单。HP发明了通用的操控机制（Q control），使得所有功能都具备同样操作用法，于是只要学会使用任一功能，就学会了使用所有功能。

良好的映射关系能保证在动作与结果之间建立容易理解的关系。

当然最重要的便是提供容易理解、有机结合的概念模型，让用户能够理解要做什么、发生了什么，以及应该期待什么样的结果。要想做到这一点，就得让产品能够持续不断地向用户提供有意义的反馈，甚至可以让整个反馈过程变得令人舒爽——看看Apple的产品就会明白。

情感化设计（emotional design）是用户享受产品使用过程的关键，其中最关键的要素是用户对产品的掌控感。这种掌控感在遇到问题的时候尤为重要。关键是在设计产品的时候，要明白用户和产品都可能出错，因此要确保能让用户理解发生了什么情况以及应该怎么处理。

关键并不在于追加功能与简单性的较量，或者功能性与可用性的较量。真正的问题在于设计：让设计出来的东西能完成期望的任务，同时保持高度的可理解性、良好的控制感，以及使用时的成就感。

本文译自Don Norman
原文：http://jnd.org/dn.mss/simplicity_is_not_the_answer.html