UI 必备｜详细且专业的交互文档应该怎么写？

上次分享了关于苹果官方商店中手表购买流程的交互改版思路，但因为图文的展示方法不会展示得非常细致，所以很多同学看完甚至会有误解认为改动后的信息量比原来的更大，或者流程比原来的繁琐。

之所以有这样的问题，就是因为依靠单一的原型图，是无法有效的解释交互逻辑和意图的。进一步延伸，在实际项目中，你的方案要如何进行评审，或者能被开发正确理解，也不能只用一两张原型图搞定。所以，设计师需要针对交互的设计方案，输出对应的说明和文档。

交互文档该怎么写和基本认识之前已经写过，没看过的同学可以翻翻以前的说明：

文章链接：

但之前没有针对具体内容做说明，所以今天的主题，就是以上次的交互方案为对象，分享如何输出交互说明的流程和案例。

任何文档，只要按“完整的”、“理论的”、“专业的”思路去做，一定都要耗费大量的精力和时间，这在实际工作场景中是很难落地的，留给我们的处理时间通常远远低于预期。

要在有限的时间内实现最佳的产出，就肯定要做变通，根据项目的实际场景、目标来制定应该输出哪些内容。

任何类型的文档，最难的是确定里面要放什么，而不是怎么做，不管是交互文档，还是需求文档，规范文档，接口文档等……而确定里面要放什么本身也是需要时间去分析的，这个时间不花，后面就要用更多的时间弥补，或者降低最终的交付质量。

前期的分析主要要确定下面这些问题：

确定文档的作用，以及给谁看的
要解释的交互内容的具体范围
确定要制作的所有原型和表现形式
最终设计稿和交互原型的关系
选择制作文档的工具和制定文档结构

问题 1，就是确定文档的目标是什么，要解决的问题是什么，是给领导看，还是做交互方案评审，或者仅仅是针对迭代中的某些特殊流程做说明，确保能开发出正确的版本。

不同的目标对后续的决策和实现形式都会产生非常大的影响，比如做评审，方案都没完全确定就怎么简单怎么来，如果要让开发能看明白正式开发出来，那说明就是另一回事。

我们本次案例的目标，就是以 —— 让开发能看懂并开始实现的选购页面说明。

有了问题 1，就能思考问题 2，交互文档中应该放哪些内容。因为一个项目中包含的页面数量往往非常多，想要完整呈现所有交互细节和信息的话就更多，全部做出来是不可能的。同时，会有很多流程、页面、组件的交互是重复的，也没有反复表示相同内容的必要。

所以我们要缩小这个范围，在本次案例中，因为我只做了一个页面，目标就是解释这个页面，所以范围已经确定了。但如果做一整个项目还是一个改版中非常多模块的迭代，我们就肯定要从中做出筛选，将最重要、复杂的交互对象确定出来，忽略那些完全不需要解释或者重复的东西。

问题 3 是确定要制作的所有原型和交互说明的表现形式。用我们演示的案例为例，理论上手表选购页只是一个页面，如下图所示：

但作为一个强交互型页面不同的状态和反馈远远不止一个，光靠文字的解释让其他人自己脑补是很不专业的，所以要把它们做出来示意，但是要做哪些内容呢？

这里就建议用思维导图把它们逐一罗列出来：

也就是说，针对当前这个页面，我要完整讲清楚它的交互的话，就包含 2 个部分的工作，首先是整体的一些样式做出来能完整预览一遍，包括页面默认的状态，全部选完以后的状态，然后是不同模态弹窗（基本是个独立页面）的布局。

然后以手机实际预览单屏的角度，解释不同的选择阶段的交互和规则，根据功能中包含了默认、表壳选择、尺寸选择、表带选择、订单详情五个阶段。

这些内容都是要被设计和展示出来的，也就需要我们考虑用什么形式展现和说明。因为本质上只有一个页面，所以肯定不会去用 Axure 这样的工具做标注。而且不同状态间的切换去做可交互的原型也完全没有必要，所以直接使用设计软件在一个画布内写清楚交互即可。

然后就是问题 4，最终设计稿和交互文档的关系，这个东西要划重点，以我今天展示的案例并不能很好的还原其中存在的问题，但是它非常重要。

