在我正式开始阅读之前，我必须告诉亲爱的读者，这篇文章是我开始工作以来的经验和我使用工具的经验的总结。并不意味着这就是交互文档的写作范式。互动文档可以根据自己公司和团队的需要来写。这里只分享我的经历。

Axure和蓝泻湖是我日常工作中最常用的两个软件，一个是生产力设计工具，一个是在线协作工具。和他们一起工作并不累。

一、前言

本文分为两个部分。第一部分是分享我在工作中如何使用Axure制作交互文档。第二部分是如何利用蓝泻湖与产品经理、视觉设计师、客户、运营商等人员进行合作。

本文基于个人有限的工作经验和知识积累。如有不足之处，请见谅。如有错误，请指出，互相学习，感谢阅读。

二、如何输出标准化的交互文档

1.区分产品需求层次，部分更新和正式产品

写文档的时候，你要知道这个需求是一个完整的项目，还是对现有项目的完善和优化。如果是新项目，需要在文档中描述产品介绍，用短句描述产品功能和目标用户。但是，如果是更新优化，只需要描述项目名称和更新后的函数的概要。

2.交互式文档的元素

(1)文档描述(版本描述，使用平台)

文档描述相当于文档的封面，文档描述中应简要介绍文档涉及的产品、平台、版本和参与者。

(2)更新日志

更新日志是文档不可缺少的一部分。它包含了一个项目从开发的第一个版本到最后一个版本的概要，方便我自己和其他协作者在文档中快速找到优化部分是什么时候被添加、删除或者优化的。我自己制作的更新日志页面包含以下基本元素:

时间:时间是指文档优化后上传到协作平台(如蓝泻湖)的时间，可以指定文档更改的具体时间。

更新内容:更新内容是指逐一列出文档变更的功能点，用文字做简单描述。更新内容是更新日志中非常重要的一个环节。如果没有文字上的描述，在查看文档版本的时候就无法快速的查看和浏览，对以后的维护来说就是一场灾难。

更新页面:更新页面是指将更新的内容对应到不同的交互页面，有助于开发者或其他小伙伴快速准确的找到更新的内容，开发者也没有时间一个一个的阅读大量的文档，所以版本更新只需要告诉他们发生了什么变化。

更新类型:有三种更新类型:添加/删除/优化。我给每个版本更新贴了不同的标签，可以更直观的说明当前版本更新的类型是新的还是优化的。

此外，您可以根据自己的需要添加修改器、版本号等元素。因为实际项目中只有我一个人维护文档，SaaS版本规划不清楚，这两点不涉及我的文档。

(3)阅读前的注意事项

阅读前的注意事项是指文档用户在阅读前应浏览的注释，否则无法理解文档中的一些特殊符号。阅读前有两种说明:

1)一般识别描述

通用标识描述是指广泛存在于整个文档中的标识元素，帮助读者快速理解文档的特殊标识和术语。

2)一般组件的描述

通用组件描述(General component description)是指在开发全新产品时建立的一套简化的设计规范，它规定了当前文档中某些组件的样式、交互和特殊情况。

(4)结构图、流程图和思维导图

1)结构图

一般在所有文档更新上传的时候，我都会用Axure的生成流程图的功能生成一个树状的结构图，点击结构图中的模块就可以轻松跳转到相应的页面。这样，在查看文档时，我就可以直接打开文档结构页面，而不用逐个浏览，整个文档的结构一目了然。点击模块可以直接跳转到对应的页面，方便快捷。

2)流程图

流程图是指与业务相关的流程图，用流程图描述业务逻辑。一般对于复杂的业务，会用它来整理逻辑。流程图不仅有利于构建一个完善的业务流程，也有利于开发整理业务的逻辑。

3)思维导图

思维导图是根据文档的需要，以思维导图的形式列出产品的功能。开发可以穷尽每个类别下的子级别，从而获得一个完整的结构。

