交互设计文档一般指交互设计说档，又称DRD，工作中一般称之为“交互设计文档”。产品经理也需要学会撰写交互设计文档，那么，一份专业的交互设计文档应该如何撰写呢？
交互设计文档也称DRD(Design Requirement Document)，是交互设计师把抽象的产品需求为具象的线框图呈现的过程，在交互设计日常工作输出的最终产物，用来告诉别人「页面设计细节」的一个说档。
一般会是交互设计或UX（体验设计师）写交互文档，也可能会是产品经理写交互文档，不同类型或体量的产品团队写文档的角色可能会不一样。
工作而言，文档的作用降低项目里的沟通成本和风险、反馈和迭代。文档很好地解决了记不住、理解错误、历史记录的问题，所以呀还是要把所有细节记录在文档中比较好，这些都是要基于文档的。
团队而言，沉淀的历史交互文档可以内部共享，互相交流学习。团队中统一的交互文档规范能提供团队各角色一致的文档体验，段曦打谢娜降低学习成本。
扯了有点多了，来点实际的吧，这是我整理交互文档（DRD）的一个目录，包含7点内容：文档封面、更新日志、设计过程（需求分析、信息架构、业务流程需求列表）、全局说明、非功能需求说明、交互规范说明；废纸篓。
当然，这个交互设计文档模版不是一成不变的，设计师要根据自己产品的需求以及内部设计团队实际情况灵活运用，不要被模版了想象力。
就类似书籍的封面，介绍是什么书？出版社和作者是谁？主要是描述书籍的基础信息。交互文档的封面也同理，通常包括、Logo、版本号、时间、团队名称或产品名称、对接交互人员。
在实际项目中要对产品进行迭代，我们会把某次迭代的版本、时间、责任人、内容都写清楚，方便落实责任，也方便以后追溯。
在呈现交互方案前，交代清楚方案背景、具体的设计内容；产品的目标是什么，让团队通过需求分析模块了解这次交互设计的一些基本情况。
需求分析时，可以根据实际项目的需要，放置一些关于设计推导过程、灵感来源的文档。比如用研报告、用户画像、竞品分析报告、用户体验地图等一些分析过程，可以让交互文档也更有力，团队各角色理解后才能更好地推进方案。
产品结构图作用是梳理产品功能点，梳理了产品有多少个功能模块。罗列出来各个功能模块下的各个页面，但不需要罗列页面中的内容。
信息结构图作用是梳理具体页面显示信息。罗列产品各个数据元素罗列出来，只需要罗列活的数据，固定在页面里的信息数据不需要罗列。
交互设计师在输出交互文档的过程中，或多或少会存在的一些通用页面、组件或说明等。如果每次都将这些组件在原型展示出来，不仅给交互文档带来冗余，还会增加交互和视觉的工作量以及理解的成本，因此对于一些产品的通用公共控件我都会放在这个目录下。
常用的控件比如按钮、列表框、栏、标签栏以及一些网络异常界面、空白页、对话框的文案规范说明、加载方式等。
规范产品中涉及到的所有单位，例如里程用“公里”，时间用“2021年01月14日或2021-01-14”的形式，金额用“元”或“￥”等等。以时间单位为例：
简而言之就是，为了满足用户、业务需求开发需要考虑的需求称为非功能性需求，这个可能会偏向技术一些具体需要前期和开发同学沟通清楚，避免后期互相扯皮，如：性能、安全等。
文档加密：是否对文档进行读写控制、打印控制、剪切板控制、拖拽、拷屏/截屏控制、和内存窃取控制等技术，防止泄漏机密数据。
表单验证：是否要考虑表单验证呢？一般后端为了安全性必须校验，前端验证可以提升用户体验（及时反馈状态），减少无意义的请求，可以选择性验证。
响应时间：是系统最重要的性能指标，直观的反映了系统的快慢。是否对响应时间有要求，响应时间太长怎么办呢？
并发量：单位时间内成功地传送数据的数量。这一块与系统并发相关，根据业务量估计，我们的系统需要支持多少并发，确定支撑项目所需要的服务器配置。
吞吐量：吞吐量是指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。
数据加载：进入新页面的时候，数据如何加载，用什么样式提示用户页面正在加载，需不需要异步加载来提高用户体验等等。
网络异常处理：网络异常时、网络切换时（从WiFi状态到蜂窝状态）、网络中断等情况下的交互设计。
升级策略；强制升级时产品怎么处理？非强制升级时产品怎么处理？升级的弹框和文案是怎样的？是否在URL中预留版本号。
国际化：考虑产品是否需要支持国际化，比如不同语言中，是否需要在开发时将产品界面中和提示文案全部写在一个配置文件中，根据当前运行的系统语言，会自动识别和判断应该加载那个文案配置文件来显示界面文案。
交互稿的结构依赖于产品架构图，把各个页面的功能层级表现出来很容易地找到就行，可以从【平台-功能-页面-子页面-子页面分支】这个维度去搭建树形结构，结构搭好完后剩下的就是对文档的命名了。
一般而言，交互页面顾名思义就是页面内容、交互说明，那么具体要包含哪些内容才能把交互页面说清楚呢？
记得刚开始写交互说明的时候不知道要写些什么，写完之后总感觉哪里不对劲，却又发现不了问题在哪里，能咋办呢？就是很呀！后面就请教同事要怎么写交互说明才不会被怼呢，然后他就直接发给我的一份交互说明自查表，这里也做了一些整理供参考。
·商业逻辑相关：不写为什么要实现这个功能，解决了什么问题等一些在交互说明里与产品实现无关的内容，这是需求分析阶段该做的；
废纸篓，被称为是交互文档的“后悔药”。在改了很多稿的交互稿中你永远不知道哪一稿才是最终稿，所以，请把你遗弃的稿子放这里！万一老大很喜欢第一稿呢…
·文档规范化：交互稿目录命名规范、页面布局规范、交互说明的精简、使用黑白灰稿，这对于提高交互文档的易读性至关重要；
·方案明确化：很忌讳临时更改交互文档或文档中的说明含糊不清，如果不可避免也要及时通知相关人员。
不管用什么形式或工具撰写交互设计文档，只要能提高效率、降低沟通成本、设计方案是否满足用户需求就能体现文档的价值了。
另外，在交互文档中并不是说交互稿画的多美观就很专业，说字信息的层级清晰能看懂就行，更重要的是基于你输出内容的背后思考。