>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

一些设计的基本原则往往是通用的、甚至可以说放之四海皆准的，例如优先级、一致性、界面的隐喻等等，好的设计都需要考虑到这些问题，甚至再更广的范围内也同样适用，而不仅仅是交互设计范畴。

一个设计师&产品经理应该在决策时下意识的、本能的考虑这些原则。就像以前很多零售业者能够一抓准，你要一斤糖，他抓起来就是一斤，不多不少，靠的就是不断的练习+思考，最后将其变成了自己的本能。

越是通用的标准，往往也就离细节越远，需要结合界面的具体部分（信息架构、导航、交互、语词、视觉等）和产品的具体领域（例如音乐播放器、阅读软件等）来看。往往说起来总比做起来容易，是不是纸上谈兵，就要在设计中具体去把握了。

这里抛砖引玉的列出让我印象最深刻的3个半原则：

1. 优先级

苹果的设计为什么让我们觉得精彩？为什么我们父母级的用户都能够很快入手？我曾经观察我的父母试用iPad，他们能够很快开始尝试操作，而不像面对很多其他的数码产品时那样无从入手。其中的一个重要原因是苹果在处理设计的优先级方面非常成功。当我在看iPhone非常细节的设计时，常常非常佩服他们的设计师&PM能够如此有魄力的砍掉功能和界面元素，从而让重点的变的更重点，让需要突出的变的更突出。

一个基本的假设：如同经济学里资源的稀缺性假设一样，用户的认知资源和系统的界面资源都是稀缺的。

当你把所有重要的东西都摆上桌面，就没有重要的东西了。用户的认知空间和认知能力有限，当他们面前有1条路可以选择时，事情会变的很简单，但是当他们面临3条路时，往往会踌躇不前。尽管我们难以量化的说用户有多少精力在这种抉择中损耗掉了，但这种损失是显而易见的。看看Android原生系统的设计，用户想要运行一个应用时，有几条路？

设计中对优先级的把握就是要让我们能够将真正重要的功能/内容/元素放到突出的位置，以最多的界面资源去展示它们，而将次要的部分，弱化、隐藏起来，再次的部分，则索性砍掉。

具体来说：

a. 用户优先级

把握核心用户，为产品自己真正的用户群做设计，不要天真的认为你的设计可以满足所有用户。

b. 功能优先级

把握核心需求，亮点功能往往两三个就足够多了。功能航母往往容易沉没（看看为何现代战争中巨型战列舰都逐渐被淘汰了），Nokia VS Apple也是这样。有一次Tina（创新工场的COO）的一句话很受教，她说她以前在（微软或IBM）做Marketing时，给客户讲产品，往往一次只讲三个Feature，即使这个产品或版本有再多的亮点。设计或者开发产品时我们总是想尽可能的将好东西放进去，但是打动客户/用户的点却往往只在三个之内。

c. 内容/信息优先级

将内容分成不同的层次，核心内容需要明显的突出出来。报纸上的标题、摘要、征文等层次清晰、泾渭分明也是这个原因。

d. 交互优先级

主要的交互路径需要让用户以最小的精神代价就能走的通，尽量减少这条路上的分支。为此，一些时候不得不将一些次要的交互路径更含蓄的隐藏起来。最常用的可能是“高级设置”这样的形式。

e. 视觉优先级

视觉更需要层次，重点的视觉元素需要让用户一眼扫过去就能看到，而次要的信息则要拉开距离，通过留白、颜色对比等等手段。一个例子是做PPT，当我们看到好的PPT时，总发现里面有大量的空间、有灰色的文字，这样将重点突出出来，而很多人在做PPT时则会直接COPY大段文字，直接用粗体、黑色，满屏幕只见到黑色的一片。

和优先级这个原则互通的概念还有简化（简化的目的实际上就是突出重点）、减法原则等等。

2 一致性

一致性可以让界面更容易被预知，可以降低用户的学习成本等等。一致性几乎是设计中最普遍的一条原则，也是缺乏设计经验的团队最容易犯的错误。做可用性评估时，几乎每次都能找出一堆的不一致问题。

通常需要注意一致性的地方包括：

a. 交互逻辑的一致性

完成同样功能，交互逻辑是不是一样的，流程是不是相似的，背后就好像有一样的数学模型似的。

b. 元素的一致性

同样的交互逻辑，使用的控件等是否是一致的，例如这里用按钮来执行动作，在那边变成了图标，另一个地方又是链接。

c. 语词的一致性

界面上使用的语言，在描述同一个事物时是否是一致的。

d. 信息架构的一致性

信息的组织层次方面是否是一致的，导航是否是一致的，等等。

e. 视觉的一致性

界面的图标、颜色、区域的分隔、指向等方面是否是一致的。

通常一致性还有另一个问题，就是在什么时候做出权衡取舍。

