怎么保证后台读取和前台输出内容格式不变_如何输出一份规范的交互设计稿

去年很长一段时间，我主导了一款APP的体验改版升级工作。由于整体改版的工作量比较大，因此设计过程中引入了合作方的设计师资源。在完成前期梳理及绘制主流程界面设计之后，部分子模块交由合作方设计师进行完善补充，输出完成设计文档后再进行集中审核整理。

在合作过程中，我发现很多设计师对一份交互设计稿应包含的内容还没有清晰认知，或者在使用设计稿模板的情况下不知道为什么要这样做。这种情况使得交互稿输出不规范或者撰写浮于表面，存在交互稿说明不清晰、返工率较高的情况。

当初笔者也有过种种疑惑，在历经多次探索之后形成了一些理解与经验。因此本文将基于Axure描述“如何输出一份规范的交互稿”。当然，本文观点仅是我的个人经验，需要各位按照自己的工作习惯进行理解-转化之后才能形成自己的知识储备。

目录

1.交互文档的重要性
  1.1为什么要输出交互文档
  1.2谁需要看交互文档
2.交互稿应该包含哪些内容
  2.1封面
  2.2文档说明
  2.3解析过程
  2.4设计方案
  2.5废纸篓
3.交互稿撰写规则
  3.1交互稿结构
  3.2交互稿页面内容
  3.3交互稿内容排布
  3.3撰写交互说明
4.结语

1.交互文档的重要性

1.1为什么要输出交互文档

实际工作中，交互设计师在产品生命周期中处于中上游的位置。对上要对接产品经理，完成将产品需求进行具象化展示，产品经理也会根据交互文档确认需求的业务细节。对下需要向UI/开发/测试明确交互逻辑，交互文档此时将会作为产品研发过程中的“说明书”。

由此可以看出，一份完整的交互文档，是需求阶段及开发阶段的重要依据，能使得多部门协作有据可循，反过来也能在执行方案落地时保护设计师避免无谓的挑战。

1.2谁需要看交互文档

1)业务方/需求方

一般是产品经理，但是笔者也接到过很多运营发起的需求，这时候阅读文档的就是运营经理。产品/运营阅读交互文档主要是两个目的：1)关注设计方案有没有满足业务需求；2)很多时候需求交付不会考虑很细致，通过交互文档能重新梳理业务，并对需求细节进行微调。

2)视觉设计师

包括视觉和UI设计师，还有可能包含动效设计师。通过传递并宣讲交互文档，能使设计团队目标一致，明确需求目标、产品定位，也能明确需要视觉化的页面/按钮/状态展示等内容。

3)开发人员

包括前后端开发工程师。开发阅读交互文档分为两个阶段：1)交互方案完成后，需要集合产品和开发完成设计评审，设计宣讲方案，开发基于目前技术提出技术修改建议，会后设计完成交互文档修改及定版；2)交互方案定版后，开发将会按照交互文档完成功能开发。

4)测试人员

包括测试工程师和参与测试的其他人。测试同学会参考交互文档完成测试用例，测试用例须覆盖所有功能、异常场景、操作行为、产品细节，须保证上线无bug，或是少bug状态。

5)其他人员

客户经理、财务、客服等岗位。某些需求对客户感知或业务逻辑影响较大，为了能开展后续工作，需要相关岗位同事一起参与并阅读设计文档。例如笔者参与过商城付款与积分兑换的相关需求，影响到了平台的收付款能力，此时就需要财务同事参与并阅读交互文档。

2.交互稿应该包含哪些内容

完整的交互稿应包含如下内容：

2.1封面

包含需求名称、版本号、更新时间、文档撰写人员的信息。如果研发团队比较固定，建议把上下游关联角色人员也写上，方便设计流程中的各角色人员沟通。

2.2文档说明

文档说明包含：修改记录、评审记录、设计进度规划、标示图例共4个页面。其中修改记录评审记录需要跟随版本更新。

1)修改记录

交互文档的每一次修改都需要记录，记录所有修改点，并更新一次版本号。同时，建议每个修改点后面跟随展示影响到的页面，并设置超链跳转。

2)评审记录

