Felix DingAn old-school Web designer who loves alternative rock, classical guitar, reading and writing.
有感于与三通的对话
晚上去参加“D2前端技术论坛”，结束出来时遇到了淘宝UED的视觉主管三通，便和他探讨起UED部门角色分工、流程和设计质量管理的问题。没想到在这样的问题上我们居然心有戚戚焉，有些相关的想法不吐不快，遂第一时间记录在这里。
我们开始此番讨论，源于我的一个关于淘宝UED角色分工的问题：在淘宝UED部门中，是采用单兵作战，即每个设计师独立承担项目中的所有角色，再辅以各领域专家（如研究、视觉和代码）的方式，还是按照设计师的专业方向，为其划分明确的职能范围？三通的答案很有意思，他说他觉得应该分一阵合一阵，因为淘宝两种方式都尝试过，总的感觉下来各有利弊。但有一点我们达成了绝对一致的意见，就是应该有一个起到架构和引领作用的小组，由它来制定整个网站的设计规范、标准和哲学，掌控每个产品及网站整体的设计质量，提升部门的设计水平，并提供基础性的工具支持。这个小组虚拟或实体都无所谓，关键在于必须有资源保证上述工作得以进行。在十几分钟的简短对话中，我们不约而同的对规范的价值一再肯定。
规范是我一直都非常非常重视的部分，它不仅仅包括对设计要求的界定，还包括了流程、方法和产出物本身。你可以把规范实现的最高境界看成：随便拉两个设计师出来，他们都可以遵循一直的设计哲学，用相同的流程和方法，产出质量相等的东西。此时人已经不是影响团队设计质量的重要因素了，团队也不会因为某个设计师的突然缺失而受到重大损失。当达到或接近这种程度时，真正重要的，就是规范本身。下午我和同事（iefen）谈话时，说了这样一句话：“人们制定规范，人们遵守规范，人们更新规范。规范进步，人也随之进步”。
这当然是一种非常理想的境界，但我坚信其方向是正确的，现实当中的例证也比比皆是。 比如，我们在学校所学到的知识，其实它们不都是完全正确的，但教育普及的结果就是低成本的提升了全民素质，降低了人与人之间的沟通成本。当科学家们把知识的内容更新后，更广大的人民受益，整个社会也随之进步。
再比如，程序开发中所使用到的各种框架，可以显著提升程序员的工作效率，保证开发质量。完全不用担心框架会限制人们的水平，因为自然有高水平的程序员会做升级框架的工作。
这样的例子举一天也举不完，但有人不同意。就像iefen说的那样：制定规范并确保它的执行，这只是一个过程，或者说做法，我们不能为了制定规范而制定规范，因为高管们并不关心规范本身，他们要的是结果。我的回答是：为什么不可以为了制定规范而制定规范？如果是制定规范这是一个过程而非目标的话，那么提升和保证设计质量也同样是个过程而非目标，因为提升和保证设计质量是为了提高可用性和用户体验，提高可用性和用户体验是为了用户更愿意使用我们的产品……按照如此逻辑推论下去，任何事情都只是过程而非目标。既然我们已经知道了其中的因果关系，不注重因，又何谈果！
所谓知易行难。三通用了一个非常恰当的词，来形容部门内基础和规范的建设，就是“公共福利”。我觉得这个词用得真tm绝了！实际上我一直在做提高“公共福利”的事情，无论是去年的“支付宝设计指南”、“代码助手”、“支付宝UI库”（类似YUI的东西），还是今年的“支付宝UI设计规范”、“支付宝模板和代码片段库”、“卡片分类测试助手”和“变形金刚”（具体用途自己猜）等等一系列的规范和工具，过程辛苦异常（其中的经历我都可以出本书了），结果不够理想，因为这是“公共福利”，因为不是今天打下去桩明天就能盖栋楼的。
说了半天规范的重要性，再花点时间来谈谈方法论的问题。作规范，说白了就三件事儿：制定规范、确保它的有效执行、建立规范更新机制。我想特别说说第二件。
确保规范的有效执行，其实是上述三件事儿中最难办到的。我最初的做法是提供文档，但我很快就发现这行不通，因为不是所有人都像我一样喜欢阅读文档，即使这个文档的内容来源于设计师自己；于是我尝试提供一些工具来辅助设计，比如前文提到的“代码助手”和“支付宝UI库”，这一方法确实有用，但效果远不如预期，根本原因在于这些工具的作用只是辅助设计，而不在设计师工作中的必经之路；于是痛定思痛之下，借鉴团队软件开发模式，我联合两位同事推出了“支付宝模板和代码片段库”（你现在在支付宝网站上看到的页面布局样式，就是其中的一部分产物），直接把符合设计规范的模板和代码片段集成到每个人所使用的Dreamweaver中，并专门设立一台服务器来提供最新的模板和代码片段源，从结果来看，这一方法的效果非常理想，可以说我现在至少能从源头上进行质量控制了。
在我的设想中，应用此方法从源头把握设计质量，后期通过架构小组审核并结合可用性测试来掌控最终设计交付物的质量（当然会有相应的审核流程和标准，时间关系不在这里展开讲了）。可惜由于种种原因，这种“中央集权式”的做法最终没能实现。我觉得除非你的团队能够一直保持高质量的设计，否则设计质量控制就是一个重要又紧急的问题，听说承志最近也在考虑类似的问题，我比较期待他的解决方案。
时间太晚了（现在是凌晨1点15分），先写到这儿吧。
2008年1月3日凌晨更新，推荐继续阅读我后来的几篇文章：
规范的制定是很重要的，
就像一些企业标准一样，
到底该怎么去控制呢？
seagoo77：你是百度的设计师吗？你所谓的“控制”指的是什么呢？
1. 很多时候, 规范也只是一个形式. 有了规范怎么去遵守才是重点.
就像我们公司通过CMM4级认证, 现在的开发基本没有应用任何CMM4的规范一样.
2. 还有就是任务的时间紧迫性, 领导不可能给你多少时间去规范
3. 我遇到的一个实际情况就是, 有些人为了开发的便捷(纯粹是为了自己的便捷), 而无视标准
这3点我觉得是影响我们公司制定, 使用规范的障碍
制度加上灵活性就是艺术。制度本身就是枷锁。所以制度这个东西看你怎么运用而已！再者，个人认为大公司因为太庞大很多东西不能施展。倒过来都是灵活性救活大公司，就好像moto V3的案例。V3的设计完全不是走正规的设计流程的！如果走流程根本不会有V3出现！
在我当前团队里,我们首先还是需要规范,所谓规范并不是管人而是去使结果能至少保质的完成,能100%的完成么?估计很难,我们的设计是不断的解决当前发现或预计的用户问题.等到了一定层面我们有会发现问题.那就继续开发升级吧!
当规范能容入到设计团队的行为和团队开发理念中,它的存在就似水!能灵活应用.不是硬着来!
哈哈，博主挺有趣的，看评论区各个输入框的标签就知道了
规范不是去管人，而是去管结果，这个论点很好
呵呵，针对人的产出进行管理，设定标准，然后人努力提升自己完成标准
而不是用各种条条框框限制住人
很有些道家无为而治的思想
@edison: “针对人的产出进行管理，设定标准，然后人努力提升自己完成标准”，就是这样，规范好了，整个团队不会因为一两个人的离去而降低甚至丧失战斗力。最近在看天涯上的《做单》，小说中的“我”所解释的外企集团军似的作战方法，正是我所说的规范的一个非常形象的解释。
丁兄，看你这篇文章很久了，现在我们公司已经开始遇到这种问题了，特别是前段架构，因为没有很系统的“规范”思想，所以很多css代码重复很多，少个像你这样的前段架构规划师，来进行统一的UI框架设计，我认为你的工作经验，特别是对于“规范”的心得和思路，非常有价值来指导我们。
@索林那瑞 这已经是3年多前的文章了。现在再看这篇文章，一方面觉得自己当时真是斗志昂扬，另一方面又觉得所谈到的内容多少有些理想化（虽然这没什么不对）。去年参加upa的时候，去听了腾讯在规范设计方面的分享，觉得大家的思路大体上是比较接近的，这也从一个侧面印证了我当初的设想和实践。
另外，规范这个东西不仅仅是前端上的。考虑到前端复杂性的急剧增长，前端编码规范这个东西，应该直接按照传统的编码规范和框架的套路来做；而设计规范则应在传统方法的基础上，结合一些设计领域专有的特点。但代码是个命脉，只有控制了代码，才能真正控制和实施设计规范。
如果可以的话，我特别想听听你们在这方面的问题和实践。
我们现在是前端html、css规范很不好，由于是2个人负责前端代码，一个人不知道另一个人怎么写的代码，所以同样的区块，又自己写了很多重复性代码，虽然人少，这个是小问题，但如果以后团队扩充人员，那么这个问题也不能忽视，毕竟一个css文件体积增减个20kb...意义是不同的。
你文章中提到的“支付宝设计指南”、“代码助手”、“支付宝UI库”（类似YUI的东西），“支付宝UI设计规范”、“支付宝模板和代码片段库”、“卡片分类测试助手”和“变形金刚”（具体用途自己猜）等等一系列的规范和工具，对我们来说，正是缺少的，很有意义。
至于php的功能代码，我们的框架很强大(小小的自夸一下)，也很规范，这方面没什么问题。
丁兄，麻烦你个事，按自己当个模型，帮我写一写前端架构师的这个岗位描述和要求。我很想找你这样全面、很强力的UE/UI/UX...反正是U系列的架构师
@索林那瑞 这两天抽空单独写一篇blog来探讨这个事儿，前几天忙着项目立项，太忙了。
你关注我blog吧，我尽快写好发出来。
丁宇 瞥你博客好久了 今天忽然看到三通这个熟悉的大名……
哈哈哈！世界好小！