产品规范之道
对规范更深层次认识来自于YUI的启发，这个几乎已经是控件代名词的英文缩写，可能很少有人注意全称The Yahoo! User Interface Library，其实就是整套带有开发模式的界面规范，因此我也喜欢把整理好的各种规范叫做XXX Design Library。
产品规范的应用对象，分为设计师、工程师两类人。对设计师来说主要是“协调”工作，使交付物统一；对工程师来说主要是“配合”工作，使开发效率提高。
1. 规范的时机
我倾向于在概念设计的低保原型之后，也就是说得先有第一批可开发的页面。我反复强调的原因，概念上不管做产品还是平台，核心都是由一个个页面组成的网站，有效规范只针对于最终产出。
很多朋友提到边设计边整理规范，这是对设计工作的总结。我的看法，产品设计与开发是整套系统工程，所以更进一步，应该边开发边整理规范，让规范与开发同步，互相契合更新。也就是说，每次迭代之后，都应该升级规范。
对工程师而言，上手来一份事无巨细的规范，读完要花两天，熟练要花十天，在庖丁解牛的开发过程中，简直就是噩梦。于是还没等走完这个过程，早因想痛打设计师而消极怠工了。这也正是不建议使用现成规范的原因，第一国情不同，第二时机不对。
2. 规范的程度
经常听到种声音“规范对开发工程师的约束力太弱。”我认为并非问题根源，因为规范的目标不是约束。产品规范对工程师的唯一好处就是快，越快越简便完成任务，工程师才越可能认可。打算让工程师把工作重心偏移到界面体验来完全不现实，因为各自的工作职责不同。
注意使用工程师的思维来横向描述产品，尤其在模块和组件角度，更有必要最终细化到代码和字段。工程师不愿意遵守，做规范的人首先应该扪心自问，是否阻碍了别人的工作？作产品设计规范不能只考虑如何设计好，关键是如何配合执行好，更不是完全主动的监督。
规范最大的作用，在于方便分享，减轻沟通压力。规范越翔实，越容易体现专业的大家风范，也就越凸显设计价值，对拿了钱就走人的设计师来说很受用。但高瞻远瞩只看上去很美，不具有可控的操作性，强制执行的后患无穷。
3. 规范的内容
概念文档，固化产品架构和业务大流程。便于设计师快速了解全局结构和流程，同时有助于工程师搭建程序结构，以及数据库逻辑。但是得注意，满脑子函数的工程师们，普遍对信息架构、交互设计不敏感。
页面设计，固化界面布局和表现。用于设计师协作完成原型设计，同时起到指导工程师修改页面的作用，尤其是页面结构、样式定义、信息块标注。忙于功能的工程师们，对界面的仔细程度往往也不如设计师。
模块控件，固化功能落实和操作小交互。既便于设计师新增、修改界面，也便于工程师嵌程序和调整。最好是做成各种精确的Module或者Pattern，做到有据可依有档可查。尤其是对状态描述，能省不少解释的口舌，也便于小范围升级和做版本管理，做到工作流程中的Don’t make engineer think。
4. 规范的执行
规范的监督成本，全部建立在规范本身的有效性之上，也就是说，对产品和团队有足够可控的了解，是提高执行效率的基础，并非设计单方面合理就行。
在项目时间受限制的情况下，工程师解决问题一定有优先级，功能高于界面不仅合理，而且完全应该这么做。我观察到的矛盾，绝大多数都因为产品方提要求的时机不合理所致。
如果没有时间压力，也没有任务压力，工程师仍然不遵守设计规范，那是工作态度问题，应该尝试与工程师团队沟通解决，或者把协调级别再调高。多注意沟通，互相调整工作方式，任何小矛盾和不契合都可能因时间而被放大。多尝试改变自己，这也是种挑战，除非有权利选择同事。
模块化开发中，工程师最怕因为乱引起的麻烦，而不是技术难度，因为难度可以妥协解决。作为设计师，多学习技术并亲自实践，除了能精确把控节奏，所获得的经验也将成倍增长。
6月 8th, 2008 at 22:06
好文，收藏至20ju.com
6月 9th, 2008 at 7:44
个人觉得还不如分享自己写规范的过程
而不是都在这里讨论出现情况，是否还有，如何存在等；
事务的发展是必然有规范的，而是规范的完整，正确，可验证性，可执行性等。
你们的文章我都没看完！
6月 9th, 2008 at 11:09
YUI 以前关注过一段时间，还下了一套library，后来放那没搭理了！有时间好好请教一下千鸟！
至于其它的，同意2楼的！用一个小例子讲会比较好！
6月 9th, 2008 at 16:18
@小鱼 给你看规范你觉得你能举一反三吗？
6月 9th, 2008 at 19:28
没看完你怎么就下结论了？
过程很简单，写了改，改了写，完了。
6月 9th, 2008 at 23:40
要把规范谈到位势必要与整个产品设计流程配合起来谈，在哪一步规范什么，规范到什么程度，文中作者思路很清晰，不过我想入行不久的朋友也许无法立即感同身受。
说到，模块化是很好的规范方式，我们在项目过程中使用基于内容构建xhtml+css的交互原型，视觉设计可以与这个步骤并行，（其中省略若干文字阐述具体操作办法- -！）那会起到非常好的效果，这比长篇大论的写文档来得更实际，并有一劳永逸的好处，不但可以使结构清晰，界面具备一致性，还能反过来验证设计合理性。
6月 11th, 2008 at 15:29
@白鸭 给我看看，我试试举一反三，哈……
6月 12th, 2008 at 1:10
看的出来，是千鸟的实际经验之谈，规范的执行和工程师的沟通是门学问。要你的搭档完成他不太关注的工作，并让他爽快的做好是需要抓住恰好的切入时机。
6月 16th, 2008 at 16:21
是骡子是马拉出来溜溜，嘴说的不一定是真的，得拉出来练练。
我招聘美工的时候，从来不看任何东西，他们选择我5个项目中任何一个按照要求和规范在规定时间内交卷，看看做的情况，基本就知道这个人的价值了。
6月 16th, 2008 at 16:23
的确看看才知是公是母，现在的女人，男人，人妖，太监，太难区分了。
一个个都很能说，很能写，但是做事情就不是那么回事了。
6月 16th, 2008 at 16:38
因为你招的是美工，我们招的是设计师。
说话难听不要紧，但冒名顶替实在不应该。
6月 16th, 2008 at 17:59
to 9楼： 一个设计师最好的能力是在没有规范的时候体现出来的
如果是在设计有了框架，很多能力就体现不出来了
还有 冒名顶替说明你太不自信了 一个不自信的人 肯定是个没多大价值的人。
6月 17th, 2008 at 20:52
一直有人对我们删除一下垃圾评论有意见。 这次我不删了。
但要说一下：
9楼、10楼、是同一个IP，邮件地址留的都是正经八百的百度和雅虎的邮件地址。 可以断定是冒充，出来放屁臭人的。
6月 18th, 2008 at 9:25
细读以上关于规范确立执行的四点总结，觉得对实际开发很有参考意义，
但是作为新人大概更想看到具体可以操作的东西，比如规范格式，其首尾主体详致内容，如果有人来写一些这方面的经验也是能受启发，
规范贯穿整个开发进程，也算是核心吧，需要用心体会才可见的，
不仅仅是规范本身确立需要设计师作逻辑分析管理维护，
且于执行过程也需要和工程师沟通能力。
至于9，10楼的说法无力
除了凸显其浅薄，实在没啥好说的
6月 18th, 2008 at 10:48
恩,文章说的真好,学到了规范的真正价值及技术是以何种方式来使用规范,确实,增加自己的沟通能力及学习技术方面的知识,会增强自己的设计及规范的构建能力…^^
6月 18th, 2008 at 20:27
“具体可以操作”的只有方法，因为形式不重要。了解做事原则之后，看任何设计规范文档都不困难，网络上有大把优秀的资源。是否可以执行是另一回事，关键得理解形式背后的设计意图。
微软的规范不一定适应雅虎，就这个简单的道理。
6月 19th, 2008 at 10:28
此文深有同感。支持千鸟的分享。
现在一些人。能深入的学习一个东西，准确的认识、并认真去实践的人太少了，更不谈去思考和总结经验。不动脑子就瞎忽悠、瞎骂的人太多了。
也告诫一些朋友，别人给你分享智慧已经是很福气的事情了，人无完人，文无尽致。
设计师真不是一种技术行业。
设计之外的很多事情往往在影响专业能力的执行效果。继续学习吧
6月 22nd, 2008 at 15:15
学习了，作者的实际操作经验很丰富，看来应该有较深的技术背景。
1. 设计师只为设计着想，确实是普遍现象。好多设计师认为设计好了，自己任务就完了，根本不去考虑后边的流程怎么接，脑子就没有Teamwork的概念。此一方面与经验有关系，另一方面与背景有关系。
2. Don’t make engineer think 提的也很有创意，对于工程师来说真就如此。如果这个“规范”别人一看就不行，被束缚了，说明“规范”不合格。经验丰富的操作者才能出有效规范，有效规范才能促进效率的提高。
希望UCDChina多写这样具有实操经验的文章，多出好作品，振兴祖国互联网设计产业。
11月 19th, 2008 at 12:04
[…] 与此同时，产品设计团队除了对低保真原型的继续支持，还应并行完善和提炼高保真原型，并且着手对产品规范中复用模块的持续化整理，主要分为三部分： […]
4月 18th, 2010 at 16:11
[…] 第十四章 设计规范 产品规范之道 http://ucdchina.com/blog/?p=478 […]
6月 18th, 2010 at 14:25
[…] 产 品规范之道133页 […]
11月 2nd, 2010 at 11:16
[…] 千鸟说的“网站设计规范其实就是产品设计规范”还是比较启发的，跳出某环节从更整体的高度来思考，产品设计的规范还会包括前端规范、数据结构规则等，他的blog产品规范之道从规范的产生、制定、执行都有阐述，且照此应用了两年的时间，很成功的经验，学习！ […]
10月 27th, 2011 at 11:09
[…] 第十四章 设计规范 产品规范之道 http://ucdchina.com/blog/?p=478 […]