撰写和执行设计规范，是一件让人头疼的事情。往往一个项目做到可以抽象出规范的时候，也是这个项目正在全力冲刺的时候，要不要抽出2到5天的宝贵工作时间，来写一堆貌似多余的文字，这是大家一直争论不休的问题，这可以总结成：“什么时候写规范？”。
规范之所以让人觉得多余，更重要的原因是认真阅读并执行规范的人实在是太、太、太少了，大部分的规范要么就成了电脑里永不被打开的文件，要么就成了书架上落满灰尘的纸，这可以总结成**个问题：“如何执行规范？”
不过我们在讨论这两个问题之前，需要先搞清楚，“在理想状态下，规范有什么用处？”
一、满足用户需要
用户在使用产品的时候，总是凭着直觉去使用，不到万不得己，不会求助于所谓的“帮助系统”（如果这个产品有的话）。这一点在互联网产品上更加突出。而保持产品概念、界面元素、视觉风格的一致，能帮助用户：
1、快速了解产品的运作方式。
2、建立**的心理模型。
2、降低培训和支持成本。
3、减少犯错误的概率。
Shneiderman在1998年提出的“交互设计8项黄金法则”中的前几条，就是“力求一致性”，由此可见“一致性”在设计中的重要地位。“一致性”带来的更直接的好处就是：用户“认识”你的产品了。这种认识纯粹是一种主观的认识，用户可能没有认真想过这种“熟悉感”，只是隐隐觉得产品很亲切，很可靠。
设计规范正是对所有元素的运行规则的一种提炼和抽象。因此，一份撰写完善的设计规范，能划出产品的正确轨迹，帮助产品在正常范围内运转。
二、满足协作需要
产品的设计和开发从来都不是由一个团队完成的。通常情况下，一个产品的更终交付环节是开发团队，而在实际工作中，这个环节甚至会具体到某个开发人员。这也就意味着，专注于功能逻辑的同事，很难也没有时间去理解并执行你在产品设计阶段中反复强调的概念、界面、视觉等因素，所以才有“更终产品只实现了当初设计70%”甚至更低的现象发生。
另外，由同一个产品团队长期、持续地维护同一个产品的情况很少出现，一般的产品人员都同时兼顾多个项目，一个产品上线后，立刻转而关注其它产品。产品上线后的命运通常是交给运营团队或执行团队去维护，那些在设计过程中被反复讨论、验证过的设计思路，很难通过无声的界面传递下去，结果就是慢慢地变形。我曾经遇过几个产品设计师，在面试时展示自己的Web产品，一般都要强调一下：“我走了以后又改过版了，当初我的设计是……”。
所以在团队协作方面，需要有一个载体，用来记录设计时的思路和规则，这个职责，也同样落到设计规范身上。
三、提高团队效率
创意是一件很累的事，不管是产品创意还是视觉创意。如果每一个界面、每一个功能，都要创建新的规则，那么从事产品设计这个工作的人恐怕很少能幸存下来。事实上，在创意过程中，我们对所使用过的东西都是茶壶煮饺子──心中有数的，但是这些“数”通常只存在于我们的潜意是凹革。
把这些颇有价值的概念记下来并传达给其它设计人员，能避免大家做重复劳动。同时，发动同僚一起来总结规则，一方面可以节省他们的精力和时间，另一方面他们也能帮助你完善这些规则。
这样的一个协作平台，也是通过设计规非凹复完成的。
当然，以上这三点都是一个理想化的状态，我们姑且称之为“设计规范的理想”。为了实现这个理想，我们需要做的事情还有很多很多。本期UCDChina的话题“设计规范”，正是想跟大家一起探讨这个议题。
同时，从08年4月开始，UCDChina写作话题与书友会讨论话题相同，并向所有同行开放投稿（投稿方式见这里）。
那么，就以我这篇文章作为一个开始，欢迎大家都来发表自己对于“设计规范”的看法，分享曾经有过的经历和经验。希望大家能解答我在一开始提出的两个问题：什么时候写规范？如何执行规范？
设计规范的理想，谢谢围观。
