400-860-8198  乐产功场®国内首家、专业的、课程最系统、知识面最全、附加值最高的产品经理培训 联系我们 优势解读 课程设置 关于我们

设计模式:何时可以打破规则

http://xue8.com 2012-9-29 17:22 来源:学吧
有时打破模式的限制、采用其他不同或更佳的方式,也许实际上更好。简言之,我们既不能全部遵从、也不能全然忽视设计模式。相反,我们需要深入理解人机交互的法则,以便知道何时能够打破法则。
文章来自于【学吧】http://xue8.com/ixd/view.asp?ArticleID=464

  我们乐于相信:对网页应用的普通要素,我们会采用成熟的设计模式。我们知道按钮应该是什么样、该如何运作、如何设计依赖于按钮的提交表单(form)等等。

  然而,破碎的表单、不成样子的按钮、令人迷惑的导航要素等等,在网页应用中比比皆是。与模式唱反调大行其道。

  这令我想到了设计模式的历史和目的、何时应该使用或不用。最有趣的是,我开始琢磨:有时打破模式的限制、采用其他不同或更佳的方式,也许实际上更好。当模式被误用时,我们都能很快识别出来。然而,有没有打破规则却更好的情况呢?欲知完整答案,容我从头道来。

设计模式历史


  
  1977年,建筑师Christopher Alexander与其他人一起著述了《模式语言:城镇、建筑物、营造》(A Pattern Language: Towns, Buildings, Construction)一书,引入了模式语言的概念,即把该语言当作“在专家领域中描述良好设计实践的一种结构式方法”。该书的目标是给普通人(不仅限于建筑师及政府)用于改善其城市、社区的一份蓝图。作者的原话是:


  圣地亚哥的街头咖啡馆(摄影:shanputnam)

  无论是在建筑学、网页设计或其他领域,一个模式总有两个组件:第一,它描述了一个普遍的问题;第二,它为该问题提供了标准的解决方案。例如,在《模式语言》中的第88个模式解决的是身份问题以及如何引入公共场所来鼓励在公众场合打成一片。所建议的解决方案之一是街头咖啡馆:

  对有兴趣进一步探索该模式的人来说,有个Flickr讨论组致力于该模式的案例。

  因为情况类似:我们有很多需要标准解决方案的普遍性交互问题,从建筑学跳到网页应用,是很自然的。其中一个例子是雅虎的“导航标签”模式。需要解决的问题是:

  其解决方案:

  都挺不错,但我们需要进一步探讨,来搞明白在数字产品设计中采用此模式的益处。

设计模式的益处

  模式在设计中特别有用,主要原因有两个:

  模式节省时间:因为我们不用解决已经解决了的问题。如果运用得当,我们可以用每个模式背后的原则来解决其他普遍的设计问题。
  模式使网页更易于使用:因为随着设计师争相采用模式,用户对其用法也习惯了,从而减少了在遇到普通设计元素时的认知负载。以学术术语来说,当模式达到高采用率时,就变成了心智模型,即在用户大脑中关于某系统应如何运作的的一组信念。
  采用已有设计模式而不是自己重新来的最强有力的理由,可能还是来自建筑学。在题为《非独创的价值》一文中,Dmitri Fadeyev引用了Owen Jones(19 世纪建筑师及有影响力的设计理论家)在其著作《装饰物的语法》中的话:

  最后一句是关键。模式不是盲目抄袭他人的借口,而是可能对设计师和用户极为有用的设计蓝图。而为了网络的福祉和用户不致发疯,我们确实需要站在前人设计师的肩膀上。有很多网页设计模式库,效果不一。除了Yahoo Design Pattern Library之外,还有Peter Morville的Design Patterns、Welie.com、还有我个人所喜欢的UI-Patterns.com。

模式何时成祸害

  现在该说另外一面了。模式的阴暗面我们讲得不够。随意从各处拷贝一个模式库、放在公司内维基百科上、然后坐等奇迹发生,有些过于简单了。集成和维护公司内设计模式库是繁重的工作,掉以轻心会带来严重后果。Stephen Turbek在“设计模式是不是一个反模式”一文中总结了模式库的主要问题:

  ·设计模式不是有效的培训工具。
  ·设计模式不能代替用户体验。
  ·完备性与易学性相互冲突。
  ·设计模式需要大笔投资。
  ·设计模式应先用于非用户体验领域。

  本文不打算深入讨论上述问题,故我极力建议读者参阅Turbek的文章。

  就本文而言,假定我们每件事都做对了。我们有一个经过发布、得到了解的模式库,并在公司内得到了广泛采用。我们把模式库作为指南和蓝图,而不是奉为不分青红皂白的金科玉律。我特别感兴趣的问题是:在解决问题时,何时应该突破一个广泛采用的设计模式并指导用户选择新方式?

