标准之惑——套用经验,还是创新?

2019-04-03    来源:Henry的交互花园

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

科技的发展使得人类的生产效率大幅度的提高,为了适应大规模的快速生产,「标准」诞生了。

在传统行业,标准所创造的奇迹可谓举不胜举。标准化的麦当劳可以保证全世界任何一家餐厅在几分钟内生产出几乎一模一样的汉堡;标准化的PC架构,使得全世界的PC厂商生产的硬件可以相互兼容;标准化的网络制式使得从美国带回来的水货手机可以在国内使用;就连我们每天坐地铁刷卡,也是因为有相应标准的支持。

在基于Web的设计过程中,我们经常会将一些常用的组件标准化,制作一套设计标准(交互标准、控件标准、视觉标准等等)。这样可以大幅度的降低重复设计和重复开发,最大程度保证工作效率。例如下面这一套,是某网站的基本设计规范示意图。它将网站中的一些组件的样式、基本交互标准化。

拥有这样一套设计标准,有以下好处:

1、对于UI设计师和交互设计师来说,已有的控件样式和交互可以复用。当设计新功能时,可以从已有的标准中选取符合产品策略要求的设计,直接组合使用。

2、对于前端开发工程师来说,可以将标准化的设计制作成可复用的控件。需要时调用,赋予一定的参数就可以适应不同位置的相似应用场景。

3、使用相同的控件为用户提供相似的功能,有利于产品整体的一致性,降低用户的学习成本,提升用户体验。

除此之外,还有一些更加广义的“标准”,例如,Google的首页特别简洁,主要的内容,只有一个logo,一排链接,一个搜索框和2个按钮。由于Google的成功,这样的设计成为了搜索产品的一个“标准”。很多搜索引擎的首页,都是类似的元素和排列方式,微软的bing算是比较创新的了,但也仅仅是加入了一幅背景图片,基本的元素并没有太大的变化。

遵循行业中这种“惯例”性的标准,有这些好处:

1、对于用过类似产品的用户,可以快速上手,降低用户的学习成本,提升用户体验。

2、如果开发周期紧,人手不足,“借鉴”行业惯例可以为团队省去一些前期的调研、分析等成本。因为被别人证明有效的“经验”,总比自己尚未清楚的验证的“创新”感觉更靠谱一些(当然,有人将这种称为“抄袭”,有人则叫“微创新”)。

但是「标准」不可能是完全通用的,如果一味的套用标准,就可能会对产品最终的体验造成损害。

例如:

在百度商业产品的某系统中,PM提出了一个新的需求,需要一个逐层定位的功能,让用户可以定位到某特定的关键词。百度的推广账户采用的是这样的层级结构:账户 >推广计划 > 推广单元 > 关键词。也即:一个账户中,可以有多个“推广计划”;某推广计划中,可以有多个“推广单元”;某推广单元中,可以有多个“关键词”。但是之前在该系统中从未有过定位到关键词级别的需求,以至于,设计标准中对于类似需求的解决方式,是使用多个下拉框,也即类似这样的控件:

这个控件的操作流程是:默认情况下 “选择单元”框置灰。用户先选择一个计划,选定后,“选择单元”框中会列出该计划下的所有单元名称,用户再选择,即可完成定位。

但是“关键词”层级的情况会有一些不一样。一般情况下,一个账户中,可能只有几个到几十个计划,每个计划下,可能最多也只有几十个单元。但是某个单元下面,则可能存在着几百上千个关键词。所以在关键词层级,如果使用下拉选择框,遇到关键词数量巨大的时候,用户绝对会疯掉。

显然,在这种情况下是不应该直接套用标准的。于是经过讨论,在原有设计标准的前提下做了一些改进,得到了新的控件如下:

在关键词层级,将下拉框换成输入框,并配合模糊查询,就可以比较容易的实现定位了。

类似的,标准之惑,还有很多,并且并不仅仅局限在界面层面。有一些时候,也会影响到产品策略层面。下面举一个产品策略方面的例子:

人人网是国内比较著名的SNS网站,他们一直坚持一个原则,就是“真实的社交关系”。这个原则,需要一些其他的条件来支撑,比如实名制。人人网倾向于认为,只有基于实名制的真实社交关系,才能够产生比较大的用户黏性。这个原则,在国内基本上被证明是成功的,所以其他的SNS网站,也在或多或少的参考这个原则,或强或弱的推行实名制。

但是Henry认为,实名制并非适用于所有的SNS网站。例如,有一种SNS,定位是所谓的“职场社交”。如天际网、优士网等。这类网站,其中一个重要的功能,是寻找猎头,跳槽。

我想,对于一个想换工作的人来说,他们可能不会大大方方的对所有人宣称说:“我要换工作啦,这是我的简历,大家都来看看吧。”所以,对于这类用户,他们在SNS网站上的活动,需要有一定的私密性。在这种条件下,强制的实名制就不适用了。

标签: Web设计 交互设计 视觉设计 

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:如何挖掘用户付费潜力

下一篇:Google Web App开发指南第二章:交互设计