设计文档交付前，一般需要经过多轮内审及外审，为了方便设计回溯，需要记录评审人员及修改点。但如果需求不大，评审次数及改动点不多，可以去除此页，并将评审内容结合至“修改记录”页面；

3)设计进度计划

进度一般为项目的统一进度，由产品/项目管理沟通后发布。若实际项目中，时间节点存在变数或未明确发布进度计划，则可以去除此页面。

4)标识图例

包含交互标识说明及手势说明2部分，固定格式，无需变动。

2.3解析过程

解析过程包含：需求说明、业务流程图、用户调研、竞品分析共4个页面。

1)需求说明

包含项目背景、项目目标、设计策略、目标验证的描述。通过此页可以帮助设计师理清需求来源及基础目标。

2)业务流程图

业务流程是帮助设计师理清需求定位及业务逻辑的，建议直接拷贝PRD中的业务流程图。如果设计师已经对业务逻辑很熟悉，则可以选择去除此页面。

3)用户调研

建议展示：调研方式、人数、调研数据、用户诉求/发掘出的问题。实际项目中，会针对产品进行总体调研，一般不会针对某个独立的功能进行细化调研，因此若无可不写。

4)竞品分析

依照需求差异，自行决定竞品分析细致程度。此处建议依照设计策略对竞品某个功能点进行侧重分析。

2.4设计方案

设计方案是交互文档最主要的部分，也是开发的最重要依据。一般包含：信息架构、流程图、设计方案(界面图+设计说明)。

1)信息架构

用xmind或mindnode绘制的产品/模块信息架构。依照需求大小决定是否展示此页。

2)页面流程图

此处是本需求中的页面流程图，包含所有的用户路径。主要用于文档阅读人员快速理清页面逻辑。

3)前后台设计方案

设计方案需要包含前台及后台，前台设计方案一般基于ios端进行设计，但也需要考虑Android端的差异化设计。如果差异点不多可直接在设计页面标明，如果存在功能性/多页面的差异，则需要单独文件夹呈现；

如果功能修改牵扯后台功能修改，则需要对应的后台设计方案，若无则不需要此页面。

设计方案可以使用子母文件夹+子母页面的形式进行排布。

2.5废纸篓

设计师经常会遇到频繁改稿的情况，甚至交互方案完成后因开发排期还需要将需求拆分。这些页面建议直接整体移入废纸篓中，防止后期用到了需要重新绘制。

3.交互稿撰写规则

3.1交互稿结构

一个完整的设计方案会牵扯前后台的修改，前端目前常见的有APP(ios/Android)、小程序、H5/web，后台页面一般为web。不同平台对应的是不同的开发团队，因此建议通过文件夹将各开发平台区分开，方便不同团队阅读。APP端一般输出一套方案，并列出Android的差异点。小程序、H5、web这三个因为要匹配不同的设计规范，建议输出独立设计方案。

设计师在绘制“设计流程图”时，一般使用flow组件代替页面梳理全量的流程。这种形式可以帮助文档阅读人员快速理清功能逻辑。但需要特别注意，这种形式对UI并不友好，UI对页面输出工作量缺乏完整的概念，因此交互可以将需要UI绘制的页面单独标注出来，并与UI同学当面沟通说明。

此外，交互稿的页面结构建议使用“功能/模块-主流程-子流程”的形式进行排布。这种排布形式既能符合产品实际架构，也能方便开发团队理解。同时绘制交互稿时，建议将流程分为两层即可。主流程应类似树状，包含所有用户路径分支，可以是两至三层分支。而子流程应为最小用户路径描述，一般为线状。

3.2交互稿页面内容

交互稿页面中一般承载三类信息，1)功能入口，即通过独立页面展示各个功能入口的排布及样式；2)流程界面：分为主流程或者子流程两类，展示具备页面跳转逻辑的一系列页面， 通过用户操作路径“串联”起实际业务流程；3) 子页面：交互方案中某些界面由流程中点击跳转而来，或是通用控件的独立展示页面。这类页面不具备下级页面，但界面中存在较为复杂的操作逻辑或包含很多内容，需要单列一页承载。例如分享样式展示、各种规则页、通用组件展示页面。

一页交互稿中，一般需要展示：页面总标题、界面标题、界面、特殊标示、交互说明、流程线；

