prd文档是什么

高质量的规范文档是一个优秀设计系统的代表物。我们详实地描述每个 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：把视觉样式指南和文案指南都隐藏，但还是要把一部分交互用法指南保留着，这对工程师们也有用。

相信每个设计师作品被客户认同定稿之后都是最开心的时候，然后就会直接把设计稿发给前端。可是在设计完成后还需要做一些整理，不仅能够提高前端的工作效率，还能方便以后的人修改时能方便快捷。

1、考虑PSD文件存储大小

之前小编一直遇到一个问题，PS文件本身并不大，但是保存PSD文件后异常大。前端在切图操作时，电脑会变得非常的卡，从而影响PS的运行速度，降低工作效率。后来小编尝试了各种办法，终于知道了是什么原因。是因为在PS操作过程中，对文档进行了过多的操作，就造成文档保存了历史图像多余的操作数据。而解决这个问题的方法也很简单，只要导入一段代码即可，就可以把多余的操作数据清除掉。

2、整理图层

最后的设计稿要确保图层是清晰的，不要把一长串没有命名，而且没有分组的设计稿发给前端。要确保每个图层都命名，把不必要的图层删除，将对象组织成组，一些特殊的组或图层标注颜色，给前端一个明显的区分。

3、文件命名清晰

PSD设计稿合理命名文件名称，例如：A1首页、B2关于我们等等，这样别人也可以清晰快速的找到所需的设计稿。客户修改页面时，只需按数字向下排列就可以，例如：A2首页、A3首页......就会简单的知道那个页面时客户最后的定稿文件。

要还原设计稿，我们必须坚持围绕以下五大核心因素进行设计：  

1、定稿前的评审    首先评审的时候一定要把改版视觉变化最大的要和开发说明清楚，布局框架改变都会增加开发工作量，能否实现或者实现是否功耗很高。

2、整理一份标注文档    这里文档不一定要十分严格的按照交互文档或者视觉规范文档来做，可以简易的做，关键是能让开发看得懂。另外，需要把文档里面更新迭代的共同的页面整理出来，最重要的是，设计师标注一定要把点击区域标注出来。   

3、向开发宣讲标注    只有向开发宣讲标注，才能在在实现时候减少出错。我们前面每走一步，都是为了后面我们检视还原度的时候要轻松一些，开发也轻松一些，就比如前期基础没打好，后面深入很难。   

4、积极响应开发的每一个疑问    在开发紧张环节中，即使我们前面所有工作都准备好了，也很难避免沟通，因此我们需要做的是积极回应，及时沟通。先沟通具体原因，然后找出解决办法，如果是标注出现问题，比如标注标死了，页面不灵活，适配局限性很大。  

5、开发还原度检视    检视是有一套科学方法的，以场景检视为例，可以按照页面展开的顺序自上而下检视，这样就避免漏掉场景，异常场景等等。更高级的做法，可以做一个测试用列，这样百分之百不漏掉场景。

望采纳。

