有感于与三通的对话

| 5 条评论 2007-12-19 01:20:30

晚上去参加“D2前端技术论坛”,结束出来时遇到了淘宝UED的视觉主管三通,便和他探讨起UED部门角色分工、流程和设计质量管理的问题。没想到在这样的问题上我们居然心有戚戚焉,有些相关的想法不吐不快,遂第一时间记录在这里。

我们开始此番讨论,源于我的一个关于淘宝UED角色分工的问题:在淘宝UED部门中,是采用单兵作战,即每个设计师独立承担项目中的所有角色,再辅以各领域专家(如研究、视觉和代码)的方式,还是按照设计师的专业方向,为其划分明确的职能范围?三通的答案很有意思,他说他觉得应该分一阵合一阵,因为淘宝两种方式都尝试过,总的感觉下来各有利弊。但有一点我们达成了绝对一致的意见,就是应该有一个起到架构和引领作用的小组,由它来制定整个网站的设计规范、标准和哲学,掌控每个产品及网站整体的设计质量,提升部门的设计水平,并提供基础性的工具支持。这个小组虚拟或实体都无所谓,关键在于必须有资源保证上述工作得以进行。在十几分钟的简短对话中,我们不约而同的对规范的价值一再肯定。

规范是我一直都非常非常重视的部分,它不仅仅包括对设计要求的界定,还包括了流程、方法和产出物本身。你可以把规范实现的最高境界看成:随便拉两个设计师出来,他们都可以遵循一直的设计哲学,用相同的流程和方法,产出质量相等的东西。此时人已经不是影响团队设计质量的重要因素了,团队也不会因为某个设计师的突然缺失而受到重大损失。当达到或接近这种程度时,真正重要的,就是规范本身。下午我和同事(iefen)谈话时,说了这样一句话:“人们制定规范,人们遵守规范,人们更新规范。规范进步,人也随之进步”。

这当然是一种非常理想的境界,但我坚信其方向是正确的,现实当中的例证也比比皆是。 比如,我们在学校所学到的知识,其实它们不都是完全正确的,但教育普及的结果就是低成本的提升了全民素质,降低了人与人之间的沟通成本。当科学家们把知识的内容更新后,更广大的人民受益,整个社会也随之进步。

再比如,程序开发中所使用到的各种框架,可以显著提升程序员的工作效率,保证开发质量。完全不用担心框架会限制人们的水平,因为自然有高水平的程序员会做升级框架的工作。

这样的例子举一天也举不完,但有人不同意。就像iefen说的那样:制定规范并确保它的执行,这只是一个过程,或者说做法,我们不能为了制定规范而制定规范,因为高管们并不关心规范本身,他们要的是结果。我的回答是:为什么不可以为了制定规范而制定规范?如果是制定规范这是一个过程而非目标的话,那么提升和保证设计质量也同样是个过程而非目标,因为提升和保证设计质量是为了提高可用性和用户体验,提高可用性和用户体验是为了用户更愿意使用我们的产品……按照如此逻辑推论下去,任何事情都只是过程而非目标。既然我们已经知道了其中的因果关系,不注重因,又何谈果!

所谓知易行难。三通用了一个非常恰当的词,来形容部门内基础和规范的建设,就是“公共福利”。我觉得这个词用得真tm绝了!实际上我一直在做提高“公共福利”的事情,无论是去年的“支付宝设计指南”、“代码助手”、“支付宝UI库”(类似YUI的东西),还是今年的“支付宝UI设计规范”、“支付宝模板和代码片段库”、“卡片分类测试助手”和“变形金刚”(具体用途自己猜)等等一系列的规范和工具,过程辛苦异常(其中的经历我都可以出本书了),结果不够理想,因为这是“公共福利”,因为不是今天打下去桩明天就能盖栋楼的。

说了半天规范的重要性,再花点时间来谈谈方法论的问题。作规范,说白了就三件事儿:制定规范、确保它的有效执行、建立规范更新机制。我想特别说说第二件。

确保规范的有效执行,其实是上述三件事儿中最难办到的。我最初的做法是提供文档,但我很快就发现这行不通,因为不是所有人都像我一样喜欢阅读文档,即使这个文档的内容来源于设计师自己;于是我尝试提供一些工具来辅助设计,比如前文提到的“代码助手”和“支付宝UI库”,这一方法确实有用,但效果远不如预期,根本原因在于这些工具的作用只是辅助设计,而不在设计师工作中的必经之路;于是痛定思痛之下,借鉴团队软件开发模式,我联合两位同事推出了“支付宝模板和代码片段库”(你现在在支付宝网站上看到的页面布局样式,就是其中的一部分产物),直接把符合设计规范的模板和代码片段集成到每个人所使用的Dreamweaver中,并专门设立一台服务器来提供最新的模板和代码片段源,从结果来看,这一方法的效果非常理想,可以说我现在至少能从源头上进行质量控制了。

在我的设想中,应用此方法从源头把握设计质量,后期通过架构小组审核并结合可用性测试来掌控最终设计交付物的质量(当然会有相应的审核流程和标准,时间关系不在这里展开讲了)。可惜由于种种原因,这种“中央集权式”的做法最终没能实现。我觉得除非你的团队能够一直保持高质量的设计,否则设计质量控制就是一个重要又紧急的问题,听说承志最近也在考虑类似的问题,我比较期待他的解决方案。

时间太晚了(现在是凌晨1点15分),先写到这儿吧。

2008年1月3日凌晨更新,推荐继续阅读我后来的几篇文章:

    
  1. seagoo77 2007-12-19 22:35:56

    规范的制定是很重要的,

    就像一些企业标准一样,

    到底该怎么去控制呢?

  2. Felix 2007-12-24 20:30:49

    seagoo77:你是百度的设计师吗?你所谓的“控制”指的是什么呢?

  3. iworm 2007-12-28 09:24:11

    1. 很多时候, 规范也只是一个形式. 有了规范怎么去遵守才是重点.

    就像我们公司通过CMM4级认证, 现在的开发基本没有应用任何CMM4的规范一样.

    2. 还有就是任务的时间紧迫性, 领导不可能给你多少时间去规范

    3. 我遇到的一个实际情况就是, 有些人为了开发的便捷(纯粹是为了自己的便捷), 而无视标准

    这3点我觉得是影响我们公司制定, 使用规范的障碍

  4. CC 2007-12-28 23:57:18

    制度加上灵活性就是艺术。制度本身就是枷锁。所以制度这个东西看你怎么运用而已!再者,个人认为大公司因为太庞大很多东西不能施展。倒过来都是灵活性救活大公司,就好像moto V3的案例。V3的设计完全不是走正规的设计流程的!如果走流程根本不会有V3出现!

  5. jameguilin 2008-01-01 21:06:01

    在我当前团队里,我们首先还是需要规范,所谓规范并不是管人而是去使结果能至少保质的完成,能100%的完成么?估计很难,我们的设计是不断的解决当前发现或预计的用户问题.等到了一定层面我们有会发现问题.那就继续开发升级吧!

    当规范能容入到设计团队的行为和团队开发理念中,它的存在就似水!能灵活应用.不是硬着来!

有什么要说的,尽管来

关于

丁宇(Felix Ding),电脑Geek,狂热的爱书和爱乐分子。现就职于上海的一家设计工作室。

我的Email:

订阅到RSS