统一的文档规范和设计规范，能够减少合作方的学习成本，即使产品不同、需求不同、设计师不同，也能够带给前后端、底层和QA们一致的文档体验。

　　交互设计师的工作虽不只是画交互稿子，但是好的交互稿不仅能够完美阐释产品内容和设计师的设计思路，还能够在项目各方协调工作中起到重要作用。保证完整的呈现产品需求和设计思路的交互稿，能够让各方工作人员有一致的工作目标，而有良好体验的交互稿，还能够便于各方理解，提高后期开发对设计的还原度，提高各方工作效率。

　　对于一个设计团队来说，统一的文档规范和设计规范，不仅能够减少合作方的学习成本，还可以提升设计师和设计部门影响力。即使产品不同、需求不同、设计师不同，也能够带给前后端、底层和QA们一致的文档体验。或许每一个设计团队都有自己内部的交互文档规范，而且不同类型或量级的产品部门可能交互设计文档的体量和组织方式都是不同的，我们设计部是一个刚满一周岁的宝宝，部门里的设计师也都是设计行业的freshman，但是我们也在这一年中不断地积累和学习，提升设计文档体验，构建了组内的设计文档规范，以下共享，互相交流学习。

　　一、结构篇-交互文档目录

　　无论对于大型产品还是中小型产品，文档目录均需要有清晰的页面结构，无论以何种形式展现，整体交互项目应尽量包含明确的修改记录、交互规范、全局性设计说明、业务设计等。

　　1. 便于查找信息的修改记录

　　明确的迭代上线日期：前后端、QA们能够对产品迭代内有有一直的认识，清楚哪些是自己某一个迭代要按成的事情;

　　业务需求及对应设计师：便于协作方进行工作分工，并能够随时找到交互设计师;

　　修改内容以及前端开发人员：明确写明什么页面修改了什么内容，或者一个需求增加哪些页面，便于协作方了解设计细节内容。写明前端开发人员，则有助于帮助自己和QA们找到对应功能点的前端开发人员是谁(我在一个迭代中可能对接好多个前端人员，具体哪些需求点是谁实现的是记不住的，太笨了～)。

　　2. 全局页面说明和全局交互

　　全局页面说明主要包括Z轴内容层级，X轴和Y轴适配方案、整体跳转逻辑等，这些均需要在产品研发前期周知前端、视觉等协作同事的。准确传达自己的整体产品设计思路，便于他们进行框架搭建或者视觉定义。另外还可以指导后期复杂需求的交互设计。

　　全局交互则是为了组件化设计，不仅保证产品设计的一致性，也能够提高视觉和开发工作效率。

　　3. 全局性方案

　　全局性方案不仅包含404/403方案、全局请求异常、空状态、页面/信息流加载方案等，还包含一些业务全局性方案，比如平台性的欠费停服流程(所有产品模块均需要)。

　　二、布局篇-交互文档布局

　　1. 单页面文档设计

　　我们组做的基本都是 Web 端的设计，由于每一个页面的内容比较丰富且交互逻辑复杂，所以逐渐形成了每一个文档页面只做一个页面的设计的规则，保证设计文档中的页面与真实产品中的页面一一对应，便于交互文档按照产品业务组织和减少协作方查找内容时间。

　　单页面设计其实与一个页面只讲一件事情的设计方法相通，在表述本页面内的设计内容时要说明清楚每一个与其他页面关联的用户接触点从哪里来到哪里去，保证开发、QA们阅读交互说明的时候能够理解当前页面内容与其他内容的关系。

　　2. 统一页面内容布局

　　作为交互文档，它的目标用户比较明显的主要是与我们协作的前后端开发、QA们、视觉小伙伴，其实我们可以很简单的就了解到他们几乎90%都在使用公司配置的显示器，公司配置的显示器基本尺寸微1920*1080，所以便可以根据显示器的尺寸定义Web页面大小、交互说明显示区域等，这样便可以尽量保证在首屏内显示相关内容。

　　另外，根据向开发了解，他们较为习惯Y轴方向浏览信息(其实感觉大部分人都喜欢Y轴方向浏览信息)，因此文档页面和交互说明布局以纵向为主，在他们单方向浏览时，保证所有交互点都能看到。

　　页面头主要包括页面名称、设计师信息和时间信息;