编者按:交互设计文档一般指交互设计描述文档，也称DRD，在工作中一般称为“交互设计文档”。产品经理也需要学会写交互设计文档。那么，一份专业的交互设计文档应该怎么写呢？

交互设计文档，又称DRD(Design Requirement Document)，是交互设计师在将抽象的产品需求转化为具体的线框呈现的过程中，日常工作输出的最终产品，用来告诉别人“页面设计细节”。

一般来说，交互设计或者UX(体验设计师)写交互文档，或者产品经理写交互文档。不同类型或规模的产品团队在编写文档时可能有不同的角色。

一、为什么要写交互文档？

个人觉得可以帮你理清思路，记录下来，方便项目总结和沉淀。

就工作而言，文档的作用降低了项目中的沟通成本和风险、反馈和迭代。文档很好的解决了记忆、误解、历史记录的问题，所以最好把所有细节都记录在文档中，文档是以文档为基础的。

就团队而言，沉淀下来的历史交互文档可以在内部共享，互相交流学习。团队中统一的交互式文档规范可以为团队的所有角色提供一致的文档体验，降低学习成本。

二、交互文档的输出内容是什么？

以上有点过了。还是尽量实际一点吧。这是我的交互文档目录(DRD)，包含7个内容:文档封面、更新日志、设计流程(需求分析、信息架构、业务流程需求列表)、全局描述、非功能性需求描述和交互规范描述。废纸篓。

当然，这个交互设计文档模板不是静态的。设计师要根据自己产品的需求和内部设计团队的实际情况灵活运用，不要让模板限制了自己的想象力。

1.文件封面

就像一本书的封面，介绍什么书？出版商和作者是谁？主要描述书籍的基本信息。交互文档的封面也是如此，通常包括，Logo，版本号，时间，团队名称或者产品名称，对接交互人员。

2.更新日志

在实际的项目中，要对产品进行迭代，我们会明确写下一次迭代的版本、时间、负责人、内容，便于以后责任的落实和可追溯性。

3.需求分析

在呈现交互方案之前，先把方案的背景和具体设计内容解释清楚；产品的目标是什么？通过需求分析模块让团队成员了解这个交互设计的一些基本信息。

在需求分析过程中，可以根据实际项目的需要放置一些关于设计推导过程和灵感来源的文档。比如一些分析流程，比如调研报告、用户画像、竞争产品分析报告、用户体验图等，可以让交互文档更有说服力，团队的各个角色在理解后可以更好的推动计划。

4.产品结构/信息结构

这两个产品应该是产品经理在设计初期画出来的。理解他们就好。他们从两个不同的维度梳理产品。

产品结构图的作用是整理产品功能点，一个产品有多少个功能模块。列出每个功能模块下的每个页面，但不需要列出页面的内容。

信息结构图的作用是对特定页面显示的信息进行整理。列出产品的所有数据元素，只需要列出活数据，不需要列出固定在页面上的信息数据。

ui�����ѵ����ui�����ѵ����

5.业务流程图/功能流程图

业务流程图，用于说明整个业务逻辑流程；功能流程图用于确定产品功能设计逻辑。

6.需求列表

用于整理这次需要做的需求并描述，做哪个端口的哪个页面，完成后可能存在的相关影响。

7.全球通用描述

交互设计人员在输出交互文档的过程中，或多或少会有一些常见的页面、组件或描述。如果每次都在原型上显示这些组件，不仅会给交互文档带来冗余，还会增加交互和视觉的工作量以及理解的成本。所以我就把一些产品常见的常用控件放在这个目录下。

1)界面重用

顾名思义，它是一些全局可重用的内部页面，如共享页面、默认页面、搜索页面、相册等。

2)通用组件/控件的重用

常用控件如按钮、列表框、导航栏、标签栏、部分网络异常界面、空白页、对话框文案规范、加载方式等。

3)单位

规范产品涉及的所有单位，如里程用“公里”，时间用“2021年1月14日”或“2021年1月14日”，金额用“元”或“￥”等。以时间单位为例:

4)字符控制

每一项都不一样，要限制的人物名字也不一样，看实际情况。

8.非功能性需求

简而言之，为了满足用户和业务的需求而需要考虑的需求称为非功能性需求，可能偏向于一些特定的技术需求，比如前期与开发学生沟通清楚，后期避免互相扯皮，比如性能、安全等。

1)安全相关

身份校验和权限:是否确认操作员的身份，从而确定用户对某一资源是否有访问和使用权限。

文件加密:是否进行读写控制、打印控制、剪贴板控制、拖放、屏幕复制/截图控制、内存窃取控制等技术，防止机密数据泄露。