交互说明文档，是交互设计师 的输出物中必不可少的一项，它关系着设计方案能否最大程度的被实现。交互新人，大多会烦恼如何写交互文档，今天来聊聊这个话题。 交互文档，写给谁看 交互文档可以看做交互设计师 输出的”产品”，它面向的”用户”是下游的同事——视觉设计师、测试工程师、开发工程师。他们会根据文档中的线框图、交互细节说明等等，来输出视觉设计稿、写测试用例、用代码实现产品设计方案，并以此为依据完成验收测试等工作。 交互文档，写什么内容 最初写交互文档时，很多人会有疑惑该写些什么内容。我的看法是，开发同事在写代码时需要考虑的与界面显示逻辑、用户操作相关的内容，几乎都要在交互文档中体现，建议越全面越好。 如果有遗漏的内容，开发可能会找你讨论，也可能懒得费时间沟通直接按照自己的理解去实现。最终，验收测试的效果不如意，你也不能全赖开发。所以尽量将交互文档写的全面些，别消费开发同事对你的信赖值。 那么，到底交互文档中，需要写哪些内容呢? 1、页面流程(界面之间) 页面流程图，可以表达产品的整体结构，帮助同事了解界面之间的关系。在撰写交互文档时，也可以以任务、子任务为模块来详细介绍界面如何跳转、何时跳转。 2、内容布局(界面内) 正在加载状态、加载完成有内容的状态、加载完成无内容的空状态、失败状态(比如网络异常/权限未开启)、不同角色的用户看到的内容是否一样、不同状态的文案图标变化 内容的加载方式，何时加载、何时显示、何时刷新 其他 … 3、交互操作与反馈(界面内) 根据用户与界面之间发生的交互操作，提供相应的反馈，可能是提示内容，也可能是界面内或界面之间的跳转。 刚入门的交互新人，喜欢把重心放在界面之间的跳转，而遗漏了界面内的内容布局和交互操作。对此，我的小技巧是，先整体看界面全局，再review界面上的每一个元素，思考各种不同场景下这些元素是否变化、如何变化。 以登录界面为例，看看怎么写交互细节说明 下图，是一个简单的登录界面，我们试着先整体后部分的方式，看看这个界面的交互说明需要考虑哪些方面。 1、登录界面的跳转流程 什么情况下，从哪些界面可以进入登录界面 登录成功后进入哪个界面 取消登录后回到哪里 界面转场方式，比如从下向上进入界面，从上往下离开界面 2、账号输入框 字段格式要求，字段长度、字段类别(汉子、字母、数字、手机号) 是否有默认提示文案，如果上次登录过是否显示上次的账号 光标是否置入此输入框，键盘是否显示，键盘用哪种视图 何时检测用户填写的是否正确，填写正确的提示，填写错误的提示，反馈提示何时显示、何时消失 输入框中的内容是否支持一键清除 3、密码输入框 字段格式要求 何时检测格式是否符合 光标置入后显示键盘的哪种视图 输入框中的内容是否支持一键清除 是否支持密码可见、如何切换可见状态 4、登录按钮 按钮是否有可用不可用之分，何时可用状态、何时不可用状态 点击按钮之后提示正在登录的方式 登录成功如何提示、跳转进入哪个界面 有哪几种登录失败的场景(比如账号未注册、网络异常等)，不同失败的情况下如何提示 多次登录失败提示方式是否变化 5、注册按钮 点击进入哪个界面 界面的转场方式是怎样的 6、关闭按钮 点击进入哪个界面 界面的转场方式是怎样的 以上只是抛砖引玉，给大家打开思路。虽然只是几个输入框，但其细节比大多数界面都要复杂。你可以找一款优秀的APP，去研究它如何设计这些细节，是否还有我没有提到的点，研究透了下次自己设计才能做到更加全面。 当然，交互细节说明，只是方案的表述，每一个小点都有好几种设计方案。如何权衡选择体验更优的方案，才最是考验交互设计 师的能力。你可以对比研究几款优秀产品，看它们在细节设计有何不同，分析其中的缘由，想想是否有更好的方案，学无止尽。 如何提升交互文档的浏览体验 交互设计 师的目标是提升产品的体验，我们输出的文档本身也应该有上佳的浏览体验。为了达到这个目标，我也在不断优化文档的撰写方式和排版。下面聊聊我尝试过的几种方式。 方式1：一页纸表示所有的线框图，配上箭头+简单的文字说明 网上流传着很多这种风格的图，最初觉得这样的图很有范儿，以为这就是他们输出的全部交互文档，所以按照这种模式产出。等到自己做的多了会发现这类图大多只表达了某个界面的正常状态，并没有详细的交互说明来体现界面的内容布局和交互操作反馈。 方式2：一页一个界面，每个界面建一个交互说明文件夹，分功能模块写交互说明(Web产品) 工具: Axure Web产品的特点是，层级复杂，每个界面比较大而且内容很丰富。通常会组织好页面层级，再画每个界面的原型，待几轮讨论过后界面布局和内容基本确定之后，再为每个界面撰写各自的交互说明。 考虑到每个界面中的内容模块和功能点不少，我没有在确定好的界面上直接标注交互说明，而是将这个界面划分为几个功能模块，并给每个功能模块新建一个页面用来写交互说明。 如下图，分别是 Axure的文档目录(左)、某个功能模块的交互说明(右) 方式3：一页显示一个大功能点的所有界面和交互说明(App 产品) 工具: Axure App相比Web界面内容简洁很多，很多人输出App的交互文档都是一页展示很多个界面，上下左右排满了。设计师大多是大屏电脑，这样设计起来确实比较连贯流畅。 但是开发大多用MacBook，没有外接的大屏显示器，一屏看不到几个界面。虽然我会按照横向主流程竖向次要或分支流程的规律排列，但是他们对这些规律并不熟悉，左右拖拽上下滚动几次就容易犯晕，可能一会儿就找不到刚看过的界面了。 如下图，界面右侧配上对应的交互说明(通常情况，交互原型应该以黑白灰颜色为主，不过因为我们的APP处于迭代优化的阶段，已经确定了视觉风格，而且某些状态需要用颜色来区分对错，所以会有一些配色。) 期间优化过这种方式，将大功能点拆分，按照以往设计Web 产品的方式来组织。对此开发同事仍然觉得不够好，所以有了后面ppt/keynote演示文稿的方式。 方式4：一页介绍一个子任务，每页最多4个界面，输出PDF格式(App 产品) 工具: Axure 画原型，Keynote 写交互说明 为什么采用这种方式呢?源于开发同事看到产品老大介绍需求用的幻灯片，觉得一张图配一个表格的方式很清晰，强烈建议用这种方式来写交互文档。 我觉得用幻灯片输出PDF 的方式确实可取，易于浏览。不过一页一个图太零散，界面之间、界面内容的不同状态关键性很强，放在一起介绍更直观。 于是，我想到了以前 yoyo 在腾讯CDC 官方博客上分享的交互文档撰写方式：《如何制作实用美观的设计文档》 。以前尝试过用他推荐的indesign写文档，但对这个工具不那么习惯以至于效率并不高，尝试过写完一个产品的交互文档之后就没再用了。不过 yoyo 推荐的将大故事拆分为一个个小故事来写交互说明的方法让我记忆犹新。 就这样，尝试了这种新的搭配方式，Axure 画原型，Keynote 写交互说明。 Keynote缩略图预览如下图，为每个功能模块建立一个任务/子任务的目录结构，按照划分的结构依次介绍各个子任务。每个页面最多介绍四个界面，页面底部作为固定的区域用来写交互说明。 测试、开发同事反馈这种方式不错，一方面是因为每页文档的结构大小一致，滑动浏览的体验也更好另一方面是因为他们写代码也是按照这样的方式一个小模块一种场景依次往下走，更容易专注看当前写的这个模块的交互说明。 虽然有同事的肯定，但这种方式还有优化的空间。因为采用了两个工具，一个画原型一个写文档，如果Axure原型有改动，需要复制到keynote，两处都要更新显然影响效率。所以我还在考虑是否切换到某一个工具搞定这两件事，比如用sketch 。除此之外，文档模板也可以改进优化。 就像前面说的，交互说明文档，就像是交互设计师输出的产品，既要根据场景的变化不断调整，又要听取用户的意见，持续优化提升体验。

