《简约至上》——话说简单与明确认识

话说简单

简单的威力

像Flip、早期的大众甲壳虫汽车以及Twitter这样简单的产品，都会对市场产生深远的影响。它们简单易用，因此能够为大众所接受；它们值得信赖，因此会赢得用户；它们适应性强，因此总会发展出别具一格的应用方式。

拜Web、手机和低价计算机所赐，技术消费者越来越多。推出简单而强大的产品的机会也会越来越多。

复杂的产品不可持续

复杂的产品很吸引人。早在2006年，技术专栏作家大卫·波格（David Pogue）就把这种现象称为夸耀效用原理：人们喜欢自己被包围在不必要的功能中。

不断向软件中增加功能，同样也是不可持续的。增加的功能越多，就越难发现真正对用户有价值的新功能。这样盲目添加的新功能早晚会成为垃圾功能。增加复杂性意味着遗留代码越来越沉重，导致产品维护成本越来越高，而且也越来越难以灵活应对市场变化。

与此同时，用户也会对你的产品越来越不满意。因为增加的复杂性导致他们很难找到自己真正需要的功能。况且，一想到为那么多没用的功能买单，他们就更加不高兴了。（所有不必要的功能都是要付钱的）

汽车巨头2008年的遭遇已经明确地告诉你：用户胃口变化的速度要多快就有多快，霎那间的改变会令你措手不及。

不是那种简单法

在做技术产品的设计时，至少有3个角度：管理人员、工程师和用户。本书是从用户角度来看问题的，换句话说，我们要讨论的是怎么让用户感觉用起来简单。

一个人在一种情形下感觉简单的事物，换一个人或者换一种情形，可能就不会觉得简单了。不过，虽然为富有经验的用户设计复杂系统是个好玩儿的题目，但只有脱离了专家的掌控并以广大用户为念，技术才会真正变得有意思起来。本书主要考虑大多数用户的体验。

特征

简单并不意味着最少化。朴素的设计仍然具有自身的特征和个性。

简单并不意味着欠缺或低劣，也不意味着不注重装饰或者完全赤裸裸。而是说装饰应该紧密贴近设计本身，任何无关的要素都应该予以剔除。

换句话说，抛开极简主义，也能够成就简单。简单的特征和个性应该源自你使用的方法、所要表现的产品，以及用户执行的任务。

貌似简单

貌似简单的例子随处可见。减肥药、高尔夫球俱乐部的激光瞄准镜，以及“足不出户发大财”的方案等。这些貌似简单的东西没有一个能够应验的。相反，它们的存在反而会让事情变得更复杂，效果更差。

但是，某些貌似简单的做法已经被大众普遍接受。这些做法的特点是能解决眼下的问题，相对便宜，而且不会引起什么争议。正因为如此，一遇到设计难题，貌似简单的点子就会层出不穷。而且由于所有人都“知道”这些做法有效，因此即使失败也不会追究谁的责任。

比如说明书，操作向导，另一个貌似简单的例子，就是让一个有魔力的角色来预测用户需求，并告诉用户该怎么做。

热衷于做这种表面文章的人，永远不可能创造出简单的用户体验来。

了解你自己

看起来好像大大小小的组织都对简化事情天生具有免疫反应。

你要搞清楚简化用户体验将会如何影响方程式中的每一项。然后，还要将这些改变排出先后次序。比较好的做法就是对每项改变的重要性和可行性做出评估。如果问别人，他们会说什么都重要，一切皆可行。为此，最好让他们将重要性和可行性分出几个固定的档次。

落在图中右上角区域的改变最重要、最可行，因此也是你应该立即着手实施的。如果你能做出这个评估，就能为简化找到充足的理由。

明确认识

描述要点的两种方式

无论是设计整个Web站点还是设计一个下拉菜单，都需要对什么是简单的体验有一个认识。这个认识将成为判断自己是否保持简单的一个标准。

我有两种方式来建立这个认识。

简单而迅速的方式是用一句话把它写出来，包括我要设计什么、要遵循哪几条设计规则，尽量使用最简单的术语。然后，在面对设计功能对照表而犹豫不决时，我就会暂时停下来，问我自己：“做这个表是为了什么？”这个描述是我判断设计是否简单的基准。在做一些比较小的设计（如大型网站中的一个页面）或者在我多多少少了解设计背景的情况下，这种方式都是很奏效的。

