ui设计规范文档怎么写
ui设计规范；ui设计规范有哪些？这个问题对于ui设计师来说应该是比较关心的吧，因为作为ui设计师，ui整理设计规范也是设计能力的一种体现。所以，无论是自己设计创作还是推动产品开发，你的设计规范是否完善，对产品的质量起着决定性的关键作用。那么我们今天就来聊聊这个问题吧！
ui设计规范有几大分类组成：
1、Logo
品牌印象的直接感受，根据页面不同背景所使用的Logo图也不同。将产品中所使用到的Logo统一分类，以下引用Moby’s Petshop UI Style Guide的Logo资源例举说明。
Moby’s Petshop UI 的Logo由图形和文字组合而成，而品牌色为蓝色，Logo的使用也需要考虑到Footer黑色背景下的Logo。所以用Logo的横竖向排版和单个Logo图形来分类更好。
分类里面则展现品牌色的Logo、品牌色背景的Logo、Footer黑色背景的Logo。
2、标准色
颜色是设计最重要的部分，没有之一。细节决定品质，所以对颜色的运用格外细致，颜色的搭配直接决定产品的品质感。颜色大致可分为品牌色、文本颜色、背景色、线框色等。给颜色添加关键词，明确用于什么界面。
以下引用real-pixels UI Style Guide的颜色规范，可以借鉴的是每个颜色不仅标注了颜色值，而且右侧给出了颜色使用的场景，值得借鉴的是按钮Normal状态和Hover状态的颜色值放在一起，这样，对不同状态显示的颜色感受更直观。
对颜色值统一规范命名变量，提高开发效率的同时更好的维护设计规范。
在前端开发中，对颜色值进行编号，这样对代码也有着极大的优化。定义一个设计规范的CSS样式库，开发过程中就不用重复修改CSS参数值，直接引用定义好的变量名就可以，这样修改设计规范的成本大大降低。
3、字体
字体是设计中必不可少的考虑因素，不同的字体气质不一样，并且不同场景下带给人的感受也不一样。所以需要在设计的时候考虑到字体的设计效果，然后在设计规范中注明。
以下引用的是Retail Banking Service UI Style Guide中的字体规范，在定义字体名称的同时也定义了字体的风格，并且添加了不同字体风格的预览效果，常见的字体风格有：Light、Regular、Italic、Semibold、Bold。
4、段落设置
在实际的产品设计中，段落有很多种样式，不同场景下的段落要求也不一样。比如：阅读内容的段落要求文本可阅读性强，所以对字体、字号、颜色、行间距等要求简单易读。而带有装饰性的段落文本则不需要那么严谨，装饰性强就可以。
需要注意的是：在定义段落默认字体的时候还需要定义一个后备字体，即默认字体不能正常显示情况下显示的字体。设计的水平层次就在于对细节的打磨，这也就是段落规范在设计中存在的意义。
5、图标
图标是重要的软件标识，在设计资源中是最重要的模块之一。在软件产品中甚至可能每个页面都存在图标，图标除了美化的作用以外，还有着明确指代含义的计算机图形。
具体分为以下三个作用：
图标是与其它网站链接以及让其它网站链接的标志和门户。图标是网站形象的重要体现。图标能使受众便于选择。根据图标大小和使用用途进行分类整理设计规范，这样才更清晰明了。
6、图片
图片也是属于设计规范最重要的部分之一，按照用途分类整理图片资源，设计风格系统化。
7、度量
在设计的过程中，我们经常会使用一套规范的度量标准，来保持产品的一致性，分别为圆角值、间距、大小。
对度量解释最好的是设计中经常使用到的栅格系统（Grid Systems），运用固定的格子设计版面布局，其风格工整简洁。这就是我们在网页和APP设计的过程中经常使用到栅格系统的原因。
8、阴影
阴影风格及参数也是设计规范中的一部分，在整理设计规范的时候，需要注意的是阴影的参数值是网页中控制阴影的参数值，而不是设计软件中的参数值。
举个例子：网页中阴影对应的参数值为：box-shadow: type:Outset offset X:0px offset Y:4px Blur:8px Spread:0px color:#000000 ，不透明度：10%，这才是程序员需要的阴影参数值，否则最终开发出来的阴影会出现不一致的情况，无法达到规范的目的。
9、组件
常用的UI组件（Component）：Button控件、下拉框、选择框（单选\复选框）、时间选择器、输入框、搜索框、进度条、分页器、提示框、警告框、表格、弹出面板、数字步进器、选项卡等。
Button控件
按钮是最常见的组件之一，按钮有5个状态：Normal、Hover、Active、Disabled 、Loading。
需要在规范中分别罗列出这五个状态，标注上对应的按钮填充色、边框色、圆角值、按钮宽度和高度，按钮文本大小、颜色值。如果是图标按钮的话，除了上述参数值以外还需要标注icon和按钮文本之间的间距和icon图标的大小。
10、下拉框
下拉框是为用户提供多个选择的单选组件，优点是用最简单的界面布局方式收纳了很多的选项，需要注意定义下拉选择框弹出的时候，鼠标移动上去的Normal、Hover、Active状态。
11、选择框（单选\复选框）
顾名思义，单选框是众多选择里面选一个，而复选框是众多选择里面可以无限制选择。单选框和复选框都需要三个状态，即未选中状态、选中状态和不可点击状态。
时间选择器：
时间选择器是选择年月日的组件，分别对应年月日星期的信息，在设计的时候需要考虑到4个状态，分别是：Select、Not_Select、Hover和Disable，并且写进设计规范。
输入框：
输入文本框是我们软件产品设计必不可少的组件，文本输入框有4个状态：Normal、Active、Disable和Error。
搜索框：
和输入框相同的地方是都需要聚焦然后输入内容完成操作，应该有为Normal、Active、搜索下拉状态、Error状态。
进度条：
这个需要在规范中注明上传进度条的整个交互操作流程，对Normal状态、点击上传/拖拽上传状态、上传中、上传成功、上传失败，整个流程状态的整理。在上传过程中，任何用户操作都应该有及时响应的动作，这样用户在使用的过程中才不会迷茫。
分页器：
分页器是用于切换内容页面的复合组件，常规的分页器有上下页操作按钮、分页页码按钮、输入页码手动查找的搜索框，以及分页器的4个状态：Normal、Hover 、Active、Disabled。
提示框：
提示框是一个事件触发弹出面板显示的组件，经常使用提示框的地方是，删除按钮、疑难问题点、提示类弹出信息等。这个风格设计就比较多了，设计风格各不相同，定义底板样式、文字样式和阴影参数。
警告框：
页面报错时的显示样式，常用的警告类信息是：操作成功、提醒用户注意、警告用户注意等。
表格：
表格类信息居多，应重点整理表格样式以及文本颜色大小。
弹出面板：
弹出面板主要由4个部分组成，分别是面板内的文本信息、按钮、面板大小样式、蒙版颜色和透明度。
数字步进器：
数字步进器属于复合类型的组件，可以理解为按钮和输入框联动的组件，所以输入框和按钮拥有的属性状态，步进器都有。
选项卡：
切换选项卡即切换内容，和下拉选择框不同的是，选项卡是将多个选项都排列出来的单选组件，需要考虑4个状态：Normal 、Hover 、Active 、Disabled 。
ui设计规范，ui设计规范有哪些？这个问题介绍到这里就介绍完了，现在你清楚ui设计了吗？设计规范对整个项目的规范性推动很强大，但是需要花时间和耐心细心打磨，所以需要花费很多时间和精力去整理资料、编辑素材、分类整合，最后还要在设计软件中将整个规范重新排列设计。如果你还有其他关于ui设计的问题欢迎持续关注易夏岚或者与我进行交流~
高质量的规范文档是一个优秀设计系统的代表物。我们详实地描述每个 UI 组件的设计与代码规范，来帮助设计师高效地作出决策，推动开发速度。编写高质量的文档需要前期规划和一系列合理的流程来辅助，付出的成本相当高。
这个系列由六篇文章组成，致力于描述编写组件规范文档的过程。本篇我会从目标读者、文档内容、文档结构开始。然后会涉及案例，设计与代码指南。这些内容来自于我自己这些年的实践经验以及社区里大家所分享的知识。
那么我以一个问题开始今天的主题：文档的目标读者是谁，他们需要什么样的内容，作为编写者我们该怎样组织文档结构来作出清晰的表达？
文档的目标读者
首先：你要弄清楚谁是你的文档的主要读者。
工程师，设计师，还有公司里的所有人！
当一个设计系统包含了代码指南，工程师们显然会是读者。那么一个只包含了代码指南的设计系统应该服务于设计师吗？如果文档里只包含了设计规范而没有代码（如 Material Design），工程师还是读者吗？
在我看来，两个问题的答案都是肯定的。规范文档是从不同的角度来服务于多种角色的。
除了设计与工程，它还服务于其他人吗？很有可能，特别是当文档所在的设计系统已经成为产品的基石时。简短有效的介绍对于 PM（产品经理） 很有价值，QA（测试） 则比较关注案例部分…等等。
很多设计系统团队还会把自己的系统公开出来，在体现共享精神的同时也能起到吸引行业人才的作用。所以文档应该能够体现团队的专业与严谨。
文档的主要目标是：为设计师、工程师和团队里的其他角色服务，让他们能够高效地做决策。
Takeaway：设计系统的效应和影响力不只覆盖设计与工程，一个成长中的系统必将会服务于更多的角色。
工程师，接着是设计师，然后才是其他人
为所有角色服务并不意味着平等地服务所有角色。工程师每天会查阅 10 次或更多次文档，他们甚至会把文档与代码编辑器窗口并排排列！设计师的访问次数应该是少于工程师的，其他角色则会更少。
所以谁是最重要的？以我的经验来看，设计系统最初就是为了工程与设计之便，由工程师和设计师建立的。即使其他角色也对其有所贡献，但他们仍是偏次要的。因此我们首先需要确保工程师与设计师的需求能够得到满足。
那么，工程师与设计师孰轻孰重呢？我最近参与设计的设计系统项目中都需要同时服务于两者，为设计和代码制作规范指南。我也在一些企业的文档中看到了对其中一方的过多偏见，或者是有将他们的目标完全分离开的倾向（稍后我会解释）。有很多维度需要考量：设计系统的目标，他们的使用频率，内容深度、质量、生产成本，以及和他们日常工作的相关度。
Takeaway：读者的优先级由很多因素决定。要有预期：工程师和设计师的需求会有冲突，并尽可能地优化和处理这些冲突。如果实在不行，就要偏向于距离最终产品最近的那一方，通常是工程师。这就意味着工程师优先，设计师其次。
文档内容
规范文档是连接读者与内容的媒介。内容会有不同的格式或模块，因此成本也各有差异，而你需要最终把它们编织在一起。
抽象地来看，规范文档的内容通常包含以下四种模块：
介绍：组件的名称，以及一段简明扼要的介绍。（必要）
案例：这个组件的各种形式，状态，尺寸等等其他要素，比较好的做法是用代码直接把这些展示出来，而不是不可以交互的静态图片。（必要）
设计参考：比如什么时候应该用这个组件，允许的做法与不允许的做法，以及视觉、交互、文案方面的指南。（推荐）
代码参考：包含 API 和其他实施及部署方面的指南。（必要）
设计与代码的分类逻辑出现差异（最简单的例子就是 Loader 和 Spinner 的命名：代码里叫 Loader，而设计里则叫 Spinner）
功能差异：设计规范里出现了代码不能实现的功能，或者代码里加入了设计里没有考虑的功能。
简介
案例
设计参考
代码参考
不同的模块会有不同的制作成本
「介绍」写起来当然非常的短平快。结构优秀的「案例」也是值得投入成本的，并且写起来会越来越顺手。工程师也需要一个合理清晰的「代码参考」。但是，真正有效的「设计参考」可能会非常耗费成本。
请点击输入图片描述
Takeaway：规范文档可以包含很多内容模块。所以需要团队在前期就进行充分的讨论，对每种内容模块做出符合自己团队和产品价值的判断，再投入成本去制作。
文档的信息结构
设计与代码：分开还是合并？
在实践中，设计师往往会自顾自的发布或更新和自己相关的内容，工程师也一样。这样的惯性行为会在无意中增加设计与工程的距离。所以大家需要在前期就对文档的信息结构达成共识。
谷歌的 Material 文档生态就是这种距离感的代表。 Material’s design foundation 优先服务于设计实践, 而 Material Design Lite，Polymer Project，Android Developer’s，Material UI (built for React) 都是服务于代码，和设计规范绑定的并不紧密。
请点击输入图片描述
这种分离的状态其实是有意义和理由的。因为 Material 是一个操作系统的底层系统，跨越了许多框架，团队，平台。它的复杂度在某种意义上超越了目前世界上所有的设计系统。但你要知道大多数的设计系统并不是服务于一个操作系统的，因此不会发展至如此复杂的形态。
对于像我们一样的产品团队来说，设计和代码分开是符合共识的。这种做法能够给分别为两种角色设计符合他们需求的体验。
请点击输入图片描述
这种做法也有风险。随着时间推移，两个网站可能出现不同步的现象：
你可能会觉得这样也挺好，毕竟设计和代码本身就是两个领域。至少对于文档的写作者来说这种分离还是挺方便的（只用考虑自己的需求，管理自己的进度）。
但真正的读者需要的是一个「真相的唯一来源（Single source of truth）」。如果你是一个对设计和代码都有需求的读者，你会发现自己不停在两个网站间切换，两个地方都有对你有价值的内容，这感觉就像是在打网球时陷入了拉锯战。
Takeaway：要慎重地看待设计与代码的分离。虽然一开始方便了内容作者和发布者，但之后会有风险。这种做法也可能会在潜移默化中造成设计与工程的距离扩大。
合并内容的两种方案：堆叠还是切换？
例如 Morningstar Design System 是把设计和代码放在一个页面里，读者就能找到完全统一的命名，指南，功能描述。
请点击输入图片描述
堆叠式的布局方式会使得页面变得冗长。当然还有一种方式是使用 Tab 来切换内容。
请点击输入图片描述
Takeaway：将设计和代码混合在一起是有可能的，大家可以按自己的需求来选择以上两种布局方式。
按类型来为内容做排列和编组
不论选择那种布局方式，文档内容的模块结构和顺序应该是保持一致的：
其实只要把「案例」放到读者一进来就能看到的地方，把设计和代码参考放在一步点击就能达到的地方，就是一个不错的设计了。下面是几种行业内比较有代表性的模式：
请点击输入图片描述
IBM Carbon 认为代码更应该被优先展示，将交互用法和样式分别放在其他的 Tab 中。Hudl’s Uniform system 把顺序反了过来，设计优先于代码。 Salesforce’s Lightning Design System 把代码和组件案例放在 Tab 上方，默认选中开发者指南这个 Tab，而后两个 Tab 则被奇怪地留空了。
Takeaway：把简介和案例放在一开始最重要的位置，接下来的模块则没有唯一的方案，需要大家自己做出符合自己团队情况的判断。
若页面很长，则为读者提供定位导航
你的文档页面越长，越需要给读者清晰的认知，要让他们知道这个页面里会包含哪些内容以及当前所处的位置。纵向的定位导航栏是个不错的方案：一直固定存在于页面右侧，在滚动时同步追踪位置，并且可以包含子标题。
请点击输入图片描述
Takeaway：不论选择哪种形式，最重要的是在整个系统中保持逻辑一致，符合读者的预期与心理模型。
展示设计？展示代码？还是都展示？
把设计和代码融合，就会有读者只对其中一个方面感兴趣，他们会提出自己的意见：
设计负责人可能会问到：我能把这些代码案例和指南隐藏掉嘛？
工程师可能会问：我能把这些和设计规范有关的文字隐藏掉嘛？
可以考虑加一个选项或按钮来允许隐藏设计/代码内容。比如：
Design Only：把代码指南、代码片段和属性表等等都隐藏起来
Code Only：把视觉样式指南和文案指南都隐藏，但还是要把一部分交互用法指南保留着，这对工程师们也有用。
