设计原则VS实际情况

这是一个网络相册。是不是该有“上传照片”这个按钮？我当时的意见是：不要有。理由是：只有在某个相册中才可以上传照片，在“根目录”（XXX的照片集）下，并不能上传照片，既然不能上传，所以不要有这个“上传照片”按钮，即使提供这个按钮，点了之后同样是要引导用户去选择相册或新建相册。

现在看来这个结论显然是不对的。问题出在哪儿？当时也确实有其他的同事反对，但并没有给出足以说服我的理由（也许是我太固执）。记得当时反对的意见大概是：“你这个想法可能从专业、学术的角度上是对的，但是实际情况…”如果仅仅是根据所谓的实际情况来判定一个设计，显然是靠不住的。因为那时说的实际情况也只是那位同事那个时候对实际使用情况的猜测。

上面描述的这个错误到底是怎么产生的？作为交互设计师怎样才能避免运用所谓专业的观点做出错误的设计？

我们需要先从设计的含义说起。

“所谓设计，指的是把一种计划、规划、设想、问题解决的方法，通过视觉的方式传达出来的活动过程。”—王受之

设计是计划、规划的过程，比如我们设计一个洗衣机，要考虑把所有的操作按钮放在统一的一个区域内，在这个区域内再将操作性质相似的按钮放在一起，并且画个圈把它们圈起来。“相似信息有相似的表现。”基于电脑的软件产品的设计，也有这样的设计思路。

但是，如果要无条件的恪守这个原则，那么，下面这样一个tabs就有缺陷了：

这是一个邮箱。第一个tab是所谓的主页，第二个是收件箱列表，后面两个是分别打开的两封邮件（当然，还可以打开更多这样的tabs）。如果要保证内容的逻辑性，不同类型的tabs是不是就要区别表现了呢？分别打开的单封邮件们类型是一样的，应有一样的变现；收件箱算是个单独的类型，单独表现；主页也是特殊的，也需要单独表现；其实还会出现撰写新邮件的tab，又多了一种。这么做的结果就是tabs变成了调色板，肯定不成。要严格遵循内容逻辑的要求，不仅不会使这些tabs更容易理解，反而是混淆视听。

撤一个更远一点儿的例子。“一个由主人生成的列表需要有添加、修改、删除功能。”这也是个有价值的设计原则。那么，下图中的这个订阅列表，是不是有缺陷呢？

每个订阅的条目后面都应该跟一个删除按钮才对啊。然而在实际的使用中，添加一个新项是比较经常的操作，而删除现有的项并不常用。把删除按钮藏起来，不仅页面重点内容（订阅的标题）更突出了，同时可以避免误删除操作。考虑实际的使用情况，把删除按钮藏起来是更合理的。

那么，设计的过程中怎样考虑实际情况？实际情况到底是哪些？考虑实际情况是不是意味着设计工作是无据可依的？

设计的目的是为了弄一个易用、好用、用户喜爱的产品出来。前面说的这些原则是一些手段、工具，为的也是实现这样的设计目的。是否遵循设计原则并不是衡量设计质量的标准。那么，什么才是衡量标准？帮助用户高效的完成任务才是标准。这里说的“任务”是指通过人物角色设计、情景描述总结出的用户任务。用户任务就是实际情况。这些任务是可知的。

再次看“上传照片”按钮这个问题。设计人物角色，一定会有一位这个网络相册的注册用户，他需要的时候会来使用相册。情景描述中也一定会有这么一天，他旅游归来，想把旅游拍的照片上传到网络相册里。分解出的任务中就必然有这样一条：登录网络相册，上传照片。象前面说的，他会是在需要的时候来使用，并不是天天来。所以他对界面并不那么熟悉。那么，如果登录进来的首页（“照片集”页面）上找不到能“上传照片”的字眼儿，也许他就要犯难了。他的任务，上传照片，完成起来就比较困难了。

当然，你可能会质疑上面的种种假设，“如果他是天天来用相册呢？”“不把上传照片按钮放出来也许他也能找到呢？”……这些问题都是其实关于如何设计人物角色的，不是这里讨论的重点，就不多说了。（当然，也许是我多虑了，专业、聪明的您，也许根本不会有这样的质疑。）

“上传照片”按钮的去留问题可以很清楚的决定了。做出这个判断不是靠现有的设计原则；不是靠某人的经验；不是靠大老板的决策；不是靠与会人员的举手投票；不是靠扔鞋…

设计的衡量标准是看是否有助于完成用户任务，而不是对设计原则的遵守情况。设计原则是一些源于实际经验的总结，为的是给实际的设计提供指导。即使没有所谓的设计原则，运用人物角色这样比较科学的方法也可以设计出很好的产品来，只是可能要多费些力气。