更好而花费时间更长的方式是描述我希望用户拥有什么体验。具体一点儿说，就是描述用户的使用情景，以及我的设计怎么满足用户在该情景下的需求。在设计一些大型项目时（比如整个网站或者移动设备），这种方式很合适，因为这种方式可以让我深入透彻地考虑到每一个细节。

换句话说，长期坚持理解用户生活的世界，理解他们的偏好和行为，始终都是第一位的。

每个设计都是在考虑诸多限制之后给出的方案。最好是在设计之初就搞清楚都存在哪些限制。然后才能保证自己的设计能够与用户的需求紧密贴合。

走出办公室

先到用户要使用你的软件的地方去做个调查。多数设计方案的评审都是在安静的会议室里进行的。在会议室里，所有人都会对设计方案投入十分的注意力。然而，很少有用户是在这种安静的环境下使用软件的。用户体验是否简约必须要在纷乱、多变的环境中才能考察出来。

无法控制用户使用软件的环境，而只能使软件设计符合环境需求。

三种用户

提到简单，可以把用户分为三种类型。

专家型用户愿意探索你的产品或服务，并且会给你提出各种改进建议。他们希望看到为他们量身定做的前所未有的技术。即便拿到的是一个从未见过的产品，他们也会摆出专家的态度。换句话说，他们舍得花时间研究新产品，探索产品的新功能。如果你是造手机的，他们就是那些想要浏览手机的文件系统，哪儿都动一动的人。不过，这一类用户总体上占少数。

第二类可以叫做随意型用户。他们可能使用过类似的产品或服务。他们有兴趣使用更高级更复杂的产品，但却不愿意接触全新的东西——要想让他们认可新功能，那么新功能必须足够简单。比如说，他们可能会对更先进的手机感兴趣，但是必须保证能够轻松地导入他们宝贵的联系人。这一类用户比你想象得少，而且他们的学习意愿不强烈。

最大的一个用户群体是主流用户。他们自己不会因为你的技术而使用你的产品，使用你产品的目的是完成某项任务。他们会掌握一些重要功能的使用方法，但永远不会产生学会所有功能的想法。这些人的口头禅就是：“我的手机只要能打电话、能发短信就行了。”大多数人属于这一类。

你可能会天真地认为，一段时间以后，其中一类人就会升级为另一类人。但这几乎是不可能发生的。即便一个产品用了很多年，用户类型的标签也是不会变的。

各人对技术所持的态度与他们在使用产品或服务上花费的时间相比，前者对他们的影响更大。

针对前两种类型的用户设计产品或许更有诱惑力——他们更识货。不过，感觉简单的体验却是主流用户所喜爱的。

为什么应该忽略专家型用户

大多数公司都会在听取专家型用户的意见上花费很多时间——这些用户都是使用他们产品或服务时间最长的——因为跟这些用户会有很多共同语言。专家型用户都是技术狂热者，他们能够畅所欲言，对如何改进当前产品固执己见。

然而，专家并不是典型用户，他们的判断会出现偏差。他们不会体验到主流用户遇到的问题。他们追求主流用户根本不在乎的功能。

诸如此类的事情我见得多了：极少数人在那里制造噪音，顽固地要求那些对典型用户而言太过复杂的功能。

你会发现，要想说服投资人（作为业内人士，当然也是专家）不去轻信专家型用户（跟投资人类似）的意见是很困难的。毕竟，你的最佳用户都在你的产品上面投入了很多时间和金钱，而且，跟他们沟通起来没有任何障碍——他们一看到你，三句话就能说到你的心眼里，一些专业词汇甚至比你都熟悉。况且，他们都是那么通情达理——如果你让他们升级到最新版本，他们一点都不会犹豫。可是，一旦先听了他们的意见，你的产品就会让主流用户感到太复杂，不好用。

为主流用户而设计

保持中立好像会更稳妥一些。与什么都苛求的发烧友相比，随意型用户倒是喜欢使用一些新奇的功能，只要把它们设计得稍微简单点就行。

大多数“可用的”设计都将这个用户群作为目标。有在线预订机票经验的人被请去测试旅游网站，有使用手机拍照经验的人被请去测试拍照手机。因此我们要针对那些不是很难伺候的人展开设计。

