ui设计规范文档怎么写，ui设计规范怎么写

大家好！我很荣幸被邀请分享关于ui设计规范文档怎么写的相关问题，同时，我还会讲解一下和ui设计规范怎么写的相关内容。如果你对这些问题还有疑惑，希望我的文章能解答你的问题。让我们一同探寻知识的海洋，开始吧！

为什么要写交互设计文档交互设计文档怎么写

今天想和大家分享一下：为什么要写交互设计文档？交互设计文档怎么写？作为交互设计师，我们平时工作最大的输出就是交互设计文档。很多刚转行的同学会在网上找模板直接应用或者慢慢摸索，这篇文章会为你解开为什么要写交互设计文档的疑惑以及怎么写！还有，学习更多的交互设计技巧，何不来学习交互设计课程？

为什么要写交互设计文档？

第一，交互设计师的交互设计文档就像UI设计师的PSD文件一样，用来保存和记录自己的设计思路。然而，交互设计师的任务不仅停留在页面上，还包括产品需求分析、用户画像、竞争产品分析、产品数据分析、用户交互逻辑等。我们都可以写在交互设计文档中进行记录，为我们的交互设计提供依据。(其实就是避免开发怼你问你设计依据是什么，你马上把分析放在他脸上，避免尴尬)

第二点是交互设计师作为产品的上游(一般的开发过程是产品经理负责收集需求，给交互设计师进行交互设计，写交互设计文档，然后通过文档评审，UI学生负责UI设计，然后提供前端学生进行界面开发，后端学生根据交互稿构建框架和业务逻辑，开发完成后进行测试，反馈测试结果，这样循环，所以交互设计师一般处于产品线的上游阶段)。写一份标准规范的交互设计文档很重要，因为我们需要用交互设计文档来表达我们的设计思路。通过交互文档，我们可以让UI学生知道页面需要向用户表达什么情绪，达到什么目的，告诉前端学生页面跳转逻辑，如何写交互模块，帮助后端学生清晰地构建后台框架和数据库，以及产品业务逻辑。最后，测试童鞋会用你的交互稿进行单元测试，编写测试用例，所以只有先写文档，才能避免后面产品开发的问题。

第三点也是最重要的一点，就是我们以后用来跳槽加薪面试作品。专家看门道，外行看热闹。如果你在面试交互设计师的时候还是带着一个长JPG或者同样在网上排版的PDF作品集，在面试官眼里是不入行的(也许你会遇到一个性格好的面试官，毕竟有几千人，面试特别看人)，因为专业的交互设计师互设计师为了避免在日常工作中干扰UI学生的设计，只会用黑白灰做交互稿，很少做长PNG或者JPG。我们可以适当包装作品集，但是过度的话会让人觉得不落地，可能只停留在入行阶段。所以在技术面试中，我们可以拿着我们的交互设计文档，向面试官讲述如何从需求层面思考产品，解决用户的痛点，最终取得什么样的成绩，获得什么样的数据。相信成功的几率会大很多。(PS:面试前请注意对公司机密信息进行脱敏处理，避免纠纷)

交互设计文档怎么写？

1.文档封面(必须)

文档封面相当于一本书的封面，用来记录产品名称、版本号、日期、文档负责人(这样开发童鞋就能准确找到你撕X)，只要能显示以上信息，其他信息(比如产品经理是谁等。)可以自己添加。

2.更新日志(必须)

以前我习惯把更新日志放在产品文档后面，但是随着工作时间的推移，我发现开发童鞋在SVN上打开设计文档后第一时间查看更新日志，所以后来提到了这一页。(是的，设计文档也需要像产品一样不断优化迭代)

更新日志主要用于记录产品迭代修改的内容，让开发学生快速了解迭代修改了什么，需要做什么工作。我的更新日志很简单，只有四个字段:日期、更改内容、页面和备注。这里唯一需要注意的是，日期必须是最新修改的内容，之前的日期在下面，很多同学每次迭代都会在下面的列中添加内容，这样开发的同学每次都要滚到底部查看信息。大哥，你是交互设计师，专业好吗？

3.产品项目背景(必须)

产品项目背景是一个项目的核心关键，告诉所有团队成员我们想做什么样的产品，需要创造什么样的价值，就像我们写作文时的中心句一样，总是提醒我们不要忘记你的首创精神，为团队成员开发项目指明方向。

4.产品需求(必要)

