标准之惑——套用经验，还是创新？

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

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

拥有这样一套设计标准，有以下好处：

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

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

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

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

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

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

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

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

　　例如：

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

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

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

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

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

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

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

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

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

　　经过试用，我发现这些“职场社交”类SNS网站，在实名制方面，采取了3类不同的策略。

　　第一类，就是像人人网一样，强制要求实名。注册流程中，必须填写中文姓名。

　　第二类，采用了相对宽松的策略，要求名字规范，但不强制要求中文的真实姓名。例如：

上图的注册过程中，可以输入英文名，但需要“规范使用”(例如，输入Henry无法通过，而输入Henry Liu或者Henry Lee这类，就可以了)。这样，在一定程度上，即保证了相对的规范，也能够保护用户的隐私。而如果输入一个明显是昵称风格的名字，则会被拒绝。

　　第三类，是采用了完全开放的策略，可以使用任何昵称。例如：

　在这种策略下，基本上认为不论是求职者，还是猎头，都可以畅所欲言，进行最大限度的社交活动。

　　这三种策略可能都有其特有的背景，Henry相信他们的产品经理也都经过了慎重的考虑，但是我个人依然认为，在“职场社交”SNS网站上，没有必要严格遵循传统SNS的实名制标准。而是应该结合这个圈子里面用户特有的特征和需求，适当创新(比如可以允许比较规范的英文姓名)，按需设计。

　　像以往一样，在文章的后半部分，再举一个日常生活中的例子：

　　近些年，有越来越多的外国人来到中国工作、旅行。所以在很多城市中，一些公共资源会提供中、英2种语言的信息表述。比如地铁上的语音报站、比如路牌等。但是笔者注意到，国内的路牌上的非中文部分，并不是统一的。有的城市使用的是英文翻译。比如，把“北三环东路”翻译成“North Third Ring East Road”。有的则使用的是拼音，例如“BEI SAN HUAN DONG LU”。

　　那么，根据“标准”，给外国人看的信息，应该翻译成外国人能理解的形式。从这个角度，貌似“North Third Ring East Road”的译法更好些。因为外国人根本看不懂拼音。但是事实真的是这样吗？

　　其实，我们分析一下用户的具体使用情境就知道该如何做了。城市中的路牌，主要有两种。

　　第一种是这个样子的：

　这种路牌，大部分是立在路边，非中文部分的主要用户是外国行人。这部分用户的典型需求，是问路。我们考虑两种不同的翻译方法，会产生两种不同的情景：

　　1、英文译法

　　外国人:“How can I get to North Third Ring East Road？”

　　中国人:(没听懂)“啊？你说啥？”

　　(…)

　　2、拼音译法

　　外国人：“How can I get to BEI SAN HUAN DONG LU？”

　　中国人：“我不懂英语，但是这家伙貌似要去北三环东路。”

　　(肢体语言…)

　　显然，对于这样的情景，拼音译法更合适。

　　但是还有另外一种，是这个样子的：

这种路牌，大部分是立在机动车道上，非中文部分的主要用户是外国司机。这部分用户的典型需求，是导航。情景如下：

　　1、英文译法

　　外国人：“North 3rd Ring East Road… Oh, I see, I should turn right on next crossing.”

　　(我要去北三环东路，哦，知道了，我应该在下一个路口右转。)

　　2、拼音译法

　　外国人：“Well… I don’t understand Chinese, and… the letters… are not English! What’s the meaning?”

　　(好吧，我不懂中文，并且，那些字母… 根本不是英文！到底什么意思啊？)

　　显然，拼音译法的好处是，看一眼就知道如何发音，所以，更适合问路。英文译法的好处是，看一眼就知道意思，所以更适合导航。

　　总结：

　　1、合理的制定和使用标准，可以大幅度提高效率，也有利于产品的一致性，提升用户体验。

　　2、但标准不是万能的，不能随意套用。具体的设计中，还是需要考虑具体需求和使用情境，然后决定是套用标准(经验)，还是修改标准(创新)。

　　3、ps:PM和UE是不分家的，必须深度合作，深入理解对方的想法，才能够设计出靠谱的产品。