通过观察这些人可以学到很多东西。我观察过的每一个用户测试都对改进网站或手机有所启示。但把这些人作为目标用户，实际上还是在考虑我们自己。

这类用户能够容忍长期存在的某些问题（比如在手机里转来转去地找自己的照片），因为他们已经学会了忍受。

然而，这些随意型用户还不够典型。这类人数量有限，相对极端，他们的技术水平较好，而且比主流用户更具有忍耐力。如果你想简单，想要被看成创新设计的先锋，主流用户才应该是你的目标用户。

如果你也想设计简单的产品，记住要为主流用户而设计。

如果为专家设计相当于为机械师造小汽车，那么为中级用户设计就相当于给那些喜欢自己动手修理引擎的人设计汽车。典型的用户应该是主流用户。

主流用户想要什么

在明确自己的认识时，要时刻把主流用户放在心坎上，这样才不至于无意间切换到专家视角，从而避免一些难以察觉的设计问题。

• 主流用户最感兴趣的是立即把工作做完，专家则喜欢首先设定自己的偏好。
• 主流用户认为容易操控最有价值，专家则在乎操控得是不是很精确。
• 主流用户想得到靠谱的结果，专家则希望看到完美的结果。
• 主流用户害怕弄坏什么，专家则有拆解一切刨根问底的冲动。
• 主流用户觉得只要合适就行了，专家则想着必须精确匹配。
• 主流用户想看到示例和故事，专家想看的则是原理。

不要指望你能教会用户多少东西，或者认为说明书可以帮助他们。在面临压力的时候，他们很容易忘记已经掌握的知识，对操作说明视而不见，回到初学者的层次上。

简单的用户体验是初学者、新手的体验，或者是压力之下的主流用户的体验。

感情需求

人是有感情的动物。即便是像工作表这样直观的应用，他们都想找到一个使用它的理由。

通过讨论更深层次的、感情上的需求，Things的开发人员理解了人们需要他们软件的真实原因，因而也促使他们把设计重心放在了满足隐性需求上面。

一个真正有用的应用不可能只是一个记事本。它还必须让用户感觉井然有序、轻松自在。Things就是一个真正有用的应用，因为它为用户提供了简单、灵活的组织任务的方式。

简单意味着控制

从简单这个角度来看，最重要的是让用户感到自己在掌控一切。

首先，用户希望感觉是在掌控自己使用的技术。

专家希望控制和定制技术。你需要站在主流用户的角度来思考“掌控”的含义：掌握结果。他们可不管什么软件或者技术，也不想让产品告诉自己该做什么。主流用户希望自己掌控起来容易、可靠、迅速。

你的设计不能跟这种掌控的感觉有什么抵触，而是应该放大这种感觉。简单的体验会让用户自信作出了正确的选择。简单的体验会让用户没有后顾之忧，因为产品的响应方式都是意料之中的。

其次，用户希望感觉是在掌控自己的生活。

有时候，掌控的感觉意味着要完成一个任务：女人买裙子时想要感觉掌控着自己的形象。有时候又意味着获取信息：男人看新闻就是要了解世界上发生了什么事（从而感觉自己对世界局势有所掌控）。

用户需要感觉自己掌控着自己的生活——从这种需求出发，还应该更进一步问：“然后呢？”

只有知道用户是谁以及他们的真实想法，你才可能有自己深刻的见解。

正确选择“什么”

下一个问题是：“用户在做什么？”

接下来要做的是描述用户从开始到结束一直在做什么。记住，你应该对用户的行为而不是你的设计最感兴趣。如果你在这个阶段过多地描述自己的解决方案，结果就会把自己绕进去。正确的做法是只描述一定程度的细节，能说清楚就行了。比如，一开始可以写“拍摄并分享视频”，然后列出用户行动的每一个步骤，详细程度要前后一致。

关键是不能遗漏用户体验过程中的任何一个步骤。

关注主要的行动，并且要从用户的视角把它描述出来。

描述用户体验

在研究某个问题的时候，你需要把它转换成一种认识。故事是描述认识的一种好方式。与一大堆需求描述相比，故事可以让读者更容易明白什么重要和为什么重要。

什么，你觉得故事不是非常有条理或者不具备技术性？错了。管理人员无时无刻不在使用故事（想一想公司的使命），技术团队也都在讲故事（流程图和用户案例）。用户体验团队同样也写故事写了很多年了。