相信大家对PS这款软件都比较熟悉了，本片文章主要是针对PS cc 2015新建文档功能的详细介绍，可能会分几个篇来完成。

1.新建文档

点击菜单栏的文件->新建，可以弹出新建文档窗口。

2.新建文档弹出

弹窗主要由名称、文档类型、图像宽度、图像高度、分辨率、颜色模式、背景内容、颜色配置文件、像素长宽比等选项构成。

3.名称

顾名思义就是这个文档的名字，建议大家在新建PSD文档的时候一定要填写一个规范的名称，比如"港囧_海报","星际争霸_壁纸"通过一定的命名规范来管理文档，方便自己日后使用和查找。这是一个管理设计资源的习惯问题。

4. 文档类型

文档类型是ps内置的一些规范的设计文档。用户可以通过这个功能快速的创建符合规范的文档，比如A4大小的纸张，iphone 6的基础画板都可以通过对文档类型的选择快速创建文档。文档类型下面的所有文档属性都会根据你选择的文档类型进行变化。

注意：不同版本的PS会有不同的文档类型，一般最新版本的文档类型一定是最全的。本文是根据photoshop cc 2015写的。

（1）剪贴板

我们用QQ截图功能截图的时候，截图的图片会存放到windows的剪贴板上，当我们在QQ聊天的对话框使用粘贴功能的时候，截图就会粘贴出来。

