日常工作中的交互流程分析

交互设计师在现实产品设计流程中，如何积极地参与并完成设计工作呢？本文作者从项目开发流程和项目中的设计管理流程两个方面，对日常工作中的交互流程进行了总结分析，一起来看一下吧。

前文针对日常交互设计师的日常职责梳理，没看过的同学可以先看之前的文章。

职务细节梳理完之后，咱们对该干的事有了一个初步的了解，那我们如何在现实产品设计流程中积极地参与并完成设计工作呢？一起来看看吧~

01 项目开发流程

公司内部的项目基本上围绕产品展开，项目迭代周期可能因为不同公司的项目而有所不同，但是大体可以分为瀑布模式与敏捷开发模式。

1. 瀑布开发模式

瀑布模式一般在需求相对稳定的传统B端公司中应用广泛，这类项目研发周期长，有着严格的阶段管理，整个阶段呈现一个线性结构，即每个阶段必须有产出物后才能进入下一个阶段，因此该模式特别强调里程碑，重视文档的管理，每个角色只是不同阶段中的螺丝钉，大家只关心自己的业务。

2. 敏捷开发模式

然而在互联网环境下，软件需要在满足市场需求的基础上快速迭代，确保研发的节奏与交付的质量。

敏捷开发模式一定程度上满足了当下瞬息万变的市场需求。因为产品的最终目标是为了让客户满意，这就需要它具有灵活性，为了满足客户需求主动进行变更，适合需求不明确、创新性或者快速抢占市场的项目。

无论是敏捷开发或者瀑布开发模式，都存在各自的优缺点。我们多数团队采用两种模式的结合来进行研发管理，较多的就是每一周或者两周进行一次迭代，它的核心是减少每次迭代的颗粒度。该模式下先把客户最关心的模块交付或者上线，剩余的功能在实际的场景中快速迭代上线，如此循环保证整个项目组的工作效率。

02 项目中的设计管理流程

1. 项目启动阶段

基于对需求的理解，产品经理需要与技术人员一起参与业务调研，规划产品的功能范围以及与公司现有技术能力的融合，确保业务理解的一致性。完成调研后，产品经理会基于对业务的理解以及行业经验的沉淀，构思出相关的解决方案。这期间可能因为多方因素（客户、领导、竞品、同事、产品本身问题）的参与，会变动频繁需求。

为了掌握主动权，在项目启动阶段，我们设计师需要主动了解以下几点：

产品目标有哪些？
产品的紧急程度，需求的排期；
他们对新产品有哪些需求？当前产品他们在用时有什么困惑；
需求方的背景是什么样的背景？在什么样的场景下使用；
竞品是什么？产品有没有做相关的全链路大图？

启动初的业务会议特别重要，我们需要直接跟业务方或者产品提出参与。按照惯例一般该会议阶段很少邀请设计，这时候更需要我们的主动。

在该阶段，虽然有些专业名词可能并不是很清楚，但是在开始前期就进入的话可以对当前产品背景以及需求有着更多的理解。

2. 项目规划阶段

在规划阶段，产品需要根据需求，整理产品的信息架构图以及业务流程图，输出需求文档以及原型图（有时候没时间的话需要交互设计师输出原型图）。

该阶段主要针对当前产品所做的工作安排，会议上产品经理召集开发、测试、交互设计师等人员一起，官宣需求文档以及确定各模块排期。在这里产品会收集基于风险、难点和资源等方面建议，及早发现问题，最终确定并完善前端、设计、后端、测试的排期表格内容。

在需求评审会议上我们主要的工作是聆听，有关当下设计的困惑我们也不应该遮掩，需要当场询问，避免后续返工。在预估排期时，我们要准确预估设计的开始与结束周期（设计周期紧张需要在会上就提出来，让负责人协调整体进度或者增加人手），让工作更加有目标感。

3. 项目执行阶段

1）项目设计阶段

该阶段我们交互设计与后端开发并行开始，后端需要准备数据库、接口以及服务器环境，而我们也需要同步开始设计了。

围绕需求文档，有部分设计师可能会根据里面的功能描述，参考组内的设计规范直接把文档视觉化。但这可能不是我们职责所在，因为这种针对需求文档的直译只是产品对于当前业务逻辑的体现，并没有根据用户目标的权重进行重新构思。

面对产品的需求文档或者产品提供的原型页面，我们需要考虑2点：

当前的产品目标是什么？当前的方案是否满足目标的实现？
围绕当前需求，是否可以通过我们的设计来帮助业务更好的完成目标？

我们要做一个有思考能力的设计师，在了解设计目标后，可以通过用户的使用场景（把用户使用的过程描述出来）发现页面存在的问题，评价当前的设计是否合理。

这里有一个注意点就是当某一个体验流程已经让用户形成固定的思维或者行业以及有了相对应的行为习惯，我们则需要遵从当前设计，只做微体验的提升即可。毕竟B端的行业属性，用户通常会有一些行业特征（常用的操作步骤），如果我们只站在自身角度考虑，则会提升用户的使用成本（毕竟产品买过去他们是实际操作者）毕竟时间就是金钱，用户对效率有着极高的要求。

2）项目评审阶段

等设计的工作完成之后就要进入评审阶段，该阶段的主要目的是为了让各方围绕产品设计方案做充分交流，最终达成一致的意见。即使在评审会上大家分歧很大，也可以知道接下来我们要做的方向是什么（通过团队决策，降低产品风险）。为了让大家在评审之前明确评审目的，我们在发评审通知的时候可以把此次会议的几个目的列出来，这样在把控评审会议的时候目标感更强。

评审会阶段特别重要，因为其他团队可能并不清楚设计的成因，所以它也是我们设计获得团队信任的阶段，在这里我们可以把自己的设计思路与思考表达出来，这样就知道了当前的设计思路与业务目标之间的关系，从而有利于团队建立对设计方案的依赖。

3）开发测试阶段

设计稿完成评审之后就可以进入前端开发阶段，等前后端一起过一遍整体流程后就可以通过邮件进行提测了。

测试人员根据测试用例（产品需求文档）测试完成后由产品经理验收。对于测试而言，该阶段的验收标准就是产品的是否正常使用，各功能逻辑是不是按照需求文档一一实现的，有没有严重的bug，若有问题则需要在上线前提出解决。

这一步也需要我们交互设计师参与，确保上线后产品的交互逻辑是否与设计稿保持一致，毕竟当用户实际场景中用的不爽，这个锅还得是设计师的责任，所以交互验收也是保证设计真正能落地的重要一步。设计走查后需要输出走查清单，确保开发可以按照清单内容逐一修复。

所有的bug改完之会叫产品来进行最终的验收，这是整体走查的最后一步了，此时产品会把全流程在走一遍，是否符合预期，无误后打包上线。