故事应该用三言两语把核心体验表达出来。对于像Flip这样的数码摄像机，可以这样写：

你站在城市街头，忽然一阵骚乱：帕丽斯·希尔顿（ParisHilton）正向你走来。你迅速从口袋里掏出你的Flip摄像机，把它交给一位路人，请他帮忙拍了一段视频，帕丽斯就在你的身后。之后，你赶紧敲开附近朋友家的门，不需要任何安装配置，就通过他的电脑把这段视频分享到了网上。

如果你正在设计一款数码摄像机，这个故事会告诉你如下重要事项。

• 这个摄像机很小，可以方便地带到任何地方。也许是像一个小挂件一样，能够随身携带的那种。肯定不是只有在某些特殊场合才会用到的大摄像机。
• 开机速度快（因为帕丽斯不会等着你），而且拍摄简单，即使是第一次见到它的人都能够拿在手里就拍。
• 要上传视频不需要特殊的软件或者数据线。
• 最后，拍摄视频的目的是为了与朋友分享。

故事可以把大量信息浓缩到寥寥数语之中，效率极高。而且，故事很容易记住，很方便与人分享。也就是说，在你们讨论设计决定时很可能需要准备几个故事。事实上，人人都喜欢故事，即使你不讲，别人也会编出来（“如果我使用这个摄像机，我就……”），让你不由得跟着他们的叙述展开想象——因此，要确保他们在使用你的故事。

有必要多花点儿时间把故事的每一个细节都想清楚。如果你想让自己的设计简单，每一个细节都至关重要。

讲故事

不要担心故事的表现形式，关键是把你的所有约束条件诉诸文字。

故事的情节要简短。千万不要长篇大论地详细描述重大活动。要通过一个小故事展示出每一个需求点，并确定满足该需求的功能（核心功能）。这样做有3个原因。首先，简单的故事容易记也容易复述，因而容易被别人传播。其次，容易让别人把这个故事的情景套用到其他环境中（你可以想象在一个孩子的生日会上把你的Flip摄像机递给孩子的父母）。最后，为故事增加细节就像是拉近相机的焦距：人们会认为你要展示一些重要的信息。乐观估计，你的细节会吸引人；最差的情况，人们也会自己找到细节重要的理由。因此，务必只添加要紧的细节，这样你的故事才会真实丰满。

展示，而不是讲。人常说：行胜于言。描述用户的行为与介绍用户的性格相比，前者给人留下的印象更深刻。不要说用户注重细节，而要去描绘她反复按照备注核对自己的工作。表演出来会给人具体而清晰的感觉。

不要编造。你的故事必须可信，要想可信必须以真人真事为原型。前面讲的用Flip摄像机拍摄帕丽斯·希尔顿的故事，就是根据我的一位朋友的亲身经历改编的。一个特定的故事可以组合不同的元素，可以揉合不同的情节，即便不是真事也要让人觉得真实可信。如果不是有真人真事来支撑，你就很难诉诸文字，即便写出来也会显得假。按照这里的描述，合理使用相关的细节，就可以让你的故事具体可信。

多练几次，大声地说，对别人讲，重新修改。这样做可以帮你修补故事中的纰漏，提炼出本质的东西来。很快，你就能用简单的一段话讲一个小故事，并利用它阐发你的认识。

好的用户故事应该简明、具体、可信，并且拥有相关细节。

环境、角色、情节

回顾一下我们讨论的认识，大致可以为分三个层次。

• 可信的环境（故事中的“时间”和“地点”）
• 可信的角色（“谁”和“为什么”）
• 流畅的情节（“什么”和“怎么样”）

很多复杂的设计都是因为没有考虑到现实世界的压力而导致的，或是因为设计者期望用户自己能够应付一切，或是因为他们不小心漏掉了某个重要的环节。你的设计应该与你所讲的故事完美契合。

把你的设计放在一个情节中，情节中有可信的角色，发生在可信的环境中。用荷兰著名建筑大师埃利尔·沙里宁（Eliel Saarinen）的话说：“在设计一件东西的时候，一定要考虑到比这件东西更大的环境——椅子在房间里，房间在住宅里，住宅在土地上，土地在城市建设规划中。”

极端的可用性

