在項目到達一定的階段，或者是某個項目完成的時候，一個的團隊需要在一起討論在項目中有什么發生了什么標題標題題目需要避免，有什么好的經驗和工作方式可以用在其他的項目中，當這些討論的結果被應用在其他的項目中，以避免那個重走以前項目的彎路，或者用以前的經驗使得后面項目的工作變得簡樸的時候，即使設計規范沒有被寫成條文，由公司的某某部分發文，但是設計規范已經形成了（當然，設計規范仍是要記實下來，這樣更利便傳達和查閱）。

  蘭思在以前的一篇文章中就說過，設計規范是由某一代相互之間有默契的team成員的默契傳承下來的，而本文中同樣要提到的是，設計規范是在整個團隊的運作過程中，一點一點積累起來的，團隊的任何一個人都要對這個事情負起責任，尤其是團隊的領導職員。

  A公司是個新成立的公司，剛組建起來的設計團隊中，大家各自有各自的想法主意主意主意，于是，老板給產品/項目經理/設計經理下了個任務，快點把設計規范制定出來，不能老是這么亂下去；于是乎，A公司的某個經理奮戰了一個禮拜，終于寫出了厚厚的設計規范； B公司是個已經運營了有一段時間的公司了，但是一直也沒有設計規范，突然有一天，老板心血來潮，或者在**地聽說設計規范是個好東西，于是找到相關的經理X。

 于是X只花了一天的時間，草草的給了老板一個規范；
 X也很郁悶，沒有設計規范不是好好的嗎？難道我們的項目，哪個由于沒有設計規范犯錯了。 “你是不是該制定個設計規范了”。等整個team的人漸漸的多起來了，X經理不僅感嘆，怎么招進來的人水平越來越差，難道是人心散了，步隊不好帶了。

  這兩家公司可以預見的結果就是：A公司的設計規范出來以后，思惟仍是不同一，甲在這個地方鉆點漏洞，乙那天由于“特殊情況”沒有按照設計規范設計，丙又說項目緊，沒辦法完全按照規范來。

  B公司的老板看到這個也沒太在意這個設計規范，于是這個規范就直接的睡在那里了，整個團隊仍是原來一樣的做事。久而久之，連制定這個規范的經理都不再看這個規范了。

　一個設計規范在制定的過程中，因為種種地原因，難免有不符合實情的地方，而且跟著時間的推移和外部環境的變化，難免有不再合用的條目。

設計師往往是訴苦，按照那些鳥規范，完全沒有辦法做事情，或者是自己其實沒有施展的空間。這兩點對于設計規范的應用上，是一個非常矛盾的事。

任何一個設計師，在自己的工作職責和權利范圍內，都有不遵從設計規范，甚至是打破它，制定新的設計規范的權利。
當一個規范不是在限制工作，而是在匡助設計師工作時，那么這個規范想必更輕易被設計師所閱讀和接受。

因而，設計規范和奧運會的記實一樣，仿佛就是生成要被打破或改寫的。

  不論是設計師仍是工程師，都比較自信或者說是自負，一旦在他的思路上加上一個框，往往是感覺四處受到限制而沒有辦法盡情施展，甚至有人說這個設計規范完全是扼殺設計師的立異能力，可以說部門設計師和工程師抵制規范的原因也是在此。在設計規范宣布的條目中可能不會寫這些內容，但是在具體的說明中，最好把背景一起放在里面，以便于設計師的理解為什么這條設計規范會存在。但是打破設計規范是有風險的，任何這樣的行為都應該被仔細的跟蹤，并且在最后確定效果，對于在全局（請留意是全局）上起到正面效果的，不但要鼓勵，而且要獎勵。

  但在另一個方面，設計規范的存在，就象社會上的法規一樣，在公司里面，對每個人都有約束的氣力，沒有充足的理由不容挑戰。但是同樣的情況，不論是在什么情況下，打破設計規范，造成一定后果的，都應該以相關的治理軌制進行懲罰，以保證設計師在沒有非常大的掌握的情況下，去違背和破壞設計規范。

  看起來的確是規范在一定程度上限制的思維，但是設計規范并不是要限制設計師思索的能力的，假如一個設計規范在限制了設計師的思索，那么這個規范并不能說是成功的規范，設計規范應該告訴設計師，你的“前輩”犯過什么樣的錯誤，這樣的錯誤可以用規范中的辦法去避免；或者你的前輩在某些方面取得的很好的成績，這個規范就是按照這個定的。