以上三种图都是帮助文档用户和作者理解文档所必需的，所以他们可以根据业务需求绘制相关的图。Axure本身对流程图和思维导图没有很好的支持，你只需要在第三方软件完成图纸后复制到Axure界面即可。

(5)互动页面

交互页面是整个文档最重要的部分，也是整个文档的主体。每个行业每个产品的交互文档都不一样。“形而上的手段”，虽然不同，也可以概括一些一般的规范:

1)文档结构应清晰合理

交互文档层次划分清晰，页面按照产品的结构划分，以此区分主次页面。

2)用词准确，不含糊

首先，在描述文档的时候，文字一定要准确，不含糊。如果技术术语解释不清，可以后面举例。你的文档的目的是让读者理解，无论是开发还是产品。因此，请用通俗易懂的语言描述您的文档，并在适当的时候给出示例进行补充说明。

其次，你的文档对应的产品目标用户理解你的描述也很重要。比如后台产品，用户不一定是知识水平很高的人，如果你用& # 8221；门槛& # 8221；如果不解释技术术语，用户很难理解产品的功能。

3)工艺完善，无泄漏

一般来说，由于各种原因，交互文档的交付总是会有一些遗漏，要么是因为不熟悉业务而没有涉及到一些功能，要么是因为不了解技术而遗漏了一些特殊场景。这时候就需要通过互动的走查和复习来发现相关问题。走查是指编剧对照走查表梳理页面缝隙，复习是指从别人的角度发现问题。所以一个好的过程是不断迭代完善的。你需要做的是让交互文档尽可能完美无瑕。

4)记录模拟数据，尽可能恢复真实数据

在设计的时候，很多人会填写大量的模拟数据来支持页面的内容。sketch有很多自动填充的插件，比如头像、图片、文字、名字甚至地址等等。这样的插件方便了我们的工作，但是有时候文字的填充不适合我们的业务，甚至可能完全不相关。

但是Axure没有这样的插件，所以在设计的时候尽量还原真实场景，比如写真实的产品名称和地址。如果填写的是不合逻辑的文字，读者很难主观融入产品的使用场景。

当然，用不同的真实文本填充每一条数据会花费我们很多时间。也可以采取一些容易找到的方式，比如列表，第一行用的是真实文本，其余的可以从第一行复制。但是，如果涉及到不同的状态，应该加以区分和解释。

5)应注意极限情况和默认状态

很多新手可能经常会被问到“这个文本框最多能填多少个字符？”“，这是因为文件中没有说明极限值。除了指定“最大”情况外，还需要指定“最小”情况。

那么问题来了，如何判断用户应该输入的字符范围呢？首先这是由两个因素决定的。

第一个因素是一般业务场景中的输入字段是多少个字符，比如商品名称。我们可以查一下淘宝等平台的商品名称，然后根据业务限制字段。

第二个因素，即输入字段，显示在您的业务场景的哪个区域，以及该区域允许显示哪些字符。如果在前景列表页面中只为该字段保留了一行，您应该直观地判断要显示的字符的大致数量。如果只能显示一行，则需要设置截断规则，通常用“…”代替，点击详细页面时会显示所有字符。

类似的极限情况太多了，比如断网、进程中断、数量范围等。极限情况随着业务和场景的不同而不同，这里就不一一列举了。

另外要注意的是默认状态，就是默认状态。当我们设计界面时，我们设计的是一个充满内容的页面，而不是产品的初始状态。如果我们设计初始状态，我们的设计草稿将是空空白。所以我们在设计产品的时候，还需要整理页面的默认状态，比如个人中心没有订单的情况，后台商品列表没有商品的情况，查询是/[/k0

6)文档注释需要清晰明确

在交互文档中，除了交互页面的设计，最重要的是标注。除了直观的界面显示，很大一部分操作交互都是通过标注来说明的。在我的工作流程中，我将其分为四种类型:全局描述、标记行描述、局部描述和交互描述，分别是对整个页面的描述、带有可视化指导的描述、局部功能的提示描述和操作描述。它可以使开发人员快速准确地定位和理解注释内容。

