大部分公司，都会或多或少的有设计规范。而大多数设计规范往往是在某个角落里面，多的放了三年五年，少的放了3，5个月。

设计规范本来是一个好东西，但是为什么没有用处呢！

设计规范不仅仅是几页纸的文字

我们看看这些公司的设计规范是怎么出来的：

A公司是个新成立的公司，刚组建起来的设计团队中，大家各自有各自的想法，于是，老板给产品/项目经理/设计经理下了个任务，快点把设计规范制定出来，不能总是这么乱下去；于是乎，A公司的某个经理奋战了一个星期，终于写出了厚厚的设计规范； B公司是个已经运营了有一段时间的公司了，但是一直也没有设计规范，突然有一天，老板心血来潮，或者在**地听说设计规范是个好东西，于是找到相关的经理X。“你是不是该制定个设计规范了”。X也很郁闷，没有设计规范不是好好的吗？难道我们的项目，哪个因为没有设计规范出错了。于是X只花了一天的时间，草草的给了老板一个规范；

这两家公司可以预见的结果就是：A公司的设计规范出来以后，思想还是不统一，甲在这个地方钻点漏洞，乙那天因为“特殊情况”没有按照设计规范设计，丙又说项目紧，没办法完全按照规范来。久而久之，连制定这个规范的经理都不再看这个规范了。

B公司的老板看到这个也没太在意这个设计规范，于是这个规范就直接的睡在那里了，整个团队还是原来一样的做事。等整个team的人渐渐的多起来了，X经理不仅感叹，怎么招进来的人水平越来越差，难道是人心散了，队伍不好带了。

兰思的想法是，这两个方法都不可取，太早的就制定好设计规范，不但限制设计师的思路，而且也是很难被接受，在后面的某个点盲目的建立设计规范，往往是产品的团队的习惯已经形成，甚至这个习惯是没有办法被改变的。

团队的形成和设计规范的形成应该是同时的

兰思在以前的一篇文章中就说过，设计规范是由某一代相互之间有默契的team成员的默契传承下来的，而本文中同样要提到的是，设计规范是在整个团队的运作过程中，一点一点积累起来的，团队的任何一个人都要对这个事情负起责任，尤其是团队的领导人员。

在 项目到达一定的阶段，或者是某个项目完成的时候，一个的团队需要在一起讨论在项目中有什么发生了什么问题需要避免，有什么好的经验和工作方式可以用在其他 的项目中，当这些讨论的结果被应用在其他的项目中，以避免那个重走以前项目的弯路，或者用以前的经验使得后面项目的工作变得简单的时候，即使设计规范没有 被写成条文，由公司的某某部门发文，但是设计规范已经形成了（当然，设计规范还是要记录下来，这样更方便传达和查阅）。

设计规范的建立是个长期的过程了，任何人都不能急，也不能忘。

设计规范应该是帮助工作的，而不是限制思路的

设计师往往是抱怨，按照那些鸟规范，完全没有办法做事情，或者是自己实在没有发挥的空间。

不论是设计师还是工程师，都比较自信或者说是自负，一旦在他的思路上加上一个框，往往是感觉四处受到限制而没有办法尽情发挥，甚至有人说这个设计规范完全是抹杀设计师的创新能力，可以说部分设计师和工程师抵制规范的原因也是在此。

看 起来的确是规范在一定程度上限制的思维，但是设计规范并不是要限制设计师思考的能力的，如果一个设计规范在限制了设计师的思考，那么这个规范并不能说是成 功的规范，设计规范应该告诉设计师，你的“前辈”犯过什么样的错误，这样的错误可以用规范中的办法去避免；或者你的前辈在某些方面取得的很好的成绩，这个 规范就是按照这个定的。在设计规范公布的条目中可能不会写这些内容，但是在详细的说明中，最好把背景一起放在里面，以便于设计师的理解为什么这条设计规范 会存在。

当一个规范不是在限制工作，而是在帮助设计师工作时，那么这个规范想必更容易被设计师所阅读和接受。

对于打破设计规范的 应该奖惩分明

一个设计规范在制定的过程中，由于种种地原因，难免有不符合实情的地方，而且随着时间的推移和外部环境的变化，难免有不再适用的条目。因而，设计规范和奥运会的记录一样，仿佛就是天生要被打破或改写的。

但在另一个方面，设计规范的存在，就象社会上的法规一样，在公司里面，对每个人都有约束的力量，没有充足的理由不容挑战。这两点对于设计规范的应用上，是一个非常矛盾的事。

任何一个设计师，在自己的工作职责和权利范围内，都有不遵从设计规范，甚至是打破它，制定新的设计规范的权利。但是打破设计规范是有风险的，任何这样的行为都应该被仔细的跟踪，并且在最后确定效果，对于在全局（请注意是全局）上起到正面效果的，不但要鼓励，而且要奖励。但是同样的情况，不论是在什么情况下，打破设计规范，造成一定后果的，都应该以相关的管理制度进行惩罚，以保证设计师在没有非常大的把握的情况下，去违反和破坏设计规范。