交互文档该怎么写？这个问题不光是新手会问，工作中负责交互问题的产品经理、设计师也会问。本文将从基础了解、工具选择、制作流程三个方面讲解如何写交互文档。快来看看吧。

今天想分享的是后端和社区里几乎每天都会被问到的交互文档怎么写的问题，不仅是想发展成为交互设计师的菜鸟，就连工作中负责交互问题的产品经理、设计师，对此都有大量的疑问。

所以我们在今天的分享里就完成一次深度的扫盲活动。

一、交互式文档的基本认识 1、什么是交互式文档？

交互文档是用来说明项目的交互方式、内容、规则的文档，也叫DRD（）。

我们在以往的分享中讲过，B端项目会包含很多交互内容，需要在前期绘制交互原型，对交互方案进行论证和确认。

如果是比较简单的小项目，或者成熟产品的小迭代，那么这样的连线图确实足以表达交互的意图和计划，写太多的注释文字则会显得多余，增加观看者的认知成本。

但如果项目和演示的过程内容非常复杂和有逻辑性，包含很多的选项和状态，那么光有原型和连线肯定是不够的，加入更多的图形描述就变得非常必要。

同时在团队协作场景中，需要将这些内容制作成标准化的“文档”，进行统一的展示、备份和归档。

所以做交互光画一个交互原型是远远不够的，“文档”成为必要的输出。

2. 它与产品文档的区别

在产品方面（非开发），有几类文档：

BRD、MRD是产品经理行业里反复讨论的东西，跟我们关系不大，可以先忽略，大家应该都有设计规范文档DGD的概念，比较容易识别，这里就不强调了。

产品需求文档（PRD）是与交互文档最为相似的文档类型，它们的文档规范、风格几乎一致，也包含了很多界限模糊、相互重叠的内容类别，会给新手的理解带来极大的不便。

要理解产品文档和交互文档的核心区别，我们必须从它们各自的工作职能开始。产品经理的主要输出是解释产品的功能和逻辑。所有原型和连接的目标都是解释功能本身。

有些产品经理会“顺便”在此基础上加入交互元素和相关说明。这正是问题的关键，因为产品经理在制作产品原型的过程中可以涵盖一些交互信息，所以很多设计师天真地认为，交互内容应该由产品来生产。

这里面一定要注意“事件”，因为一份有效的 PRD 的主题肯定不是围绕交互展开的。面对需要大量图表、连线、解决方案、解释的交互问题，产品经理往往会选择直接跳过去，只把功能描述清楚，剩下的交给交互设计师或者 UI 设计师去完成具体的交互解决方案。

因此交互文档在产品文档的基础上补充了交互内容，重点讲解了项目的交互内容，以便设计师和前端开发人员能够更直观的了解后续的工作内容。

付费文件来自，案件地址：

交互文档与产品文档相互独立又相互补充，当产品文档无法有效说明产品交互时，应选择输出独立的交互文档，提高项目协作的效率。

二、交互式文档工具选型 1、主流交互式文档工具描述

目前主流的交互式文档输出方式有三种：

/ 导出一般文档以创建在线 Wiki 记录

是一款用于制作产品原型的软件工具，也是产品经理和交互设计行业使用最广泛的原型设计工具。

它的主要优点是相对容易创建交互式组件、连接和导出。

当然，仅仅制作原型还不能称之为交互文档，它们还提供了相对完善的内容注释、文字录制、图形绘制功能。

这样我们就可以完成原型，并将其与页面结构的管理结合起来，添加交互式文档所需的其他信息，并最终输出文件。

在一些比较传统的行业或者外包领域，使用的记录文档往往是Word或者PPT（用于会议演示或者打印），这就需要在原型完成后导出原型图例，并利用这些文档软件进行文字记录和衔接。

由于Word、PPT的版式限制（强制分页），用它们制作交互文档非常不爽，而且这些文档需要保存在本地，这就引发了各种文档版本管理问题。

因此还有一部分团队也希望使用常见的文档格式来记录和满足云端同步、备份、版本管理的需求，并会利用类似 Wiki 的工具来打造交互文档，比如语雀、飞书等工具。

如果只是一些相对较小的项目迭代，一次性的交互文档，可以采用前两种方式。但真正大规模、系统的交互文档往往使用团队内部的 Wiki 进行创建和管理。与设计稿不同，这些使用内部账号或者需要内网访问的文档并不会发布到网上进行分享，这也是完整的交互文档在网上找不到的主要原因。

2. 针对B端设计师的交互文档工具建议

与网上能找到的大多数交互式设计资料不同，我不建议你使用 来绘制原型，也不建议使用它们或普通文档或 Wiki 来输出交互式文档。因为：

——效率太低了！

产品经理和交互设计师的主要产出就是文档，自然可以投入更多的精力和时间去制作原型和撰写内容。而UI设计师的主要工作肯定是最终的视觉界面和交付，所以用最复杂的方法制作交互文档显然是不合理的。

同时需要提到的是，使用/等软件制作通用的线框原型效率太低，大多数情况下页面跳转和交互都可以忽略，而且随着页面数量的增加，左侧导航层级会非常多，这会进一步降低搜索和浏览的效率。

我始终建议使用您正在使用的云 UI 设计软件直接绘制产品、交互式原型和输出文档，例如实时设计或。原因包括：

