如何写一份全面、易读的交互说明文档？思维导图

页面流程图，可以表达产品的整体结构，帮助同事了解界面之间的关系。在撰写交互文档时，也可以以任务、子任务为模块来详细介绍界面如何跳转、何时跳转。

根据用户与界面之间发生的交互操作，提供相应的反馈，可能是提示内容，也可能是界面内或界面之间的跳转。

刚入门的交互新人，喜欢把重心放在界面之间的跳转，而遗漏了界面内的内容布局和交互操作。对此，我的小技巧是，先整体看界面全局，再review界面上的每一个元素，思考各种不同场景下这些元素是否变化、如何变化。

以上只是抛砖引玉，给大家打开思路。虽然只是几个输入框，但其细节比大多数界面都要复杂。你可以找一款优秀的APP，去研究它如何设计这些细节，是否还有我没有提到的点，研究透了下次自己设计才能做到更加全面。

当然，交互细节说明，只是方案的表述，每一个小点都有好几种设计方案。如何权衡选择体验更优的方案，才最是考验交互设计师的能力。你可以对比研究几款优秀产品，看它们在细节设计有何不同，分析其中的缘由，想想是否有更好的方案，学无止尽。

网上流传着很多这种风格的图，最初觉得这样的图很有范儿，以为这就是他们输出的全部交互文档，所以按照这种模式产出。等到自己做的多了会发现这类图大多只表达了某个界面的正常状态，并没有详细的交互说明来体现界面的内容布局和交互操作反馈。

Web产品的特点是，层级复杂，每个界面比较大而且内容很丰富。通常会组织好页面层级，再画每个界面的原型，待几轮讨论过后界面布局和内容基本确定之后，再为每个界面撰写各自的交互说明。

考虑到每个界面中的内容模块和功能点不少，我没有在确定好的界面上直接标注交互说明，而是将这个界面划分为几个功能模块，并给每个功能模块新建一个页面用来写交互说明。

如下图，分别是 Axure的文档目录（左）、某个功能模块的交互说明（右）

App相比Web界面内容简洁很多，很多人输出App的交互文档都是一页展示很多个界面，上下左右排满了。设计师大多是大屏电脑，这样设计起来确实比较连贯流畅。

但是开发大多用MacBook，没有外接的大屏显示器，一屏看不到几个界面。虽然我会按照横向主流程竖向次要或分支流程的规律排列，但是他们对这些规律并不熟悉，左右拖拽上下滚动几次就容易犯晕，可能一会儿就找不到刚看过的界面了。

如下图，界面右侧配上对应的交互说明（通常情况，交互原型应该以黑白灰颜色为主，不过因为我们的APP处于迭代优化的阶段，已经确定了视觉风格，而且某些状态需要用颜色来区分对错，所以会有一些配色。）

期间优化过这种方式，将大功能点拆分，按照以往设计Web 产品的方式来组织。对此开发同事仍然觉得不够好，所以有了后面ppt/keynote演示文稿的方式。

为什么采用这种方式呢？源于开发同事看到产品老大介绍需求用的幻灯片，觉得一张图配一个表格的方式很清晰，强烈建议用这种方式来写交互文档。

我觉得用幻灯片输出PDF 的方式确实可取，易于浏览。不过一页一个图太零散，界面之间、界面内容的不同状态关键性很强，放在一起介绍更直观。

于是，我想到了以前 yoyo 在腾讯CDC 官方博客上分享的交互文档撰写方式。以前尝试过用他推荐的indesign写文档，但对这个工具不那么习惯以至于效率并不高，尝试过写完一个产品的交互文档之后就没再用了。不过 yoyo 推荐的将大故事拆分为一个个小故事来写交互说明的方法让我记忆犹新。

就这样，尝试了这种新的搭配方式，Axure 画原型，Keynote 写交互说明。Keynote缩略图预览如下图，为每个功能模块建立一个任务/子任务的目录结构，按照划分的结构依次介绍各个子任务。每个页面最多介绍四个界面，页面底部作为固定的区域用来写交互说明。

测试、开发同事反馈这种方式不错，一方面是因为每页文档的结构大小一致，滑动浏览的体验也更好；另一方面是因为他们写代码也是按照这样的方式一个小模块一种场景依次往下走，更容易专注看当前写的这个模块的交互说明。

虽然有同事的肯定，但这种方式还有优化的空间。因为采用了两个工具，一个画原型一个写文档，如果Axure原型有改动，需要复制到keynote，两处都要更新显然影响效率。所以我还在考虑是否切换到某一个工具搞定这两件事，比如用sketch 。除此之外，文档模板也可以改进优化。

就像前面说的，交互说明文档，就像是交互设计师输出的产品，既要根据场景的变化不断调整，又要听取用户的意见，持续优化提升体验。

这个话题就先分享这么多，如果你有更好的方法或建议，欢迎关注我的微信公众号（qingxizhaji），留言交流。