产品需求列表用于记录产品需要做哪些【功能点】。我们通常可以从产品经理或项目经理那里获得这些功能点。收集需求后，我们需要根据P0.P1.P2的重要性对其进行分类。

5.交互原型(必须)

几乎可以说，以上所有的东西都是为完成交互原型做铺垫的。相信大家对交互原型都很熟悉，但是分享一些经常出错的点。

1）尽量只使用黑、白、灰配色，以免干扰UI学生的设计。这是大家经常犯错的一点。毕竟很多同学以前都是UI出身，做交互稿的时候顺便配色，会对UI同学的设计产生很大的影响(不在其位，不求其政，做UI的时候也不想有人指指点点)。所以我们做交互稿的时候只用黑、白、灰就够了，灰度代表信息的重要性，简洁规范。

2）页面跳转用连线表示其实很方便，真正厉害的人不会到处炫技。有的同学在互动稿上跳来跳去，动态面板，中继器等。，这让开发学生看起来特别不舒服，所以经常用连接的方式来表达往往是最简单明了的。

3）如果涉及到多端设计(IOS.Andriod.PC端)，除非产品很大，否则放在同一个设计文档中，避免以后审核时获得多个文件。

4）创建一个适合自己的组件库。在日常设计中，80%的控件可以重复使用。做一个合适的组件库可以节省很多时间(我整理了工作多年的B端和移动终端常用的组件，需要的时候可以和大家分享)

好了。关于“为什么要写交互设计文档？交互设计文档怎么写？”的文章就分享这么多~总而言之，在进行交互设计时，提前做好一份交互设计文档能够更好的帮助自我进行交互设计，更好的将工作进行简单化~

UI设计规范说明书

高质量的规范文档是一个优秀设计系统的代表物。我们详实地描述每个 UI组件的设计与代码规范，来帮助设计师高效地作出决策，推动开发速度。编写高质量的文档需要前期规划和一系列合理的流程来辅助，付出的成本相当高。

这个系列由六篇文章组成，致力于描述编写组件规范文档的过程。本篇我会从目标读者、文档内容、文档结构开始。然后会涉及案例，设计与代码指南。这些内容来自于我自己这些年的实践经验以及社区里大家所分享的知识。

那么我以一个问题开始今天的主题：文档的目标读者是谁，他们需要什么样的内容，作为编写者我们该怎样组织文档结构来作出清晰的表达？

文档的目标读者

首先：你要弄清楚谁是你的文档的主要读者。

工程师，设计师，还有公司里的所有人！

当一个设计系统包含了代码指南，工程师们显然会是读者。那么一个只包含了代码指南的设计系统应该服务于设计师吗？如果文档里只包含了设计规范而没有代码（如 Material Design），工程师还是读者吗？

在我看来，两个问题的答案都是肯定的。规范文档是从不同的角度来服务于多种角色的。

除了设计与工程，它还服务于其他人吗？很有可能，特别是当文档所在的设计系统已经成为产品的基石时。简短有效的介绍对于 PM（产品经理）很有价值，QA（测试）则比较关注案例部分…等等。

规范文档是从不同的角度来服务于多种角色的

很多设计系统团队还会把自己的系统公开出来，在体现共享精神的同时也能起到吸引行业人才的作用。所以文档应该能够体现团队的专业与严谨。

文档的主要目标是：为设计师、工程师和团队里的其他角色服务，让他们能够高效地做决策。

Takeaway：设计系统的效应和影响力不只覆盖设计与工程，一个成长中的系统必将会服务于更多的角色。

工程师，接着是设计师，然后才是其他人

为所有角色服务并不意味着平等地服务所有角色。工程师每天会查阅 10次或更多次文档，他们甚至会把文档与代码编辑器窗口并排排列！设计师的访问次数应该是少于工程师的，其他角色则会更少。

所以谁是最重要的？以我的经验来看，设计系统最初就是为了工程与设计之便，由工程师和设计师建立的。即使其他角色也对其有所贡献，但他们仍是偏次要的。因此我们首先需要确保工程师与设计师的需求能够得到满足。

设计师与工程师优先级最高

那么，工程师与设计师孰轻孰重呢？我最近参与设计的设计系统项目中都需要同时服务于两者，为设计和代码制作规范指南。我也在一些企业的文档中看到了对其中一方的过多偏见，或者是有将他们的目标完全分离开的倾向（稍后我会解释）。有很多维度需要考量：设计系统的目标，他们的使用频率，内容深度、质量、生产成本，以及和他们日常工作的相关度。

设计师 vs工程师