7)从第三个角度看文档

把自己当成文档的用户，产品的用户，文档的审核者。从这个角度看，你会明白那些地方的语言不清晰，逻辑混乱。详尽地梳理页面的时候尽量不要偷懒，能想到的情况都一一说明。

(6)文件附件

交互文档的意义是通过可视化线框向相关人员展示产品需求，因此需要辅助文档来完善整个文档的功能。这些文档的附件包括但不限于导出的字段、上传的表格、产品需求表，以及其他软件制作的辅助文档，通常携带在Excel表格、Word文档、PDF文档、图片等文件中。

Axure没有直接上传其他文件类型(除了图片和文字)的功能，所以我们一般用云协作软件来上传，比如蓝泻湖的资源库功能。通常，您需要在文档中所需的页面上添加相关说明，表明相关文档附件的存在。

(7)回收站功能

回收站是指你做的组件和页面由于需求变化或其他原因无法使用，需要优化或完全删除，但不排除以后会改回来。您只需要将您的组件或页面放入回收站，并标记相应的名称(为了方便下一次查询)。如果以后需要，可以直接复制到对应的页面。

(8)交互式查找表

要构建交互式的上行表，您需要首先熟悉产品业务逻辑。走查表是基于产品功能的，每个产品的交互走查表是不一样的。其中平台差异比较大。比如移动app和web平台的差异导致页面实现逻辑不一致，那么容易漏掉的点也不一致。web端基于浏览器实现逻辑，而app则需要根据各个平台(iOS和Android)的不同构建不同的走查表
基本逻辑考察:

业务逻辑演练:

构建一个走查表是一个持续改进和迭代的过程。只要不偷懒，一般都会建立好的规避措施。

第三，其他问题

1.设计组件的安排和生产

在开始一个项目之前，如果是一个全新的项目，我建议你为这个项目建立一个构件库，这可能会花费你很多时间，但是你会在后续的设计中感受到它的便利。同时，建立了标准化的构件库后，不需要时不时的查看尺寸等细节，只需拖拽到界面的合适位置进行更改，既保持了整个文档的统一性，又提高了设计文档的质量

另外，如果你的产品有自己的设计体系，但不是做成组件的，我建议你做一套组件，引入到自己的Axure中，在后续的更新和维护上会给你带来很大的方便。

同时也可以使用第三方设计组件，比如蚂蚁金服推出的蚂蚁设计。

2.高保真和低生活水平该选哪个？

一些有视觉背景的交互设计师可能会纠结于交互文档是否应该和设计稿一样做，增加了很多交互操作和动态效果。关于应该选择哪一个，唯一的参考是您的交互式文档使用场景是什么，以及谁是目标用户。

如果你的使用场景是在公司开发使用的，目标用户是与你合作的前端开发者、产品、UI，那么你的文档是为了提高开发效率而存在的。这时候就不需要和视觉稿一样了。你只需要用黑白灰线框做产品原型。这样做有四个好处:

(1)设计效率极高，能快速完成产品的原型设计；

(2)修改方便。在原型阶段，交互稿的改动是非常频繁的，所以如果你做的和视觉稿一样，加上很多交互操作，改动会害死设计师；

(3)适合没有细节的开发和快速查看。当页面上UI元素较多时，会影响开发(后端)梳理逻辑，因为这些细节会误导他，更何况UI界面的元素是可变的，不确定的。开发只需要在一开始就梳理业务逻辑。至于UI，是视觉设计稿和前端的问题，交互阶段不存在这个问题；

(4) UI可以充分发挥其设计感，设计出更出彩的界面。作为交互设计师，我们只需要关注页面交互和业务逻辑，不需要在意元素圆角和阴影的大小。如果你的交互稿和UI视觉稿一样，会从主观上影响UI设计师的判断，甚至可能导致同事之间的冲突。

