我们在做互联网产品中，有的是以产品功能，但大部分以项目为纬度进行分割。在产品1.0后，设计团队需要UI设计师建立规范，如果你所在的产品团队有2个以上的UI同学。那可能在1.0还没开始，一套好的UI规范就是需要立马做的。

首先要明确，UI规范是需要UI设计师或UED团队来完成的。但今天这里我归纳了一些好的设计规范方法集合（含多个案例）。

从如何建立设计规范、团队什么是需要规范、设计规范应该有什么纬度，本文涵盖较多的图片内容，建议注意。

下面这些内容都来自一群优秀的设计师回答者，通过产品经理视角归纳了上面3个问题的答案。

设计规范的分类

UI的设计规范总共可以分为三类：

1

品牌类（VI）

帮助企业做的宣传手册、PPT、市场公关等pr文件，企业的整体形象颜色。就好比你现在看到的瓜子二手车，绿色是整个的颜色。

2

平台、系统类

常见的是IOS、谷歌、开放平台、小程序等，需要第三方开发者介入，需要第三方的开发者在设计上遵循什么理念，以及遵循该套理念 后的背景与原因、好处

3

产品业务类

面向产品内部，规则侧重在产品设计和实现层面，实用性第一。设计文档、标注都不能少，其他设计同学或工程师可以直接参考或使用

互联产品的设计规范概念

设计互联网产品，Style Guide /Pattern library、Specification各具不同的功能和作用，却都含“设计规范”的概念

1

Style Guide

偏重视觉概念，常见文档或图像格式呈现（还可以扩展）

内容：对设计作品的字体（Typeface)、字型（Font）、色板、品牌标识规范（Brand Guideline)、Icon等要素进行展示和说明

这个部分主要的功能是方便设计师与设计师之间，展示产品的视觉风格。方便风格复用，规范新的元素或第三方接入。

2

Pattern Library

偏重（web前端）开发概念，基本都是以网页文档形式呈现

内容：对界面元素（UI Elements)的样式风格以及实现其效果所对应的代码片段作出解释（HTML、CSS），常见的布局（Grid System)、字体排版（Typography)、按钮、菜单、列表、对话框（Dialog)、Toolip等等

可以帮助团队Web设计和协作开发，统一产品风格。减少UI还原与验收的工作，保证用户体验与最初设计稿一致。

3

Specification(Spec)

介于设计与开发之间，由设计师直接在（mockup)中创建

内容：主要由Annotation（注释，国内俗称“标注”）和Measurement(量度）构成。其实说白了就是我们常规研发中的让UI切图，是开发与设计人员最直接的交流。通过切图，我们可以把字体字型、色纸

UIKit与设计文档规范

细节的设计规范在不注重设计的公司是非常难以推动，第一是版本变化太快。很可能今天上线的新产品，明天就说要重构。UI稿都没时间做完了，哪还有时间去琢磨这个版本的设计规范，小步快跑待商业模式清楚后再去考虑设计规范的事情。

当然，如果团队中已经有几个设计师的情况，可以考虑在基础控件、组件上建立规范，方便设计稿合并的时候可以连接上。

通过设计团队一起讨论、草稿、细化、定稿、规划、批量化，设计规范就像炒菜一样。绝对不是通过加点盐、少点醋可以把菜做好的，而是通过时间的积累，越沉淀会越香。

设计师也需要从无规范到沉淀自己的规范，如果一个版本推翻，就全部重新更换规范。这就是去了规范的意义，规范是可以复用，并且也可以让用户达到了固定的认知，推翻则可能是对用户习惯的挑战。

UIKit,其实说白了是将设计稿源文件以 psd\sketch文件，可以让不同设计师快速使用，并且产生设计风格相似的产品。

比如小程序与app或web，如果已经订好了web，则设计师可以通过该规范快速产生小程序设计稿，让小程序可以用一套规范。

如知乎在web的热搜榜与知乎小程序的热搜

UI设计文档规范

文档与UIkit的不同点在于，可以更加详细和准确的表达。对风格、颜色、文字、控件、交互、图标、东校，甚至还可以包含配乐都有了明确的标注。需要不停的更新、迭代、完善，这是一个持续的动态文档。有点类似产品经理的需求池、需求文档一样，随着新功能、新版本、新元素的加入，设计师需要增加UI设计文档规范的内容甚至推翻部分规范。

文档规范又分

• 字体排版（Typography),即界面式设计