Takeaway：读者的优先级由很多因素决定。要有预期：工程师和设计师的需求会有冲突，并尽可能地优化和处理这些冲突。如果实在不行，就要偏向于距离最终产品最近的那一方，通常是工程师。这就意味着工程师优先，设计师其次。

文档内容

规范文档是连接读者与内容的媒介。内容会有不同的格式或模块，因此成本也各有差异，而你需要最终把它们编织在一起。

文档内容模块：简介和案例文档内容模块：设计参考和代码参考

抽象地来看，规范文档的内容通常包含以下四种模块：

介绍：组件的名称，以及一段简明扼要的介绍。（必要）

案例：这个组件的各种形式，状态，尺寸等等其他要素，比较好的做法是用代码直接把这些展示出来，而不是不可以交互的静态图片。（必要）

设计参考：比如什么时候应该用这个组件，允许的做法与不允许的做法，以及视觉、交互、文案方面的指南。（推荐）

代码参考：包含 API和其他实施及部署方面的指南。（必要）

不同的模块会有不同的制作成本

「介绍」写起来当然非常的短平快。结构优秀的「案例」也是值得投入成本的，并且写起来会越来越顺手。工程师也需要一个合理清晰的「代码参考」。但是，真正有效的「设计参考」可能会非常耗费成本。

横轴：细节的丰富程度由浅到深。纵轴：制作成本由低到高

请点击输入图片描述

Takeaway：规范文档可以包含很多内容模块。所以需要团队在前期就进行充分的讨论，对每种内容模块做出符合自己团队和产品价值的判断，再投入成本去制作。

文档的信息结构

设计与代码：分开还是合并？

在实践中，设计师往往会自顾自的发布或更新和自己相关的内容，工程师也一样。这样的惯性行为会在无意中增加设计与工程的距离。所以大家需要在前期就对文档的信息结构达成共识。

谷歌的 Material文档生态就是这种距离感的代表。Material’s design foundation优先服务于设计实践,而Material Design Lite，Polymer Project，Android Developer’s，Material UI(built for React)都是服务于代码，和设计规范绑定的并不紧密。

请点击输入图片描述

这种分离的状态其实是有意义和理由的。因为 Material是一个操作系统的底层系统，跨越了许多框架，团队，平台。它的复杂度在某种意义上超越了目前世界上所有的设计系统。但你要知道大多数的设计系统并不是服务于一个操作系统的，因此不会发展至如此复杂的形态。

对于像我们一样的产品团队来说，设计和代码分开是符合共识的。这种做法能够给分别为两种角色设计符合他们需求的体验。

组件设计规范与 API和代码规范分别放在两个网站上。来自：Atlassian

请点击输入图片描述

这种做法也有风险。随着时间推移，两个网站可能出现不同步的现象：

设计与代码的分类逻辑出现差异（最简单的例子就是 Loader和 Spinner的命名：代码里叫 Loader，而设计里则叫 Spinner）

功能差异：设计规范里出现了代码不能实现的功能，或者代码里加入了设计里没有考虑的功能。

你可能会觉得这样也挺好，毕竟设计和代码本身就是两个领域。至少对于文档的写作者来说这种分离还是挺方便的（只用考虑自己的需求，管理自己的进度）。

但真正的读者需要的是一个「真相的唯一来源（Single source of truth）」。如果你是一个对设计和代码都有需求的读者，你会发现自己不停在两个网站间切换，两个地方都有对你有价值的内容，这感觉就像是在打网球时陷入了拉锯战。

Takeaway：要慎重地看待设计与代码的分离。虽然一开始方便了内容作者和发布者，但之后会有风险。这种做法也可能会在潜移默化中造成设计与工程的距离扩大。

合并内容的两种方案：堆叠还是切换？

例如 Morningstar Design System是把设计和代码放在一个页面里，读者就能找到完全统一的命名，指南，功能描述。

一个页面之堆叠式：把设计和代码放在一个页面中，纵向滚动来查看。

请点击输入图片描述

堆叠式的布局方式会使得页面变得冗长。当然还有一种方式是使用 Tab来切换内容。

一个页面之切换时：把设计和代码放在一个页面中，通过 Tab来切换内容。

请点击输入图片描述

Takeaway：将设计和代码混合在一起是有可能的，大家可以按自己的需求来选择以上两种布局方式。

按类型来为内容做排列和编组

不论选择那种布局方式，文档内容的模块结构和顺序应该是保持一致的：

简介

案例

设计参考

代码参考