有时强制的一致性会引发其他问题，例如用户在执行某些任务时效率会降低，会导致界面的复杂度增加等等。这是我们不得不做出权衡，决定是保持一致性，还是采用一个异常的但又合理的设计。以前碰到的例子是，需要说服做开发和测试的同事们在某些特殊的地方牺牲一致性来得到更好的设计。他们会很在意一致性，这几乎是设计师最容易推动的原则。

3. 感觉

可用性工程的教科书里，往往会有“主观满意度”的内容（实际上这也是ISO9241的内容之一），但是却也往往语焉不详，因为主观的问题往往难以通过工程/经验的方法来解决。

但是我们还是可以找出几个明显的能够在设计中考虑到的点，来照顾用户的感觉。例如以下几点：

a. 快的感觉

天下武功，无间不摧，唯快不破。IBM做测试的同事会拿秒表（当然他们似乎还有更好的工具）来掐时间测试Performance，如果某个版本的Case有Performance的明显下降，会是个大事故。

我们通常还可以在设计上有很多处理来产生快的感觉，例如先让界面显示出结果，同时后台再去做操作（例如存储等耗时间的操作），避免用户的等待（当然最痛苦的是被工程师告知界面上的显示效率就已经低到需要用户等待了）。

曾经看过一个研究，在进度条的显示上，越来越快的进度条最能够让用户感觉到快，而不是那些完全真实反应内部进度的进度条（真实的情况可能是越来越慢）。

b. 安全的感觉

用户敢在看起来很“山寨”的界面上输入自己的密码么？用户需要经常自己保存么？Google的Gmail是个好例子，而MS Windows的升级后自动重启是个坏例子，某一次我同时遇到了它们：Windows XP打完某些补丁后，会要求重新启动系统，这时你可以选择立刻重启，或者点击一个按钮，等待若干时间后再提醒，如果什么都不做，它会在一小短时间内自动重启。当我正在工作时，显然不愿意立刻重启系统，于是我选择了稍后提醒，然后又工作了很久，在Gmail里写了一封邮件。这时刚好有人来找我讨论问题，等回到电脑前后，发现它自动重启了..... @!#!#!$，没有保存的工作都丢失了。但是好在Gmail会自动保存我已经写过的邮件内容，让人稍稍安心。

知乎的文本编辑框也是一个好例子。

c. 其他感觉

例如界面语言是否让用户感觉到尊重等等。
一个小例子，新浪微博的客户端里，用户发完微博后，有时因为系统的原因（发送按钮监听到了两次事件，或者别的什么原因），微博内容可能会在用户不知情的情况下“试图”重复发送，这时会弹出一个提示框，告诉用户说“不要太贪心哦....balbalba” 用户多委屈...

3.5 临界点

临界点就是压倒大象的最后一根稻草。是什么让用户决定注册产品开始使用的？往往就是多动那么一下手指、多学习思考一小下，用户就从门口溜走了。临界点往往是多种因素综合的作用，和用户的主观心理（感觉）和客观因素（绩效）等有关系，姑且作为半个原则来看。

常常惊讶于一些产品（特别是移动产品）能够在用户看到的第一个界面，放一个大大的登陆或者注册框在上面，任何好东西都没给用户看到，就让用户先来注册。以前在一个设计中，给一个公司的同事讲过一个故事：如果有一天你在街上找人问路，那人说“给我5毛我才能告诉你”，尽管你不情愿但还是给了他5毛，他拿了钱告诉你说“经过查询我发现自己不知道”。在实际的设计中，用户付出的并不仅仅是金钱的费用，他们的精力通常是成本，这时用户就会去盘算到底值不值得来进行下一步的操作。

听曾在Google工作的同事讲过这样一个例子：Google的右边栏广告以前点击率总是上不去，后来做了一个改动，这些广告点击率立刻上升了很多。这个改动就是：让这些广告的区域离搜索结果区域的距离更近一点......

Kik这个产品的成功，和他们不动声色的利用用户通讯录来帮用户快速匹配好友有很大的关系。姑且无论这样做是否合乎道德和法律，他们的确帮助用户跨越了临界点。试想如果它需要让用户一个个自己通过昵称、帐号来添加好友，还能有今天的成果么？

一个注册的流程、一个对话框、一次点击... 这些小地方就很有可能会是用户的临界点，设计的价值往往也就在这些地方，小改动往往会有大变化。

通常我们要特别注意优先级高的任务/界面里，是否会存在临界点的问题。如果优先级最高的任务里，用户难以跨越我们的门槛，就很难保证产品的成功。这是一个细腻的工作，有时作为设计师&产品经理，你可能不得不为了一个小细节和开发团队讨论/争取很久，因为别人会觉得这个细节不值得投入工作量，但你知道这可能会决定能否帮助用户跨越他们的临界点。如果你认为值得就坚持吧。

Via： 马力在知乎上的回答。

互联网er的早读课 2015-08-23 08:40:32