PS的剪贴板文档类型，就是利用windows剪贴板里的图片内容进行新建文档，通过剪贴板新建的文档，宽度，高度，分辨率等其他属性都会和剪贴板里的图片属性是一样的。

（2）默认 photoshop 大小

这不是经常使用的文档类型，这个文档类型是个PSD文档的示例。默认photoshop大小的，高度，宽度会受到不同版本的影响。比如英语版和中文版可能就会不一样。至于PS这个默认的文档类型的大小的由来还得大家自己去挖掘一下了。

不管是那个photoshop版本默认photoshop大小尽管宽度和高度的单位可能不一样，但是一定都是1.33:1的比例。据说是最初的mac

就是图中的这台电脑的尺寸比例就是1.33:1所以photoshop就从那个时候起一直到现在沿袭了这个比例将其应用到“默认photoshop大小”当中。

（3）美国标准纸张

如果将文档类型指定为美国标准纸张，那么在下面的大小属性里就可以直接选择美国三种标准纸张的样式了。方便快速创建文档。

（4）国际标准纸张

和美国标准纸张差不多，在大小属性里可以选择国际通用的标准纸张大小，可以通过国际标准纸张类型直接创建自己需要的标准纸张的文档。

（5）照片

照片文档类型和纸张文档类型差不多，你可以通过大小属性快速创建你想要的照片尺寸。

（6）Web

web是面向网页设计师使用的文档类型，在ps cc 2015当中web这个文档类型和之前的ps版本都有很大的区别。因为ps cc 2015支持了画板功能，所以我们选择web文档类型的时候，下面的属性会变成画板大小，这意味着我们创建的文档不再传统的PS文档类型，而是PS的画板文档。在画板大小属性里会有一些常用的web设计使用的文档，方便快速创建，也省去了自己去搜索响应尺寸大小的麻烦。

（7）移动应用程序设计

在PS cc 2015版本当中，PS为了使用UI设计的需求，添加了画板功能，移动应用程序设计文档类型和Web文档类型差不过，通过这个文档类型我们可以快速创建符合需要的手表、手机、平板、超极本等PS文档。

（8）胶片和视频

使用AE和PS的同学可能会应用到这个文档类型，当你用AE创建一个PAL D1/DV的文档类型以后，可以用PS创建一个一样PAL D1/DV的文档样式，然后自己就不用去考虑 PAL D1/DV视频制式的尺寸大小问题了。

（9）图解

图解这个文档类型是给用户提供快速创建小图标等小图标组件的文档类型，它会创建画板PS文档。

（10）画板

当然你也可以单纯的选择画板，这样在画板大小属性里就可以选择所有支持画板的文档样式。

（11）自定

我们也可以创建一个自定义的文档类型，属性可以完全自定义，并且你在设置好属性，点击确定之前；我们可以点击存储预设按钮将你设置的文档属性存储成一个固定的文档类型。比如你创建一个名片样式的文档，存储这个预设属性，下次我们再设计名片的时候就可以直接选择这个预设的文档类型进行创建。

（12）其他

如果我们已经新建了一个文档，新建文档处于打开状态，当我们再一次新建“未标题-2”文档的时候就可以根据之前创建的“未标题-1”的尺寸来创建。

未完待续……