读了一篇文章——《如何撰写开发哥哥喜爱的交互文档》，结合平时自己的工作方式进行思考，发现有些方法的确在践行，但有些是遗漏的，因此， 根据文章中提到的一些方法，对平时的工作方式进行了总结，整理出适合自己的书写交互文档的思路。

一、给谁看

就跟做产品需要关心用户是谁一样，写文档要关注读者是谁，他们关心的内容是什么。

产品：关注核心流程是否充分满足产品需求

UI：控件样式及页面展示

开发：控件交互、页面展示、页面跳转、页面加载方式、异常情况处理等页面实现逻辑

测试：场景是否考虑周全、异常情况是否全部覆盖、是否受设备限制等

除此之外，有些情况下，交互设计师会直接对接业务人员，他们关注的内容与产品基本一致，即——核心流程是否满足业务需求，按照『问题-解决方案-流程』的步骤推进即可。

二、意义：为什么我们要输出清晰易懂的交互文档

Why：让团队成员了解项目背景，为什么做          How：让大家明白如何做

既然是一个团队，有一个共同的目标可以增强凝聚力。针对项目背景的解释，让大家了解到项目要解决的问题，让大家从同一个出发点去思考问题。详细讲解设计方案，能够让大家带着前面提出的问题去评估解决方案的合理性，如果在阅读过程中发现解决方案有误，尽早提出就可以及时修改，使方案更加完善。这样子，最终的方案就不仅仅是一个产品和交互设计师认可的东西，而是得到了项目组全体成员的共同评估认可，出错几率更小。

在介绍项目背景时，最好结合数据进行说明，通过这种方式，能够让项目动机更具说服力。比如，对比两种方式的提交率和成交率，无论从提交还是成交来说，方式A都比方式B更优，因此在产品迭代时，要考虑到更多的引导和推荐A方案。

三、设计方案及交互说明

以页面为基准从整体上考虑：原型稿上呈现出来的，只是交互设计师否定再否定的思考结果，有很多取舍是在最终的设计方案之外的

例如在拿到需求时，从整体上考虑共有几个页面，页面关系如何，完成任务的访问深度是否合适？访问深度过深，如何避免用户迷失？设部分思考很少以文档形式留存下来，但却对于设计方案来说必不可少。

从流程上思考：如何可以让流程更加简洁，开发和测试都更容易读懂

能够达成目的的路径有多种，但一定有简单和复杂的差异。尽量多想想能否以更简单的流程来达成目标，避免被既定思维限制。

极端情境考虑

1、网络因素——弱网情况 & 检测不到网络：提示用户网络问题导致的数据加载失败，并引导重试

2、数据因素——数据加载失败 & 数据为空：数据加载失败时，提示用户失败原因且引导重试；数据为空时，建议用户更换请求数据关键词，给出解决方案

3、权限因素——需要授权才能展示的数据或内容 & 页面加载环境变化：如在微信环境下，拒绝授权账户信息

4、设备因素：是否响应屏幕旋转的情况 & 不同尺寸设备的适配情况

交互元素的状态变化

在原型图上标记出可交互的元素，并逐一进行交互描述，描述格式为——触发事件+界面变化（元素变化）+关闭/返回方法。描述之后，需要写清楚元素状态变化的几种情况：

1、状态变化：包括Normal、pressed、disable。对于一些通用组件，以交互规范的形式事先定义好状态，能够有效提高效率

2、数据变化：包括长度变化时如何处理，数据类型变化时如何处理、出现特殊字符时如何处理等

3、动效要求：是否对元素变化有动效要求，动效表现为如何，包括动效示例及缓动曲线参数说明等，使开发能够很直观的了解你所说的效果

4、跳转关系说明：元素之间的链接关系，如何从A到B，又如何从B回到A

为了避免遗漏，可以建立交互设计自查表，引导帮助自己查漏补缺，特别是遇到大型项目，一般周期较长，交互设计自查表，不仅能够起到查漏补缺的作用，还可以提高自己思考效率。

四、不同类型需求的展示形式不同

a.页面优化，尽量放线上对比图，明确更改点

b.新增功能，需要清晰的流程图

c.大型功能，注意拆分细节任务流，方便协作

工作时已养成一种固定的撰写习惯，读到这条建议后，深以为然。根据需求类型灵活处理文档形式，以『易读性』为目标，才是一种好的习惯。

五、文档管理

看过一些文章，一般会在原型图内做版本记录，但我的习惯，为了避免单个文件过大，更倾向于以项目为维度，建立独立的文件夹，以清楚的文件名进行管理。项目完成后，进行复盘时，可以将项目按照页面拆出来，建立以页面为基准的管理文件夹，便于工作交接。