如果你的使用场景是项目演示，目标用户是没有软件开发知识的老板、甲方(客户)和测试用户，你需要根据自己的需要搭建一个可点击、可跳转的原型演示，在项目演示过程中可以用来向客户或老板演示操作，给他们一个直观、生动的印象。如果他们有最大的决策权，他们就有很大的机会通过这个计划。

所以高保真和低安全性的争论是没有必要的，选择哪一个完全取决于交互原型的使用场景和目标用户。个人不建议一般工作情况下把交互文档做成可视草稿！

四.Axure+蓝色泻湖创建产品开发协作工具

1.上传axure到蓝湖，建立一个好的文档

在蓝泻湖建立相应的项目，招募相关参与者，通过蓝泻湖软件将Axure文档直接上传到蓝泻湖平台，并通知所有参与者文档已经通过其他通讯软件上传。

2.将附件文档上传到资源库

如果您的交互式文档附有其他类型的文档，您可以将它们上传到资源库，并在交互式文档的相关页面上进行解释。

3.检查版本历史功能

在查看时，开发人员可以点击相关的版本历史进行比较，或者快速跳转到文档更改的页面。

4.交互式文档关联设计草稿

如果你的设计稿和交互文档页面使用同一个名字，蓝泻湖会自动将你的设计稿和交互稿关联起来，可以直接从交互稿跳转到对应的设计稿，非常方便前端开发。但是目前还没有手动关联的功能。在大多数情况下，自动关联不是很容易使用。只能说是比没有强的鸡肋功能。希望以后可以做手工联想。

5.团队成员合作、标记和通知

如果需要强调某个功能，可以直接给原型和@ participants添加评论。蓝泻湖的标注功能已经很好了，唯一的缺点是如果有改动，我无法在同一个软件中完成修改页面和修改描述的操作。所以如果在Axure中修改页面，然后蓝色泻湖中的标注描述对我来说效率太低，那么我的标注描述就在当前页面中完成，方便导出和使用。

6.用链接密码共享文件原型

如果你的项目需要展示给第三方，但他不想注册蓝泻湖的账号，比如甲方、客户、参与测试的用户等。，可以把链接和密码发给相关人员，方便快捷。

动词 （verb的缩写）结局

本文到此结束。当然，一个交互文档不仅包含这些内容，还根据不同的需求和业务场景有不同的范式。因此，总结适合自己和团队的交互文档是最好的协作方式。

在我看来，交互文档的标准化虽然面临挑战，即如何输出别人容易理解的文档，但最重要的是如何根据业务需求输出合理的解决方案，实现业务需求和技术实现的平衡。

举一个简单的例子来说明技术交流的重要性:在做一个与表单相关的项目之前，当在后台创建一个表单时，它涉及到表单域的排序。我的设计方案是把表格名称和表格介绍连同字段一起填好，用最后一个键提交。

这里有一个问题:

前端和我沟通，因为我们系统没有这样的交互，表单保存到数据库后需要上下移动。如果要在前端做虚假的上下移动，用最后一个键提交给数据库，会比较费时费力。

所以我们优化了方案，一步一步填进去。首先，在创建新表单时，我们填写了表单名称、表单介绍和相应的限制方法。保存后，我们在下一步中添加了表单中的字段。添加每个字段后，我们直接保存到数据库中，上下移动时与数据库交互。最后，我们为用户提供了一个保存按钮和一个保存发布按钮，用户可以在前台独立选择表单的显示状态。

另外，在第二次编辑时，我们把它放在同一个页面上，从上到下布局，因为此时系统和把表单写入数据库都和我们之前的交互是一致的。

类似的例子太多了，往往在于发展和交流的过程中。我也认为懂技术的交互设计师在方案落地上确实有优势，但是懂技术并不意味着你要会写代码，而是需要知道计算机是如何实现你的设计方案的。这是一个又长又复杂的话题，这里就不展开了。

另外，如果有同学需要本文展示的互动文档，请联系我，我的微信官方账号，星野笔记