何时突破模式?

  尽管模式有种种好处,大部分网页设计却似乎对模式不屑一顾。打破模式最明显的例子莫过于网页表单的设计。有了多年的研究,我们知道如何设计实用的表单。从Luke Wroblewski所著的《网页表单设计》、到无数讨论多栏格式和标签位置的文章,我们不用再摸索了。模式已有,并深入人心。然而,基本不可用的表单在网上却是司空见惯。

  作为打破表单模式的一个例子,我们看Expotel的注册表单:

  注意:输入域很小、域标签用了左对齐,而域标签与输入域隔得甚远,“关闭”和“注册”按钮的位置与设计世纪上强调了“关闭”。还有,“欢迎词”是什么?在哪儿用呢?我们都会同意,这不是良好的表单设计,不是突破模式的好方式。

  然而,对破坏了的模式下判决并非总是像上述例子那么简单。谷歌最近决定在其Chrome浏览器中移除打开新标签页按钮上面的加号,就受到了些批评。这打破了在大多数支持标签页的浏览器已经使用了的模式,然而谷歌声称他们在更改之前做过用户调查。这是正确的决定吗?

  还有一些用户界面技巧我们也许还不知道如何评判。iOS应用程序例如Clear和Path引入了前所未有的新式交互,用户反馈则褒贬不一。是设计的进步、还是失败的实验?

  和大多数设计决策一样,答案很少是黑白分明的。模式与新解决方案的矛盾不可能由一个公式来判定。用户熟悉既定的操作方式,然而问题的新解也许更好、甚至更自然、更符合逻辑。那么,何时应该弃旧从新?有两个场景我们应考虑突破设计模式。

新方式从实践上改善了可用性

  在现有设计上从事迭代的危险之一,是所谓“局部最大值”。Joshua Porter有如下解释:

  对设计模式而言,也许有这种情形发生:我们不断改善某个现有解决方案而无视更好的解决方案。A/B测试的陷阱之一是:它能有效地找到局部最大值,但无法找到标新立异的方案。

  从渐进创新我们获益良多,但有时一个模式已经成熟,到了非大刀阔斧革新不可的程度。我们需要睁大眼睛考察每个设计问题,力图找到新的解决方案,并且准备测试这些方案以确保我们不致被错误的直觉所左右。正如Paul Scrivens在《设计构思》中所指出的:

  这是谷歌Chrome团队声称在浏览器内移除加号按钮的理由。该团队相信他们找到了更好的方案、并已做过测试。

既定方式已过时

  在大多数应用里有个用来“保存”的图标。你上一次见到软盘驱动器是什么时候?就是啊。时过境迁,我们不得不顺其自然。否则,我们会陷入沼泽,如Twyla Tharp所证明的那样(Yesenia Perez-Cruz引用):

  出版行业对此最有体会。Stewart Curry在《比喻必须死》(The Trope Must Die)中说:

  这就是Clear和Path等软件开发人员的天地,他们正在从事大胆、正确的创新。他们认识到,我们正处于以手势为界面的快速创新阶段初期,他们愿意引领潮流。某些想法将失败、某些将胜出,但重要的是,设计模式对我们已置身其间的新触摸屏世界要做出回应。

  我们的设计模式不仅需要根据交互比喻变化而调整,还要根据一般重大技术用法来调整。Tammy Erickson在其称作“再世代”(后Y世代)方面做了些研究,在《移动技术如何打造新一代》中讨论了她的部分发现:

  当一切都永远联机、可获取时,对服务和手机软件的期望会改变。对较慢的转变、看来太复杂的流程,我们会觉得难以忍受。在一个时间与注意力都变得空前匮乏的环境下,我们已在被迫重新考虑注册表单和支付流程。我们不用重新发明轮子,但我们确实需要找到不断前进的更佳方式。

知情决策才是正确决策

  设计模式带来了诸多好处,但也带来了需要我们警惕的害处。然而,对这些有帮助的指南置之不理是不明智的。没有公式告诉我们如何行事,相反,我们需要在一定的范围内操作,以确保能够建立伟大的设计方案而不至于疏远用户。下面是我们需要做的:

  学习与我们正在开发应用相关的设计模式。我们需要牢记这些模式,知道其存在的理由,以便能在工作中将其用作粗犷的蓝图。
  以足够开放的心态面对每个新项目,以便发现老问题的更佳解决方式。
  跟上本行业(以及相邻行业)的发展步伐,以便能够认识外来的变化,而这些变化需要我们重新审视目前运行良好、但也许很快就要过时了的解决方案。

  简言之,我们既不能全部遵从、也不能全然忽视设计模式。相反,我们需要深入理解人机交互的法则,以便知道何时能够打破法则。

新浪微博