• 颜色（Color)规范，产品主要的颜色库

• 图标库（Icon)

• 控件库（UI Toolikt)

• 视觉框架（Visual Hierarchy)，定义产品的交互框架结构，与信息架构有关需要产品经理参与

下面是一个UI文档规划web端案例

企业vi/品牌形象的规范

企业vi并不是互联网的UI规范，他没有像互联产品的什么button\控件等。但他们都非常相似，因为两者紧密相关。通过企业的logo展开的产品、企业服务、企业形象都是vi、UI设计师需要考虑的。

两个比较好的例子就是MUJI和Apple，下面分别是他们的app \网页\实体店。

MUJI

Apple

设计UI规范步骤

既然知道UI规范有什么，需要什么内容。UI同学真正在实际工作中是如何建立设计规范的？

大体的流程为

1. 浏览所有组件

2. 分类

3. 整合

4. 参考竞品，优化组件

5. 写UI文档》验证、拓展更新

浏览组件

浏览产品所有的页面，对产品的组件进行全面的了解，比如如果是社区产品，则feed流、登录注册、图文组件。一定要注意纬度是最细的：组件，搞清楚有多少种组件

分类

不同行业的产品，组件的优先级会有不同。比如电商类的是以图文组件、新闻资讯的是信息流组件。

通过截图的方式进行收集，不要一开始就用sketch或axure来进行绘制。非常耽误时间

整合

对组件进行分类，注意的是有一些组件可能会出现个性化的情况。根据产品经理需求而定。对照新版本和需求，对现在没有的组件也进行标注，以下面的方式进行展开

参考竞品、对照需求，优化组件

通过分类，我们可以以组件的类型去参考一些好的案例。比如网易、腾讯等产品，甚至是自己所在行业的竞品，上面我们只是把之前的组件进行了规整。接下来就是对不同类型的组件进行优化，因为很多组件可能在没有规范的时候其实是老化或淘汰的。

参考竞品既可以知道组件规范的问题，也可以知道是否付费时代用户趋势。在这步完成后，我们的组件就基本新鲜出炉啦。

写UI规范文档

通过上面的工作，我们接下来使用sketch或蓝湖等工具，将文档规范输出。注意前面说的，UI规范文档是一个持续动态的文档，保证团队可以及时更新和复用。下面是一个例子

颜色提供高度定制化还是提供有限色板

在这里有2个前端开源工具，分别是Bootstrap和Semantic UI，都是非常丰富的前端规范案例。

Bootstrap是美国Twitter公司的设计师Mark Otto和Jacob Thornton合作基于HTML、CSS、JavaScript 开发的简洁、直观、强悍的前端开发框架，使得 Web 开发更加快捷

Semantic UI

Semantic is a development framework that helps create beautiful, responsive layouts using human-friendly HTML.

在色调的选择上

有去色板的，色彩主题非常容易切换；由于颜色的可选性不多导致场景的选择上会更加苛刻，或者需要添加额外的设计

定制化的优势是方便提供色彩的丰富性，每一个component的颜色都可以毫无相关，但劣势是增加了色板的控制难度，对开发的要求也会非常高。开发需要通过管理不确定的颜色，就要管理未知的代码设计。

下面是在是一个案例

本次规范内容原创的作者门：

阿本、陈希 Chris、周莜、叶卉、静静、阿本、icecreamliker

好的内容会发光，感谢他们的内容提供。相信也能在这里帮助正在阅读的你。

定一套设计规范，减少产品弯路。

之所以花这么长时间整理这篇归纳内容，是近期在工作中深刻认知到一套UI规范是可以大大提升开发效率，减少在测试、UI还原的工作量，并在思考一个问题产品经理如何协助UI定规范？

产品经理需要告知需求的背景、需求介绍、产品未来的规划甚至是产品的商业模式。

当然，如果你只有一个点子，还没有开始你的项目运营。那设计规范可以放在后边，但当项目上线后，逐步开始进行UI的迭代与团队成员增加，一个持续动态更新的UI规范是非常有必要的。

产品经理要知道在UI规范中常见的一些事件，比如按钮的状态、输入框的状态等类型。因为很多情况下，UI设计师一个人是没办法全部想全面，产品经理需要在测试环境甚至是线上环境就给予建议。

当然，理想的方式还是在UI设计中就给予对应的元素、元素状态。