比如像下面这样的原型案例，可以通过简单的链接快速分享，或者添加团队成员自由查看。

在我长期的实践经验中，这种方式优势最明显，效率最高，最容易理解，也满足UI设计师的需求。如果项目还有其他因素，也可以选择前面的方式来输出。

任何文档的目标都是为了留下文字记录，让读者更容易理解我们想要表达的信息。不要被固定的方法所限制，而要努力探索适合团队当前场景的方法。

三、交互文档的制作流程 1、文档框架结构制定

了解完基本的知识点，下面我们来具体说一下如何输出交互式文档。

当然，在输出交互文档之前，你需要明白什么是交互，交互设计的具体设计内容和步骤。交互文档是对你设计的解决方案的书面记录。你不能在对交互一无所知的情况下强迫自己写文档。

交互式文档的制作首先要确定文档的记录内容和文档结构。

记录内容是指你计划把什么交互内容放到文档里，并不代表你每次设计项目的时候都要把项目所有的页面、流程交互都重做一遍。

例如，在一个中等规模的迭代中，增加了几个公共列表页，调整了一些明细字段，增加了一个功能流程，那么文档就应该以记录流程为主，而不是记录所有页面，毕竟公共列表页和明细变更可以在产品需求评审阶段得到充分说明，而功能流程则不能。

如果是一个全新的项目，包含几十甚至上百页，将所有页面的流程和交互内容展示出来，工作量是难以承受的。在画原型的过程中，会发现大量重复的页面、流程和交互，所以在做文档的时候，需要有目的地合并重复的内容，只保留重要的页面和流程。

文档里应该放什么，需要结合项目的实际情况来考虑，需要设计师去评估。另外，标准的交互文档会包含背景介绍、编辑日志、文字图例、业务流程、词汇表、页面结构等。

这些“文案”细节并不是必须的，你可以根据现在的场景来决定需要添加哪些。比如，如果项目的产品需求和业务背景已经讲清楚，业务流程和术语解释团队成员也都理解得很好，那么这些页面模块就完全没有必要了。

另外，基于前面对内容放置的考虑，结构的顺序不一定要类似下面的例子，完全遵循产品导航目录。

因此，基于一个中型迭代项目，我将开发如下第一级文档结构：

每一个一级文档结构都对应着UI软件中的Page目录，力求要求尽可能少的Page，而不是像.

结构还可以按照复杂程度进一步细分，就像写一篇文章的提纲一样，帮助我们提前规划完成这篇文档所需要的内容和工作量。

2. 关于连接和注释信息

有了结构，就需要在对应的Page中填写内容了。一般的文字介绍、流程图、思维导图，可以正常输入或者将导出的图表粘贴进去。

至于具体的交互内容和流程讲解，则重点在于衔接和注释，例如下面是我课程演示中一个简单的交互流程演示案例。

在UI软件中，做连接其实是一件很简单的事情，只需要画一条直线，然后设置箭头和尾部的图形、描边颜色和粗细就可以了。

然后将线段图层放在画布外，起点放在触发交互的区域，终点靠近目标画布边缘（不需要延伸到画布里面）。如果使用水平或者垂直的方式连接两个画布，可以双击添加锚点，形成90度角。

连接的应用是一个非常简单的操作。不要太过分地通过插件或其他功能来实现。此外，我在文档中添加的说明文字主要有两类：交互事件和交互规则。

交互事件代表着如何触发两个相连的页面进行跳转，所以我会在线段里贴一张文字卡片来解释触发条件以及交互操作是什么。

然后就是页面或者流程里的交互细节，包括数字标签和对应的文字备注两部分，都是使用 Auto 可以快速创建的组件，每次要做备注的时候，只要把标签复制到页面里，设置好对应的值，再把右边的文字卡片复制到页面边上，添加对应的编号和内容信息就可以了。

在设计软件中，画布的自由度很高，你想怎么记笔记、怎么添加内容都可以，只要内容详细，团队成员看得懂，就是一份优秀的交互文档。在画图过程中多和同事沟通，优化展示方式，可以避免很多问题，进一步加速我们的生产效率。

3.基于文档的团队协作应用程序

所有文件完成后，最终就到了交付和协作阶段。

由于我们是通过在线UI软件完成交互文档的制作，所以最简单的方法就是给文件设置公开访问权限，然后分享链接。

但每个项目都分享一个网址，或者同时有多个项目，需要其他成员自己去收藏网址，就比较麻烦了。所以尽量利用软件中的团队协作功能，创建一个团队，添加成员，让他们自己查看当前文件目录中的交互文档。

在评审过程中，其他团队成员可以通过评论功能对互动内容进行纠错、提问、建议等，方便我们进行优化改进。

通过这种简洁高效的文档协作模式，我们可以非常快速的敲定整体的交互内容并开展后续的工作。

回到之前的话题，我们是UI设计师，不是专职的交互设计师，原型文档输出之后，下一步就是做可视化界面，那么交互文档能不能不用呢？

交互文档最好的状态是应用最终的界面图例解释了交互内容。

也就是当我们完成了所有页面内容的设计之后，强烈建议将界面展现与交互文档整合起来，这样前端和产品除了能看到最终的交互落地效果（有时候最终的设计与之前的交互不一致）之外，还可以直接通过这个文档查看界面数值标注，而不用在交互和设计文档之间来回切换，这样更能发挥文档的作用。

四、结论