你是否曾经遇到这样的问题：换了一家公司，不知道该怎么融入团队开展工作？本文作者结合自身的经历，分析他是如何快速进入业务状态开展工作的，希望能给你带来一些帮助。
经常在设计群潜水的时候，都会碰到有小伙伴问相同的问题：换了一家公司，如何融入团队开展工作？刚好最近自己也是换了一个平台搬砖，所以想结合这段时间自身的经历，来跟大家聊聊，作为交互设计师，我是如何快速进入业务状态开展工作的。
为什么强调“快速”，是因为对于一个职场老鸟来说，公司招你的目的不是花时间培养你，而是来救火的。如果不能快速进入业务状态，就会招来周围同事的质疑，尤其是对于像交互这种“可有可无”的职位而言。所以，如何在新的环境中快速融入，快速产出就显得尤其重要了。
由于公司之前没有交互设计师的岗位，所以当我进入到团队中时，首先主动了解的是在没有这个角色之前，团队是如何运转的，以及遇到了哪些阻力。这样我才能找到当前团队协作的问题，并通过这个岗位的优势去解决，从而凸显自身的价值。
在通过与产品、技术、设计等部门同事的简单沟通后，归纳出如下两个问题：
在跟旁边的技术同事沟通得知，由于之前没有清晰的交互流程产出，只有产品出的简单的线框图，导致大部分交互流程靠开发想象，再加上产品的线框图是通过生成axure云端链接的形式存放，经常会出现打不开、找不到的情况。产品就通过口述的方式进行流程的宣讲，从而导致的结果就是开发出来的与产品的预期偏差太大。
而针对这些现状，结合之前的工作经验提出了两点优化建议与方向。
1）统一团队协作工具与项目文件
当前技术同事在开发的时候，需要不断切换链接去看对应的产品需求、交互流程、设计稿，不仅繁琐，经常也会出现由于项目文件命名不同对应不上的情况。所以在我的建议下，开始使用同一个软件来承载这些文档，同时将相同项目的文件采用统一的命名规则，从而提升技术同事查找相关文档的效率。
2）规范交互文档的内容输出
之前交互流程的产出由产品兼任，由于没有那么多时间考虑页面细节，就会导致部分页面流程的缺失。所以在我加入以后，针对当前团队的特点，优化了之前的交互文档的结构，同时与产品协同产出，将业务规则与交互说明落到对应的页面上来，进一步提升技术同事的开发效率与准确度。
需求变更往往是导致项目不能按时交付的主要因素，在与产品经理沟通中得知，导致这个问题的主要因素是开发出的页面流程与前期需求沟通的时候不一致，所以如何确保需求准确的传达给技术跟设计同事，对此我将整个链路拆解出了四个阶段，即：需求评审、交互评审、页面与流程宣讲、实现跟进。
1）需求评审
需求评审是之前团队已有的流程，但是之前评审需求时，每个角色都有自己的想法，由于没有将需求做页面化的呈现，导致直接将不确定的需求给到设计以后，设计开发出的需求不符合前期规划的预期效果，就会带来返工。
而在我加入以后，在进行需求评审的同时，我会主动去归纳此次需求范围层的内容，并快速生成可视化的效果，展现产品与功能雏形。这样做的目的是能让各个角色根据当前的信息架构来判断是否是大家达成一致的效果与流程，减少因需求不明确而带来的返工。
2）交互评审
交互评审，是我加入以后主动去推动的流程。一般是在产出整个功能所有页面的信息架构跟流程后进行，主要目的是拉齐需求方看看整个功能用户的操作链路是否满足前期讨论的需求。而且在这个阶段也可以避免一些因交互形式的改动而带来的开发工作量的增加，从而导致项目延期的风险。
3）页面与流程宣讲
页面与流程宣讲，是在我补充整个页面与流程的交互文档后进行，主要目的是面向负责此次项目的设计与开发同事，通过同步此次方案的背景、迭代的内容、用户交互的页面流程与规则、需要获得哪些数据、设计注意事项等内容，来减少开发设计过程中因前期功能不熟悉而带来的理解偏差。
4）实现跟进
实现跟进，主要跟进设计阶段与开发阶段。设计中，要时刻看看设计进度以及是否很好的表达出了原型中的信息层级，而开发阶段主要是对于一些极端情况做出解释与定义，防止模凌两可的状态导致流程的不通畅，同时在测试结束后还要做一轮验收，主要查看功能是否完善，极端情况是否考虑周全等。
当我加入到团队后，就立马接手了需求,其实这么迅速的投入到工实际项目中是不太利于方案的产出的，因为在不了解业务背景的情况下，很容易陷入“我以为”的状态。所以在做这个紧急任务的同时，我也在利用有限的时间去完成如下三件事情，帮助自己更好的开展后续的工作。
1）了解产品商业模式
交互设计师不是一味的站在用户的角度去考虑问题的。产品体验设计的再好，如果不能带来公司效益的增长，也会无济于事的。所以主动了解公司的产品商业模式，不仅能很好的在产出方案的时候平衡商业与体验，同时也能在主动推进产品体验优化的时候更好的选择合适的方向。
2）体验产品流程
体验产品流程是一种很好的方式，来帮助自己快速熟悉产品。通过对每个模块，每个流程的拆解，不仅能知道该功能设计的目的，同时也能知道当前的流程存在哪些问题以及可优化的方向，为自己建立整个产品的功能架构图提供了很好的帮助。
3）获取产品节奏
产品在不同的阶段，需要解决的问题都有所不同，获取产品的节奏能更好的明确后续的工作重心与方向。
举个例子：当我加入到团队以后，在跟上一级的沟通中了解到了现在产品的商业模式，于是我就开始针对产品几个能影响到用户增长与订单转化的流程着重体验，找出优化的方向，比如注册登录流程。因为不同于常规C端的注册登录，当前产品需要用户注册后开通会员才能正常查看内容，该链路的体验好坏决定了产品的付费用户数量，所以我觉得对于产品是至关重要的。
但是在我进一步跟上一级的沟通中得知，产品当前的存量用户还可以，而且大部分的新用户并非通过app主动注册的形式产生，所以产品的注册登录流程并不是现在最主要的，而是在于结合产品运营，如何让现在的存量用户活跃起来。所以在获得了产品的节奏后，我重新调整了对产品的体验优化的方向。
切换视角对于交互设计师而言尤为重要，因为这个岗位的价值就是为用户设计合适的操作路径，从而达到“降本增效”的目的。在产出方案的过程中，越多的站在用户的视角，意味着产出的交互流程越接近用户的使用预期。
在我加入团队没多久，就接到了一个内部OA系统的交互需求，该需求产品经理已经在前期做了简单的功能设计，但是由于没有设计用户的操作路径，所以需要我这边来进行补充与协助。我就以这个为例，来拆解一下在做交互需求时，我是如何站在用户的角度去思考与设计的。
公司的oa系统主要是用来维护核心用户，根据用户的属性不同做分层运营。新需求是需要增加一个“记需求”的功能，用来记录用户的诉求，从而方便后续的跟进。已有的线框图如下：
接到这个需求后，我并没有急于去做后面的交互流程补充，而是通过跟目标用户的交流，了解了他们使用这个功能的场景，再切换自己的视角，试图站在用户的角度，来重新审视现在的交互行为的合理性。
第一个交互行为是用户查看记录好的需求。当前的设计是放在用户列表的顶部，并以卡片切换的形式查看。此交互形式虽然能提高需求的重要层级，方便用户查看，但是对于需求的数量有要求，如果相同重要层级的需求过多，采用这种形式展示就会增加用户的操作成本，那该如何优化呢？
通过对用户使用场景的调研，明确该操作是目标用户的常用操作，且需求量会很多。针对常用操作，要做的就是减少用户的操作路径，方便用户触达。所以选择了跟客户列表用tab切换的形式展示；而针对数量多的特性，信息列表无疑是很好的选择，能承载更多的内容，同时也能让tab切换后的页面形式保持一致。
接着我们就需要根据当前的交互形式，对场景跟目标用户的需求做进一步的拆解。信息列表虽然能承载更多的信息，但是内容一多，查找起来就会很困难，如何让用户找到一个或者一类需求呢？我就继续补充了该信息列表的搜索跟筛选功能，通过搜索能定位到具体的需求，同时为了提升搜索效率，增加了关键词联想的交互规则；
而筛选是将同一特质的需求摘取出来，那如何定义需求有哪些特质呢？我通过功能的目的进行拆解，该功能是记录需求方便后续的跟进，根据跟进的目的以及用户的使用场景，定了需求的筛选维度：时间、重要程度 。然后为了让整个操作形成闭环，在用户记录需求的时候也增加了自动获取时间以及让用户定义重要程度的功能。
第二个交互行为在于用户记录需求，原始的线框图是以选择项的形式让用户操作，但是为了能尽量覆盖大部分客户的需求，设置了不同维度不同层级的选择项，这就会导致一个问题，增加了用户记录需求的时间，那该如何进行优化呢？
在与目标用户的沟通中发现，他们一般记需求是发生在打电话跟客户沟通的时候，而需求的内容往往不固定，之前的方式是采用手写的方式记录。结合使用场景与用户习惯，将之前选择的交互改成文本输入，同时为了进一步提升用户记录需求的效率，在用户进入记需求的面板时，直接唤起键盘，方便用户直接输入。
设计师往往自我定义为“执行者”，尤其是刚进入新的团队，在人生地不熟的时候更不敢发声，但是衡量一个设计师的专业性，不仅仅体现在他的产出物，还要看看他对于过程的思考与论证，而这些都是要表达出来的。
在我加入新的团队产出交互方案后，就主动推进交互评审的进度，拉齐其他部门进行整个方案的宣讲，指出之前流程可能成为用户操作阻力的地方，以及自己整个的改版方向与目的，为什么最终选择了这个交互方案，最后还对自己的方案定义了考察的指标，方便后续对于方案效果的跟进。也正是敢于将这些内容说出来，才得以迅速的在团队建立良好的口碑。
以上，就是笔者根据最近的经历，分享的一篇关于如何快速进入业务状态的文章。后续也会继续分享自己在实际工作中，关于产品交互的心得与感想。经验有限，欢迎大家批评指正与交流。
本文由@背包流浪 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。