看到简单体验的用户故事，你就知道了什么是简单的体验：能够适应极端条件。

要想简单，务必把目标定得高些再高些，不要使用常规的可用性目标。

目标中“瞬间”和“毫不费力”听起来有点夸张，因为事实上这是做不到的。然而，争取你不可能达成的目标有一个重要的好处：保持正确的方向。

如果把目标设定为“快速响应”而不是“瞬间响应”，那么哪怕把响应时间只缩短1秒钟，你也会满足了，认为已经作出了改变——毕竟，那也算是“快”了呀！

慢慢地，在一次次的改变之后，你会发现自己的设计不再简单，反而变得更慢、更令人讨厌。类似的妥协和让步随时都会发生在设计会议上，而这也正是为什么我们钟爱的产品会越来越令人厌恶的原因。

刚才也说到了，很多开始时简单的产品到最后都变得越来越复杂，很难使用。但是，如果你设定了一个极端的目标，你的产品就能随着时间推移越变越好（至少能够实现真正重要的目标）。

瞄准极端的目标，即使是那些无法完全实现的目标，也能够帮你保持产品简单。

简便的方式

在思考小的改进或者做某些小东西（如一个网页）的时候，通常会产生一些灵感并上升到全新认识的高度。

我会用简单的语言把正在设计的东西描述出来。我会大声跟愿意听的所有人说出来——我觉得这样做效果很好。如果自己感觉听起来不正常，或者听众们不理解我在说什么，我就知道应该修改措辞重新来过。而且，我经常会说给一些新人听，事先不给他们任何提示。如果身边没有别人，我会把灵感记录下来，但跟别人讲述才是最佳方式，因为他们的反应会告诉我是对了还是错了。

我的目标是拿出一个简洁、清晰、完整的描述。

我甚至想只用一句简短的话来表述。如果这句话既能忽略细节而概括出主要活动，又能不让听众失去兴趣，那么就说明它已经达到了简洁的标准。如果听众可以正确地理解，那么也就说明它足够清晰了。

有了描述之后，我不会四面出击，而是专注于如何用尽可能简单的方式来实现。对Flip来说，就是“瞬间开始拍摄，不费吹灰之力分享”。

通常，要做正确肯定得经过几轮反复，但这是值得的，因为反复可以让我关注真正重要的东西。

洞察力

运用学到的东西构思故事，然后再据以深刻理解自己要解决的问题，接着奇迹就会发生。

并没有什么窍门。只不过在你付出足够多的时间和精力后，终于实现了毫不费力的功能，你会感觉像是变魔术一般。

验证你的想法意味着还要花更多时间观察现实中的人，通常可以使用原型或者竞争性产品作为辅助。只有通过验证，才能知道你的见解到底有没有价值。

花点儿时间观察和研究你的故事背后的数据。

明确认识

无论是走大路还是抄小道，你都会发现写出自己的认识比自己想象的时间要长。

“作为设计者，我们希望马上开始设计。但克制自己非常重要。”Cultured Code的尤尔根·施魏策尔如是说。太早开始设计意味着会遗漏重要的见解，甚至意味着设计思路完全错误。

乍一看到某个问题，你会觉得很简单，其实你并没有理解其复杂性。当你把问题搞清楚之后，又会发现真的很复杂，于是你就拿出一套复杂的方案来。实际上，你的工作只做了一半，大多数人也都会到此为止……。但是，真正伟大的人还会继续向前，直至找到问题的关键和深层次原因，然后再拿出一个优雅的、堪称完美的有效方案。

——史蒂夫·乔布斯（摘自Steven Levy的Insanely Great: The Life and Times of Macintosh, the Computer that Changed Everything）

不要匆忙着手设计。理解核心问题需要时间。

分享

与别人分享你的认识，即使你不在场也能保证作出正确的决定。而且，你的所有干系人都能说出什么是好的决定，什么是坏的决定。

让最核心的理念随处可见，提醒人们时刻谨记。随时随地使用，让它成为人们时刻不忘的追求。把它公之于众，意味着团队所有成员都知道自己应该交付什么样的功能。

找到并开始分享你的认识之后，就可以开始设计了。

跟参与项目的每一个人复述你的故事，看见他们一次就讲一次。不要停下来，要天天讲，反复讲。直到你讲得自己都厌烦了，人们才会真正领悟你的认识。