此外需要注意：1)如果界面或流程中存在大量状态分支，可以增加子页面；2)页面总标题与axure左侧页面栏中名称保持一致；3)流程线中不仅要有流程连线，还要有判断条件；4)标示图例可以依照实际需求展示，无则不展示。一般为打点需求、特殊的交互手势等。

3.3交互稿内容排布

交互稿是一种供别人阅读的文档，在进行内容排版的时候，需要重点考虑阅读便利性。首先，界面的排布建议从左到右、从上到下进行，使用类鱼骨图的形式进行展示。这样的排版符合普通人的阅读习惯。其次，要善用网格与标尺，无论是使用标尺、网格、还是设置标准间距，都是为了保证页面信息的韵律感，规律的信息排布能减少阅读过程中的焦躁感。

3.4撰写交互说明

交互说明是交互稿的重要组成部分，需要描述界面中无法承载的信息。开发通过阅读说明了解产品的交互逻辑，因此撰写时要保证文档信息的准确性、适读性。建议注意以下几点：

1)确保信息无遗漏

撰写交互说明时应该注意检查信息有无遗漏，是否包含所有页面跳转、信息提示、异常状态、页面动效等。建议日常使用“交互自查表”进行交互走查，这样多次后就能基本脱离表格并且无遗漏了。

此处还有一个心得，对于新手设计师，可以尽量多写，把能想到的交互逻辑都写进去，再结合自查表完成走查，这样能保证逻辑完整无遗漏。但当你有了足够的经验或项目有了成熟的设计规范，再或者你已经与开发团队磨合的比较好了，可以将一些较简单、默认的交互逻辑删除，通过精简文档达到突出重点，提升阅读效率的目的。

2)慎用标志点

很多交互模板或者规范中，应该都会把交互稿所有需要标注的地方打上序号点，但是依照笔者的经验，建议不要教条化的使用这种形式。每个需要标注的地方都打点，会导致点过多遮挡界面信息。而且带序号的点需要设计师已经有明确的说明写作顺序，这本身就是与思考新事物的思维顺序相反，影响你的交互稿输出效率。

此处，笔者建议使用：页面内为独立界面时，直接在右侧拉线增加交互说明(方式1)。页面内流程时，采用“各界面下部统一添加交互说明+重点地方打点”这种形式进行撰写(方式2)。

3)善用标红/加粗提示

交互说明中，某些逻辑需要开发特别注意的、需要业务方二次确认的、需要测试重点测试的，为保证阅读者能有效接收信息，建议使用“@相关角色”的形式进行重点标注。

4)交互描述要明确简单

为提升阅读者的理解速率，应尽量使用简明扼要的语句进行描述。使用举例形式也能降低理解难度。

另外，为了交互文档后期维护的便利性，建议同一份文档内存在多处相同的交互逻辑时，只写一处即可，其他地方使用超链接跳转至该逻辑描述区域。

5)界面＞文字

当一个流程中，存在路径分支或者多种提示状态时，建议优先使用“多界面+简单交互说明”形式进行展示，而非纯文本描述多种状态/分支差异。纯文字形式对交互设计师的语言要求高，且会提升开发理解的难度。

6)文档修改要有标记

每次更新交互稿，都应该在“更新日志”里写明，并在页面中也标志出更新的地方。否则会给开发和QA同学带去极大的麻烦。修改提示建议只保留最近2个版本的修改点，所有版本的修改都放在页面内，会会影响信息读取效率。

7)利用文档完成协作

交互会与产品、UI、开发进行紧密合作。交互在方案设计过程中，如果对图片内容或风格有想法，可以在交互文档中表现/描述出来；开发逻辑有些不确定的点，也需要记录上，待确认后修改。

4.结语

本文仅通过笔者自己的项目经验，总结出的一种交互稿模板，主要应对的是C端功能类设计的需求。而其他需求(类似营销活动、B端平台等)则不能完全套用此模板。建议各位以此模板作为引子，结合各自实际项目经验，沉淀出适合于自己的交互稿模板。

本文交互稿模板链接: pan.baidu.com/s/1PaETeG  密码: l82s

---

感谢阅读，更多内容请关注知乎专栏：木子公社，或者扫码关注我的微信公众号