下载掌阅APP，畅读海量书库
立即打开
交互设计说明文档是交互设计师的主要产出物，与视觉设计师交付的高保真设计稿一样重要。文档类产出物的包容性比较强，各个团队对交互文档的内容、质量要求均不一致。本节主要讲解交互设计说明文档的撰写方法，将交互设计师在工作中的思考和执行过程按顺序记录下来，得到一个全面、规范的交互文档，为大家提供参考。在实际项目中，可以根据团队的工作标准对交互文档中的内容进行增减。
交互文档通常会被传递给产品经理、交互设计师、视觉设计师、开发工程师、测试工程师等产品团队的人员查阅，是交互设计师与上、下游的相关工作人员的协作工具。上、下游的相关工作人员会根据交互文档中的交互方案进行设计、开发、验收。所有的迭代依据、产品逻辑、交互规则，都是通过交互文档进行对标的。在产品迭代环节，交互文档有着至关重要的意义和作用。
产品经理： 在项目迭代中，交互设计师是与产品经理沟通频率最高的人，产品经理将需求或方案草图传递给交互设计师，由交互设计师产出符合需求的设计方案。产品经理是交付物的重点关注者，他们会确认交互方案能否满足产品需求，并且确认具体的设计思路和业务流程。在实际工作中，产品经理有时会为了达到产品目标而忽略用户体验，这时交互设计师需要平衡其中的利弊关系。在规范的工作流程中，产品经理需要输出产品需求说明文档（PRD，简称产品文档）。交互文档中的原型图、流程图、结构图是产品文档中的重要组成部分，通常会将产品文档和交互文档结合使用。
交互设计师： 在完成方案设计后，通常会组织交互设计评审会议。在时间紧张的情况下，会将交互设计评审会议和视觉设计评审会议组织在一起，这时会邀请其他交互设计师提出建设性的意见，他们会从专业的角度审视交互文档，从而达到相互提升的作用。大型项目一般有多位交互设计师协同工作，因此交互文档的可协作性很重要。
视觉设计师： 对交互设计师而言，交互方案最终如何落地，要先看视觉设计师，再看开发工程师。视觉设计师是交互设计师的下游人员，会重点关注交互文档中的交互原型图模块，他们会根据交互原型图进行高保真设计稿的设计。有经验、有能力的视觉设计师会在设计高保真设计稿时对交互原型图查漏补缺，可能会提出不同的设计意见，并且设计出不同的高保真设计稿。这对交互设计师而言并不是一件坏事，因为这样可以不断地对交互文档进行打磨，从而产出更好的设计方案。如果视觉设计师只会根据交互原型图“上颜色”，那么需要反思一下交互原型图是不是做得太偏向高保真设计稿了，导致视觉设计师没有发挥的余地；或者他们对高保真设计稿本身就没有更好的想法。对于有视觉设计经验的交互设计师，可以对视觉设计师提出建设性的意见，传递自己的交互设计理念及期望达成的视觉效果，一起为设计方案的落地负责。
开发工程师： 前端的开发工程师主要关注交互原型图和页面跳转逻辑、状态等，后端的开发工程师主要关注业务逻辑、信息架构，因此交互设计师在撰写交互文档时，需要说明页面的交互状态、信息呈现规则、权限规则等。在交互设计评审的过程中，开发工程师是必须到场的关键人员。对于前端、后端的数据交互逻辑及可能发生的异常状态，开发工程师通常比交互设计师更敏感，能够帮助交互设计师完善交互文档中的设计规则。
测试工程师： 在迭代版本发布前，会由测试工程师对即将上线的改动点进行功能测试，他们需要按照交互文档中的交互逻辑、信息规则、权限规则、交互状态等进行验收，并且根据存在的问题向开发工程师提出整改意见。测试工程师主要关注功能可用性和业务逻辑通顺性，所以交互设计师、视觉设计师通常会和测试工程师一起验收。测试工程师主要验收功能可用性，交互设计师主要验收交互规则的完整性和实际的使用体验，视觉设计师主要验收页面还原度。
除了以上人员，有时还需要将交互文档交付给领导或甲方。之前的团队会不定期抽查交互设计师的交互文档，检查文档撰写是否规范、方案描述是否详细等，用于提高交互设计师的基本素养。
有些团队因为迭代资源有限，并没有设立交互设计岗位，交互设计环节也不够系统化、规范化，通常由产品经理和视觉设计师共同分担交互设计的工作。在这种情况下，纠结“如何使用规范的交互文档进行高效协作”显然是没有意义的，具备交互能力的视觉设计师可以将交互说明、状态规则等信息写在高保真设计稿的旁边，然后将其上传到蓝湖、摹客等设计开发协作平台。
对于撰写交互文档的软件，可以根据团队协作的要求选择，也可以根据工作性质选择。例如，专职的交互设计岗位一般不会要求输出高保真设计稿，为了方便进行原型图设计、流程图设计、文档撰写和团队协作，可以使用Axure作为交互文档撰写工具。UI和UX设计岗位可能会输出高保真设计稿，因此没必要重复导入Axure进行撰写，通常使用哪款软件产出设计稿，就用哪款软件撰写交互文档，如Sketch，以便对高保真设计稿和交互文档进行修改。下面笔者将Axure作为交互文档撰写工具，讲解交互文档应该包含哪些内容，以及交互文档的撰写技巧和注意事项（交互文档素材由宛苏提供）。
报告、文档是否配备封面，可以间接反映撰写者的工作态度，交互文档也不例外。在对外交付时，为了让人一目了然，掌握文档的大致内容，交互文档封面通常包含产品Logo、产品名称、标题、版本号、负责人。
目录结构设计能够清晰地体现文档的层级关系和关键事项，不是简单地将功能流程的名称写上去。交互文档目录的命名规范为“编号-内容/功能描述（备注）”，其中“备注”是开放式填写的，可以描述新增和修改日期，也可以描述其他想表达的事项，如“1.1-公共模块（新增）”，如下图所示。
在实际工作中，经常会对设计方案进行新增、删除、修改等操作，更新日志主要用于为文档本身的迭代留下记录，如下图所示。一方面，可以方便团队中的设计师协作，使工作问题有追溯，帮助产品团队人员掌握迭代内容；另一方面，在该项目再次进行迭代时，可以一目了然地看清楚历史操作情况。
更新日志由更新日期、版本号、更新内容、更新原因、更新人和备注组成，为了提高更新日志的阅读体验，笔者在工作中有以下3个习惯。
· 将更新日期按倒序排列，即最近的更新日期排在最前面。
· 用不同的颜色或标签表示不同重要程度的更新内容，方便自己和他人对工作内容进行管理。
· 更新内容采用“目录+具体内容”的格式，具体内容一般细化到页面组件维度，并且在具体的更新内容区域用Axure设置一个点击热区，方便阅读者跳转到相应的目录。
评审记录有助于交互设计师管理交互设计评审会议中大家提出的建议和疑问点，对于交互设计评审会议中没时间详细讨论的问题，可以将其记录下来，然后在会后找到问题提出者进行沟通，尽可能地让交互方案满足产品、业务、用户三方面的需求。此外，交互设计师可以记录大家提出的问题和新发现的设计灵感，然后在交互设计评审会议后对这些问题进行评估，并且进行设计方案的迭代，从而为设计工作赋予长期生命力。评审记录可以提高交互文档的权威性，对交互设计师在项目推进上有一定的帮助。一般在正规团队的交互设计评审会议中，如果有重要的问题和决策，那么要先统一各相关人员的意见。被评审过的交互文档是已经获得认可的方案。评审记录由评审时间、评审模块、参会人员、问题收集、待议事项组成，如下图所示。
图例说明覆盖了整个交互文档中的内容，主要用于帮助使用者解读交互文档。交互文档不仅会在产品迭代中使用，还可能在产品竞标和讲标、方案汇报、对外交接等小众场景中使用。这些小众场景的使用者不一定是专业人员，可能并不清楚某个术语或某个手势的含义。为了使交互文档易于理解，通常会使用图例说明对交互文档中经常用到的专业术语、图例使用和交互手势进行解说，尽量把工作做细致、做专业。图例说明示例如下图所示。
设计背景是项目立项的开端，也是启动设计工作的起点，在不了解设计背景的情况下，所有设计工作的后续开展都会处于被动状态。设计背景是指产品价值和用户价值，即某个功能的开发能使产品获得怎样的成果，能为用户带来怎样的便捷或利益，交互设计师应该怎样为产品价值和用户价值赋能。笔者在工作中和产品经理就新功能展开讨论时，通常会先问“为什么做？”“对产品和用户的价值有哪些？”“使用场景是什么？”……
理论上，产品的设计背景应该在产品需求文档中进行详细描述，但在项目体量较小，并且没有完整的产品需求文档的情况下，需要主导项目设计工作的交互设计师将设计背景描述在交互文档中，方便与其他设计师交接任务或协作，有利于开发工程师快速了解项目。设计背景不一定在立项阶段立即完善，如果团队没有这方面的要求，那么交互设计师可以利用空余时间进行补充，作为项目复盘，为以后的设计汇报积累素材。设计背景示例如下图所示。
在交互文档中，设计分析的内容占比较小，却是交互设计师总体工作中的重要部分。交互设计师的实践性很强，其工作重点不是如何设计原型图，而是设计原型图前的想法，即为什么要这样做，设计目标是什么，分析思路是怎样的。
开展设计之前的思考、灵感，平时主动调研的用户需求、设计优化点，都可以放到设计分析的目录中，对外可以提高交互文档的说服力，帮助协作人员理解执行目标；对内可以帮助自己梳理设计思路。设计分析的局限性是很低的，可以利用通用的方法论进行分析，也可以采用平时的桌面研究、竞品研究等进行分析，不要求一定按照模板的框架填写内容。平时累积设计前的思考记录，有利于以后进行项目复盘。设计分析的维度不限于访谈记录、目标用户、痛点、需求分析、竞品分析、设计目标、执行策略、桌面研究等。
前面介绍过，结构图分为信息结构图和功能结构图。结构图在交互文档中起辅助作用，主要用于帮助使用者从鸟瞰视角评估有哪些功能和信息，以及在交互设计的前期确认产品要实现哪些功能、功能需要呈现哪些信息。结构图出现在交互文档中的什么位置取决于产品体量。对于体量大的产品，其功能模块和分支通常是复杂的，可以站在功能级视角绘制结构图。不同的功能模块有不同的功能结构。对于体量小的产品，可以站在产品级的视角绘制结构图。
在设计原型图前，一般先通过流程图梳理复杂的交互流程，帮助交互设计师对整个流程的闭环和容易遗漏的场景有一个全局把控。在正式设计原型图前，可以使用流程图与业务方、需求方确认大致的交互流程，降低工作成本。在确认好交互流程后，即可根据流程图设计原型图。
1.交互方案的组成
交互方案由页面标题、原型图、页面标注、交互说明、主流程线、跳转热区组成，是交互文档的核心内容，占比超过70%。一个主流程通常由单独的目录承载，如果主流程下存在分支流程，则使用二级目录承载。
页面标题： 每个页面的独立标题，不是页面导航栏的大标题。独立标题采用“页面编号-页面名称-页面状态”的格式，方便协作人员了解当前页面的状态和类型，如“01-首页-普通用户视角”“02-首页-VIP用户视角”“03-搜索-无历史记录-拼音键盘弹出时”等。
原型图： 具体的页面设计方案，在视觉样式上注意对比与对齐的运用，重点体现功能层级和功能状态。市场上有很多免费的原型图组件库，交互设计师为了将更多的时间用在设计思考上，通常会直接调用组件拼装原型图。
页面标注： 单个页面中组件或状态元素的编号，通常直接标注在页面上，或者使用Axure自带的元素说明功能（在选中元素后，在右侧工具栏的“说明”选项卡中填写交互说明）。如果需要对页面中的功能交互和状态进行说明，那么确保说明文案和页面标注的编号保持一致，方便查看。
交互说明： 对应页面标注的功能描述和交互描述，描述内容包括业务逻辑、规则限制、交互状态、触发方式、反馈事件、要求等。在交互说明中可以用红色标记重要的内容，避免协作者遗漏；对于一些常识性、重复性的说明，可以省略不写，避免大量文字堆积。
· 业务逻辑： 功能模块特定的业务描述和介绍，主要用于对复杂和特殊的模块进行说明，如判断条件、数据取值等，方便协作人员理解和在进行交互设计评审时自己讲解。
· 规则限制： 字段极限值、范围值、字段变化、排序规则等。例如，文字超出某行，支持单击将其展开，支持使用“...”将其截断，等等。
· 交互状态： 组件和字段的状态，包括默认状态、初始化状态、特殊状态、禁用状态及其和业务规则的联动关系。例如，对于“当报名人数≥100时，报名按钮呈现禁用状态，按钮标签文字为×××”，为了方便阅读，可以把真实的按钮样式放在文字下方展示。
· 触发方式： 一般针对需要特殊描述的触发方式和触发热区进行说明，如某触发热区同时支持单击、下滑、下扫等触发方式，如果没有说明清楚，那么开发工程师通常只会设置一种触发方式。
· 反馈事件： 描述操作后的反馈事件。例如，在点击禁用按钮后，弹出Toast、对话框等进行提示，或者跳转至某个页面。
· 要求： 不是交互说明的必填项，而是交互设计师的个人意愿，通常用于描述对视觉设计师和其他协作者的建议和注意事项等。交互设计师是设计方案的全局把控者，有权利、也有义务对上、下游的相关工作人员提出建议。例如，提醒视觉设计师下个迭代会增加该组件承载的内容，需要考虑UI样式的延展性。此外，可以标注页面中希望在首屏完全显示的内容，避免视觉设计师在出图时将关键内容隐藏。
主流程线： 表示页面之间跳转关系的线段，Axure自带线段连接工具，通常用于描述正向流程的跳转关系和需要特殊说明的逆向流程跳转关系，常规的流程（如点击左上角箭头返回上一页）一般不用刻意连线，否则画布中布满线段，非常影响阅读体验。此外，线段应尽量避免遮挡关键元素。
跳转热区： 如果原型图的跳转关系非常复杂且涉及的页面较多，使用主流程线表示跳转关系会显得复杂、不够直观，则可以结合跳转热区共同表示页面之间的跳转关系。跳转热区可以帮助交互设计师在评审、提案过程中向参会人员演示页面跳转效果。Axure自带的跳转热区元件能够高效地设置跳转目标和触发热区的范围。
2.交互说明的排版
好的排版能提高交互文档的易读性，差的排版可能会导致协作人员忽略关键的规则描述。下面总结3种实用的排版样式和1种负面案例。
（1）上下平铺
在画布中原型图较多的情况下，通常会采用上下平铺的排版样式，将上方区域留给原型图和主流程线，将交互说明放在相应的原型图下方，一个原型图对应一套交互说明，整齐排列，避免界面杂乱的情况，示例如下图所示。
（2）左右平铺
在画布中原型图较少的情况下，使用的主流程线较少，可以利用计算机的优势，采用左右平铺的排版样式，在左侧放原型图，在右侧放相应的交互说明，按从左至右的顺序浏览，比上下平铺的阅读体验舒适，示例如下图所示。
（3）表格式
在交互说明较多、逻辑维度较复杂的情况下，可以采用表格式的排版样式，通过表格对规则进行明确分类，提高复杂信息的易读性，示例如下页上图所示。
（4）动态跳转类
交互说明建议采用平铺描述，不建议将所有的说明都写在注释中，不利于交互说明的直观展示。在Axure的预览模式中，注释中的交互说明需要协作人员逐个点击才能看到，很容易造成功能点遗漏。此外，不要依赖动态跳转效果，因为哪些地方可以触发点击事件或许只有交互设计师知道，其他协作人员往往会忽略；而且在Axure中制作动态跳转效果需要调用各种事件和动态面板，会降低人效。但如果方案评审为了更直观地演示复杂逻辑的跳转关系，则可以采用动态跳转类排版样式，示例如下页下图所示。
全局通用说明是指在整个项目的设计方案中，能够不局限于某个场景，并且可以大面积复用的设计元素、组件和页面。在绘制设计方案时，经常会用到重复的元素、组件和页面，如果每个流程都将颗粒度画得很细，则会造成交互原型图的管理压力，所以统一管理、统一规范使用场景，不仅有利于保证设计方案的一致性，提高输出交互文档的效率，还可以帮助视觉设计师和前端开发工程师提前规划好通用的组件类型，使整个协作链在交互规划、UI产出、前端封装上达成一致。
全局通用说明最好边做边整理、不定期更新。在设计过程中，当发现某个组件或页面复用次数较多时，可以马上将其移动到全局通用说明中。如果在设计方案接近尾声时整理，则会产生重复工作量。全局通用说明主要包括常用组件、复用页面、空数据页面、异常页面。
常用组件： 系统中一切有复用价值的组件，如对话框、Toast、Loading等，示例如下图所示。
复用界面： 系统的功能流程中经常发生跳转的公共页面，如搜索页面、选择地址页面、选择联系人页面等，示例如下图所示。
空数据页面： 系统中所有的空页面均属于公共页面，可以统一设计、统一调用，并且间接帮助视觉设计师梳理所有空数据页面的类型，以便绘制不同类型的插图。在统计空数据页面时，可以说明使用场景和页面调用目录，使前端可以统一配置空数据页面。空数据页面包括数据为空的页面、未搜索到结果的页面、网络异常的页面、服务器异常的页面、内容被删除的页面、暂无权限的页面等，示例如下图所示。
异常页面： PC端存在由权限问题、域名有误、服务器问题等小概率事件导致的无法正常访问系统的场景，此时需要显示异常页面，告知用户当前的异常情况和处理方法。常见的异常页面包括403页面、404页面、500页面等。
信息规范： 有时为了兼顾信息的阅读体验，我们会对文字信息进行针对性设计，让信息在不同状态、不同场景中的呈现方式更便于用户解读。而信息的呈现方式需要交互设计师把控，并且在交互文档内清楚说明信息的变量规则。例如，常见的时间规则会按照今天、昨天、一周内、更早、跨年的维度显示，然后在此基础上细分时间段，帮助用户识别信息，如下图所示。此外，考虑到用户的记忆成本，我们通常把手机号的显示规则制定为“×××××××××××”，通过中间的空格字符将数字隔开。这些规则不仅要考虑界面的简洁程度，还应降低用户对信息的感知成本，通过场景细分的设计方式使信息更能触达用户的当前场景，方便用户记忆。信息规范通常在设计方案阶段就应该提前规划好，因为涉及前端与后端的取数逻辑，如果后面进行批量调整，则需要重新根据每个模块进行检索；并且有很多数据（如B类产品的数据）是用户录入或从后台导入的，如果后续规范信息显示规则，则会使用户的历史数据产生优化风险。
权限说明： 无论是C端产品还是B端产品，业务权限是非常重要的基础数据，如果本该限制的权限点，由于交互设计师的疏忽而没有限制，则会导致用户隐私受侵犯，以及因用户误操作导致信息丢失等情况。系统中不同角色的权限范围是不同的，C端产品一般分为普通用户、VIP用户、游客用户，B端产品一般分为超级管理员用户、管理员用户、普通用户。B端产品的用户还可以按角色进行分类，如销售经理、财务专员等，这些角色会涉及不同的功能权限、数据权限，交互设计师需要在交互文档中说明不同角色的权限。例如，在微信群中，群主和管理员有编辑群公告的权限，普通成员看不到“编辑”按钮；后台管理员有新增、删除、修改功能的权限，而普通用户只能使用新增功能，不能使用删除和修改功能；在协同办公系统中，普通员工无权限查看集团领导的手机号，而集团领导有权限查看全体员工的手机号和工作履历。为了将维度、分类、详细规则罗列清楚，权限说明一般采用正规的表格样式，示例如下图所示。
在实际工作中，经常需要调整设计方案，原因可能是需求变更、交互文档没通过等，但在调整设计方案（尤其是流程级、页面级的大调整）前需要准备相应的备份项，以便后续查看和使用。
1.理解需求在上，动手干活在下
很多新手交互设计师在接到需求后就立马开始输出交互文档，这样的交付效率很高，但是通常质量较低，需要返工。在实际工作中，笔者每天中的大部分时间都是在讨论和开会中度过的，真正动手干活的时间很短。尤其是业务属性强的B端产品，往往业务模块之间存在交叉重叠，可能改动一个地方会涉及很多场景，甚至理解业务逻辑都要花费很长时间。此外，如果产出物没有依附于产品业务及目标，那么做得再好看都没有意义。因此，交互设计师在接到需求后，需要多花时间和产品经理讨论，了解需求的背景及目标。例如，是要提高转化率，还是要提高活跃度；这个功能会涉及哪些延展和关联场景，等等。在完成这些工作后，首先绘制一些主流程的草图，然后与产品经理讨论设计层面的想法，最后针对主流程细化分支流程和交互细节，从而帮助交互设计师产出最贴近产品目标的设计方案，如下图所示。
2.不要过早抠设计细节，先把流程跑通
在输出交互原型图时，很多新手交互设计师容易过早地琢磨细节，如字号、字体、图标大小、栅格布局等。在原型图构思阶段纠结这些细节会把设计方向带偏，甚至影响交互设计评审的时间和质量。这个阶段的工作重点应该是把抽象的需求转化为具象的原型图，在设计稿中主要表达需求在界面中的交互逻辑，而不是黑白稿的UI样式。在通常情况下，输出原型图的顺序是主流程页面→分支流程页面→正常/异常/特殊状态→补全交互说明。
3.交互文档既要详细、规范，又要清晰、整洁
详细、规范的交互文档可以体现交互设计师的基本功。开发工程师及测试工程师会参照交互文档进行开发和验收，如果交互文档没有表达清楚交互逻辑和设计点，必然会提高团队的沟通难度。
清晰、整洁的交互文档可以降低团队上、下游相关工作人员的理解成本，基本的排版美观、信息层级分明是要考虑的，阅读也是一种体验。
4.尽量使用符合逻辑的真实数据
当描述页面中的文案时，杜绝使用与实际数据不相关的描述，有些前端文案的组织关系涉及后端算法和取值，很容易误导协作人员。此外，使用真实的业务数据可以让原型图更具代入感，降低不必要的沟通成本。
5.太长的文字说明没人愿意看，尽量使用图形化描述
交互文档作为传递信息的工具，交互设计师需要考虑读者的阅读体验，尽量避免使用太长的文字描述一个交互规则，如果必须要用大段文字描述，那么建议使用不同的颜色或字重突出关键字句，帮助读者快速捕捉重点信息。交互设计师应该具备信息归纳和提炼能力，如果无法用少量文字将交互规则描述清楚，则可以采用表格、图片与文字搭配的方式，或者直接贴上参考效果的链接或截图，从而精准且高效地传递设计想法。
下面来看一个例子，一段说明文字如下：
在用户点击评论入口后，判断用户是否登录，如果未登录，则弹出登录界面；如果已登录，则允许用户发表评论。在用户点击“发表”按钮后，判断用户今天是不是首次评论，如果是首次评论，那么发表评论并奖励10积分；如果不是首次评论，那么只发表评论。
对于上述富有逻辑性的交互说明，采用流程图的方式表达会更加清楚明了，如下图所示。
6.体现思考价值，提升设计流程的严谨性
笔者公众号的读者朋友曾提过一个现实问题：文档写得再好，开发工程师也不看，视觉设计师即使看了也有自己的设计想法。这种情况和交互文档的质量没有太大关系，和团队的协作机制、交互设计价值有直接关系。对于迭代资源比较紧张的中小型团队，设置独立的交互设计岗位，会延长上、下游相关工作人员的协作周期，在这种情况下要求他们按照交互文档进行细节化落地，确实有一定的难度。笔者之前工作过的产品线在迭代流程和UED工作流程中处于初始阶段，交互设计流程完全是从0到1推动的，经历过不少阻碍，同样面临过交互文档“写了没人看，看了不照做”的问题，笔者当时推动解决该问题的方法有以下3点。
（1）获取领导的支持，做设计宣贯，推动交互设计流程规范化
仅凭一人之力是无法顺利推动团队工作流程的，此时需要借助直接上级和业务负责人的帮助，与他们约定会议，专门阐述交互设计流程对产品的好处和价值，并且申请拿一条产品线的迭代周期做试点，如果试点结果性价比较高，那么以后的推动工作可以以此为鉴。如果连领导都无法支持你的想法，那么后面的工作开展就无从谈起了。在争取领导的支持后，与其他设计师一起准备交互设计推广材料，包括交互设计案例分享、为产品价值带来的帮助、为业务数据创造的增长等，然后组织产品团队和设计团队开宣贯会，并且在会议上逐一解答他们的疑问，传递领导支持的信号和准备启动新工作流程的实施步骤。
（2）创造交互设计价值，完善个人影响力，为产品团队和设计团队赋能
在争取到试点机会后，按照正常的交互设计流程开展迭代工作，如果之前由产品经理负责产出原型图，则基于他的原型图进行交互优化，产出正规的交互文档，并且主动挖掘遗漏场景和解决方案的可能性，帮助产品经理扩大功能设计的视野。对视觉设计师的协作通常体现在设计赋能上，正确引导视觉设计方向，在这个过程中产生争议是避免不了的，此时应该组织小范围的设计评审进行讨论。例如，为相关人员单独拉个讨论群，将交互设计的想法和价值阐述清楚，如果你的交互设计想法符合实际且有理有据，那么大家不会无缘无故地反对你。在协作过程中，不要抱着始终坚持设计方案的心态，应该怀着解决问题的心态，让上、下游的相关工作人员感受到，新的交互设计流程能为他们解决以往解决不了的问题，并且给团队带来了新的设计想法。在迭代完成后，主动组织一次设计复盘会议，放大设计成果，对交互设计思路、跟进过程、团队中发现的问题及改进方法进行总结，在上线后有数据支撑的效果更好。参会人员是本次迭代的相关人员、上层领导、业务负责人等。在复盘会议结束后，将复盘结果通过邮件同步给所有参会人员。
（3）增加向上沟通的频率，明确划分责任
在明确迭代流程和价值后，需要着重维护交互文档的权利。在产出交互文档后，组织大家进行交互设计评审，将交互文档传递给上、下游的相关工作人员，用于确定交互方案和细节。在交互设计评审会议结束后，可以继续完善交互文档，最好将本次评审的结果、会议纪要、开发评估结果和交互方案一起通过邮件同步给参会人员和领导，把好的结果和想法传递给领导，并且确定执行方案，然后按照该方案进行落地，避免在开始迭代后，开发工程师说细节实现不了，如果因为资源紧张实现不了。那么把该问题记录成文档，并且简单阐述落地价值，然后向直接上级或产品负责人说明该方案在本次迭代无法上线的原因和计划上线的时间。
解决问题的整个过程非常考验交互设计师的职场综合能力。在流程规范化后，交互文档“写了没人看，看了不照做”的问题自然就迎刃而解了。推动流程规范化的前提是产品团队有独立的交互设计岗位。设立独立的交互设计岗位，说明领导重视用户体验，希望有人聚焦改善用户体验的工作。如果由产品经理和视觉设计师共同完成交互设计工作，那么单独产出一份完整的交互文档确实不符合现实情况。此外，很多有一定规模的B端产品没有交互设计师位，只提供用户体验设计师岗位。由于产品特性的因素，因此需要产出高保真设计稿+交互说明，但丝毫不影响交互文档的撰写和阐述，只不过换了一种工具、形式罢了。