2022-9-2 博博
大部分的设计师应该都没有见过所谓的“交互设计文档”吧？在实际工作中，所谓的交互设计文档是由交互设计师所输出的，但是大部分的互联网公司是没有交互设计师的。交互设计师的工作内容被UI设计师与产品经理相互分摊。那公司为什么不招聘一个交互设计师岗位呢？（boss：呵呵～一个人能完成的任务为什么要两个人！）
所以本篇文章为了让我们设计师能够很好的了解什么是交互说明文档？它是干嘛的？有什么用？如果制作？有哪些内容等多方面全面了解。（哪里有了解的不到位错误的地方，也希望各位大神多多指点相互学习。让我卷～）
交互文档，即交互设计说明文档（英文名“Design Requirement Document”）。又称“DRD文档”。用来承载交互说明、交互原型、项目背景等内容，存档并交互项目相关伙伴的团队协作文档。
也许你想到：什么？交互文档（DRD）我压根没见过，这难道不是口头说说就行嘛？无需交互设计师。（大部分公司的交互文档是由UI设计师/产品经理来撰写）但是有的公司产品也分担着UI设计师的工作.......只要你如果优秀干啥都行，不优秀话语权都没有。（比如我们这些“小美工”。职位只是对一个工作的划分不代表对你能力的划分，只是公司的一种小手段～
回归正题，作为交互设计师，工作职责起到“对接上下游，承上启下”的作用，不论是在方案评审的讲解，还是日常的工作沟通，都应具备优秀的沟通能力、语言表达和DRD表达能力。而DRD不仅能完美的诠释出产品的内容和需求，还能够为产品出一套完整的设计规范，让产品保持一致性，方便团队协作减少沟通成本，也方便后期的修改。
DRD是利于团队协作的媒介，也是产品规范与项目总结的重要输出文档。
交互文档撰写并不是只有给自己看，最重要的是给：产品经理、UI设计师、开发（最需要）等等。并且作为交互设计师的输出物，交互文档是联系开发流程上下游的重要文件，它需要具备良好的可读性、唯一性和时效性。
首先不同公司，不同团队产品经理与UI/UX设计师之间的配合输出物是不固定的。
1. 大部分公司，产品经理细心点会连交互说明和原型一起出了（包含在PRD文档里），但是大部分会出现体验层的漏洞。
2. 如果公司产品是负责传一句话，有交互设计师的情况下，交互需要从功能规划、信息架构、原型说明一起搞了。
3. 还有在小公司比较罕见的流程就是产品搞PRD，交互搞交互文档，彼此之间的逻辑可以互相印证。
作为交互设计师的下游，我们也需要较早的介入需求沟通之中，提早避免后期可能存在的问题出现。
（但是很多时候交互设计师就是我们自己）
开发是最需要看交互文档的重要成员之一，因为他决定着产品的逻辑以及页面的跳转流程、交互方式、动效方式等等。（不过大多数公司只有简单的PRD文档，开发也只是简单看看～）
你习惯用什么工具撰写交互文档？PPT、Sketch、AI、Axure … ？
你习惯用什么格式输出你的交互文档呢？PPT、PDF、HTML …？
其实使用什么工具都无所谓，只要能够正确的描述出交互文档所需要表达的内容和逻辑就行。（就是谁都看得懂）
我比较喜欢使用Axure软件撰写交互设计文档，大家可以根据自身爱好或者公司规定进行选择（例如sketch、figma、PS等等..都是可以的。
说了这么多，究竟交互文档包含哪些内容呢？
一般来说，一份最基本的DRD文档需要包含：DRD封面、更新日志、文档图例、产品背景、页面交互、业务流程图、交互原型、回收站等模块。
DRD封面：包括产品/项目名称、版本编号、撰写时间、撰写人等基本信息。按需可增加参与该项目的各方负责人。（如：产品经理，交互设计师，视觉设计师，开发，测试，团队名称等）
更新日志，包含具体新增或修改的内容，修改人，修改日期等信息。在实际工作中，方案的修改和优化是不可避免的。更新日志方便项目成员一目了然关注到重点更新的内容，也方便开发找到对应的负责人进行沟通，提升工作效率。
针对你在该文档所用到的图例进行说明，辅助阅读（如：操作/跳转图例、标签图例、流程图例以及手势操作图例。）。特别适合刚入团队，首次阅读你DRD文档的人来讲，是非常有利于团队成员对你文档的理解。
可包括一些项目背景、需求分析、用户调研、竞品分析等。用于设计思路的整理和记录，方便阅读，方便参与评审会的人理解整个项目背景下的设计思路，也方便日后总结与沟通。但无需将所有的分析内容都放入，结构化整理重点内容放入即可。
业务流程图的目的就是梳理并分析优化业务流程。我知道很多同学做UI设计师的时候可以完全不管业务，直接做设计，但是作为交互设计师了解产品业务是非常重要的，因为不了解业务你就无法完成交互设计，优化业务场景。
举个例子：在教育考试系统中一般流程是：教育局出通知→学生报名考试→老师审核→报名通过→老师编排学生考试名单→学生开始考试对号入座→教育局公布成绩→学生查询成绩→考试结束，看这一些列的流程，因为关联特别多，如果对业务不熟悉的话设计起来会非常的不便，如果前期因为业务流程不熟悉而设计出错误的交互稿的话，后面就会特别麻烦。
一听： 先听客户/产品介绍。以最简单的方式了解产品重点，即基本要素中的角色、活动、协作关系梳理出即可。
二沟通： 完成上一步后，就可以进行提问了。主要是沿着流程进行发问，重点放在分支、产物关系上。看看是否存在分支的情况，各协作之间是否有交付物。
三确认： 最后一步就是自己讲一遍流程，和客户代表或者业务产品进行确认是否有理解偏差的地方。
以医院APP取号业务为例
页面交互是交互文档的主要内容可以详细说明界面中元素的来源，控件的交互方式，数据的样式，字段的长度规定，页面元素的状态变化等。每个交互页面的内容应该包括：文档页面标题、界面标题、界面、设计说明。
文档页面标题：一般在每一页文档的顶部。写明当页内容是属于哪个模块或流程的，让看的人不容易迷失；
界面标题：注意命名，方便交互稿中的互相联系，如“跳转【XX页面】”，“回到【XX界面】状态”；
界面：界面尺寸建议按实际界面的比例缩小，避免你想当然的设计并不符合规范，也避免一个界面太大影响阅读效果；
设计说明：逻辑关系、操作流程或反馈、元素状态、字符限制、异常/特殊状态 等等，都可以放在设计说明中；