其实只要把「案例」放到读者一进来就能看到的地方，把设计和代码参考放在一步点击就能达到的地方，就是一个不错的设计了。下面是几种行业内比较有代表性的模式：

左：IBM Carbon模式中：Hudl's Uniform System模式右：Lightning Design System模式

请点击输入图片描述

IBM Carbon认为代码更应该被优先展示，将交互用法和样式分别放在其他的 Tab中。Hudl’s Uniform system把顺序反了过来，设计优先于代码。Salesforce’s Lightning Design System把代码和组件案例放在 Tab上方，默认选中开发者指南这个 Tab，而后两个 Tab则被奇怪地留空了。

Takeaway：把简介和案例放在一开始最重要的位置，接下来的模块则没有唯一的方案，需要大家自己做出符合自己团队情况的判断。

若页面很长，则为读者提供定位导航

你的文档页面越长，越需要给读者清晰的认知，要让他们知道这个页面里会包含哪些内容以及当前所处的位置。纵向的定位导航栏是个不错的方案：一直固定存在于页面右侧，在滚动时同步追踪位置，并且可以包含子标题。

Morningstar Design System在文档页面右侧设计了一个两级的定位导航栏

请点击输入图片描述

Takeaway：不论选择哪种形式，最重要的是在整个系统中保持逻辑一致，符合读者的预期与心理模型。

展示设计？展示代码？还是都展示？

把设计和代码融合，就会有读者只对其中一个方面感兴趣，他们会提出自己的意见：

设计负责人可能会问到：我能把这些代码案例和指南隐藏掉嘛？

工程师可能会问：我能把这些和设计规范有关的文字隐藏掉嘛？

可以考虑加一个选项或按钮来允许隐藏设计/代码内容。比如：

Design Only：把代码指南、代码片段和属性表等等都隐藏起来

Code Only：把视觉样式指南和文案指南都隐藏，但还是要把一部分交互用法指南保留着，这对工程师们也有用。

ui设计规范怎么写

一、UI标注的规范

1、尺寸。例如图标、图片这些内容关于尺寸维度的标注。

需要注意，比如图片的尺寸比例，不是固定的它的大小数字，这样开发才能更好的适配，常用的图片比例有4：3、16：9等。如果控件给出固定的尺寸数值，按钮的宽和高度都标注出来，开发就会写死按钮的尺寸，一旦遇到屏幕有比例不同的时候，按钮还是固定的大小，就会影响视觉效果；

2、标注文字的字体、字号、颜色、行高和透明度等等。

这些都要给出一个极限情况的规范，如最多显示几个字符，字符超过极限值就用“...”的方式处理；

3、间距的规范。

间距相对比较简单，只要标注清晰就不会有太大问题。但有时候将间距和尺寸混淆。我们可以这样理解为尺寸是容器的大小，而间距是容器之间的距离，所以间距和尺寸有着很大的不同；

4、颜色标注规范。

文字的颜色已经归类到文字属性里面，不用重复标注。颜色标注内容有：分割线颜色、背景色、按钮颜色等等。 建议使用公司或品牌原有VI配色，可提高公司或品牌VI之间的关联，增加可辨识性和记忆性。

二、UI里图片处理规范：

除了图片风格、色调等常规的统一性意外，还要着重注意切图和图片优化。

1、安卓系统

安卓系统切图：

统一采用Png格式

部分需要做适配的图片需要制作.9格式

安卓系统图片优化：

图片压缩优化

ICON可采用PNG 8

支持完全透明和完全不透明两种效果和256色

需要高清的可采用 PND24/32

2、iOC系统

iOC系统切图：

统一采用Png格式

以640/750宽分辨率为@2x输出三套尺寸：@1x@2x@3x

iOC系统图片优化：

图片压缩优化

ICON可采用PNG 8

支持完全透明和完全不透明两种效果和256色

需要高清的可采用 PND24/32

三、UI中的命名规范：

统一的、规范的命名对我们自己的文件整理有很大的帮助，后期修改文件、图层的时候更加方便快捷。

并且做好版本管理、文件归档的工作，会提高项目沟通衔接，能更好的为版本管理、文件归档做铺垫。

比如常见文件包命名规则是：项目名字＋切图＋作者名字＋日期。

比如常用的英文单词列表：

bg（backgrond背景）

nav（navbar导航栏）

tab（tabbar标签栏）

btn（button按钮）

img（image图片）

icon（图标）

selected（选中）

default（默认）

pressed（按下）

back（返回）

content（内容）