因为真实项目中很多交互文档交付时设计稿是没做完的，而设计稿最终的布局甚至是交互可能会和交互文档中的原型有很大的偏差（就是设计师自己照着做，但还有设计评审可以再改嘛！），既然是以最终设计为标准，那要前面的交互文档有什么用，再根据新版重写一遍？

所以这个阶段中，如果设计稿也是你自己出，方案已经对得很清楚了，那么文档可以认真的做完。如果设计稿没确定，大概率会被调整，那么文档依旧只能是现阶段的半成品，按较低的规格输出即可，尽快完成设计稿，并用最终设计稿来做交互说明才是合理的。

问题 5，就是具体应该用哪个工具，以及如何创建文档的结构了。本次的案例因为流程短，直接用原设计软件一个画布做完就行，所以不需要特意去制定文档结构，这个在前面分享的交互文档中已经有提及，大家自己去看就行。

以上五个问题，都是在输出交互文档和说明前需要分析和考虑的，顺序不是固定的，要加入其它的分析要素也可以并没有限制。考虑得越多，想得越清楚，那后面做交互相关的说明就是水到渠成的，不会被表现形式和方法限制。

到这一步进行交互流程案例的说明，首先是根据前面的规划准备好对应的原型：

然后确定交互解释应用的图形元素，如连线、标识、说明文本区域等（虽然本次用不到太多连线）。

然后，就是先做个大标题，并将整体展示内的页面合并在一起，使用一个说明文本卡片来做基本的解释即可，具体的说明放在后面。

真实项目里做交互说明，重点是页面的交互逻辑，而不是按作品集的做法写“八股”，只把关键的信息记录进去，尤其是团队成员都参与项目了解项目背景和业务的话，更不需写一大堆废话，这是没人愿意看的。所以我的添加内容如下：

文档说明：本文档内主要展示苹果应用商店中 App Watch S9 的交互流程说明，旁边是该流程中包含的几个主要状态的完整页面，可以简单的预览。具体交互说明见右侧。
默认页面：用户进入选购页后页面的状态，还未选购
全选页面：用户完成商品所有选项后的状态
模态说明：用户点击选项帮助后弹出对应说明页面的模态窗口
模态大图：点击商品图后展开的图片模式

然后，再开始进入右侧的具体解释部分，同样要包含对应的大标题，然后把页面和文本区域绘制出来，并完相关的排列。

交互的解释一定要遵循先总体后细节的顺序，先对层级高的事件做说明，再解释层级低的。

比如默认状态页面，主要描述的对象是头部的图片区域和下方的按钮栏，表壳的选择是在下个阶段才进行的交互，所以我的描述内容如下：

顶部图片区域：

主要展示商品图片，默认显示图例为商品默认展示图和价格文案
这个模块包含 5 个阶段，除了当前默认，还有表盘、表壳、尺寸、表带四个阶段，每个阶段会展示对应选择后的图例
点击可以展开模态窗口，查看大图，显示的图片和内容匹配，具体匹配逻辑见 PRD 文档
在表盘、表壳、尺寸、表带的选择时，该模块悬浮在顶部

添加购物袋栏：

购物袋栏悬浮在页面底部
左侧的价格默认实现最低价，后续随选项切换价格
右侧的购物袋按钮默认不可点击，需要完成所有选项才可以点击

内容区域：

内容区域可以进行上下滚动，在表盘、表壳、尺寸、表带内容区间被上下模块覆盖和遮挡

再到选择表壳的部分，相关的描述如下：

顶部图片区域：

切换成和当前所选表壳类型相同的图例
点击后查看表壳相关的图例

表壳选项：

点击铝合金或不锈钢可以选择对应表壳材质，选择后下方色彩选项移除不兼容的材质类型，并默认选中兼容色彩的第一个选项
可以不点击材质直接选择色彩，但是会自动选中和该色彩匹配的材质，并移除其它材质的色彩选项
不同表壳类型会有价格的差异，下方的价格需要进行切换

再到选择表壳尺寸的部分，相关的描述如下：

顶部图片区域：

会有动画（具体看设计），只保留选中的表壳尺寸
点击后可以查看该尺寸的相关图例