立即登录 设计早就不是一个人闷头画图就能搞定的事了。稍微复杂一点的产品，背后都是几个设计师甚至跨团队在协作。一旦没有一套统一的交互规范，很容易就会出现同一个按钮在不同页面长得不一样，编辑流程在A模块和B模块完全是两套逻辑的情况。最后用户觉得难用，设计师自己沟通起来也累得够呛。交互规范这件事，说到底，就是为了让团队里所有人对“该怎么做”有一致的理解，少做重复劳动，把精力真正花在需要创造的地方。
所以这篇文章，我想和你聊聊三个问题：一般的设计规范到底包含什么？怎么制定规范才能真正省时省力？以及，怎么判断一套规范合不合理？
这三个问题其实是环环相扣的。先搞清楚规范包含哪些内容，你才能拿着这些内容去落地，不至于一上来就抓瞎。但光知道内容还不够，很多团队做着做着，规范反而变成了负担——每个新项目都要重新搞一套，规范本身成了需要维护的又一个大项目，当初想省时省力的目标根本没达到。关于这一点，我们团队也还在不断摸索，这里先给出一些思路供你参考。最后，既然花了时间制定规范，总得有个标准去衡量它到底好不好用，不然很容易变成自说自话，设计决策的合理性也站不住脚。
话不多说，我们一个一个来。
规范到底包含什么
设计规范通常可以拆成两大块：视觉规范和交互规范。
视觉规范管的是那些很具体的、一眼就能看到的东西，比如字体、字号、颜色、图标风格、间距、投影等等。这类规范一旦定下来，基本就是“死”的，除非有新的组件类型出现，否则已经存在的页面统一按这个来走就行，没什么讨价还价的余地。
交互规范则要“活”一些，它更关注结构和逻辑。比如整体页面的信息层级怎么划分，导航和内容区的关系怎么定，弹窗、提示、加载、空状态这些反馈机制长什么样，再比如编辑、删除、提交这类通用操作的标准流程是什么。因为这些和具体业务强相关，交互规范一般是给一个框架和边界，允许设计师在这个范围内灵活调整。它不像视觉规范那样必须一板一眼，但缺了它，协作就容易乱。
拆开来看，交互规范大致会覆盖这些方面：产品结构、页面布局、公共组件、业务组件、反馈机制、公共流程（比如登录、注册、编辑）和业务流程（比如下单、退款）。视觉规范则是在这个基础上，把颜色、字体、间距这些细节补全。
制定这样一套规范的初衷其实很实在：让团队内部合作有据可依，减少扯皮；让每一次更新都有迹可循，方便追溯；用组件化的思路提高复用率，设计和开发都能少做重复工作；如果有多条业务线并行，统一的规范能让它们看起来是一家人，体验不会各玩各的。
怎么让规范真的省时省力
我个人比较懒，所以对“怎么偷懒”这件事一直很有研究。规范如果不能帮我们省力，那还不如不做。
怎么让制定规范这件事本身也变得高效，得看项目处在什么阶段。项目初期，重点是把产品结构和一些常用的公共流程、公共组件先定下来，不用太细，但框架要对。这样初期交互设计和开发就能有一个差不多的起点，不至于每个人都在凭空发挥。项目中期，随着业务深入，一定会冒出新的组件和流程。这时候要不要把它们纳入规范，主要看三个点：它出现的频率高不高，是不是通用，以后好不好扩展。项目后期，工作收尾的时候，再回头检查一遍，看看新加的东西有没有和旧规范冲突或重叠，有没有哪些地方其实可以提炼成新的通用组件，更新到规范里去。
如果设计师同时负责多个项目，情况就复杂一点。我遇到的场景大致有三种：第一种，整个公司就围绕一个核心产品做，那简单，从上到下维护一套规范慢慢迭代就行。第二种，公司有N个产品齐头并进，彼此看着像但又不是同一个东西，比如面向不同行业的SaaS工具，每个产品都需要定制，强行统一反而不合适，那就只能各自维护一套规范。第三种，公司有多个产品但它们是互补的，比如一个平台下分不同功能模块，这种情况下可以抽出一套公共规范，把共性部分统一掉，再根据各自的业务特点派生分支规范。
第一种和第三种还算好办，第二种最让人头疼。产品不同，基调不同，规范不同是合理的，但维护起来代价很大。如果你正好遇到这种情况，我的建议是，再怎么变，每个公司总有一个核心业务是立身之本。可以把核心业务里的核心流程和组件先抽象出来，做成一套更底层的“基础规范”，让它能适配不同产品的形态，剩下的差异化部分再按项目单独去维护。这样至少能保证核心体验不乱，其他部分灵活处理。
说到底，省时省力的关键，就是把公共组件和公共流程提取出来作为统一规范，而结构、布局、具体业务流程这些容易变动的部分，以项目为维度去维护和迭代。公共部分不变，差异部分各管各的，出了问题也容易定位。
怎么评价一套规范合不合理
现在很多设计师都有经验，项目初期就能列出一套看起来像模像样的规范。但问题来了，列出来之后，怎么判断它是不是一套好的规范？我觉得可以从三个维度去问自己几个问题。
第一，这个组件在项目里出现的频率高吗？如果只是某个犄角旮旯里用了一次，那完全没必要收进规范，当成特例处理就好。第二，它在其他模块里能复用吗？复用率有多高？如果现在不能复用，有没有办法稍微调整一下让它变得可复用？第三，如果它本身不能直接复用，那能不能通过简单的增删变体来复用？或者能不能用几个更基础的组件组合起来，达到同样的效果？
这三个问题对应的就是频率、普遍性和可扩展性。一项规范条目，如果同时满足这三个条件，那它大概率是值得写进去的；如果一条都不沾，那就得再想想，是不是我们想多了。
以上就是我平时关于设计规范的一些碎碎念，目前主要还是从概念层面在做梳理，后面有机会再整理一些具体的例子拿出来聊。希望这些思路能给你带来一点启发。