转载自:https://www.pmcaff.com/article/index/1284824297878656
前言
这篇文章讲的是如何制作一份产品、UI、开发、测试都喜欢看的交互设计文档。文章内容主要是自己工作中用到的交互设计规范模板（axure版本），这套规范是自己总结出来的，但是构建的思维方法借鉴很多前辈大神的方法论，特别是淘宝U一点团队所分享的公开课内容。
抱着他山之石，可以功玉的想法，结合自己公司团队的工作特点，总结了一套交互设计规范。使用中，有些小收获，分享出来，大家多多沟通，共同进步。
这篇文章的行文思路是，先说明交互设计规范准则是什么、然后举例说明交互设计文档各模块的书写思路及踩过的坑，最后是一份可供下载的模板和组件库。
一、交互设计规范化文档的准则
1.1 为什么要输出一份交互设计规范
1、“设计有记录、信息可追溯、交流有依据”。这个很重要、重要、要。一个产品的诞生不是你一个人几天的事，它有多部门配合的宽度，也有多版本迭代的长度。一个交互设计师，如果设计不严谨挖了坑，早晚是要填的，交互设计规范或许可以帮你规避一些坑。
2、“在团队中，信任真的是一切沟通的基准”。交互设计师，工作中除了解析需求，绘制交互稿外，更多的时候需要配合UI完善设计，跟进开发实现效果。如果你绘制的交互稿没有那么的完善，缺东少西，UI和开发就会慢慢对你没有信任感。这个时候，你的其他工作也会很难开展。也不是说一份交互设计规范，就能让开发对你产生信任，但是一份好的规范，能弥补你部分欠缺，提高你设计的正确性，同时一份好的规范文档可以降低沟通和学习成本，展现你的专业化能力。
1.2 交互设计规范要求
1、符合自己的就是最好的。一定是根据自己公司工作流程，和上下游沟通后来确定自己的文档应该包括哪些内容，哪些内容需要着重写，哪些内容可以少写，书写的方式应该怎样，团队内行业内是否有共同的说法和写法。毕竟规范的作用就是为了提高工作效率的。
2、扩展和更新。不同类型的项目，所涉及的控件，所使用的规范要求不同，要学着调整和更新自己的模板。
二、交互设计文档各模块的书写思路和踩过的坑
先来一份交互文档的目录
2.1封面
开篇明义，文档的基本信息概述。
版本编号：此文档的最新编号；（一定要记得更新）
设计人员、开发人员、测试人员：表明文件流转的下一级相关人员，方面沟通（如果涉及人员众多，也可单独列举）
一份规范的交互稿不仅是对自己负责，也是对其他伙伴负责、对将来负责。
2.2文档说明
交互文档的目的就是为了上传下达，将需求转化可视化文档，是一个过程性文件。所以，文档的可阅读性是衡量一份文档好坏的一个标准。而文档说明这个模块就是为了给不同的文档阅读者相同的“世界观”。
2.2.1项目背景与范围
更完整的项目背景应该出现在产品需求文档中，而交互文档中书写的目的有两个，第一，如果项目小，没有完整的产品需求文档，这里就是向各方人员传达项目背景的地方；第二，加深整个项目组成员对项目的理解，看内容前，先有一个共同知识背景。
（书写小贴士：书写内容相当于用户体验要素中，战略层、范围层的梗概。）
2.2.2更新日志
目的也是有两个：第一，面向自己。工作是一个过程，完整的记录更新日志，方便自己将来查询，同时，也方便和开发测试互撕的时候，亮证据；第二，面向开发、测试。整个开发过程漫长，协助方多样，完整记录，可以降低各方不必要的沟通成本。
（书写小贴士：1、更新日志，可以在交互文档评审通过后，需求锁定后，在开始书写，设计过程中的更改可以不书写进去（个人经验）；2、书写的内容要具体（写的不具体，后续会有坑）；3、书写中最好增加关联链接，方便相关同事快速找到位置；4、同一个位置多次更改时，要标注最新内容）
2.2.3设计进度计划
进度计划这种东西一般出现在项目工程表中，或者项目工程排期中（具体的可能根据不同公司，有所不同）。而交互稿中的设计进度排期的作用，和前面两个一样，一方面是给项目组成员一个共同的背景，另一方面，是自己设计过程的记录。
（书写小贴士：1、按照设计过程，可以大致分为需求整理、需求评审、交互设计、交互评审、UI设计、UI评审、开发、测试，根据自己情况进行划分；2、个人经验，此处的进度计划不是整个项目很严谨的工程计划，此处的只是设计师与相关同事沟通协商工作的一个梗概，以及自己的记录，自己看的明白就行）
2.2.4评审记录
区别于更新日志，评审记录主要书写于设计阶段。评审记录主要分为内部评审（设计师（项目内交互和视觉）、UED负责人、UED相关设计师）和外部评审（设计师（项目内交互和视觉）、UED负责人、UED相关设计师、业务负责人（产品和需求方）、技术负责人、技术相关人、市场运营人员）
（书写小贴士：1、一般都伴随着会议记录出现，我一般会书写好以后，直接剪切当会议记录）
2.3、解析过程
解析过程是我认为最重要的一部分，是产生信任和思维可视化的地方。在进行交互设计原型绘制之前，一定要以目标为导向拆分自己的思维，并将“虚拟”的目标转化为各种设计元素。
说简单的点，这块就是设计维度的需求分析。不同人可能有不同的分析方法和展现形式，不管怎样的方式，只要能梳理自己思维帮助自己设计并且清晰的向自己伙伴传达信息即可。
以个人经验，根据不同类别的项目，不同大小的产品，需求分析的维度和角度都有不同。此处我就简单说一下，我常用的一种需求分析方法。
以人为核心，以目标为导向的思维解析法
我们做设计，大到一个产品，小到一个页面，在设计的时候都是有目的，也有需要达到的目标。目的可能来自于公司战略，来自于市场需求，或者来自于money，不管来自哪里，商业社会里，我们做产品肯定是有所图。同时，我们产品服务的用户，他们的特点有很多、所使用产品的环境有很多、用产品时的想法感觉也有很多、他们也有自己的对产品的追求和要求。而我们是设计师，不是艺术家，我们需要在有限的条件下，利用我们的才能设计最贴合用户需求，最能产生商业价值的产品。这个过程就是下面这个需求分析推导的完整思路。具体内容，我就不再这里展开解释了，可以仔细看下图。我针对各个具体环节做了一些简单说明。将来如果有合适的、可对外分享的案例了，我可以详细说明下。
（书写小贴士：1、书写形式可以多样，只要能帮助自己理解需求、方便设计即可；2、需求分析可以有更详细的文档，交互文档里写，还是那个目的，让上下游看到，能达成共识；3、我文档中列举的其他几种方法，只是一个例子，可根据具体情况使用）
2.4、页面交互方案
页面交互方案，也就是我们常说的那种交互原型文档。具体如何写，在这里就不多说，具体业务具体讨论。这里只说下，在日常工作中，常见的几种交互文档书写的思路方法，已经书写的范围和注意事项。
2.4.1流程图
重要性就不多说了，很重要。另外，一定要在设计前梳理好流程图（可以不完整），一定不要后续为了展示补流程图，那样，流程图就不能起到它本身的作用了。如果你原来不是这样做的，可以调整下思路。
（书写小贴士：1、流程简单可以绘制一个流程图，如果流程多，建议拆分成各个子流程绘制；2、除了绘制功能流程图外，建议可以绘制业务流程图；3、绘制软件多样，可以axure，也可以使用第三方软件。）
2.4.2信息架构图
重要性也不说了，很重要。绘制信息架构图，只是一个展现结果，如何绘制才是核心，方法就不在这里展开。
（书写小贴士：1、信息架构图可以从功能--页面--模块--元素这样的维度书写；2、共通模块可以并联使用；）
2.4.3交互页面
交互页面主要有两部分构成，一部分是页面，一部分交互说明。
一个Axure页面表达一个事效果最好，最受同事喜欢。什么叫做表达一个事呢？一个事既可以指一个流程，也可以指一个页面。
一个axure页面表达一个页面。
（书写小贴士：针对核心页面具体说明，至于页面所关联的子页面和流程就在其他页面表达。）
一个Axure页面表达一个页面的多种状态：
一个axure页面表达一个流程
一个流程是指最小的一个子流程，子流程与母流程之间可以通过Axure文档的树结构表达
2.4.4交互说明文档
一份合格的交互说明文档应该包括但不限于
页面内容说明（数据来源，数据特点，内容类型，范围，极值，排序规则等）；
交互反馈，状态；
交互动效、视觉要求。
下面这个案例中，对页面元素做了详细说明，包括数据特点、计算规则、更新极值、特殊情况说明、状态说明，视觉样式说明等。
写到这里基本就算完了，其他内容就是针对不同产品的个性化需求，做不同具体设计说明。
三、神助攻
就像文中开头所说的交互设计规范的目的是提高工作效率，降低沟通成本，提高设计质量；至于这“两个提高一个降低”能否实现，除了规范外，我这儿还有两件“法宝”。
一、定制化的组件库。结合自己的工作特点，定制一个符合自己业务范畴，和工作习惯的组件库，效率肯定会事半功倍。组件库不是一蹴而就，而是自己根据业务特点和设计习惯，慢慢调试的。附件是我自己定制的一套符合自己设计特点的组件库，大家可以在此基础上修正调整。
二、团队。团队之间的默契，配合与协同，才是提高工作效率、降低沟通成本，提高设计质量的制胜法宝。
看我啰嗦了这么多，我也有点不好意思，就奉上一份交互规范源文件和一份设计组件库。供大家参考。多多沟通，多多交流。
交互规范源文件：链接：https://pan.baidu.com/s/1PnRZpir8JJDmCNVLfEi0vQ 密码：pew7
组件库：链接：https://pan.baidu.com/s/1lS4DpO5mU0VtrMh-K3XFCw 密码：r4rp
（ps：组件库是在蚂蚁金服开源的组件库基础上调整更新的）