表单验证:是否要考虑表单验证？一般后端一定要验证安全性，前端验证可以改善用户体验(及时反馈状态)，减少无意义的请求，可以选择性验证。

反攻击策略:考虑恶意操作是否需要IP限制、高频访问限制等。

2)性能相关

响应时间是系统最重要的性能指标，它直观地反映了系统的速度。对响应时间有要求吗？响应时间过长怎么办？

并发性:单位时间内成功传输的数据数量。这个块与系统并发性有关。根据业务量估算，我们的系统需要支持多少并发，并确定支持项目所需的服务器配置。

吞吐量:吞吐量是指系统在单位时间内可以处理的请求数量，它反映了系统处理请求的能力。是目前最常用的性能测试指标。

3)用户体验相关

数据加载:进入新页面时，如何加载数据，以什么风格提示用户页面正在加载，是否需要异步加载来提高用户体验等等。

对话框和吐司:各种临时盒子和吐司的样式，文案的规格等。

统一组件:此时系统功能模块化，支持灵活配置，有利于减少重复开发量。

网络异常处理:网络异常情况下的交互设计、网络切换(从WiFi状态到蜂窝状态)、网络中断等。

4)其他

兼容性:产品在不同系统/终端之间不协调、不和谐的意思。

升级策略；强行升级时如何处理产品？产品没有强制升级怎么处理？什么是升级框架和副本？是否在URL中保留版本号。

国际化:考虑产品是否需要支持国际化。比如在不同的语言环境下，开发时需要把所有的产品界面和提示文案都写在一个配置文件中。根据当前运行的系统语言环境，会自动识别判断应该加载哪个文案配置文件来显示界面文案。

用户行为分析埋点:需要做埋点吗？公司是在后台做统计还是借助第三方数据统计平台？

9.页面交互流程图

1)如何组织交互式草稿结构

交互稿的结构取决于产品架构图，很容易找到每个页面的功能级别。树形结构可以从【平台-功能-页面-子页面-子页面分支】维度构建。结构构建完成后，剩下的就是文档的命名了。

2)每页互动稿内容

一般来说，交互页面顾名思义就是页面内容和交互描述，那么为了让交互页面清晰，应该包含哪些内容呢？

页面标题：告诉别人这个页面是什么？导航栏标题，让页面标题常驻；界面标题：方便交互稿中的互相索引，比如“回到界面B状态”；界面内容：建议尺寸为375*812px，内容黑白灰稿为主，要便于阅读；设计说明：逻辑关系、元素状态、小微流程，都可放在设计说明中；流程线：说明界面间逻辑关系，可使用软件自带流程线；链接：指向其他页面，比如支线流程，开发同学阅读起来会很方便。

3)互动描述说了什么？

接下来，我们将开始交互式文档的最关键部分。交互指令怎么写？

记得刚开始写交互指令的时候不知道写什么。写完之后总觉得哪里不对劲，但就是找不出问题出在哪里。我能怎么做呢？很是绝望！后来我问同事怎么写交互指令才不会被杀。然后他直接给我发了一张互动说明的自查表，在这里做了一些安排，供参考。

另外，我们的互动讲解要尽量写的详细一些，这样最终的验收效果会更好。

4)互动说明中没有写的内容

商业逻辑相关：不写为什么要实现这个功能，解决了什么问题等一些在交互说明里与产品实现无关的内容，这是需求分析阶段该做的；视觉规范相关：不写视觉规范规格标注，各司其职专心做自己的事情，术业有专攻；研发代码相关：不写功能代码实现逻辑和规则等。

10.废纸篓

废纸篓被称为互动文档的“后悔药”。你永远不知道互动稿中哪个稿是改了很多的最终稿，所以请把你弃稿放在这里！万一老板很喜欢初稿& # 8230；

三、总结一下，写文档需要注意什么

文档规范化：交互稿目录命名规范、页面布局规范、交互说明的精简、使用黑白灰稿，这对于提高交互文档的易读性至关重要；数据真实化：页面的展示元素要还原真实的场景，有代入感才能发现交互文档中更微妙的细节；任务流程化：一个页面一个任务，一个任务从开始到结束要逻辑清晰、有闭环；交互组件化：建立起自己的交互组件库，组件不在多在于精，要持续更新；方案明确化：很忌讳临时更改交互文档或文档中的说明含糊不清，如果不可避免也要及时通知相关人员。

四.附言

无论用什么形式或工具来写交互设计文档，只要能提高效率，降低沟通成本，设计方案是否满足用户需求，就能体现文档的价值。

另外，在交互文档中，并不是说交互稿因为好看所以专业，而是说文本信息的层次清晰易懂，更重要的是基于你输出背后的思考。

这些是边肖在实际工作中写的一些交互式文档的粗略总结。